Position Statement for First eWorkshop on Agile Methods (April 8, 2002)

Ken Auer kauer@rolemodelsoft.com

I have been a software practitioner in various capacities since the mid-1980s. I have developed software for scientific, manufacturing and business applications as well as for a variety of software development tools. I have played the role of developer, consultant, project manager, trainer, mentor, director of applied research, director of consulting, and small company president.

Over the years, I have observed that a competent team that works together toward a goal with honest communication and a flexible plan that does not get in the way of meeting the goal is far and away the biggest contributor to success at any scale. A competent team that works together will outperform a team of talented developers that don't. A team of talented developers led by a controlling manager who tells them how to work will fail and disperse. I have managed to a plan and met the goals of the plan. The six-month plan seemed good to everyone when we started, but we were not allowed to stray from it as we learned without a lot of bureaucratic and unproductive time. We had a choice to "stop work" while the plan was adjusted (which would have taken at least a month or two based on the bureaucracy in place to approve any such adjustment), or do the best we could within the guidelines of the plan. So, our highly-skilled team moved forward. The end result was a fragmented team featuring two camps: those who "did what they were asked to do" (even if they didn't like it) and those who "did what they thought was best, complying only enough to not get fired". Also, everyone (the project sponsors, and the development team, not to mention me) was unhappy at the end with a product that was not nearly as good as it could have been if we were more agile.

When I heard about XP, I was both attracted to it (a lot of best practices that I had learned over the years were in there) and a bit skeptical ("Aren't there some inefficiencies inherent that make it less than optimal?"). I was challenged to suspend disbelief and try it. In 1998, I was given a one-month window to do so on a small scale and was surprised by the result (even though the first month was often uncomfortable). As I compared the result with all of my previous software development team experience, I couldn't help but be impressed. The quality of the software and the quantity of the results were quite impressive in spite of the fact that the gap in experience of the developers was wide. The amount of knowledge gained by both the senior and junior developers were even more impressive. I then had the opportunity to lead a much larger project using XP. The raw talent and technological skills of the team I was given was far below any team I had ever been a part of for an extended period of time. The person driving requirements had never really done so. The results were amazing. Although a more talented team could certainly have produced better results faster (using the same process), the focus and quality of development was far above what otherwise would have been expected.

I would suggest that the article by Dr. Boehm is that of a man who has experienced many well-executed projects employing a plan-driven approach (and I'm sure, some less than stellar executions of the same). Dr. Boehm is observant and humble enough to recognize some of the benefits of agile methods. However, it is clear that he has neither experienced well-executed "agile" projects nor been able to objectively analyze the differences and has deferred to others of like-mind who suffer from the same inexperience. For example, he regularly alludes to the assertion that agile methods only work with skilled developers or, at the very least, skilled leaders. However, he does not seem to recognize the importance of skilled planners and designers necessary for the success of plan-driven approaches. He also only briefly alludes to the problems "architect breakers" cause in plan-driven approaches as if that validates the approach rather than points to a problem with the assumptions of the approach. In fact, it would be difficult to argue that the dangers of having unskilled planners/designers in a plan-driven approach would not be more devastating to the end result of a software project than an agile approach where at least the knowledge gained through trial and error can be fed back into the process. The fact that less-than-great developers will be involved in coding using either method should point toward an approach where problems are caught early and the skill-level of the developers are raised during the process rather than accepting problems as a fact of life to be blamed on the "lowly coders who didn't get it". Dr. Boehm rightly points out that "cowboys" are helped by Agile Methods that add some discipline to their approach. Agile Methods can also help "disciplined but unskilled developers" raise their skill level.

Dr. Boehm certainly and somewhat accurately points out the potential pitfalls of blindly following agile methods without tacit knowledge. I would suggest he apply the same filter to point out the pitfalls of plan-driven methods before asserting the appropriateness of one versus the other. Otherwise, he is merely propagating ungrounded assertions of the scathing critics in a kinder, gentler way.