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

The Agile Edge on traditional teams. First, Agile teams not only do a bit of initial architecture modeling at the beginning of a project, they also do the work necessary to prove that the architecture works early in the lifecycle. This practice, common in the Unified Process, reduces technical risk because it doesn’t assume that the architecture works simply because the architects say that it will. It requires greater discipline than the traditional approach of detailed up front modeling because it becomes very clear very quickly whether the team actually has what it takes to deliver a working system. Second, identifying quality of service (QoS) requirements, such as security and usability issues, and then convincing business stakeholders to weave them into their prioritized work item stack requires significant skill and discipline. It would be undisciplined not to address these requirements at all, but almost as bad would be to invest months at the beginning of a project to address them before delivering anything of business value. Yes, it’s a lot of fun to work on cool technical frameworks, but that isn’t what our business stakeholders are actually paying us for. The third scalability issue surrounds software process improvement (SPI). The Agile approach is to regularly, at least once an iteration, take the time to consider how effectively the team is working together and whether something can be done to improve things. This continuous SPI approach enables Agile teams to take advantage of their insights right away, improving their productivity throughout the project. It would be undisciplined not to attempt SPI at all or to wait until the end of a project to identify “lessons learned” in project postmortems that do little more than give people a sense of closure after their traditional death march. The Discipline of Teamwork Agilists, when given the opportunity, will rarely work alone because they know it is too risky to do so. It requires discipline to follow non-solo practices such as pair programming and modeling with others because it’s too easy to assume that you’re smart enough to get the job done quickly by yourself. It also requires discipline to be responsible for the entire system, not just your little part of it, motivating you to work closely with and thereby learn from people with different backgrounds than your own. It requires discipline on the part of management to stay out of people’s way and allow them to self organize, even when it’s clear that the team is likely making a mistake, and not try to plan everything in detail for the team. Providing people with learning opportunities such as this can be frustrating at times but is absolutely critical for growing your staff. Another aspect of agile project management discipline is the act of holding a daily stand up meeting to promote communication within the team about issues that really matter, such as what everyone is doing and what problems they’re running into. This forces you to confront and deal with problems as they arise, instead of papering them over with overly optimistic status reports. Agile software development, when done properly, is highly disciplined. Agile is much more highly disciplined than traditional development, which in turn is more disciplined than code-and-fix development. If anyone tells you that Agile isn’t disciplined, then ask if they have ever been involved with an Agile project, and if so, whether it met the criteria defined earlier. I have yet to meet someone with both real-world Agile and traditional experience who claims that traditional is more disciplined, and it appears to me that traditionalists are clearly throwing stones in their glass house by claiming otherwise. I’d like to thank Ted Rivera of IBM for his detailed feedback regarding the initial draft of this column and Bill Krebs, also of IBM, for the various insights that I gleaned from him in the conversations that we’ve had around this topic. DDJ Scott is a DDJ Senior Contributing Editor, Practice Leader Agile Development with IBM Rational, and author of several best-selling books. He can be contacted at www.ambysoft.com/ scottAmbler.html. 62 Dr. Dobb’s Journal l www.ddj.com l October 2007 http://www.rallydev.com/ddj http://www.rallydev.com/ddj http://www.ambysoft.com/scottAmber.html http://www.ambysoft.com/scottAmber.html 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.