In May this year I obtained the BCS Agile Foundation certification. Here are some of the key insights.
Project variables
In a digital project, you have a set of variables that you can control.
In a Waterfall project, you attempt to deliver a fixed scope. To meet this, the time and cost may have to change – and the quality may also be undermined.
In an Agile project, you fix the time and cost, but vary the scope. You might deliver less, but the quality is high, costs are controlled, you release on time, and what you do deliver is the most valuable work you could have been doing.
(A lean approach is slightly different. You look at flow rather than time, value rather than cost (if you only focus on cost you might not get a good ROI), and quality rather than scope (deliver less, deliver right).)
Agile focuses on the early delivery of value to the customer
A Waterfall project only generates value at the end of the project. You start off by specifying what you want to build, then you carry out design, then development, then testing, before launch. It is only at this last step that any value is experienced, because this is the first time that a working product is used by the customer.
An Agile project goes through all these stages during each sprint. At the end of each time-bound unit of development, something valuable is released to the customer. This means that value is delivered more quickly than in a Waterfall project.
Agile focuses on frequent delivery of value
Working in short sprints allows you to regularly release valuable software.
In 2010 Etsy re-engineered their backend systems to reduce the time taken between software releases. The aim was to be more responsive to customers. In 2011, Etsy released new software 12,000 times – about 30-40 releases per day. They tested code on a small percentage of the audience, and then ramped this up to 100% if it tested well. This new approach reduced defects on go-live by 90%, as each change was so small that it was very difficult to make mistakes.
Think about how you could make a small, safe change to your business process. This would help with risk management, and with agility.
Agile values emergent solutions
It’s important to plan, but plans always have to change. Our competitive advantage is in how well we respond to change.
Management must provide vision and purpose, so that self-organising teams know the overall direction they should be travelling in, and management must clear out blockers for teams. This is different to command and control, with management closely directing the actions of teams.
We must design for uncertainty and change
The ‘Waterfall’ model of developing software was codified by Royce in 1970. He noted that it is “risky and invites failure”. The waterfall approach assumes a simplicity which does not exist in a complex environment like software development.
When applied to software development, a waterfall approach makes three dangerous foundational assumptions:
| Myth | Reality |
|---|---|
| The customer knows what they want | We don’t know what we want until we interact with it and see if it works for us or not. |
| We know how to make the software. | Generally developers don’t know how exactly to build the software until they start building. |
| Nothing changes during the project | Understanding and requirements change over time. Barry Boehm found that estimates given at the start of the project could be 4 times too high or 4 times too low. Later estimates are more reliable. |
In an uncertain environment, use an empirical approach
Build something -> Measure how well it works -> Learn
Loop through this cycle as rapidly as you can.
Regular delivery allows for the earlier realisation of value, and for learning and customer feedback that can improve the product. This reduces the risk of building the wrong thing.
If you take a single, late delivery approach (as in Waterfall), the risk of not delivering the right product only starts to fall later on when you do UAT or go live. It’s better to deliver regularly, and to focus on high-value and high-risk areas, delivering these early to de-risk the project.
The economic case for Agile vs Waterfall
The Standish Group’s 2002 Chaos Report found that:
– Around 1/3 of projects are never completed.
– For completed projects, 45% of features were never used. So almost half of all time, effort and cost was for no reason.
– 19% of features were rarely used.
– 64% of time/effort/cost was wasted. So you need to focus on value, and you need to validate ideas with customers.
The Cutter Consortium found the following improvements due to the adoption of Agile practices:
– 61% cheaper.
– 24% faster.
– 83% fewer defects.
– 39% smaller teams.
These gains are a result of simplicity – maximising the work not done.
The key learning is: make your products smaller and more focused on the core value.
Report on the delivery of actual value, not on progress through project stages
In traditional project reporting, you monitor progress through different stages of the project. But there’s no value delivered until you go live.
Instead: look at revenue, impact, satisfaction levels, customer calls, organisational KPIs.