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

d11ambler_p4ma 9/10/07 11:38 AM Page 60 The Agile Edge by Scott W. Ambler Governing Agile Software Development Working closely with stakeholders is the key NOW THAT AGILE has crossed the Moore’s technology adoption chasm, I’m seeing more and more organizations asking serious questions about Agile software development. According to the Dr. Dobb’s 2007 Agile Adoption Survey (www.ddj.com/architect/ 200001986), 69 percent of organizations in North America have run Agile pilot projects and 85 percent of them have run several. Now that organizations have gotten their feet wet, they’re starting to think about how to scale Agile approaches to meet their real world needs. A critical question that many people are asking is, “How do you govern Agile projects successfully?” The answer, which often surprises people, is that it’s a heck of a lot easier to govern Agile projects than traditional ones. Many traditionalists will claim that Agile projects are difficult to govern, but nothing could be further from the truth. To be fair, most of these people are likely confusing code-and-fix projects with Agile projects, and without a doubt, code-and-fix projects are virtually impossible to govern. There are two aspects of Agile software development that promote superior levels of governance when compared to traditional software development. First, the Agile approach of producing working software on a regular basis provides stakeholders with greater visibility into what a project team is actually doing. Second, the greater level of involvement provided to stakeholders— they control the budget, scope, and schedule on Agile projects— enables them to direct the project teams effectively. discussed last month, we find that Agile teams must be far more disciplined than their traditional counterparts to actually make this work. Greater Stakeholder Control With the approach in Figure 1, stakeholders can change their requirements at any time, they can add new ones, and they can reprioritize existing ones, putting them in complete control of the scope. This works when the development team writes high-quality code that is loosely coupled and highly cohesive, when they refactor when required to keep their design of high quality, and when they have a regression test suite, which they run regularly. It’s very easy to add new functionality to an existing code base in this sort of situation, particularly when the team invested a bit of time at the beginning of the project envisioning the architecture with a bit of initial Agile modeling. Because Agile teams ask stakeholders each iteration how much they want to invest, our stakeholders are effectively in control of the budget—and rightfully so seeing as it’s their money that is being spent. When stakeholders have insight into the actual status of a project team, and when they can change the funds that each team receives each iteration, they’re in a position to actually govern IT projects. Figure 2 shows the current status of a collection of software development projects. The height of each stack indicates the relative amount of work the individual teams have left, the color of the stack indicates the current status, and the number of the top of the stack indicates the expected ROI of the system under development. With this sort of information, stakeholders can make intelligent governance decisions. For example, the projects with red status clearly need to be redirected, and I’d even consider canceling the low ROI one at this point. The yellow status projects also could use some help. From a portfolio-management point of view, I’d consider increasing the funding to the high-ROI green teams because I want to put my money into successful teams that provide the greatest value. In other words, with an Agile approach, stakeholders can start treating their IT investment as an investment. Following a traditional approach, it often seems that money spent on IT is more of a gamble than an investment, and I think that it’s because of the lack of visibility and control that traditional teams provide to stakeholders. Stakeholders are put in control of the schedule as a side effect of producing working software each iteration: We can be six months into a project and the stakeholders can tell us that we’ve delivered sufficient functionality to justify delivery into production. In combination with working in priority order, they can drive Agile development teams to deliver a system to the marketplace at the earliest opportunity. Informal Visibility Into Projects Figure 1, modified from OpenUP (www.eclipse.org/epf), overviews the strategy for scheduling work on an Agile project team. This strategy is an extension of Scrum’s requirements management strategy to take into account all types of work items that software development teams perform. Not only do we implement requirements, represented as ovals in Figure 1, we also set up workstations, experiment with new technologies, take vacations, attend training courses, and other team health activities. Obviously, there are trade-offs involved with prioritizing nonrequirements-related work into the work stack. During each construction iteration, Agile teams develop working software, fulfilling the highest-priority work items from the stack and thereby providing the greatest return on investment (ROI) possible. By delivering working software each iteration, stakeholders get clear feedback as to what the team is achieving. This “informal visibility” into development projects is far more valuable than the traditional documentation-based “earned-value management” (www.earnedvaluemanagement.com) because it’s concrete. Stakeholders don’t have to rely on the promises made in traditional status reports, or in comprehensive requirements documentation, but instead work with actual software and determine if the team is actually delivering value. Stakeholders can provide immediate and valuable feedback to the team, steering them in a better direction if the team gets off track. As I 60 Dr. Dobb’s Journal l www.ddj.com l November 2007 Formal Visibility Sometimes the informal level of visibility provided by working software each iteration isn’t enough for some organizations, usually because they find it difficult to measure what they got. Although you http://www.ddj.com/architect/200001986 http://www.ddj.com/architect/200001986 http://www.eclipse.org/epf http://www.earnedvaluemanagement.com http://www.earnedvaluemanagement.com http://www.ddj.com

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

Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Smart Compilers - But Smart Enough? Conversations Grid-Enabling Resource-Intensive Applications Distributed Computing: Windows and Linux Adobe AIR: Desktop/Web Convergence Transparency on Demand Reusable Associations Effective Concurrency The Agile Edge Swaine’s Flames

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