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
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
0 comments:
Post a Comment