Lately, it has become common for traditionalists to claim that Agile software development isn't disciplined, a harsh criticism that needs to be addressed because nothing could be further from the truth. I suspect that the people who are making these claims either misunderstand Agile or they're for excuses to not adopt Agile techniques. This month, I describe the discipline required of Agile developers, share my criteria for determining whether a team is Agile, and argue that traditional development provides a false sense of discipline.
Many traditionalists mistake code-and-fix approaches for Agile approaches, and they're correct that the code-and-fix crowd isn't very disciplined. Compounding the problem is that the code-and-fixers often claim to be agile because they're not writing documentation or not doing code inspections. When traditionalists know how to distinguish Agile teams from code-and-fix teams, the criteria described in the accompanying sidebar "How to Tell the Agilists from the Code-and-Fixers" should help, they'll see that they're mistaken on Agile being undisciplined. This is important because it will enable them to consider Agile in a fair light, and more importantly it may make them start to question how disciplined traditional approaches are in practice.
The Discipline of Regular Delivery
The greatest motivator of discipline within Agile approaches is the regular delivery of working software. The shorter the iteration the greater the discipline required to make it work, and interestingly Dr. Dobb's 2007 Agile Adoption survey (www.ddj.com/architect/200001986) showed that 85 percent of Agile teams prefer iterations between one and four weeks in length. Providing concrete, measurable business value in the form of working software each iteration is incredibly tough because you actually have to do your job. Undisciplined IT professionals hide behind detailed documentation, reviews, or other questionable forms of traditional "earned value," which are little more than promises to deliver something at some point in the future.
There are several agile techniques that you can adopt to get yourself out of the undisciplined rut of traditional "earned value". First, do just a little bit of initial, high-level modeling up front to give you the information that you need for initial planning and architectural decisions (www.agilemodeling.com/essays/amdd.htm). This is often on the order of hours or days, not weeks or months, because your focus is on modeling and not on writing extensive documentation. Second, don't overbuild your software to support some mythical future requirements that may never be applicable but instead work in the priority order as defined by your stakeholders (more on this below). Third, adopt a just-in-time (JIT) approach to planning instead of the false security of a detailed, up-front planning. Mike Cohn's Planning Poker (www.planningpoker.com) is a perfect example of this because it easily enables people who are doing the work to plan it out on a JIT basis. Interestingly, the Agile Adoption survey also showed that the fourth most useful work product on agile projects is a detailed iteration plan yet the least useful was a detailed Gantt chart.
