Sunday, March 23, 2014

Waterfalls with in the Sprints – a Handshake or an Anti-pattern?

 There seems to have  two conflicting beliefs here. Waterfall is based on the belief that it is best to "get it right up-front"; Agile is based on the belief that it is best to balance "right up-front" against "learning through feedback from building something". Here is an interesting debate: Waterfalls with in the sprints –a handshake or an anti-pattern?

From process perspective, it is a handshake.  Having small defined processes inside of a larger empirically driven project is a compromise, handshake if you will. The whole concept that waterfall and agile are binary yes/no choices at extreme opposite ends is a falsehood. Indeed, agile and waterfall is not opposite, but complementary; It is about how to balance "Waterfall" with "defined process" and "Agile" with "empirical process" respectively.

You really need to work out what you believe. Every project is different and will require being handled from a slightly different place on the spectrum between defined and empirical processes. Pick a starting point along this spectrum that makes all stakeholders comfortable (preferably closer to the Agile side) and adjust as necessary going through the project.

From experience teaching perspective, it is a mindset issue. Remember that if you are a hammer everything looks like a nail. It is important to help everybody to make the transition, otherwise they will continue to do what they have done in the past expecting different results. Provide them with real scenarios where they will go from testing to development to analysis to anything else, and hopefully they will start to make the mental switch until they are all comfortable with the new agile world. Don’t make the process too rigid, but rigorous to allow creativity flow and improve productivity as well.

The end goal is continuous delivery. If a self-organizing empowered team uses a waterfall type process in their sprint to successfully deliver their previously agreed upon work to the full definition of ‘done’, then Agile is working properly. If it creeps in silently, it could be a bad thing, but regular retrospectives should prevent that. If it is forced, the organization has deeper issues preventing Agile from working.

From soft skill or whole-cycle perspective, it could be an anti-pattern. Waterfall & agile shouldn't be seen as exclusive either-or alternatives, but waterfall doesn't lend itself to being 'mini', it's a whole-cycle process. So, in general - every project & team is different, everyone's mileage will differ - if mini-waterfalls are happening inside sprints, it's usually a result of people having not quite grasped agile; putting new agile labels on the waterfall things they already know, and trying to squeeze waterfall procedures into agile-sprint straightjackets. 

Either hand-shake or anti-pattern, a hybrid approach to well mixing waterfall and agile is a better approach to manage project with both discipline and flexibility; well balance defined process and empirical process; make continuous improvement and enforce interaction and collaboration


Post a Comment