Improving an organization’s agile capability can take many forms:
It can involve training people in product-focused frameworks such as Scrum and Kanban, or project-focused frameworks such as PRINCE2 Agile™ and AgilePM/DSDM. Along with this it can include coaching and mentoring departments and organizations where their existing working practices may be a more mixed and generic agile style.
What we typically experience through our work at agileKRC is a very positive view of agile – that it’s improving how people are working. However, we also recognize the difficulty in measuring and quantifying how much things have improved.
A recent article that talked about how agile had saved a large amount of money (hundreds of millions) on a particular project was unclear about what had made the saving. Was it agile or was it the new technology being used? I’m sure agile contributed to a better final product and/or a speedier delivery but how much did it contribute? This wasn’t at all easy to see. Using a waterfall approach would also have resulted in huge savings too but what was the difference? How much better was agile?
One thing for certain – in my view – was that some of the savings on this project (if not most of them) were nothing to do with agile. Measuring agile success is hard and this problem exposes a serious problem: if you can’t tell how successful agile is, should you even be using it? Because as Tom DeMarco said: “you can’t control what you can't measure.”
What can you do to start measuring the benefit of the agile way of working?
- Separate out the benefits derived from a piece of work or project from the benefits of using agile. If you ask your Financial Director or CFO whether they prefer getting agile right or getting the business case right, you will get only one answer.
- Consider your organization or department’s big picture view: What is really important? What is it trying to achieve? Is it trying to be quicker, better or cheaper? Remember, if you are saying ‘all three’ then you will struggle because they are not necessarily complementary. In fact they compete with each other. As the sign in a Blacksmith’s shop said “Quick, Cheap or Well-built – pick two!”
- Measure agile to see if it’s improving the value you are delivering: remember, agile is an enabler, it is not the final destination. The tricky part is that many of the measures you can apply to agile will involve being subjective (e.g. how well is collaboration working?) as opposed to objective (e.g. what savings are being achieved?)
- Measure things such as transparency, self-organization and communications. Again these are hard to measure but important. One simple technique is to carry out a weekly check on happiness or morale, although this needs to be carried out sensitively and appropriately.
It is vital that any organization or department needs to know what success looks like – what are you trying to achieve, and importantly, is agile achieving it?
Although vital to do, it is not easy; when I surveyed the attendees on a recent webinar about this, only 8% had clearly defined success criteria for their agile transition. That is worrying!
As the Dutch say “meten is weten”; to measure is to know!
What techniques do you use for assessing the success of projects that use agile methods? Do you employ different methods and criteria when evaluating PRINCE2 or waterfall projects? Please share your thoughts and experiences in the comments box below.
More AXELOS Blogs from Keith Richards
PRINCE2 Agile™ - why so many myths?
The genesis of PRINCE2 Agile – a work of agile collaboration
PRINCE2® Agile: Creating Best Practice that even an "Agilista" can live with!