We have been looking at executive coaching and what sorts of conversations we can have with them as coaches. So far we have looked at resource management and financial control.  Continuing on our theme,  I'll be looking at the next burning question execs tend to have -  "How do I ensure good ROI in an agile environment?"

ROI is a term that frightens non financial folks but what it boils down to is "am I getting good value for my money?" Is the money I am spending giving me enough benefit to justify spending it? In a traditional organisation, ROI is managed through the business case and estimation processes. The business case will set out a number of benefits and the estimation process will work out how much it  will cost to deliver those benefits. In an agile environment, we don't go through those processes.  We don't do detailed up front estimates.  So how does the person in charge -  the person whose money we are spending - make sure they are getting good value?

The key thing here is that we do go through estimation processes, they just look a bit different to the ones they are used to. Agile estimation through measures like story points or feature points , or through a mechanism like right sizing, give a very accurate and lightweight mechanism for working out how big something is. Add this to the concept we covered last time of having stable, and long lived delivery teams with essentially a fixed monthly cost, and and you have a very accurate picture of both size and cost, and exactly what you want to have in order to make an ROI decision.

Couple that with some nice metrics around cycle time to see accurately when things will be delivered, add in some thinking about cost of delay and you have a very powerful set of tools to make good, well informed business decisions. These tools give an exec the ability to go beyond just straight ROI when making decisions and start to get into the world of work flow optimisation - smart scheduling of work to maximise ROI over time. 

If you aren't comfortable with the concept of cost of delay, you really need to get comfortable with it before having this conversation.

So agile gives some very good tools to the execs for having ROI discussions. Problem solved? Not quite. There is also a deeper level to this. The benefits stated on most business cases are, if we are totally honest with ourselves, pure fantasy. Most are impossible to track back to an individual feature or project -  if we have 10 projects all claiming a 1% increase in users over 6 months, when user growth comes in at 1%, which project was responsible?  Did one succeed and the other 9 fail?  Did they all partially succeed? Most of the time all 10 projects decide that the 1% was down to them and all 10 claim success.  Because they are often split across different portfolios, with different management and governance bodies, they usually get away with this.

The reality is that unless you have some really fantastic analytic capabilities, or there are some very, very specific benefits tied to one project -  launching a new product for example - it's almost impossible to separate the impact of one project from all the others going on.

The trick here is to measure up a level. Rather than trying to measure the impact of each individual project, measure the impact of a whole portfolio. Rather than setting benefits at the individual project level, where they are impossible to tease apart, set high level business objectives for a whole portfolio and track that. After all, what's really important is the overall business outcome. If your target is a 5% increase in user numbers, does it matter whether that increase comes from one project or 20? What I am talking about here is outcomes based funding which I have spoken about earlier. 

The outcomes based funding discussion is not the place to start this conversation. This is the advanced course. You really need to have the basics covered before you bring this one into the mix, but it's definitely a conversation worth building up to. If you can get this happening, you are really in a good place as it leads to all sorts of nice discussions about how the organisation organises and funds work. The end goal is to convince the organisation to fund capability, not work - fund a set of stable teams that get work done and funnel work through that capability. Don't do what they do now and fund packets of work projects and form teams around them (I feel quite safe assuming that this is what they do now and pretty much every organisation in the world works this way).

That pretty much covers the ROI conversation (in a terribly superficial way of course...I could usefully spend the next 6 months talking about nothing but ROI (but I value my readers and want to keep them). Next time I'll look at the biggie. The one that really underlies all the others - how does an executive maintain control in an agile environment.