I recently started with a client as an agile project manager in a software team building a new global intranet site for all staff.
Everyone came from tech backgrounds and had experience working in agile environments. After a few months, I was asked to send a status report to the entire company. Not long after I hit ‘send’ I received an email from someone external to the software team…
Dear Allen,
Thanks for your report. Whilst I found it really interesting, I have no idea what ‘agile’ means.
Could you please explain when you get a chance?
The best explanations are often the simplest.
The waterfall approach to product development
So, I explained to them using this analogy. Let’s assume a restaurant wants to release a new burger. This burger is their product and launching it to market is the project. To deliver this project, we first need to get the product ready.
Options for delivering our project (i.e. launching our burger):
Let’s start with the traditional waterfall approach and follow a phased delivery. This is a sequential process where the work flows steadily downwards through a number of phases.
A typical project lifecycle may look like:
1. Analysis >> 2. Design >> 3. Build >> 4. Test >> 5. Deploy
Using the burger example, this might look like:
1. Research the best burgers >> 2. Design the best burger >> 3. Source ingredients and put it together >> 4. Test the burger and ensure it reflects the design >> 5. Launch the burger
Putting analysis and deployment aside for simplicity, we’ll go straight into the design phase. Let’s assume that the team dedicated to designing our burger takes two months to determine that it’ll have four ingredients: lettuce, tomato, cheese and beef.
Now it’s time for a different team to build these ingredients. Let’s assume that this team works in a factory that can only produce one ingredient at a time.
Note: like most businesses, the restaurant has limited resources; this means that we have to depend on this factory alone as buying additional factories would be too expensive.
Let’s say that each ingredient takes two weeks to produce – this means it will take two months to turn out all of our ingredients and build our burger.Now that the burger has been designed and assembled, it’s ready for testing – as we don’t want to release it until we’re sure it’s right.
We ask a range of people to try the burger to make sure it meets the requirements. We consult with:
- our customers (end users) – although this isn’t common with the waterfall approach
- people within our project
- people across the wider business
Organising this testing takes quite a bit of time and requires another dedicated team, so let’s say testing, planning, and execution takes another two months.
Testing is positive and our burger is now ready to launch to the public – we’ve successfully delivered our project using the waterfall approach. However, there are some common problems that emerge when following this methodology:
- The requirements for the burger were gathered up to six months before it was launched. It may have been the best burger at that time, but what if preferences have changed and now customers want chicken rather than beef?
- Other than a small window of testing after the burger was completely built, there was no opportunity to get feedback. If the testing had called for changes, it’s likely a new project would have been required.
- The burger design was determined to be feasible during the design phase. But what if something went wrong during the build? Imagine that the tomatoes kept getting eaten by birds. We would’ve had to include different ingredients – this would require a redesign and delay the entire project.
- The waterfall approach generally requires the effort of separate teams comprised of experts in their respective fields – designers design, builders build and testers test. There is no real sense of sharing knowledge or skills which can result in wasted effort.
The waterfall method is a traditional approach that made sense for its time. Before the introduction of agile, communication was slower, needs were changing less rapidly and there were fewer channels available.
This meant that it was necessary to define strict criteria upfront to progress the project and ensure quality. Visibility of a project’s status was also not as good as it is today.
Waterfall is still a worthwhile approach for many projects and organisations. In fact, there are specific circumstances that require this method – such as projects with high governance requirements, fixed-scope or that depend on specific expertise e.g. drug development in the pharmaceutical industry.
The agile approach to product development
So how does agile solve some of the problems associated with the waterfall approach? Essentially, where waterfall focuses on a long phased delivery before providing value, agile focuses on short bursts of incremental value.
This approach allows value to be created faster while providing more opportunities for feedback.
In this diagram, the balloons are increments of value added to the product.
Burst One – 6 weeks
Using agile, we’re going to design just a bit of the burger initially, starting with the lettuce. The team that designs each ingredient will be the same team that builds it (because it’s a cross-functional team that shares knowledge).
Once the lettuce has been produced, that same team tests the burger, determines that the lettuce has added value and continues with the project.
Burst Two – 6 weeks
The next part of the design is to add tomato. But hang on… remember the birds? We learn at this stage that the tomatoes are being eaten by birds so we need to redesign our burger.
Since we’re agile, rather than redesigning from scratch we’ll just redesign this ingredient – instead of tomatoes, we’ll add beetroot.
Burst Three – 6 weeks
We build our beetroot, test the burger and determine that the beetroot has added value. We now have a burger with lettuce and beetroot.Time to add some oomph to the burger – we’re now ready to design the cheese, build it and test the burger again. The team decides on Swiss cheese but our test sample doesn’t like it; they want Tasty cheese instead.
This means we’ll have to make a small fix to our cheese in our next burst (and we can do this using agile). We now have a lettuce, beetroot and cheese burger – but the cheese needs to be changed.
Burst Four – 6 weeks
We need to introduce some beef to the burger and fix the cheese as per our feedback. However, at the beginning of this burst our customers told us they no longer want a beef burger – they want a chicken burger instead.
We can still make these changes this late in the project with agile – which means we’re now confident that we’re working with current requirements, not those of around four months ago.
We design our chicken, build it and make the fix to our cheese, then test our burger with the audience.
Their feedback is that they’re happy with the new cheese and pleased that their latest requirement (the chicken) has been met. Success – our burger is complete and ready for launch.
Agile v Waterfall
Both methods delivered a complete burger ready to launch to customers within about 6 months. The main difference between the methods is that for the waterfall approach to be entirely successful in this scenario, none of the problems that we listed could have occurred.
In today’s market it is very likely that one or more of these problems may have arisen, which – using the waterfall approach – would have caused:
- delays in launching our burger
- creating the wrong burger (i.e. beef instead of chicken)
- high uncertainty of whether the burger would do well
- lower value to stakeholders as their input was not taken into account
Using agile, the team could be confident that they were launching a burger that reflected current customer preferences, was thoroughly tested and delivered on time.
Note: this article is intended to skim the surface of the differences between waterfall and agile methods of delivery in a fun and readable way. We hope it’s helped to illustrate how projects were traditionally delivered using waterfall and why many projects today rely on agile delivery as an alternative.
Agile practices work in other areas of the business, not just software development. I encourage you to share this blog with teams who aren’t accustomed to applying agile to how they perform and deliver work.
Let us know how its goes in the comments, and if you come up with your own analogy – please share it with us.
You can download our Elabor8 Burgers infographic of a typical waterfall vs agile project.
