Moving from Waterfall to Agile Methodologies

To understand how to do this, let's focus on the outcomes first.

Now, you have probably seen this diagram before and there's a good reason for that. Henrik Kniberg's diagram is an oldie but a goodie as it expresses the major differences between the two approaches in a simple way:

Image

The image is clear and the differences can be quickly identified. The top line, with its technical milestones, is effectively waterfall in spirit and the bottom line depicts agile where progress is punctuated by recognisable objects. These are usually referred to as the minimum viable product (MVP) for that story. 

Obviously, if you were working for BMW and your production line manager said "we haven't built a car yet, but do you like this scooter?" you would all be sacked. Large scale automobile makers don't innovate design on the factory floor; their challenges are different. Agile concerns how progress is managed on pioneering work with new systems and applications. The important parts of the diagram are the smiley customer faces and the perception of progress against a usable outcome. In this sense, the diagram is absolutely 100% correct.

In agile, we don't value progress by how near it is to "the end product", but by how complete a story is to fulfilling customer outcomes. In fact, an agile way of working allows you to stop at any point and still deliver an outcome that has value. This is demonstrated in the bottom line of the diagram; the customer primarily wants a transport solution to get from A to B in the quickest time possible. The initial design process would lead the product development team to consider a car being the best and quickest mode of transport.

However, after each increment and whilst developing, testing and eliciting customer feedback on the transport solution, it is soon realised that due to traffic travelling by motorbike is the fastest way to travel from A to B. Nevertheless, some customers may require a safer transport option, so product development continues to create a car, which delivers more value to different set of customers.

Compare and contrast this with the waterfall line, where no outcome is usable until the product is complete. This means the customer is locked in until the end. Why is the smiley face bigger at the end of the agile process as opposed to the waterfall process? Perhaps because the agile process didn't waste time building a roof and delivered a drop-top, which may have been preferred by the customer due to a summer release for example.

Now let's look at the way of working. If you use the waterfall vision, then a car is a consumer product and making one can be seen as a project with a completion date. If you view it as an agile project, then you have a fixed team working on the customer journey to produce a method of transport. The team works on short-term outcomes or stories that have value in and of themselves. It is important that the team align with the customer journey and not just with transient workers who will be moved onto another project.

By focusing on what a customer is currently asking for, teams achieve much quicker time to value than they would do if they only thought about a notional complete product. 

In waterfall, time is spent (and lost) at the head of the project collecting requirements. These describe what the final product must do based on what the customer believes will be needed. But until the development process is finished, the customer may well get no value whatsoever. In agile, work is delivered through stories that directly represent a customer outcome somewhere on the journey.

Finally, let's look at agile planning. We describe the large scale view as epics and break these down into stories. Depending on how you do things, a story that is accepted by the team can then be split into engineering tasks. It is important that at the story level, we talk only in the language of the customer or product, and only allowing the engineering perspective to emerge at task level.

Image

Looking at the diagram above, we see how interests are inverted. In an agile sprint, time is fixed and you are working with fixed-sized team resources. So it is the scope of a project that gets regularly (re)prioritised and groomed by the product manager and stakeholders, probably in a tool like Jira. The product manager decides which work should be accomplished in the next sprint based on agile qualitative and quantitative feedback from various channels, such as market conditions or customer feedback. And because resources and time are fixed, the development teams can react to market changes and deliver value to customers faster. The manager can monitor the release cadence (which is a key tenant of agile development) and by looking at projects through this iron triangle teams are able to adapt while still following a plan.  

The takeaway?

Stop thinking about time and cost. Think about value and priority.

And spend time with your customers, not with ageing requirements.

If you're still not too sure how best to move from Waterfall to Agile to release the potential of your business, then please contact us.

Or you could even visit a couple of our pages to understand how Catapult can help with Agile Planning and Agile Delivery.