Dr. Dobb's Journal - March 2008 - (Page 66)

The Agile Edge Agile Myth Agile teams don’t write documentation Reality Agilists treat documentation like a requirement—it gets estimated, prioritized, and “implemented” in the appropriate order. By putting price tags on things, we find that our stakeholders are a bit more selective as to how they choose to invest their hard-earned money. We also prefer executable specifications in the form of tests over static documents (see my February 2008 column for details), reducing the amount if interim documentation created. And of course, we’ll still need to create user documentation, support documentation, operations documentation, and even system overview documentation for the maintenance team. DDJ’s 2007 Agile Adoption Survey found that 93% of Agile teams do whiteboard modeling, 77% of teams do some up-front requirements and architecture envisioning, 66% of Agile teams do paperbased modeling, and 47% of Agile teams use some sort of electronic drawing or CASE tool. Visit www.agilemodeling.com for more information as to how Agilists model in practice, and www.ambysoft.com/surveys/ for details about the survey itself. Agile requires greater discipline than traditional approaches, as I describe in my October 2007 column at www.ddj.com/architect/201804241. Agile teams do as much planning, and often more, than traditional teams, but they do it in a different way. The 2007 Agile Adoption Survey explored the value of various work products on Agile teams and found that the 5th most valuable one was an iteration task list, the agile version of a detailed project plan. The 19th most valuable work product, out of 19, was a detailed Gantt chart (but as VersionOne’s Robert Holler points out, at least it’s in the top 20). Agilists plan, they’re just not creating dubious management artifacts. Agile works best in these situations, as do traditional approaches, but the survey also found that many organizations are now successfully running agile teams of 50, 100, and even over 200. Furthermore, the survey showed that organizations are even succeeding at agile offshoring (albeit at a lower success rate). As I showed in my November 2007 column (www.ddj.com/architect/202401107), agile projects are easier to govern due to the higher stakeholder involvement and greater visibility provided by the regular delivery of working software. Yes, but so does traditional. Agile does in fact motivate people to be generalizing specialists who have a wider range of skills than people who are just specialists. This is a good thing for the individuals because it makes them more employable and it’s good for organizations because their people are more effective. Agile teams don’t model Agile is undisciplined Agile teams don’t plan Agile only works for small, colocated teams Agile is difficult to govern Agile requires talented people Table 1: The myths surrounding agile software development. Flexibility Scales Once you get beyond all of the myths and recognize that it’s not a black-and-white world, it soon becomes obvious that there is no one single agile strategy that is right for all situations. This is true even in the most simple of situations, let alone in the complex situations that we usually find ourselves in— teams are made up of individuals, people who have their own unique experiences, skills and preferences. The implication is that we need to be flexible in the way that we approach software process—that a single “repeatable” approach isn’t going to work in all situations. This is particularly true when you scale agile software development approaches, and that to do so effectively you need to recognize that there are many factors to consider. Each team finds itself in different situations, and depending on where it finds itself with respect to these various factors will determine which agile strategies to apply and how to do so. The critical complexity factors are: 1. Geographical distribution. Is your team colocated (working in the same room), near located (working in the same 66 Dr. Dobb’s Journal l www.ddj.com l March 2008 http://www.agilemodeling.com http://www.ambysoft.com/surveys/ http://www.ddj.com/architect/201804241 http://www.ddj.com/architect/202401107 http://www.rallydev.com/ http://www.rallydev.com/ http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - March 2008

Dr. Dobb's Journal - March 2008 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Social Networks and Software Development Conversations Detecting Bugs in Safety-Critical Code Change Code Without Fear Continuous Integration and Performance Testing Wt: A Web Toolkit Automating Release Notifications The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - March 2008

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.