Waterfall in Agile clothing
A common misstep that organisations make when adopting Agile is doing it because there has been a top down order from the leadership team to “do Agile” without the necessary support required to execute it properly. What this often results in is the “Cargo Cult”.
What these Waterfall in Agile clothing projects typically look like is:
- Requirements thrust upon teams
- Told they should be Agile
- Slice the requirements into phases
- Create a roadmap based on ‘iterative’ phases
- Determine that the phases are sequential
- Plan the first building block using Agile buzzwords
- Explain the ‘Agile’ plan
A symptom of this is the Knowledge Gap.
This causes teams to scramble together data and a plan, one that is usually unachievable and driven by features.
Whilst this may not be actively worse than Waterfall, the problem is that teams are forced to create a plan that satisfies the leadership team’s notion of Agile without focusing on value creation and validated learning.
Skateboards and cars
Let’s go back to basics: how do we help people get from A to B? Most people have probably seen the car and skateboard analogy.
A Waterfall approach leaves the user stuck at point A until the car is ready:
An Agile approach gets the user on a skateboard so that they have the ability to move between points:
The result of the scrambled plan described in the project above is that you are in the Waterfall in Agile clothing trap: the user is stuck at point A while teams build the axon and wheels in phase 1, the body in phase 2 and eventually the whole car is released for their use.
The impact:
1. Delayed value to users, which causes
- No engagement
- No growth
- No financial gain
You need a new phone. Apple say “don’t worry, you’re going to get a new iphone and it will be perfect for you but we can’t guarantee when in the next 3 years it will be available”. You’d be forgiven for turning to Samsung.
2. No feedback, which creates
- A lack of information to determine the direction of your product
You’re cooking for a large group of people. You don’t think it’s salty enough so add 4 teaspoons of salt without anyone else doing a taste test. You serve the dish. No one eats it.
3. Long release cycles, which means
- Big batch sizes. When technical problems arise upon release of the batched features, finding the source of the problem is far more difficult and, sometimes, deemed not worth locating.
You’re shopping. If you have one bag and set the alarm off, working out which item is causing the problem is far easier than if you’re carrying 16 equally large bags. If you don’t find the source, you keep walking and hope for the best.
There is a minimum amount of build that must take place to satisfy a user’s need to get from A to B. A skateboard with no wheels only works on snow, useless if you’re trying to get around London. A skateboard with no board is just wheels, useless wherever you are.
Your Minimum Viable Product, a concept from Lean Startup that focuses on validated learning, is not the whole product. It’s the first project that enables you to gain insight on the next piece of work that will benefit your users.
The solution:
To me, user involvement is imperative to product discovery and processes, however, what I want to provide are some ways to avoid falling into the trap of ending up with a project that is Waterfall in Agile clothing.
My recommendation for how to do this is to take a structured approach to your product and focus on measurement. The key to this, in my opinion, is having clear metrics to guide product development and testing the results to ensure that your teams are creating user value and learning from the feedback they receive.
Minimising the risk of falling into the trap
One word of warning is that quantitative indicators may tell you where to find the story but not what the story is. It does not replace user research, involvement or testing, but that’s for a future blog post.
Focus on the problem. Define the increment and outcomes. Test the results. React. Repeat.