Big agile

it's not just for small projects anymore Jesse Fewell.

Abstract

One of the stereotypes for agile approaches is that they only work for small projects. Ten or 15 years ago, that might have been the case, but things are vastly different today. Agile techniques now are used as part of the day-to-day project operations for the largest telecom in Europe to the largest DotCom in the United Kingdom. But how does self-organization work for a thousand people? How can you possibly run a large program without any documentation or architecture? In this paper, we will explore both recent trends as well as actionable tips for growing out of small agile into big agile.

The Roots of Small Agile Teams

The agile movement as it exists today was formally launched by the release of the Agile Manifesto in 2001 (Beck et al, 2001). The document was designed to identify the project management elements common to a variety of “lightweight project methods,” the successes of which had generated notable momentum at the time. The elements codified by the document include four values and twelve principles, many of which center around the structural attributes of successful teams.

Elements of the Agile Manifesto Specifying Team Structure

Exhibit 1 – Elements of the Agile Manifesto Specifying Team Structure

Many of these elements are inspired by the successes of smaller projects of fewer people. Indeed, several of the lightweight methodologies influencing the Agile Manifesto, call for exactly that. The eXtreme Programming method was designed for project teams of two to ten people and the Scrum framework specifies teams, ranging from three to nine individual contributors (Beck, 2004).

This emphasis on small teams is not uncommon. Exhibit 2 shows one example among many studies and sources, in which the United States military has cited the increased successes that often accompany smaller project teams (Mitre, 2004).

US Military Guidance on Team Size for Technology Projects

Exhibit 2 – US Military Guidance on Team Size for Technology Projects

Case Studies for Scaling Agile Methods

Yahoo (Benefield, 2010)

In 2005, Yahoo began the implementation of agile methods as a means to maintain an Internet startup culture in, what was at the time, a US$32 billion company. Here are the lessons learned:

  • Coach, don't Dictate – Several teams did not respond well to strict adherence to the defined processes. Sometimes because of the need for process tailoring or sometimes because of a lack of grass roots support, change advocates need to be flexible when rolling out agile methods across a large organization.
  • Fund the effort appropriately – As agile methods became more popular throughout the organization, there were not enough staff available in the agile PMO to adequately support with training, tailoring, and coaching. Surveys revealed those teams that did not receive appropriate support reported dramatically less performance and satisfaction. To mitigate the losses, it was calculated that one agile coach should be funded per 100 project team members.
  • Align with Management – Agile methods are a means to a strategic end. They should be aligned with the goals and needs of leaders throughout the organization, whether the PMO or the various managers of functional organizations.

Nokia/Symbian Merger (Clare & Measey, 2009)

In 2009, Symbian's merger with Nokia involved more than 2,000 employees in offices across the United States,

Finland, India, and China. These are the lessons highlighted in the case study:

  • Stakeholder management is key. The use of agile methods is a means to an end. If organizational leaders and influencers are not aligned on the intended outcomes, then any effort to implement and standardize those methods will be put at risk
  • Structured rollout across years rather than months. Implementing agile methods on a small team of ten people is fairly straightforward. Scaling that implementation to dozens and hundreds of teams requires significant change management across many departments and business units. Be prepared for the long journey.
  • Benefits real but not measurable. In larger organizations, any number of change initiatives or process improvements can be in flight at the same time; therefore, it becomes more difficult to draw a line of sight from measurable business benefits to the changes specific to agile methods. Change leaders will need to explicit with achievable goals.

John Deere (Goldsbury, 2012)

Starting in 2010, one of the largest equipment manufacturers in the world made a wholesale shift in the use of agile methods for building its electronic systems. Here are the lessons:

  • An all-at-once implementation can work – Because John Deere's products are tightly interwoven, a gradual adoption would have required using a variety of project management methods at the same time, creating an unwieldy coordination problem. As such, they opted for a more dramatic change effort, starting with 150 people in one week, and then adding another 100 people at a time over the next 6 months.
  • Involving your offshore partners is critical – To improve coordination, John Deere aligned the project timelines and iteration schedules with across their offices. This also required aggressive involvement of all the related offices in the agile change effort, as well as broad-based training in agile methods.

Best Practices for Project-Wide Implementation

When implementing practices across larger projects, these case studies and others reveal general best practices.

Decompose projects into collections of small teams.

There are always projects that need more than the ten people per team prescribed by agile methods. In these cases, projects will need to charter a project with several proper, self-sustaining agile teams.

Align schedules across teams

To avoid scheduling complexities, agile teams working on a common project scope should operate on a common iteration schedule. Exhibit 3 illustrates this dynamic.

Align Team Schedules

Exhibit 3 – Align Team Schedules

Charter Domain Committees

Larger organizations often incur delays, as one group waits for outputs from another group. To remain productive, teams need more details to overcome such delays and be productive. Projects should charter committees for each of the areas that impact the delivery teams, such as requirements definition, architectural direction, or testing strategies. These committees are responsible for converting high-level goals into actionable direction for the agile teams.

Best Practices for Program/Portfolio-Wide Implementation

Flow projects into stable teams

Many functional and matrix organizations will charter a team for a given project, and then disband the teams upon the project's completion. Agile methods emphasize the institutional value of project teams, and require that teams remain stable much longer than otherwise planned. Although this incurs additional effort on slicing work to fit existing teams, doing so dramatically simplifies resource planning and tracking of labor budgets, as shown in Exhibit 4.

Flow projects into stable teams

Exhibit 4 – Flow projects into stable teams.

Best Practices for Program/Portfolio-Wide Implementation

Establish a product ownership team

Agile methods emphasize the value of real-time scope decisions by a singular authority, often called the “Product Owner (PO)”; however, the complexity of larger programs tends is such that any given deliverable often requires the outputs from several teams, coordinated by a project manager. This dynamic incurs a complex dependency network that should be replaced by the advance planning of a cross-functional planning team. This approach strikes a balance between plan-driven methods and the real-time decisions advocated by agile methods. Exhibit 5 illustrates the contrast.

Installing a Product Ownership Team across Agile delivery teams

Exhibit 5 – Installing a Product Ownership Team across Agile delivery teams

Best Practices for Organization-Wide Implementation

Convert one business unit at a time

Most large-scale agile implementations have initially been championed by technology units. Once those business units start showing measurable business improvements, then the value and appropriateness of the methods are better known.

Revisit Career Paths

Self-organizing teams take more ownership of their daily assignments. This can leave many career project managers and functional managers feeling their organizational value eroding. The risk is that these employees will leave, and take their seniority and intellectual capital with them. As with any major change initiative, efforts should be made to re-craft the roles and responsibilities of leaders. Specifically, if leaders are relieved of the overhead of more tactical directions, they can begin to be leveraged more strategically. This kind of transition should be broadly communicated and appropriately rewarded.

Communicate Victories

Many agile champions seek organizational change as a prerequisite to effective project delivery. However, most of the change management methodologies define cultural change as the result of new collective experiences. Once programs begin to improve business outputs, senior management should broadcast those results. Then, with the value of agile methods conveyed throughout a business unit, other programs and units will be naturally motivated to leverage the methods for their own benefits.

Conclusion

Agile methods were very much founded on the science of small teams. To the surprise of many, larger projects and programs have experienced the value of those methods for several years. But they have only done so by tailoring the methods to address specific challenges.

Beck, K., et al., (2001) Agile Manifesto. Retrieved from http://www.agilemanifesto.org

Beck, K. (2004). eXtreme Programming Explained. USA: Addison-Wesley

Benefield, G. (2010). Rolling out Agile in a Large Enterprise. Retrieved from http://www.controlchaos.com/storage/scrum-articles/YahooAgileRollout.pdf

Clare, H., & Measey, B. (2009, October). Enterprise Agile at Symbian and Nokia. Scrum Gathering Munich, Munich, Bavaria, Germany. Proceedings retrieved from http://www.scrumalliance.org/resources/1108

Goldsbury, C. (2012). Your Tractor Was Built With Agile. Retrieved from http://www.infoq.com/news/2012/03/deere

Schwaber, K., & Sutherland, J. (2013). The Scrum Guide. Retrieved on from https://www.scrum.org/Scrum-Guides

The MITRE Corporation (2004). Key Success Factor: Team Size. Retrieved from http://www.mitre.org/work/sepo/toolkits/ippd/StandardProcess/factors/KSF10.html

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2013, Jesse Fewell
Originally published as a part of 2013 PMI Global Congress Proceedings – New Orleans, LA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.