Agile delivery

Agile delivery requires as precise feedback and control as waterfall, just different.

More and more, organisations are looking to add Agile delivery methods to their transformation delivery capabilities. Agile delivery, without the right control and metrics, will not improve on Waterfall in terms of helping to realise successful outcomes. 

Over the years, as Project Management has developed, there have been numerous, increasingly sophisticated, techniques for controlling delivery and measuring progress. Many organisations, frustrated by the ‘inertia’ of Waterfall approaches, move to Agile. The apparent attraction is speed, and more flexibility in delivery, but in doing so, they forsake some of the good disciplines of Waterfall and wonder why delivery (still) goes awry. 

A structured lifecycle still matters

 Whether you are using Waterfall or Agile delivery the following things occur: 

• business teams express a desired outcome e.g. improve customer service, increase market share, increase or improve productivity
• this gets prioritised against available investment, competence and capacity 
• a delivery technique is adopted in order to develop the required business capability i.e. a digital product or a service; and, 
• the business then uses this new capability to achieve their desired outcome. 

Agile techniques are increasingly adopted because they promise greater certainty of outcome, closer to cost (and at lower cost) and time (usually quicker) than other delivery approaches. 

Getting it wrong early is always costly 

However, just switching to Agile delivery does not improve the journey any more than a change of car improves a bad driver. Agile does not help if business outcomes are not well-expressed, or if the wrong things are prioritised. Agile does usually mean that less is committed before things go wrong – but that is still costly. Errors caught later in the lifecycle can cost hundreds of times more than those uncovered early.  The cost is not just financial, late failures can affect team morale and delivery credibility. So, regardless of the delivery method, there is a need to express outcomes effectively, and to prioritise against business needs and the available capability and capacity. 

Key things to look out for

Within the Agile approach there are a few key measures to monitor and refine continually to ensure appropriate control: 

• Backlog – this is the prioritised set of target outcomes, and the estimated effort to realise them. There is a need to refine effort estimates to increase accuracy in estimating delivery time/cost. The backlog needs to be maintained right from capturing first business demand, all the way to decomposed user stories. Can you measure how effective you are at qualifying the demand? Is there a good collaboration between stakeholders, product owner and development team to create good quality user stories? 

• Delivery capacity – clear assessment is required of the delivery capacity (design, develop, test) available. This includes allowing for demands from other parts of the business, such as ‘business as usual’ operational fixes. Without this, it is impossible to match demand to supply, to get accurate views on how much can be delivered by when. Do you know how much time is actually available for the development team to do the development work? 

• Burndown – this reveals whether delivery is progressing as expected. Issues often arise with bottlenecks in particular teams (analysts or testers say). As understanding develops the level of detail at which burndown is measured can be refined. Use and share productivity measures like burndown to motivate individuals and teams to deliver more. 

• Quality – this is crucial. Finding out at which point outcomes are not being achieved, and delivery is being compromised, helps improve the process earlier in the lifecycle. It also helps estimation of the delivery capacity, in order to set aside for correcting things. As performance improves, so measures of quality can be tightened. Acceptance criteria enrich the story, they make it testable, and they ensure that the story can be demonstrated or released to the users and other stakeholders. Are the process and the outcomes transparent to the product owner, project manager and QA? Is the team encouraged to produce high-quality software first-time, during the development period, rather than consequent to more testing cycles? 

• Measures of success – Agile methodologies were founded on getting capability out fast and at low cost, to accelerate user and customer feedback. If there is insufficient clarity on what the measures of success are, and/or these are not monitored, then regardless of delivery efficiency, it will be impossible to assess effectiveness. Good metrics focus on outcome rather than output so stakeholders should be engaged at the requirements definition stage, to define metrics to measure success for the new digital product or service. Sign-off on requirements must also include assessment against criteria, to measure success. 

There are many specific measures and technique based/tool-based dashboards, but fundamentally, if you are leading a programme that includes some Agile delivery and you do not measure these five parameters, you are not in control of your delivery. 

In moving to Agile, or mixed delivery models, you still need to be rigorous in your expression of business outcomes and how you prioritise what you need and can deliver. Particularly with Agile delivery, you should not be seduced into thinking that “lighter touch” documentation requires any less precise control and understanding of demand, capacity and quality of outcome. 

At Project One, we work with many customers whose business teams are frustrated that the nirvana promised by Agile (more achieved, for less in shorter timescales) just appears to be breeding more confusion. We work with them to help improve how they express their outcomes, how they balance demand and supply and how they monitor and fine tune their delivery. Is Agile working for you, or could you be doing better, but cannot see how?  Talk to us.