LOGIN | REGISTER NOW | SUBSCRIBE
 
Print

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


By Dave West


 Dave West
Email
December 15, 2011 —  (Page 2 of 3)
Scrum comes in the middle of the process
Scrum in particular has become popular; many teams are adopting its basic principles, such as daily meetings, the roles of product owner and Scrum master, and Scrum planning and retrospectives. Scrum's success can be associated with many things, but in particular a strong focus on teams and team dynamics has attracted many people who feel that traditional approaches lack a real people focus.

Developers like delivering software, so the practice of frequently releasing software makes intuitive sense. However, teams should guard against embracing Scrum principles but missing some of their most important characteristics.

For example, applying Scrum to only developers is a recipe for disaster. A proper Scrum team must comprise all the people necessary to deliver working software. Typically, this means developers, testers and business analysts working toward a common goal.

The reality of water-Scrum-fall is that change will continue. The water stage defines the overall direction of the project, but the team will have many insights during the project that challenge initial ideas. By supporting change while at the same time ensuring that the team understands the impact of that change, the team will not only build better applications, but will also learn more about its process for future implementations.

One way to drive the point home is to ask the project's management a simple question: "Do you want the technology to help us adapt quickly to threats and opportunities?" If the answer is yes, then tune the approach to favor discovery and action over planning and execution.

Fall: Limits to release frequency
Frequent software releases to the customer enable rapid feedback and ensure that valuable software is being used as early as possible. However, most organizations do not have the architecture required to support dynamic, flexible releases; instead, they do infrequent releases backed by heavy processes and governance. Adopting agile processes will not itself change the firm's underlying enterprise architecture; therefore, teams have to make the best of the situation.


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

Pages 1 2 3 


Share this link: http://sdt.bz/36195
 
Most Read  Latest News  Resources
SAP unveils SAP HANA platform innovations for Big Data and spatial processing
Features include smart data access and expanded cloud deployment options
Alteryx raises $12 million to put Big Data analytics in the hands of all business analysts
Quest founder's firm, Toba Capital, selects Alteryx as its first analytics investment
Google I/O kicks off
Developers get new APIs and tools, and the Go language hits version 1.1
Jelastic launches new version of its Java and PHP hosting platform
Jelastic today announced the launch of a new version of its ultra-scalable cloud hosting platform
Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter



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
MAY 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?