General

Agile from the Professional Services Perspective

Posted on by holnor

IMG_2574

Recently I was asked whether Agile is a viable proposition for Professional Service Organisations (PSO) to use in the management of projects? If so, what factors need to be taken into account?

Before answering this, it’s important to note that while Agile is a framework for Software Delivery, it is not a project managment methodology. This is a common misunderstanding. It is crucial to understand this when dealing with multi-discipline and multi-team projects.

In Scrum, (an Agile approach) an ideal team is made up of between 6 and 8 co-located members, all focused on the delivery of a product. If that product is independent of all other products then Agile is sufficiently structured to act as a quasi project management methodology. However, for all other types of project it is insufficient. Agile ignores all of those project management tasks required to ensure each team is working in a manner that supports and facilitates the work of the other dependent teams. It also ignores all those activities such as business case development, status reporting and change management that, while not delivery tasks per se, can be the difference between project success and failure.

That said, it is still true that from the perspective of a PSO Agile is the optimal mode of solution delivery. It allows for certainty in the engagement; as the customer is actively involved on a daily basis. It significantly reduces the gaps in engagement. For example, where the solution is handed over for UAT and the team waits for feedback before being able to finish. This in turn allows for greater resource utilisation and this means each project is potentially more profitable.

So why don’t all PSO’s use Agile all the time? Simple – often the customer can’t or won’t commit to the level of engagement required. You know the story, the key people needed to make decisions and sign off on the solution all have day jobs which prevent them from being available when they need to be. This means that the project stalls, or worse yet, takes the wrong direction when working on an ambiguous requirement. This is the typical scenario when dealing with smaller customers in particular.

An additional complication to the above comes with the customer’s lack of an internal IT function. Why is this a problem? Well, it prevents a project being truly Agile, as they will not have the capacity to automate the delivery of the solution into production (i.e. continuous integration/continuous delivery – CICD). CICD is a mandatory element of Agile projects which is often overlooked. Furthermore, if you don’t do it, then you aren’t truly Agile.

The PSO can set up CICD to deliver into an interim environment (usually a test environment); then manually release into production. This is a hybrid solution that will allow development to continue while the customer tests what has been delivered. Of course, in smaller projects the CICD overhead just isn’t worth it, as end to end the project is only going to be 1 or 2 sprints in duration (2-8 weeks). That is unless the customer wants to become Agile. In that case, setting up the automation mechanism becomes a proejct in its own right.

One other obstacle for a PSO using Agile to deliver a project is the contract itself. Many customers will view the initial statement of work as being a fixed price, no matter how you word it. The result is a rigidity in the project that prevents the team reacting to change in the way that Agile promotes. The change process has to be formal out of necessity for the PSO. It is the only way that a PSO can hold the customer to account for spurious changes, delays and the resulting cost overruns.

 

 

Agile in Mixed/Outsourced Environments

Posted on by holnor

IMG_2312

In 2011 I wrote a dissertation on Agile and outsourcing. After analysing all of the data I had collected along side that publicly available from various sources including Microsoft, Ambysoft (http://www.ambysoft.com/surveys/) and The Agile Alliance the only conclusion I could reach is that Agile and Outsourcing were incompatible. The fundamental obstacle was the contract between the vendor and the client.

Things have come a long way since then and it is possible to run projects in an agile manner. But only if the client understands the level of commitment required on their part. Having been on both sides of the contract I am finding that there is still a disconnect here. Often the expectation is that an Agile project can be run with the same level of customer engagement as a project run under a waterfall methodology, with a greater degree of success.

I exclude body shop engagements from the above as in those cases the reality is that the customer isn’t paying for the delivery of a project they are paying for the use of a specific type of resource/expertise.

So when are outsourced Agile projects successful? When the vendor is responsible for the delivery of the solution and has full commitment from the customer to be available at the agreed level. It all lies in the structure of the contract. The contract needs to be balanced and clear about the responsibilities of both parties and state the consequences from a delivery perspective if any of those responsibilities are not met.

Agile also does not work under a fixed price contract as the core tenet of Agile is the ability to deal with change. and fixed price is the antithesis of change.

Failure to acknowledge any of this is a recipe for disaster.

 

 

Embracing Creative Destruction to Get Ahead

Posted on by holnor

IMG_3023.jpg

In this recent post by Rohan Rajiv are some novel insights into what traditional companies need to do to get ahead of their rivals. While his focus is on the technology sector and how to compete against the big tech companies the lessons are valid for all. In particular the idea that the innovation curve is no longer contiguous.

The idea that innovation has jumped ahead and that there is a chasm between the market leaders and the traditionally solid performers should resonate no matter what industry you are in. It is just more evident in technology.

So, how does Rohan suggest that this chasm be bridged? By accepting that many of the tried and tested ideas that have made us reasonably sucessful will no longer to continue to bring success. Once this is understood it is easier to identify novel ways of challenging the status quo. Not all of them will work but those that do will accelerate business success. If a company takes a learn fast approach (see my earlier post for more on this idea) then the ideas that don’t work will encourage a culture of entreprenuerism within the company that will further accelerate success.

Over the years I have worked with a number of non-tech companies on transformation projects. The most successful of thes have seen the internal conversations revolove around how to manage the transition away from the traditional business model (e.g. we sell data products) to a new paradigm where the company is selling a technology based and data driven partnership with the customer.

Rohan’s over arching theme of “creative destruction” is one that the top tech firms have embraced wholeheartedly. For example Microsoft have stopped being Windows centric in the development of its productivity suite with updates oten being provided to other plattforms (iOS in particular) first. The idea is that they want a piece of every device out there. This is a variation of what Amazon has done with it’s market place. They want a piece of every online transaction and don’t care if they sell the product or someone else does.

Applying creative destruction in our professional and personal lives is not something that comes easy. However, if we are realistic, the days of a person holding a job for life are long gone and  there will be times in which it is essential for us to reinvent ourselves in order to stay relevant within constantly evolving industries.

A classic example of this is traditional manufacturing in western countries. Repetitive low skill jobs are either been performed by robots or have been moved off shore to countries with cheaper labour rates. The remaining manufacturing jobs are high tech and higly skilled. The result is a significant jump in unemployment while people retrain or find alternative low paid work (if it exists).

So no matter who we are and what we do, unless we embrace change we will find it increasingly difficult to keep up. Or as Rohan sums up “what got us here won’t get us there.”

 

Communication – a lesson I learned in Starbucks of all places

Posted on by holnor

Sitting I Starbucks a Saturday or so ago having a quiet coffee and reading the paper. It was the last place I was expecting to learn this lesson. A group of 6 young kids (ages ranging from about 4 to 6) and their mothers came in to the store, pushing and shoving and generally having fun as kids do. The striking thing about this group though is that every single person had a hearing impairment including the adults.

The thing that struck me was that if they wanted to “talk” to someone they had to establish eye contact. Because of this everyone paid attention to each other and the conversations were clear and concise. There were no misunderstandings in regard to what was expected, what each of them wanted or indeed how they felt.

In this day and age where communication is becoming more and more remote with less and less face to face interaction it made me sit up and take notice. I’ve lost count of the times over the last 6 months where email or IM communications have spiralled out of control over a subject or situation that could have, should have and ultimately were resolved by having a 5 minute face to face conversation.

There is a clarity of purpose and intent that can be conveyed in a look or the tone of the voice that is absent in written material. Without this the effort needed to gain the same clarity goes up exponentially with the complexity of the subject.

So next time you find yourself on your third email explanation of something “simple” maybe it’s time to pick up the phone, or better yet get up and go talk to them?

The Trouble with Metrics

Posted on by holnor

Over the years I have worked on a number of back office system projects. Typically they projects are aimed at delivering either cost savings or performance improvements (or optimistically both). Naturally management are eager to monitor and calculate how much of each is achieved. To that end they look to set up a number of measurements that will show the level of uptake, throughput, cost per unit etc.

When the system is designed to make it easier for someone to do their job you would expect that their productivity would increase… Makes sense right? But it’s not alway the case. For example implementing a system that makes it easier for a sales rep to capture the client details, record conversations and track follow up actions will only increase the productivity of the rep if their job doesn’t require them to meet the client face to face. It would be pointless therefore trying to measure the benefit of the new system and the performance of the rep on the basis of the number of phone calls the rep makes each day. If you do then the result of that will be to encourage sales reps to sit at a desk and make phone calls. Not a good result when what you really want from them is to be generating new sales and building relationships with clients so that they become repeat customers.

Therein likes the problem with metrics… Get them right and they will be able to tell you a story of how your business is performing, identify areas for improvement and highlight those activities that are contributing to good performance. Get them wrong and they have the unintended consequence of influencing peoples behaviour toward irrelevant tasks that should not be their focus.

A classic example of this is the UK government target that no patient should wait more than 2 days to see a doctor. The result… When you ring up to make an appointment many doctors won’t allow you to make an appointment that is more than 2 days in the future as it will distort their statistics. Additionally if there are no appointments available you have to ring back the next day in order to make an appointment for 2 days in the future (rinse and repeat until you get in early enough to beat the rush). They do this as the government is not interested in how many people are unable to make an appointment on their first, second, third (or more) attempt. But I’m almost certain this was not the behaviour that the government was trying to encourage. It’s just the unintended consequence of a poorly thought out and defined metric.

So when determining what metrics should be used to measure performance, you must determine (either for yourself or your client/customer):

  1. is the metric relevant (to the job and/or system)
  2. what behaviour is use of the metric likely to encourage (and is that what you want to happen)
  3. is the information the metric conveys actionable
  4. what are you going to do with the information

If the answer to any of the above is negative then it’s probably not the right metric to be using. On the bright side though, being able to identify this will make you look good and help avoid some of the post implementation pitfalls that beset many projects.

BYOD – Just the tablet/smartphone or should it be something more

Posted on by holnor

With all the talk and hype around BYOD(Bring Your Own Device) the focus is squarely on the hardware and primarily tablet and smart phones. But what about other devices, a mouse, keyboard, a laptop or indeed the software that you need or use to make yourself more productive? Is it the responsibility of your employer to provide it? Or do you like to use your own?

Personally I like my employer to provide the basics, a desk, chair, phone and laptop (if they have a locked down environment) with the essential productivity tools of the PM trade (Word, Excel, PowerPoint and Project) and Email. Beyond that all I ask is that they allow or facilitate the installation of other tools that I have a valid licence for or an open source equivalent.

This comes from a lesson learned way back when I was a junior code monkey (thats a programmer for those of you that aren’t from an IT background). I worked with a contractor who seemed to be able to do things in hours that would take the rest of us days or even weeks. I cornered him at a post release celebration one night and asked him how he did it. His tip… If you know of something out there that will make you more productive use it. it doesn’t matter if its a better mouse, keyboard or a piece of utility software. Even if you have to pay for it yourself it’s worth it in the long run. Think of them like a builder thinks of his tools. A good tradesman will use the best tools he can afford as that allows him to work quickly and efficiently, maximising the amount of work he can do and therefore money he can earn. Would you want a builder to use the cheapest tools he can find? Or would you prefer that he use precision tools that are robust and reliable? Having a retired builder for a father I knew he was right.

Since then I have built up a software library that I look to leverage to what ever extent my employer/ client will permit. Some have an aversion to the use of 3rd party tools in their development or to installing open source software within their environment. But thanks to the BYOD phenomena, these days more and more are opening up to the idea and realising that productivity is what’s matters most.

These days my productivity kit bag includes an iPad, mouse, phone, various portable storage devices and cloud based services such as Office 365 and GoTo Meeting. This kit is evolving and as I find new, better and (sometimes) cheaper ways to do things I will replace the older less productive tools. This may be a mindset difference between the contractor and the permanent employee but I truly believe that I have a responsibility to my employer to be as productive as possible.

So far this is a philosophy that has has served me well with every contract being extended past the initial engagement.

Control the Conversation – really?!

Posted on by holnor

A colleague I met recently at a conference has an interesting take on how to get what you need out of a conversation while acknowledging that you can’t actually control the conversation. Why can’t you control a conversation? Well it comes down to the obvious really… For it to be a conversation it has to be a two way dialogue otherwise it’s just a set of instructions being delivered to the other person. Engagement is crucial.

But to get what you need you can start with 5 simple steps:

  1. Determine what success looks like.
  2. Think how you might get there and who can help.
  3. Create an environment that will enable and accelerate the process.
  4. Decide how to behave.
  5. Take a deep breath and say, “Hello”.

Be sure to include a healthy dose of respect for the other opinions that come through in the conversation as you might really learn something out of them.

You can find the full post here