This is the first in a series on agile incentives. In it I will take a number of key roles within an organisation, outline the high-level incentives that person has, and then discuss how the adoption of agile aligns with those incentives.
Today I’m going to start right at the ‘top’ of the organisation: the Chief Executive Officer (CEO).
When thinking about incentives, I’m guided by a fascinating book (and Podcast) I came across recently. The book is The Elephant in the Brain: Hidden Motives in Everyday Life by Robin Hanson and the Podcast is Conversations with Tyler, where Robin discussed his book with Tyler Cowen. Robin’s central thesis is that over 90% of human behaviour is driven by signalling: People say and do things not because they are wise or foolish but because they are trying to project a particular persona to other people. Having observed (and been puzzled by) human behaviour in organisations for a number of years, this argument certainly makes a lot of sense to me. The podcast also contains one of the best explanations of why people fail adequately to do risk management within projects that I have ever heard but that’s a topic for another blog post.
CEO Incentives
Even if you are sceptical of the signalling argument in general, you must surely accept that a lot of the job of a CEO is about signalling. One person can’t possibly stand over hundreds, thousands or even tens of thousands of people and direct them to do the right thing minute by minute. Somehow they have to project their personality across an organisation. In the vast majority of cases they will not even meet most of the employees. Equally, they have to be able to instil confidence in the owners and investors. They have to be able to convince them that they are in control of the destiny of the company. It was said of Steve Jobs that he had a “reality distortion field” – all CEO’s have to have this to some extent.
The key incentives for a CEO are:
- Answer to the board, and to the owners (shareholders, family members, etc)
- Show that they recognise the big problems/opportunities that face the business, and that they have big solutions to match
- Show that they know what is going on (that is, they know when things are going well and when things are going wrong)
- Be seen to take decisive actions when things are going wrong.
- Be seen to be “modern”, “forward looking”, “innovative”.
To see how the adoption of agile matches up with these incentives, I’m going to cover three scenarios:
- Enhancing an existing system
- Replacing an outdated system (Includes automating a manual system)
- Creating a new product
Before I do that, let’s tick the “modern” and “innovative” box. Even though Agile has been around for over 20 years now – I’ve been doing it since the mid-noughties – it’s still seen as modern and innovative in many industries. The adoption of agile will certainly signal that the CEO is with it as far as modern product development practices go.
Moving on…
Enhancing an existing system
In this scenario there is an existing system that needs to be improved. It could be a physical system, like a manufacturing line in a factory, or it could be a software system. The key here is that there are already people using the system and any disruption to the working of the system must be minimised as it will cost money.
Motivations for adopting agile:
- Deliver enhancements more frequently
- Being able to better tell which enhancements are valuable
- Spreading out your disruption: rather than replacing one working system with a completely new one, with massive risk of failure, you have lots of small, low-risk disruption, as people get used to the system changing gradually over time.
So how might the adoption of agile align with the incentives of the CEO? I’ve come up with the following, not necessarily exhaustive, list
- Be able to “solve” the problem of “not enough enhancements” (even though they are not necessarily delivering more enhancements, just more frequently)
- Easy to show whether enhancements are being delivered more frequently
- The Board will be able to see that enhancements are being delivered more frequently
- If you can deliver at the level of a single feature (known as Continuous Deployment) then it’s easy to see whether a feature works
- The risk of catastrophic failure, though still there, is small. Any failed changes are easy to back out.
- It’s easy to set targets (for numbers of enhancements delivered, if not for value); If the team is not hitting targets, the CEO can fire the head of department, the team manager, or the entire team
Broadly, the incentives of the CEO are aligned with agile, and any actions the CEO takes to fix things, although they may not help, won’t undermine the strategic basis for agile. Getting rid of people when agile isn’t working may not be the best thing to do, but it doesn’t lead to the abandonment of agile
Replacing an outdated system/automating a manual system.
It’s very difficult to conceive of these kind of projects (for this is what they are) as anything other than fixed price/fixed duration projects. Since the resources you can apply to a project tend to have a sweet spot (I don’t know what the optimal number of people needed to build a family house is (a dozen maybe?) but I bet a team of 100 wouldn’t be efficient or cost effective), then this type of project tends to boil down to one of two outcomes: either you can deliver the project within the desired timescale, or you can’t.
An incremental approach that you might use in the new product situation will be very difficult to implement here as the people who use the existing system may have very little time or patience for you while you try out stuff that might or might not work. In addition, it may just not be possible to break off chunks of the existing system and replace them with bits of the new system. Imagine you’re a car manufacturer moving from production of petrol and diesel burning vehicles to battery-powered ones. It probably just isn’t feasible to incrementally change the production line (including the supply chain) from one to the other. Far easier to build a new line and then decommission the old one at your leisure.
The best that you can do in terms of agile is build the new system incrementally, with lots of show and tell to get feedback from the eventual users of the new system. The key benefit of this approach is that you get a very early warning sign when things are going wrong. I would argue, however that things are not really going wrong – the agile approach will tell you what you should have known all along, that you’re not going to deliver on time.
In this scenario Agile matches the CEO’s incentives, in that they will know very quickly whether something is not going to deliver on time, much more quickly than using traditional approaches. The problem is that, knowing that the project is going to be late, the CEO has now to be seen to be taking action. Given that it’s going to be difficult to get the scope reduced, the action becomes getting the team, somehow, to commit to the original date. There is scope for all sorts of undesirable behaviour here which are not particularly related to agile. For a comprehensive list bad ways to react to “late” projects see Steve McConnell’s Classic Mistakes Enumerated.
Creating a new product
Here I’m talking about either a new product being developed by an existing organisation or a new organisation that has been formed specifically to develop a new product.
Here the motivations for adopting an agile approach are:
- You have no idea whether the product overall will be successful, and which features of the product the users will find the most valuable. Agile helps you to get version one of the product to market, with a minimum set of features (the so-called Minimum Viable Product or MVP) as quickly and as cheaply as possible
- Once the product is out there in people’s hands, you can get feedback which can shape the future direction of the product or even change that direction entirely (this is known as a ‘pivot’)
In this case, there’s a really good alignment between agile and the CEO’s incentives. They will get a product to market quickly, thus impressing the board and investors. They maximise their chance of the product being successful (people sometimes worry about releasing a product ‘too early’ but I think this is overblown – people (myself included) forget that the first version of the iPhone didn’t have the App Store, wasn’t 3G and didn’t even have copy and paste and that went on to make Apple the biggest company in the world). If the product turns out not to have a market they can pull the plug without wasting too much money, thereby being ‘decisive’.
Conclusions
So what can we say about how well agile adoption matches CEO incentives? Firstly, it’s clear that agile is a very good approach for new product development (the startup scenario) where there’s a lot of uncertainty about the shape of the solution or even whether there is enough value there to make the problem worth solving. From the CEO’s point of view, the ability to get a product to market faster and get a flow of information about the value being created makes it a lot easier for them to show that they are on top of things.
Assuming you’re doing development in good faith, the information that you get from releasing increments of stuff frequently has real value, no matter what you’re using agile for. Of course, it is possible that the CEO knows up front that the new development will not succeed, perhaps because their business is so far behind the curve that they can’t possibly catch up. In that case, a better strategy might be to opt a traditional methodology, pretend everything is going fine, and keep drawing a pay check until it becomes obvious to everyone that the company is doomed. I’m sure that no CEO ever does that.
There’s no doubt that, as an investor, I’d be far more likely to put my savings into something that was going to start producing revenue after 6 months than one where I had to wait for 3 years to see a return. I’d also tend to ask fewer awkward questions of a CEO that was able to show me working product every month than one that was asking me to put my faith in tasks ticked off on a big Gantt chart.
The big question is, once you’ve gone to the trouble of generating that information, what do you do with it? I guess that as a CEO, it depends on what you want to signal. Do you want to signal command and control or that you can grow the capabilities of your team? I have found that the hardest thing when leading teams is to watch them make mistakes and to decide that the learning they will gain from making the mistake is more valuable than what you would save from putting them right. It takes real bravery to do that but it’s a very powerful signal.