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

The Agile Edge 1. Face to face (F2F) discussion (4.06) 2. F2F at whiteboard (3.46) 3. Overview diagrams (1.89) 4. Overview documentation (1.86) 5. Video conferencing (1.62) 6. Teleconference calls (1.51) 7. E-mail (1.32) 8. Detailed documentation (0.16) 9. Online chat (0.15) There are several interesting observations to be made. First, the belief that traditionalists have in the value of detailed documentation can be understood as it has neutral value, regardless of all the rhetoric that we hear in the agile communities surrounding the evils of detailed documentation. Second, sharing overview documentation with stakeholders does seem to have some merit, although it is nowhere near as effective as direct communication, clearly belying some agile prejudices against documentation. Third, media richness theory, which Alistair Cockburn introduced the Agile com- munity to (see www.agilemodeling.com/ essays/communication.htm), pretty much holds. The “hotter” the communication channel, generally the more effective it appears to be. Fourth, these results may explain why distributed agile projects appear to be riskier than colocated projects because the greater the distribution, the more restricted your communication options become. Dr. Dobb’s 2008 Agile Adoption Survey (www.ddj.com/architect/ 207600615) found measurable differences in the success rates of distributed agile projects—83 percent for colocated agile teams, 72 percent for near-located agile teams, and 60 percent for far-located agile teams. Agile Modeling and Documentation Best Practices So now that we know that agile developers are in fact modeling and writing documentation on a regular basis, it begs the question why so many myths still exist. I believe that there are three primary reasons. First, the agile community struggles to coherently describe what they do in practice. For example, if you mention up-front modeling on many popular agile mailing lists, the conversation almost instantly devolves into ranting about the evils of big design up-front (BDUF) and extraneous bureaucracy with virtually no mention of what people are actually doing. Second, many traditionalists fear agile software development approaches because they require a different skillset and often greater discipline to succeed at agile. The “new rules” around agile development are naturally scary to anyone not familiar with them or anyone who hasn’t taken the opportunity to make the transition yet. Third, the lack of detailed written specifications early in the project can make it seem that agile teams aren’t modeling to traditionalists who aren’t familiar with Agile Model Driven Development (AMDD)-based approaches. For example, we saw in Figure 1 66 Dr. Dobb’s Journal l www.ddj.com l November 2008 http://www.agilemodeling.com/essays/communication.htm http://www.agilemodeling.com/essays/communication.htm http://www.ddj.com/architect/207600615 http://www.ddj.com/architect/207600615 http://www.mcobject.com http://www.imagix.com http://www.mcobject.com/enterprise http://www.ddj.com

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

Dr. Dobb's Journal - November 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer's Notebook Saving Open Source Conversations iPhone Building Your Own Web Server Green Telnet What's New In Boost Threads? Testing Service Oriented Architectures Test Case Generation, UML, and Eclipse Unit Testing Web Services C3 Programming The Agile Edge Swaine's Flames Effective Concurrency

Dr. Dobb's Journal - November 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.