This is a blog post by Andy Hiles, adapted from his article originally published on InfoQ.
Water-Scrum-fall is a hybrid software development approach that aims to successfully combine Waterfall and Scrum approaches into a hybrid Agile way of working. This blog post takes a closer look at how Water-Scrum-fall originated, what benefits and disadvantages it brings to an organisation, and why ‘doing’ and ‘being’ Agile are two completely separate things.
What is Water-Scrum-fall more specifically?
‘Water-Scrum-fall’ is used as a way to describe a position in which Scrum as an Agile framework is injected into an organisation or project flow to solve and fix a non-Agile or Waterfall way of working.
From a process perspective, Water-Scrum-fall includes three phases:
- Detailed planning and design
- Development based on the Scrum method
- Strict and managed delivery of the product/service.
- These three phases are often dominated by fixed contract terms and have really long delivery lead times.
One of the points worth raising early is that Water-Scrum-fall can easily become a preventative case for organisations aiming for full Agile adoption; there is a mindset, culture and behaviour that should push you further with Agile. Unless these are also supported, organisations will just stop and miss the whole point of Agility.
In business environments there is often an intangible gap between customers’ expectations and the products or services they are delivered. Agile aims to reduce this gap through closer collaboration with customers, ensuring constant feedback and their involvement in the development process. Through this we focus on delivering the best value and business outcome for our users, customers and business stakeholders. In a Waterfall model, product or service development often results with low customer satisfaction as the feedback and customer collaboration opportunities often lie outside of lengthy processes with absolute constraints on delivery times, costs and scope.
Trying to bridge the gap between customers’ expectations and what they are delivered, organisations turn to Scrum, injecting it only into the development stage. This focus on only optimising the development section of a project lacks any opportunity to integrate feedback provided by Scrum from planning and iterations. This is where organisations end up with is Water-Scrum-fall.
Deciding to ‘Water-Scrum-fall’: Pros and Cons
So how does an organisation decide to adopt Water-Scrum-fall? Well, it actually doesn’t. Water-Scrum-fall is something which usually happens with some organisations that are aiming to ‘be Agile’. Scrum is the most popular Agile framework with a well defined and published guide, Scrum is lightweight, simple to understand, hard to master. As part of an organisational change initiative organisations turn towards Scrum in an attempt to solve some of their product development issues such as increasing their time-to-market.
We need to recognise that the structure behind Water-Scrum-fall is not designed to handle uncertainty and change, and what’s more, it can’t handle them in an effective way. You can get inspiration from the Agile principles and statements, but the truth is that you wouldn’t be using Water-Scrum-fall if you were really interested in following the Agile principles.
Is there any benefit in using Water-Scrum-fall? Apart from the fact that it represents a ‘stepping stone’ into Agility, I would say there isn’t any benefit. Yes, it’s a good starting point and it can highlight the inefficiencies in the way you currently work, but it’s not sustainable if you want to really be Agile.
The difference between ‘Doing’ and ‘Being’ Agile
Oftentimes you’ll come across companies which claim to ‘be’ Agile. When you ask them what they mean by that, you hear “We are doing retrospectives” or “We do daily stand-ups”. That’s ‘doing’ Agile. Which is completely different from being Agile.
Let me explain.
You can bake a cake by following a recipe, adding ingredients and placing the resulting mixture into the oven - but none of this guarantees you’ll have a tasty cake.
Same goes with Agile. You can ‘do’ Agile but you won’t necessarily ‘be’ Agile. And that is because ‘being’ has more to it than just performing some actions. Being Agile implies a certain culture; it implies gathering, measuring, and using feedback to harness change, constantly improving while letting yourself driven by feedback.
Agile is a mindset and Agile thinking can expose some of our ‘weaknesses’ like the inability to deliver products fast and it can improve things like meeting the customer’s needs through ensuring continuous feedback is provided.
Just to be clear, Water-Scrum-fall is not something entirely negative. Regard it as a starting point on your organisation’s journey to becoming Agile and let it start highlighting the inefficiencies in the way you work. Aim for ‘being Agile’ rather than ‘doing Agile’ and try to avoid getting stuck in Water-Scrum-fall pretending you are Agile.
Image credits: Andy Hiles 2015 Water-Scrum-fall presentation on SlideShare.