The allure of agile is seductive – an organization tries it with one or two projects, experiences greater success than they’ve achieved historically with waterfall approaches and decides to apply this new methodology to all projects. The risk is that when they hit a project that was not well suited to agile methods, the temptation to throw the baby out with the bath water is compelling and they revert to their previous approaches.
So what are some criteria that might rule out the use of agile methodologies?
- I’ve written before about the importance of trust on projects and this affects agile projects to a greater extend than waterfall ones – environments with low levels of trust might be better suited to traditional approaches where rigorous (though onerous) decision & deliverable sign offs and change approvals could reduce the likelihood and impacts of finger-pointing.
- Projects where real-world constraints prevent the ability to re-factor components or to refine requirements through an iterative approach. When one is laying a building’s foundation, you usually only get one chance to do it right and the costs of rework are significant. This is not to say that construction projects can’t benefit from agile approaches (especially during the creative or design phases), but their utility will be restricted to those work packages that can support progressive evolution.
- Projects that impose significant “hops” between the customer and the delivery team. This has nothing to do with geographic distance – there have been many successful virtual agile projects. The issue arises when requirements are distilled and translated multiple times from the customer to the team members. The likelihood of miscommunication and rework increases to the point where a traditional approach might yield better results with less effort.
- Minimal or no change is expected to the requirements. If a project’s needs are very well understood by both customer & team, a traditional waterfall approach may be a better fit. A good example of this could be an application upgrade driven by the need to maintain vendor support (as opposed to re-engineering business processes).
- Time-sensitive projects with project teams or customers that have not used agile methods before. As with any methodology change, the first time a practitioner experiences it, there is a resulting loss in productivity as they come up to speed on the new methods. If there is a deadline looming, sometimes tried and true approaches (though less efficient) should be employed.
- Industries where strong external regulatory requirements drive the need for heavy artifacts or strict adherence with well documented processes. While agile methods can be used during research or analysis phases on such projects, product development and manufacturing phases in such domains are forced to use waterfall approaches to satisfy these compliance needs.
No comments:
Post a Comment