Dr. Dobb's Journal - October 2007 - (Page 60)

The Agile Edge by Scott W. Ambler The Discipline of Agile Agile isn’t about code-and-fix development 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-andfixers 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. 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. The Discipline of Quality Agile developers take a test-first approach to development where you iteratively write a single test and then just enough production code to fulfill that test. This is easy to say but in practice requires significant discipline because it’s very easy to assume that you, or someone else, will do the testing later. It’s also very easy to assume that you’re writing great code and that you don’t really need to write a test for this “obviously simple” code that very clearly could have nothing wrong with it. As I described in Agile Testing Strategies (www.ddj.com/development-tools/196603549), many agile teams choose to have an independent test team doing investigative testing in parallel to the construction efforts. This requires discipline on the part of the development team because the tester(s) will regularly provide defect stories that should be treated like new requirements to be prioritized and put on their work stack appropriately. True defects, as opposed to potential new features, should be addressed by the team quickly to avoid increasing their technical debt. Traditional teams often let defects build up throughout the project, if they even detect them at all, with the intention of addressing them at some mythical point later, a very risky, expensive, and undisciplined way to work. Following this approach, developers very likely will not provide them with detailed specifications, as it’s not required for investigative testing. Instead, testers are provided with a new build on a regular basis, at least once an iteration although nightly is even better, so that they can work with the most recent version of the system available. Handling this sort of “chaos” requires significant discipline on the part of investigative testers. There are several quality-related development techniques that require significant discipline. First, it is common for agilists to follow shared coding conventions, database standards, and even documentation guidelines, requiring agile developers to conform to the agreed to norm instead of simply following their own preferred approach. Second, it requires great discipline to refactor only what is needed right now for the task at hand and not fixing a lot of stuff that should be done at some point. Third, the discipline of requiring that builds be successful before continuing on with the development of new functionality is absolutely critical because it promotes code convergence within the team and a continual focus on quality. 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 60 Dr. Dobb’s Journal l www.ddj.com l October 2007 http://www.planningpoker.com http://www.ddj.com/development-tools/196603549 http://www.ddj.com/development-tools/196603549 http://www.ddj.com/architect/200001986 http://www.ddj.com/architect/200001986 http://www.agilemodeling.com/essays/amdd.htm http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - October 2007

Cover Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook AI: It’s OK Again! Conversations Visual Cryptography and Bit-Plane Complexity Segmentation Inside the Windows Vista Disk Encryption Algorithm Memory-Aware Components Software and the Core Description Process Logging In C++ Effective Concurrency The Agile Edge Swaine’s Flames

Dr. Dobb's Journal - October 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.