Print

Analyst Watch: Water-Scrum-fall is the reality of agile



Dave West
Email
December 15, 2011 —  (Page 1 of 3)
Organizations are increasingly adopting agile software development methodologies through a combination of bottom-up adoption and top-down change. However, the reality of agile adoption has diverged from the original ideas described in the Agile Manifesto, with many adoptions resembling what Forrester labels water-Scrum-fall.

This happens in part because agile adoption has been practitioner-led, leading teams to focus on domains they can influence, mainly the team itself. Areas outside of their control, such as project planning and release management, continue to follow more-traditional approaches, meaning that Scrum adoption is limited to the development team. That team is presented with a detailed project plan and a set of requirements that it then works through, incrementally delivering software (but not to production) as the production release process runs at a different cadence.

While this model is not inherently bad, application development professionals need to carefully consider and make the right decisions about where the lines fall between water-Scrum and Scrum-fall. Otherwise, they are unlikely to realize agile's business benefits, such as faster time-to-market, increased business value, and improved flexibility and responsiveness.

In recent research, Forrester offers the following advice to help organizations manage the water-Scrum and Scrum-fall boundaries to increase agility:

Water defines the upfront work
Governance rules require many organizations to define requirements and plans before starting work. In some companies, these plans form the basis of a contract between the business and IT that defines project direction, timeline and budget.

One vice president of development framed this in conversations with Forrester, saying: "We have to spend time upfront with the business building the requirements and plans to ensure that we know what they want, and they know how long it is going to take and how much it is going to cost. The problems start when the business does not know what they want or the architecture is new to us."

Given these realities, it’s imperative that application development and delivery professionals push back on the water-Scrum side of the model. Spending too much time upfront will not increase the quality of the release; on the contrary, it is wasteful. Documents are a poor proxy for working software, and thus any documents created should be just enough to introduce the problem area and allow high-level planning and development work to commence. How many times have end users only understood the problem after they have seen a solution that was not quite right? Feedback late in the cycle tends to be less welcome, as the team has to balance the feedback with the significant cost of changing the application.



Related Search Term(s): agile, Scrum, waterfall

Pages 1 2 3 


Share this link: http://sdt.bz/36195
 


Comments


12/20/2011 09:33:17 AM EST

You are on point but many years too late. I was a consultant in 2006 preaching the virtues of a true Scrum process framework implementation. Within one organization I worked with, they had 4 delivery streams active (think: million dollar projects), only 1 of 4 were true Scrum, the others were what we called "ScrummerFall" or "AgileFascade" - a mash-up of cherry picked Scrum and Waterfall features. These 3 delivery streams had management that resisted a full Scrum implementation and it showed. The one true Scrum delivery stream that had a project stakeholder sitting with the project team, et. al was on time, on budget, and was the model for all other future delivery streams once the CIO saw how well it worked. Remember though, Waterfall is not without its place. Waterfall is useful when everything is known up front or needs to be known up front (think: spaceship software). Agile is useful when things are NOT known (think: most web development these days). Iterative (cycles of understanding) and incremental (frequent delivery of working system) process frameworks do not always fit into every situation with good reason.

United StatesDaniel Bullington


12/20/2011 01:55:51 PM EST

While I share your observations, I think the term water-scrum-fall is misleading and dangerous. Scrum in its very strict setting can by definition not ly between water and fall, IMHO. What we observe is people not doing scrum, when the do just parts of it. Frontloaded (or upstream) processes are in my view not Scrum, this is Scrumbut. If an organization embraces agile practices it will maybe also face the problem of proably not delivering fast to production. In oder to become agile, they will also adopt continuous delivery eg. and even change their architecture to enable it. If they don't they are not shippable, that's also Scrumbut. Scrum helps surface those problems, besides hundreds of others. Being agile is also the mindset of adressing those problems, eg. to get faster feedback. I am very unhappy about the title of this article and the term Water-Scrum-Fall, imho it puts Agile and Scrum in a wrong light. I am happy you put the solutions into it. What one might observe is organizations failing to adopt Scrum and agile practices on an end-to-end level, that's different from what the term states. Nobody says adoption of Agile and Scrum is easy. Sorry, but I had to say that.

AustriaAndreas Wintersteiger


close
NEXT ARTICLE
Agile leaders reconvene at Snowbird
Gathering will mark anniversary of signing as leaders review how far they've come and what needs to be done next Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
APRIL 2014 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?