Agile lore says that Agile processes are best suited to projects that are run at a single locations, staff teams no larger than 15 members, enjoy full-time customer participation, and involve development of new rather than existing (and likely highly integrated) applications. But fewer and fewer projects meets those guidelines and the complexity inherent in these projects is only increasing. So in order for Agile processes to truly meet the needs of large organizations, they must scale. In fact, many companies and consultants have effectively adapted their Agile processes to meet current-day requirements. As I work with IT organizations and independent software vendors (ISVs), I've found quite a range of best practices that organizations can adopt to achieve large-scale Agile development.
Of course, every company categorizes its projects differently. Large-scale Agile projects can mean those projects that:
Span multiple geographic locations and thus involve developers from different companies and cultures.
Comprise teams with 50 or more members, many of whom have no Agile experience.
Are building business-critical applications and/or those that must comply with significant regulatory requirements.
Require integration with legacy (mostly non-Agile) applications and third-party software packages.
Include a number of sub-project teams that must integrate their individual systems to build the final "application."
Scaling Agile Projects Most managers that I speak to try to tackle only a few of these challenges in early Agile projects, and then introduce other large-scale factors in subsequent projects. It's not surprising that many of the largest projects involve Agile consultants and mentors; the industry is
Advertisement
only just building capabilities among in-house IT developers. Also, many IT shops look to ISVs for best practices, appreciating the rigor with which professional developers (who only make money if they deliver quality software) work.
Teams have succeeded with large-scale Agile development by:
Managing large teams. It's common to see large organizations begin their Agile experiences by adopting Scrum. As teams or projects grow in complexity, they may also implement a "Scrum of Scrums." In this scenario, a representative from each Scrum team, after its daily meeting, joins up with those from other teams and provides information and collects feedback across teams. Mike Cohn of Mountain Goat Software notes that these Scrum of Scrum meetings don't need to take place every day; some organizations find two to three meetings a week to be sufficient.[1]
Providing visibility into multi-site development. Developers at a single site can easily adopt Agile practices, but collaborating across sites presents a new set of challenges. Here's where technology for collaboration and management becomes a necessity. For example, Lockheed Martin is introducing Agile processes to a large traditional waterfall-run organization. Several hundred developers, working at multiple locations, are responsible for developing components for the latest modern fighter aircraft. Metrics and visibility are critical to communicating progress to management. Lockheed uses VersionOne's tools to provide multi-site information in the form of burndown and velocity charts, among other metrics. Once educated, managers appreciate the value of these types of reports - especially when compared to traditional multi-page Gantt charts.
Running Agile projects offshore. It's clear that Agile development can succeed on offshore projects, even in organizations with traditional CMMi focus. For example, ThoughtWorks' Bangalore staff use continuous integration, written test scripts, wikis, and ongoing meetings among ambassadors (back and forth between on- and offshore sites) to ensure seamless collaboration among teams in the US, UK and Europe, and India.[2]BMC Software uses Scrum and Rally's tools to manage product development teams in the US, Israel, and India.[3]
Supporting incredibly high volume and high visibility applications. Among the most highly publicized Agile teams are those from companies like Google and Yahoo. These represent some of the highest volume Web-based applications and yet the teams have successfully used Agile processes to ensure their successes. As another example, British Car Auctions (BCA), the largest vehicle remarketing business in Europe, worked with Conchango to extend its Vehicle Inventory Management system to improve levels of customer service. This core system schedules and manages the entire remarking process for over one million vehicles per year, and requires integration with BCA's core transactional systems and databases. To meet its aggressive goals, management mandated a number of Agile practices such as requiring teams to complete iterations in four weeks and requiring end-users to provide total involvement and commitment.
Investing in productive tools. As we discussed in articles in the August 2006 Agile Journal, tools are an essential component of a large Agile project and they are do not detract from a team's emphasis on people. Productive tools do not necessarily mean formal development tools - many companies turn to and extend open source tools to suit their needs. For example, working with Digital Focus, CNSI developed a Web-based application for Medicaid claims processing. The teams used a wiki (FitNesse) to show project status and built some custom widgets to show real-time progress graphs for each team's velocity, unit test count, etc. They also used WebEx and conference calls to "get everyone together" for iteration kickoff and user acceptance testing meetings.
We're Not There Yet
The body of large-scale Agile experiences is growing and most developers acknowledge that this may be difficult, but certainly possible. Large software vendors are writing articles and presenting case studies of their customers' success - and this is certainly important to their traditional corporate customers.[4] But we're certainly not there yet. There are a number of issues related to large and complex development projects that do not (yet) fit well with Agile processes.
Addressing regulatory compliance requirements is at the top of this list. Sarbanes-Oxley is required for all U.S. companies, industry regulations such as HIPAA and Basel II pose specific challenges to development projects, and overall governance is a line-item on many IT budgets. Some consultants, such as Agile Logic, are beginning to incorporate this important dimension of an Agile project into their services. Microsoft MSF for Agile Development (industry criticism aside) is pragmatically including guidance on compliance from the start. This is certainly an important topic to watch in 2007.
Also, technical issues revolving around distributed offshore development - including integration of legacy code, packaged software, architectural components, and open source software - are also likely to gain attention in the coming year as companies expand their use of Agile processes on larger and more critical development projects. Agile consultants from Eastern Europe and Russia are entering the market and are competing against Indian firms with pragmatic offerings, particularly those that address international business issues.
The debate about the applicability of Agile processes on large-scale projects isn't over, but it's certainly losing power. Vendors, consultants, and developers themselves have a vested interest in putting the whole topic to bed.
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)
Ade Miller: ...
If your interested in scaling agile to large teams/projects then the following expereince report from Agile 2007 may be useful. It covers rolling out a more agile approach to a 70 person product team that was part of the Visual Studio suite.
“Agility and the Inconceivably Large” - Ade Miller & Eric Carter
Articles 
