BT

Delivering Software with Water-Scrum-Fall

| Posted by Ben Linders Follow 29 Followers on Nov 07, 2015. Estimated reading time: 11 minutes |

 

Water-Scrum-fall is usually described as an hybrid agile way of working.

According to Andy Hiles water-Scrum-fall is a gated and phased delivery approach for software where Scrum is used as the main development management method.

However Hiles believes it can be used as a stepping stone to agility, to become a living breathing agile organisation.

Andy Hiles gave a talk about water-Scrum-fall, Unicorns and Rainbows at the first Agile Greece Summit. InfoQ covers this conference with news, Q&As and articles.

InfoQ interviewed Hiles about the origins and his definition of Water-Scrum-Fall, the difference between “doing” agile and “being” agile, meeting expectations of customers with agile, the advantages and disadvantages of Water-Scrum-Fall, and on implementing the Scrum Master role.

InfoQ: Where does the term Water-Scrum-Fall come from?

Hiles: I’m not aware of who originally coined the term, but it's been used by the agile community for a good few years. I first heard it used as a way to describe a ‘hybrid’ agile way of working. At the time I didn't really understand the fine line that existed between a hybrid model and water-scrum-fall. It was only when I started working in a water-scrum-fall environment that I really understood what the term meant.

I have seen water-scrum-fall used as a way differentiate a different implementation approach between agile purists and pragmatists. For me that use is really provocative and an excuse for misunderstanding agile and in particular Scrum.

InfoQ: What’s your definition of Water-Scrum-Fall?

Hiles: For those unfamiliar with the term, it sections off software delivery into three phases. Firstly there is a period of detailed design and planning. Next, Scrum is used as the main development management method. Finally there is a retention of a strict and managed service delivery/release to live period. The encompassing three section practice is often gated, dominated by fixed contract terms and very very lengthy end to end.

InfoQ: Can you share what you see as the main differences between “doing” agile and “being” agile?

Hiles: Doing is defined as activities in which a person engages or performs. I can do and perform all the activities to bake a cake, I can add ingredients, I can stir the resulting gloopy mixture, I can then put this in the oven, but none of this means that it will taste any good, or infact I will get a cake in the end. They are just activities I saw Mary Berry perform and I tried to copy her. Analogies aside, the state of play with agile is very much the same. I always hear people saying ‘such and such organisation is agile’, brilliant I think, “what do they do?” I ask, “oh they do standups and pair programming” comes the reply. But what makes them agile tho? These are activities in the agile cake, so does this mean by doing they are being agile?

There is a distinct difference.

When we look at being it is about existence and living. For me this is about evolution and change. Being agile for me is grabbing every opportunity to measure, gather and use feedback for steering change. In essence learning. The most important part is having a ‘focus on continuous process improvement’. I say to anyone questioning their agility that if they have a focus on continuous process improvement driven by feedback, then they are in my eyes ‘being agile’. I can't be Mary Berry, but I can do my best to improve my cakes by learning from a cup of tea and piece of cake feedback cycle.

InfoQ: Agile aims to reduce the gap between what customers expect and what is actually delivered to them. Can you elaborate about this gap and what makes in your opinion makes it so difficult to reduce it?

Hiles: Gosh where to start with this one. Let’s start by firstly blaming contracts. Thats easy to do because it sets the assumption that a signed contract implies that the ‘iron triangle of doom’ (fixed time, cost and scope) is already in play and there's really nothing more we can do about it.

The typical scenario is the sales chap with his target of client signups goes out to get signed engagements for either existing products or even better a contract to deliver a new all singing all dancing product. The danger with this scenario is that while the sales chaps know a lot about what they do, they aren't the people delivering the end product. These sales targets get translated into projects with formulated scope, time and cost. These projects get approved to go ahead and end up on the desks of business development managers, programme managers, project managers, product designers and architects. By the time it gets to the development team it's usually a few weeks before the promised delivery date. While we always feel sorry for the development team in this scenario (and we should), we actually forget about the quality assurers, the release and environments chaps and the end customer who all also suffer from the iron triangle promise. This is a typical waterfall delivery practice.

Donald Rumsfeld famously said “there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know.”

This for me defines every backlog or list of requirements I have ever seen. If we are in the known knowns zone with our projects then we should be doing waterfall. But as we all know things change, and there is uncertainty so we become unwittingly chaotic and should steer ourselves towards agile to manage this change. But we don’t.

To close the expectation vs delivery gap organisations that are looking to be agile commonly throw in Scrum as the solution, but only in the development part. This is water-scrum-fall.

By then it's too late to leverage the feedback cycles from planning and iterations that Scrum brings to the table. The benefits of the roles and the responsibilities that have been created by Scrum to provide assurance that we are building the right thing right have not been allowed to emerge. The result is that the project ploughs on, safe in the knowledge that all that big design up front will save the expectation gap from uncertainty, and the new iterative process will deliver everything faster and cheaper.

InfoQ: Do you have ideas how agile can be deployed to meet the expectations of customers?

Hiles: I don't think of agile as a ‘thing’ that can be deployed. One of my favourite ways of describing agile is that it's like the pirates code (a reference to a quote from ‘The pirates of the caribbean’ film), “the code is more what you'd call ‘guidelines’ than actual rules”.

Agile is a mindset, a set of guidelines, Scrum is a framework that can be deployed, it has strict rules and events to follow, they are not the same thing. Agile thinking exposes our inability to deliver fast, it drives out what the customer actually wants and improves quality by providing multiple opportunities for continuous feedback, which in turn focuses the developers towards how to build the right thing right.

There some simple things you should start to be aware of and look to change.

Firstly collaboration. This has to start with engaging your customers, they need to understand how you work, especially if you are going to use Scrum or even just looking to change the way you work. Your customers will need to understand what is capable and what role they will need play. Collaboration is essential internally as well as externally. Now think of your customers and your organisation as one big team. You deliver together. With collaboration comes, feedback. Harnessing feedback is the key to product quality, value and direction. Feedback is a driver for change, and should be continuously embraced as an opportunity to learn. Finally look to shorten delivery cycles. Measure your lead times for getting work from concept through to production. Model your delivery cycle, seek input and be prepared for change and disruption. Remember that shortening your delivery process improves feedback and collaboration opportunities, which in turn improves quality and the potential realisation for delivered value back to your customers.

InfoQ: Do you know why some organizations decide on using a water-Scrum-fall approach for agile?

Hiles: I don't think anyone decides to water-scrum-fall, it just happens as a natural output and part of the incentive to be agile. As it is the most popular agile framework organisations look to Scrum to solve the problems they believe they have for example in decreasing their time to market. Scrum has not only a defined framework to follow but has also won the market in this by its role based training approach, so it becomes the defacto agile go to. Unfortunately as we know Scrum is seen as a development only practice by organisations and not a ‘how to handle uncertainty and change in your end to end product development’ practice.

InfoQ: Can you mention some of the benefits of water-Scrum-fall? And some disadvantages?

Hiles: Apart from describing water-scrum-fall as a kick-off stepping stone to agility, I am struggling to find any real benefit. The structure behind the process isn't really setup to deal with uncertainty or change as it implies a known knowns situation, so why bother to Scrum? You could look to the agile statements and principles for inspiration, and gain benefit from utilising business and development team relationships, but to be fair if you were interested in the principles you wouldn't sit still in a water-scrum-fall situation.

InfoQ: Organizations sometimes struggle to implement the Scrum Master role. Can you elaborate what makes it so difficult?

Hiles: When we look at the Scrum Master role it has a relatively short description. The Scrum Master is a servant leader, a teacher and protector of the Scrum process. The Scrum Master advises on helpful interaction with the team and works with the product owner to ensure the backlog is managed and valuable to the business. Sounds simple to do huh?

I mentioned earlier that Scrum is revolutionary, and it is. Changing to a world where a single role ensures the process is followed and understood while remaining outside the team and not being responsible for the delivery is tough. Everyone involved in Scrum suddenly needs to figure out where they fit and how they work with and within the framework.

Scrum Masters tend to be high performing, outgoing, self-motivated individuals focused on getting things done and reducing complexity in everything around them. Scrum Masters also seem to strive to be the 1000ft view person, removed from the delivery and looking for any opportunity to change and improve pretty much everything around them.

From my experience, organizations that are working with Scrum neglect the power of the Scrum Master as a facilitator and servant leader. They expect project managers, technical delivery experts, testers, developers release engineers all rolled up into some kind of project super hero. Scrum Masters know it just doesn't work like that.

InfoQ: Can you give some examples of things that organizations can do to implement the Scrum Master role effectively?

Hiles: Do Scrum. Feels silly to say that, however the ‘Scrum but’ rule applies here. Scrum will expose really good things and also point out where support for your product development is required. Scrum Masters will be there to support the organisation in its use of Scrum so trust the role and the person to do the job they were hired to do and support them and the Scrum framework they represent.

Scrum Masters sit in that difficult world between the expectation of the management and the resulting customer expectation of delivery. So use them as consultants to ensure Scrum best practice is being followed within the organisation. Learn from their experience and listen to their opinions and ideas for change, again support the role and its authority.

Like everything around agile. this is pretty simple for me to contain into a short couple of sentences. Unfortunately as with everything around agile I recognise this advice carries its own complexities of implementation and change can be extremely hard.

InfoQ: Is there some additional advice that you want to give to organizations that want to increase their agility?

Hiles:. Let me just say there's no need to fear water-scrum-fall, especially if it's looked as a transition or a first step to learn how the organisation works around Scrum and agile.

Water-scrum-fall is a good place to start, it will expose the inefficiencies in how you work, its politics and all the things missing that you actually need to achieve Scrum nirvana. It’s when you sit still around water-scrum-fall and become a doing agile projects business that the alarm bells should start to ring. Aim to becoming a living breathing agile organisation and through doing Scrum it’s the start of your journey not the end.

An agile coach said to me once that ‘time is inelastic’, I love that as a term as a reference back to the iron triangle. We are always heading for some deadline or timeboxed event, it’s how we behave within that time box that determines our success.

About the Interviewee

Andy Hiles is a highly experienced agile practitioner, event speaker and certified BCS agile trainer based in the south west of the UK. Andy has experience of full ‘end to end’ of software development for both product and service organisations. He has a thorough understanding of the challenges around organisational complexity and what it takes to make an agile transformation successful. A Certified Scrum Practitioner with the Scrum Alliance his career has progressed through major international organisations such as Intel and Nokia. Andy is currently a lead agile and DevOps consultant for IBM. A firm believer that great teams build great products. Andy strives for success and in doing so displays his experience and passion for agile in every engagement.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

'Water Scrum Fail' by Jase Stevo

I work for a company that adopting 'water-scrum-fall' and your analysis is very prescient; so much so that I think you might have worked here ;-). We have the three gates exactly as you describe. My fear is that our adoption of water-scrum fall has so dilluted the practices and philosophy of 'by-the-book-scrum' that the resulting hybrid approach will only bring uncertainty. Then in retropsect we will look back and say we "tried agile and it didn't work here - it just led chaos" and the baby will be thrown out with the bathwater.
I wish I could share your optimism, but as a frustrated agilist of 10 years in a fixed release, fixed price, fixed features, BDUF, plan-driven company there's little reason to be anything other than wearily sceptical.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss
BT