Agile – The next big thing?
Posted by: Beth Cohen
Agile Methodologies, Business Value, Software development, IT Innovation, Scrum
Question: What is behind claims that agile methodologies can increase software development productivity 10-100 times over traditional approaches? Is this for real?
I just spent a week with a wildly enthusiastic international crowd of 1400 agilists attending August 2009 Agile Conference in Chicago. As far as they are concerned, agile is set to become the standard development methodology in a few years. I agree that there is much merit to what the agile community is saying. Certainly, better communications between product owners and developers is always desirable, daily meetings and the idea of breaking the work into short manageable chunks called iterations are bound to improve any project’s velocity. But I am skeptical of any claims for such dramatically increased productivity.
If you dissect what the agile folks mean, the high productivity numbers become suspect. For example, one case study involving a Danish software company looks great at first glance, but looking more closely at the methodology, each iteration requires the work be pre-staged so that it is ready for the development effort. All the pre-staging is magically not counted. By breaking the work into smaller chunks and working closely with product owners, there is less wasted effort in building unwanted features. This is all true, but to call the abandoned features unproductive is somewhat disingenuous. Indecisive management is a fact of life and going agile is not going to fix it.
Unfortunately, I also see agile software development quickly getting a reputation for creating new ways to overwork already over burdened knowledge workers. It is all well and good that the agile principles are based on 40 hour work weeks, but so are the PMI (Project Management Institute) recommendations. We all know how well those are adhered to. The Scrum folks even have the audacity to call their iterations sprints. You cannot run a project marathon as a series of sprints without serious burnout. Since the developers on the team participate in work estimates, there is even more pressure to blame the workers if they fail to meet projections that are unrealistic to begin with. At the conference, one session on metrics suggested that the team not share information on team productivity with management in case the numbers were misconstrued.
In conclusion, I find much in agile methodologies attractive and just plain good common sense. However, any claims that seem to be too good to be true, should be viewed with skepticism.
About the Author
Beth Cohen, Luth Computer Specialists, Inc.
0 Comments
RSS Feed
Email a friend
