By all accounts, 2006 was an important year in the world of Agile development. Agile processes have hit the mainstream, with even very traditional IT shops showing interest (if not yet investment) in changing the way they develop software. The numbers are growing: over 1100 people attended the Agile 2006 conference in Minneapolis; over 15,000 people participate in Yahoo groups on topics including general Agile development, XP, Scrum, and Agile management (although many belong to more than one group); 700 Agile developers responded to the VersionOne study with their perspectives; and so on. But there's still more ground to cover. There are too many variants of Agile processes, confusing potential adopters. There is little to no experience using Agile processes for commercial off-the-shelf (COTS) applications and related integration projects. Management is focused on business value, governance, and software delivery while Agile advocates still focus on the developer community. Hopefully, 2007 will be a year to address these issues so that Agile processes can become the norm rather than the exception for software developers.
It's OK to be "agile"
I have been fortunate to have worked with IT organizations, software vendors, and professional services firms across industries and nationalities that have been aggressive in transforming their software development practices. Most agree that an incremental approach to Agile adoption is pragmatic: start with a few Agile practices, such as short iterations, continuous integration of code, or test-driven development, and then adopt additional development and management practices when the organization or team is ready.
In the March 2006 issue of the Agile Journal, I defined the difference between "agile" and "Agile" development and argued that both approaches can be valuable to development teams. To recap, agile development refers to teams that are nimble, flexible, and responsive to
Advertisement
business needs, using a variety of iterative development processes. Agile development refers to teams using the specific set of processes including XP, Scrum, DSDM, Lean, and Feature-driven Design. This journal is expressly named the "Agile" Journal, as we are interested in the practices that truly transform a development organization and can deliver benefits far beyond those found on traditional development teams. That said, there are myriad reasons why an organization would desire (or require) a mix of agile and Agile practices and still achieve improvements in quality, productivity, and value delivery to the business. The industry must support those organizations. There are a number of challenging issues that Agile/agile advocates must address in the coming year; religious observance of a particular Agile approach should not be included on any list.
The 2007 Agile Agenda
Instead of continuing the philosophical debates, let's get to the pragmatic issues. What is it that must be addressed in 2007 for mainstream development shops to be successful? I see several issues that have been discussed but not resolved, and a number of issues that don't even make the headlines. But in order for organizations to implement Agile processes on enterprise-wide initiatives, they must:
Consider best of breed Agile practice adoption as an option, not a rebellion We must work to achieve enough commonality among the many Agile approaches so that we're not tied to a specific flavor. Remember the pain of the notation and terminology wars among the object-oriented methodologies in the 1980s? We're almost there again. It's truly disappointing to read the Agile industry leaders slam those using more traditional yet iterative processes (most frequently, RUP), citing their non-compliance with true Agile practices.
The reality is that investment in legacy processes is a big deal for most large organizations, and so change must be incremental. The smaller Agile consulting firms cite their customer successes, but it's rare to find these companies addressing enterprise-wide initiatives. It's the larger (read: old world) consulting firms like Accenture, IBM Global Services, and EDS that must address initiatives of this scale. They are among the slowest to adopt Agile practices yet when they do, their impact is significant. Some Indian firms, including Sapient and Patni, have even developed Agile practices that fit with their CMMi achievements.
Also, we can't hamper the enthusiasm of new adopters who buy into the big picture but can't handle the industry disputes. In a recent conversation, Jonathan Poole, Managing Director for Valtech U.K. put it well. "We must make Agile understandable to people who have not been doing development for a decade." If we're stuck in explaining the different approaches in, say, Lean development versus DSDM, we've obviously missed the point.
Figure out your Agile governance solution
Every company must put into practice some type of governance program. At a minimum, government and industry regulations force compliance down to the application development level. Further, visibility into project risks and progress has become a requirement by most businesses that sponsor IT projects. The inherent visibility created on teams using Agile processes can contribute to an organization's governance program.
So what is the minimum that you need to do to satisfy your organization's requirements? Those that have approached the problem in this way seem to have an easier time adapting their Agile processes. Of course, necessary documentation may force some non-Agile activities, but that needn't impede the progress of the core Agile team.
Incorporate Agile processes on enterprise software projects
IT shops use Agile processes on their custom development and integration projects. Large COTS vendors such as SAP and Oracle have experience using Agile processes within their product development organizations. But we don't see many customers using Agile processes to implement these mammoth software products. Why not? Considering the percent of IT budgets that are directed towards enterprise software projects, it behooves the vendors and affiliated consultants to help customers make the change.
On COTS projects, the two places that teams tend to start are with Scrum and test-driven development. Even without changing the ways in which they customize product processes and user interactions, teams can address requirements, delivery cycles, and effective testing with Agile practices. As vendors move to the Web 2.0 world, this quick turnaround and more instant user gratification will become the norm.
Address deployment and not just development
One financial services organization that I worked with several years ago touted its success in delivering 30 day releases of software products. Its development teams even went so far as to convince customers of the value in their new Agile development processes. But the customers didn't receive this value - the operations organization balked at the rate of change. It wasn't that the customer's couldn't handle the frequent disruptions to their production applications, it was that the operations teams could not deploy the changes at this pace.
The gap between development and production support organizations remains wide, despite years of moaning about these types of problems. The vendors that can effectively bridge development and deployment technologies should be able to make a big difference. The problem is that many of these technologies arise from "big" infrastructures that don't lend themselves to Agile development. For example, IBM's ongoing work to integrate the Rational/WebSphere/Tivoli environments has the potential to automate much of these processes, but doesn't fit easily with Agile development environments. Interestingly, the open source community demonstrates the ease of migration from development to "production" environments in a somewhat seamless manner, while using Agile processes on many large projects.
Measure success in business terms
Delivering value to the business is the imperative for every software development organization. Agile teams should, in fact, have an easier time doing this. I began writing about value-driven metrics for Agile projects several years ago and received tremendous feedback about the appropriateness of such an approach. If you truly prioritize requirements based on business and customer value, you should be able to quantify the value that you have delivered with each release. This is a big change for most organizations, but above all, this is the issue that should make the biggest difference for companies adopting Agile practices.
About the Author Liz Barnett is the Editor in Chief of the Agile Journal and Principal Analyst at EZ Insight Inc. Previously Liz spent 10 years as a Vice President and Research Analyst at Forrester Research, joining Forrester as a result of its acquisition of Giga Information Group. Liz held management positions at Accenture, PepsiCo, and Atelier Research. She also was the Research Director for the advanced software development and advanced network computing research services at New Science Associates, prior to its acquisition by Gartner Group. Liz holds a patent for developing a distributed application development/CASE tool. Liz earned her B.S. in operations research and industrial engineering at Cornell University.
Error, missing joomlaboard config file!
Comments (1)
asif qumer: ...
This article, under the section "It's OK to be "agile"", explains how to start with an gile, and i am very much agree with the idea proposed here, as we have developed a model for the rational adoption and execution of an agile appraoch, which initially focuses on the short iterations, continuous integration of the code, test-driven development, evolving teams and processes, basic agile tools to start with and in short keeping the things flexible, speedy and responsive. later, involves the further practices, as it is very hard to bring a big change in the existing culture.
Articles 
