Many organizations are now implementing Agile development practices and methods. To get their feet wet they need to select projects that are “suited” for Agile. Since Agile methods emphasize face-to-face collaboration and small teams, the natural pick for such experiments are small, self-contained projects where all the project team members are in one location. Not surprisingly, these experiments usually succeed – meaning that using the new Agile practices did not result in a project failure, and perhaps the project was delivered slightly faster or with less problems than normal for that organization. Success?
To answer this question, you need to understand what Agile is. I sometimes ask this question at the end of a day of teaching Agile concepts. Usually people then answer with concepts from the “Agile Manifesto” or start to describe Agile development methods or Scrum to demonstrate that they have been paying attention in class. All true, but somewhat missing the point. Agile is agile. It is the ability to respond to changes as they occur, quickly and efficiently. In Agile development, that capability is most evident in the ability to reprioritize backlog items without having to redo massive amounts of project plans. Simply put, the team can respond very quickly and efficiently to changes in priorities and scope.
Now back to those projects: While it is good to gain experience with the mechanics of Agile methods on small, self-contained projects, significant benefits of Agile are not realized on such projects. In fact, Waterfall may be perfectly suited and sometimes faster under these conditions! On larger, complex projects however, the power of Agile can truly be demonstrated as a never-ending series of priority and scope changes is accommodated and much more easily absorbed through Agile planning practices. So, next time you have a complex project, with lots of undefined requirements, multiple stakeholders and teams, and potential for changes, consider Agile!