When Agile is Waterfall

Image by Annie Spratt, Unsplash.

Many organisations have really great software teams who adhere to Agile principles and values such as Scrum to develop technology products. However, when you dig below the surface you realise that although the software is being built within an Agile framework, the rest of the process is Waterfall! Projects are sequentially planned over 2 years and even if the team are planning to shorter time horizons, such as a quarter, their ‘goal’ is simply a list of well-defined features rather than an objective to meet, without the opportunity for change based on customer feedback.

THE SIGNS OF WATERFALL

It is surprisingly easy to inadvertently become a Waterfall project.

• You don’t release software until the project is completed
• No room for inspecting and adapting / the user feedback loop.
• Working software is not released at the end of a sprint (or sooner if you have continuous deployment). Linked to the first point but shows that your development and release cycles are misaligned meaning that you are banking working software. Remember the Agile principles ‘Working software is the primary measure of success’ and ‘Deliver working software frequently’.
• Transition working software to clients over a protracted period of time. Lengthy rollouts are inherently cumbersome, they take considerable time and resource to plan, manage and execute. This often happens when replacing existing functionality with brand new functionality.
• Consistently changing requirements — part of being Agile is understanding the difference between being flexible enough to respond to change and consistently changing requirements. The first is Agile and allows you to adapt to need, the second indicates lack of strategy and correct planning.
• Teams working in silos based on expertise — each with conflicting objectives.
• No Product representation on the executive team. If the most senior product person in your product organisation is the CTO, it indicates that Product is given a lesser status and this will affect how Agile the organisation is likely to be. CTO’s are great at determining and maintaining the technologies used and overseeing the delivery of software etc. If product is truly valued you might find a COP who is great at building strategy, radiating their vision at the highest levels of the company and skillfully balancing user and business needs.

WHY IT MATTERS

YOU WILL BUILD THE WRONG THING

A major difference between Agile and Waterfall is the timing of software release. Waterfall typically is at the very end of the project. At this point, if you have built the wrong thing you have just burnt all your cash and wasted a lot of time and effort.

Agile recognises that getting the product right is really hard. This is why one of the cornerstones of Agile is delivering working software regularly. The basic premise is that customers don’t know what they want and as a result software companies are not sure they are building the right things. Therefore you need to de-risk as much as possible. Working on a project for a year then releasing has a massive risk. Building for 2 weeks and releasing means that worst that will happen if you have 2 weeks of code that needs deleting.

INEFFICIENCY

Contrary to the belief of many and perhaps compounded by the misunderstanding of the word ‘agile’, Agile teams have a plan, usually a big, detailed plan. Changing requirements are fine and of course welcome, however, it must be recognised that they come at a cost. Small iterations during a project have a small cost, constantly changing between workstreams comes at a very high cost. This cost is time. Mike Cohn brilliantly illustrate this in the following story.

Imagine you are in a restaurant and your order chicken, but before the waiter goes you say “Actually, I’ve changed my mind, I want the fish”.

The waiter says “Sure” and takes your order to the kitchen.

There is no cost of change as the decision was made early. Take the same example, but this time you change your mind 10 minutes after the waiter has gone. This time the cost of change is high as your chicken is already being cooked.

Another major inefficiency is to use your Development Team purely as a feature factory . Product people should be bringing well-defined user challenges and problems to a cross-functional teams so that it can be solved together. This may include: Product, UX, Developers, Architects, Customer Success. As Marty Cagan pointed out ‘If you’re just using your engineers to code, you’re only getting about half their value’.

Inefficiency massively frustrates the Product and Development teams. The reason most software development teams choose Agile is the benefits they see by putting the user front and centre of what they do, releasing working software regularly and getting customer feedback so they can improve, which is a better way of working.

AVOID THE PITFALLS

It is our responsibility as Agile practitioners to evangelise and educate our organisations. It is unreasonable to expect Execs, and other departments to understand the value of Agile if we don’t explain what it is, how it works and why it’s better. Your starting point is to highlight why Waterfall is great for well-defined projects such as construction projects but doesn’t work for software development projects.

Swapping from the traditional ‘Command and Control’ to empowered self-organised teams is a daunting prospect for many Execs who are not used to decentralising control. You have to help demystify what is going on by including them into your Agile ceremonies, such as observing a Daily Standup and Sprint Retrospective. Leveraging the Showcase to show your progress and invite feedback will be refreshing to many Execs and your wider stakeholders.

As discussed above, planning is key to Agile. You therefore need a mechanism to share short and mid-term plans, which is where your Roadmap comes into play (see my article on ‘Building your Product Roadmap’ for full detail). Investing in quality practices will really help, especially in those more scaled teams. An experienced Scrum Master will be invaluable in achieving this.

Waterfall projects communicate via Gantt Charts and heavy documentation. Agile projects communicate via face to face interactions. This is so important, especially for Product Managers. You should be in constant communication with customers, Execs, stakeholders and the Development Team. Effective communication builds trust and understanding, there should never be misunderstanding or ambiguity.

Be vigilant of sliding into a Waterfall Project. Ensure you stay ‘Agile’ by investing in great processes, communicate often and with all the relevant people and have open and inclusive practices. Finally, being Agile means that you are focussed on the user, and more importantly delivering value for the user at every stage. Do this and you will be so much more likely to deliver a successful product.