Agile Zone is brought to you in partnership with:

Ebba Kraemer has several years of experience from advising management and driving change initiatives in development organizations as a former consultant at the management consulting company the Boston Consulting Group (BCG). Ebba currently works as Senior Productivity Expert at Hansoft where she daily advises software development organizations around the world on implementing agile methods to improve their processes and efficiency. Ebba has posted 3 posts at DZone. You can read more from them at their website. View Full User Profile

Wet agile or agile waterfall?

11.04.2013
| 20140 views |
  • submit to reddit

The second blog post in the Exploring the landscape of large scale agile frameworks - series


“Wet agile”, “the agile waterfall” and “the Agile-Waterfall Hybrid” … this controversial, mixed-method baby has as many names as formats. Some have received a lot of dedicated thought, are fit-for-purpose and manage to preserve the main benefits of the more pure methods. Other hybrid models have resulted by accident; either as a consequence of… 

  • … a half-way-stopped agile transitioning program that dropped dead somewhere between waterfall and scrum in an unsuccessful change initiative 
  • … a compromise between method-promoters of different ideologies (often management being on the more waterfall friendly side vs. developers generally promoting more agility)

The result of the latter two cases can be horrible to witness and worse to experience for everyone involved regardless if they sit within the development organization or are on the receiving end waiting for the product. 

However, I do not think the frequent occurrence of poor agile-waterfall hybrids we can witness in the industry is a reason to consistently argue against mixing the two arts as many agilists do. Rather, these cases highlight the need to bring the successful and proven versions of agile-waterfall hybrids into the light and reserve a place for them among their purer cousins in the landscape for large scale agile frameworks.    

Founders of more successful hybrid versions often come from product development companies that deal with both software and hardware. The driver behind the method mixing in these cases is, if we simplify to the extreme, the realization that many aspects of hardware development benefit from waterfall processes, whereas software development has much to gain from an agile approach. 

The Agile-Waterfall Hybrid described by Erick Bergmann and Andy Hamilton from Schneider Electric is a great example of a model that merges Agile and Project Management Process/waterfall in a good way without compromising the methods’ core principles to much.    

  • Erick Bergmann and Andy Hamilton presented the Agile-Waterfall Hybrid at Agile 2013 and the key concepts of the model can be well understood from the presenting material;  https://submissions.agilealliance.org/system/sessions/attachments/000/000/760/original/Agile-Waterfall_Hybrid_01AUG2013.pdf
  • The model allows software teams to adapt agile practices while hardware development and overall product management is handled through a traditional PMP/waterfall approach 
  • The overall PMP process has a well-defined interface to the agile software development which is continuous right from the start of the concept/feasibility study up until validation and production. The interface has the format of close collaboration for all activities ranging from definition of requirements and scoping to continuous software deliveries and feedback between the agile side and the waterfallish PMP side
  • The model accommodates development where the same/similar software is used in several products with separate POs. Eg., the software teams need to deliver features to multiple stakeholders continuously in a similar fashion as component teams typically need to act towards feature teams. The very challenging backlog management situation resulting for teams in environments like this is addressed in a good way by the model. In short, it describes how you can achieve swift product releases by putting effort into the feature releases planning on the software side
  • There is no perfect alternative. Just like any other hybrid model, this Agile-Waterfall Hybrid compromises with some of the principles of the non-hybrid methods. The waterfall side of development is forced to live with the flexibility surrounding the software requirements and the agile teams must commit to time-fixed delivery dates, cost forecasts and risk assessment. 

Hybrid development models face many challenges. It is not easy to combine the dependency tracking and clarity of waterfall with the flexibility and openness to change of Agile development without diluting the benefits and create complex work processes. However, examples like the one referred to above prove that it is possible and as the industry need for these types of models is evident I hope to see more of these being published in the future. 

Published at DZone with permission of its author, Ebba Kraemer.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Nicolas Seyvet replied on Sat, 2013/11/02 - 7:05am

Scrum is already used in many ways a shorter-waterfall.  But I wont develop on that.

In effect, the problem is not in adopting the best of Agile practices and/or the best of waterfall but rather to embrace the core values of Agile/Lean as expressed by the Agile manifesto.  The rest is execution.  On that I agree with you.

The problem with large companies usually is applying the lingo without following/understanding the core values.  For example, ticking the box on "Agile" because there is a daily meeting, and a "cross-functional" team.  Many do this (like where I work). Then, the issue is mostly to change the that, and that requires changing the company culture.  And, there, I do not see how a different models will help.  What is needed is a recipe for applying an Agile culture in a process driven /waterfall workplace.  When process helps to avoid responsibility, how do you suddenly trust people? 

Conrad Muller replied on Wed, 2013/11/06 - 11:01pm

My take on Agile is that the users are part of the team, the project is broken up into easily understood and tested units, and change is part of the goal of project management.

I still insist on a big investment up front in gathering requirements, prototyping, and building user support for the project.

I guess that is what Ebba is talking about. It works for me. I guess this is a vote in favor.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.