Home > Articles > Columns > From the Editor > Incremental Agile Adoption

Incremental Agile Adoption

E-mail
Written by Administrator   
Monday, 11 February 2008 15:23
fromeditorSmall steps can lead to big progress, particularly in the case of Agile adoption. Few organizations have the luxury of adopting a new development process in its entirety; legacy processes are too well-entrenched and the cost and risks of change frequently outweigh the short-term benefits. Instead, most organizations considering Agile practices adopt them incrementally, steadily building on their successes and ridding themselves of traditional approaches. Over the course of several projects (measured in months, not years), these teams gain Agile development and management skills and scale their efforts. This article addresses the ways in which companies can adopt Agile practices incrementally, rather than feeling compelled to adopt an Agile process in its entirety.

What are the Real Goals of Agile Development?
Transitioning to Agile processes can, and often should, be done in an Agile way - incrementally, in short cycles, with clearly measurable results.[i]  However, before getting to the how of Agile adoption, teams should remind themselves of what they're trying to accomplish. Agile processes are generally intended to help teams achieve some high level goals:
  • Delivering business value to the customer on a frequent basis.
  • Producing high quality software.
  • Responding to changing requirements, as defined and prioritized by the business.
There are many ways that teams can achieve these goals. Unfortunately, the discussions about whether an organization is "Agile" or not are still taking place.[ii] These debates are a waste of time and energy; giving a team an Agile, waterfall, or any other label has no bearing on the products that it produces.   

It is important to understand the details behind specific Agile processes, as they differ greatly from iterative or waterfall process.[iii]  But Agile adoption is a journey that provides benefits all along the way, not only to those who feel they have completed it! By focusing on business-driven priorities and short feedback cycles, companies can become more responsive and flexible in the ways that they build software and steadily reap the benefits that Agile practices can deliver.

{sidebar id=1}How to Accomplish These Goals
It is true that some organizations, such as new product development companies and a few leading-edge IT shops, successfully adopt full lifecycle Agile processes all at once. At industry conferences and in case study white papers, we can learn of these companies' experiences and the synergy achieved by Agile development and management practices. But, realistically, only a small number of organizations are unencumbered with legacy systems integration requirements and are able to absorb this degree of change and disruption within their development teams.

Many companies are headed in this direction, but must do so in a more step-wise fashion. Incremental Agile adoption can start from the top down, by introducing Agile team management practices, or from the bottom up, by using selected Agile development and testing practices. Factors such as the organization's culture, existing legacy platforms, receptivity of IT staff, location and size of teams, etc. will frequently drive these decisions. Within these broad frameworks, large IT shops commonly take one of four common Agile first steps: implementing short iterations, conducting daily meetings with IT and business participants, insisting on early and comprehensive unit testing, and implementing an automated continuous integration environment (see Figure 1). Depending on the starting approach, choice of subsequent practices may vary, but it is easy to find teams that have addressed these four areas among their earliest Agile practices.

Short iterations, frequently two weeks and rarely longer than four weeks, lie at the core of every Agile process. Scrum practices provide a straightforward way to address the definition and delivery of short iterations. Techniques for Agile team management can be introduced regardless of the development process. This means that Scrum can be used on a number of teams, providing commonality across different architectures, toolsets, and techniques. Some would argue that teams starting by just shortening their cycles are essentially implementing mini-waterfalls. So what? As long as this isn't the end game, it's a good way to address some core problems common to development teams: endless requirements and analysis phases, inability to contain scope, and poor relationships with business customers. If the date is fixed, then something else has to give - and teams quickly learn that scoping requirements is the logical step. Incremental Scrum adoption is probably the most common scenario for shops new to Agile processes. As the customers accept the fact that future releases are only weeks or months away, they gain confidence in the process.

Daily stand-up meetings provide a vehicle for the entire team - not just IT staff - to discuss progress and address issues on a timely basis. Managers use these sessions to not only resolve issues, but also to build a stronger team community. You could argue that any development organization could implement daily status meetings but that wouldn't make them Agile. However, daily meetings - and thus the need for quick issue resolution - lead to changes in developer practices and team collaboration. Daily meetings must be kept short or they risk spiraling into finger-pointing sessions or getting side-tracked, as can be the case in code reviews.[iv] For distributed teams, there are a few common approaches to bringing the team together: conducting daily intra-site meetings and then less frequent inter-site sessions (usually using some sort of collaboration technology); juggling time schedules so that geographically distributed teams have some overlap of their daily working hours; and using a "Scrum of Scrum" approach to roll up collocated team status into an overall global daily meeting.

Unit testing can be a critical component of any Agile development team's success. On Agile teams, unit tests are created and performed by developers early in the life cycle and are second only to the code itself as valued assets. By surfacing problems early in a project, team members have the ability to respond quickly and reassess customer requirements. While not all unit testing is automated, IT shops have been steadily investing in automated (usually functional) testing for years. Open source tools (e.g., JUnit, FIT/FITnesse, Selenium) provide a path of least resistance for many early Agile testing initiatives. In XP, "any program feature without an automated test simply doesn't exist."[v] Test-driven development leads to changes in developer and tester roles and responsibilities, and provides quantitative input to daily team meetings.

Continuous integration(CI) is probably the most important technical investment that an Agile team can make.[vi]  One of the core practices of XP, CI helps teams improve development productivity, software quality, and also visibility into the project. In essence, developers are obligated to integrate and verify any changes they submit to the shared code base. In The Agile Success Factor: Continuous Integration, Kirk Knoernschild notes that "teams successful with continuous integration have mastered knowing when to perform software lifecycle activities to maximize the necessary feedback at the appropriate moment in time." While not a requirement, successful CI typically implements a productive toolset that includes software configuration management, build management, and automated testing. 

lb0208-1
Figure 1: Common ways to begin using Agile practices

Broader Issues To Tackle
Regardless of the initial practice chosen, Agile teams typically face some broader organizational challenges. Many are caught off guard by the magnitude of these challenges and the necessity for incremental change. Three stand out as they confront the legacy IT organization's status quo: integration with the program management office (PMO), staff training, and solutions for geographically distributed teams. Pilot projects must therefore also pilot Agile metrics, training, and collaboration, alongside the new development practices.

  • Communicating with the program management office (PMO). It is difficult to integrate the process and metrics of an Agile team with those of a traditional PMO. Agile teams typically measure progress in terms of value and functionality delivered, while the PMO measures against predetermined plans and budgets. This isn't something that can be resolved quickly, but it's amazing to see how many teams are surprised by this disconnect.[vii]
  • Cross-training staff. We've spent years training developers to become specialists, drilling down into specific roles such as analysts, designers, programmers, and architects. Agile teams demand generalists, so that every team member can understand all requirements and artifacts built along the way.
  • Supporting distributed teams. Few organizations have the luxury of collocated teams - even if you could get all the developers together, the customers and business management are typically in other locations. So you can't assume that you can build Agile expertise and then address geography. Multi-site collaboration demands technology solutions as well as interpersonal skills.
The key message here: starting slow is the way to go. For the vast majority of companies interested in Agile practices, incremental adoption represents the most pragmatic way to improve their software development organizations while managing risk. As they implement organizational, process, and technology changes, teams can continually reassess their progress and determine the most pragmatic next steps. It's the Agile way to become Agile.

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 earned her B.S. in operations research and industrial engineering at Cornell University.


[i] In addition to incremental adoption, I defined three other initiatives that I think are necessary for Agile adoption in 2008: investing in staff training and mentoring to build an internal Agile organization; leveraging others' best practices and deliverables as a means to jumpstart Agile initiatives; and investing in metrics and techniques to provide visibility, publicize Agile successes, and easily comply with governance programs.

[ii] The inaugural issue of the Agile Journal in March 2006 addressed the "Agile" versus "agile" debate, and why both can be successful. Read it now - it's still completely valid!  See http://www.agilejournal.com/articles/from-the-editor/%93agile%94-versus-%93agile%94-development.html

[iii] This two-part article provides a good overview to the seven most popular Agile methodologies, XP, Scrum, FDD, Lean, AUP, Crystal, and DSDM: http://www.devx.com/architect/Article/32761.

[iv] In his article "Making Agile Reviews Effective," Kirk Knoernschild describes risks common to code review sessions, and how to make these sessions more productive. Most of his points are relevant to daily stand-up meetings, as well. See http://www.agilejournal.com/articles/the-agile-developer/making-agile-reviews-effective.html.

[v]  "Extreme Programming Explained," Kent Beck, p. 57.

[vi] See Martin Fowler's excellent article on what and why of continuous integration, http://www.martinfowler.com/articles/continuousIntegration.html

[vii] See "The Agile PMO" for Matt Gelbwaks' discussion of the differences between traditional and Agile PMOs, http://www.agilejournal.com/articles/articles/the-agile-pmo.html.

Comments (0)Add Comment


Write comment

You must be logged in to post a comment. Please register if you do not have an account yet.

busy
Last Updated on Tuesday, 12 February 2008 12:40
 

Agile Marketplace - Announcements and Special Offers

AgilePalooza - Serious Learning in a Fun Atmosphere
AgilePaloozas are community events sponsored by VersionOne and Agile Journal.  These one day conferences provide serious learning in a fun atmosphere.   Two tracks are included: Learning Agility and Advancing Agility. Speakers include internationally recognized agile coaches and trainers. The next seminar will be held August 27th in Dallas, TX – use discount code agilejournal and save $20!
Register Here


CollabNet Subversion Edge Improves Governance, Security, Administration

Quickly configure SVN, Apache, and ViewVC with one certified stack, fronted by a powerful UI.
Try our beta version and let us know what you think!


Virtual Conference: Agile ALM for Distributed Development
Learn how Agile technologies can create efficiencies for your business, hear from industry experts, and network with your peers. CollabNet and their technology business partners present two tracks of valuable information—business and technical. This environment will be available until July 20, 2010 at 3:30pm PDT, so please come back as often as you like to access the resources and presentations.
Register Today!