Taking Agile to Scale

Lessons from a Multiteam Development Program

Click HERE to download the PDF

Click HERE to read the full report


Agile development’s emergence in the late 1990s triggered major changes in software development. Originally intended for small, co-located teams, the agile approach soon drew favor from project managers leading large-scale efforts, often characterized by multiple teams, higher levels of risk, and a legacy of cost overruns and late completions.


Agile development approaches embrace change by moving decision authority to the team level, making the team responsible for rough long-term plans and detailed short-term plans.

This study explores the evolving impact of agile practices on large-scale software development programs with an emphasis on multiteam coordination.

Case Study: The Perform Program

The research report focuses on lessons learned from Perform, one of Norway’s largest software development programs. Perform successfully combined agile and traditional project management practices to deliver a new office automation system—on time and on budget—that incorporated changes to the Norwegian Public Service Pension Fund.


Managers organized Perform as a matrix program with four main projects intersecting, primarily through personnel from the software development teams. The lead director focused on external relations and a program manager worked on internal operations. A different manager led each of the four main projects: business, architecture, development, and test projects.

Modes of Coordination in Large-Scale Software Development

The Perform case study demonstrates coordination is critical when managing large programs with multiple teams. Perform utilized three main coordination modes:

Group Mode of Personal Coordination initially emphasized more structure and organization in the project’s early stages. Scheduled meetings at program and project levels allowed participants to gather and share information.

At the program level, demonstration meetings held every three weeks provided the only opportunity for everyone to meet. Managers met two times a week in a “metascrum.” The metascrum included managers from the main projects and the central program. They discussed high-level obstacles to progress and assessed risks.



Well into the program, managers introduced a new arena called open space technology. Through this, team members discussed challenges and improvement initiatives. More informal, unscheduled meetings focused on identifying interdependencies in tasks before assigning work to individual teams. Throughout the multi-year project, groups met to discuss overall software architecture and project management.

Individual Mode of Personal Coordination entailed direct informal coordination between members of different teams using both horizontal and vertical channels. Managers enrolled new team members during the build-up phase. They split teams and redistributed members to facilitate this process. Project leads consciously used team changes as an important mechanism for distributing knowledge and enabling coordination. However, as team identity strengthened over time, members increasingly resisted these changes.

Open collaboration enabled team members to ask other teams and organizations for advice, to address dependencies between tasks, and to keep tasks on schedule. Social arenas, such as lunches, functioned as coordination mechanisms throughout the project. Relevant stakeholders discussed decisions in these informal settings and later formalized them in team meetings.

Impersonal Mode of Coordination mechanisms included the program plan, guidelines, and checklists. The program plan encompassed all necessary project tasks or “epics.” Initially electronic spreadsheets documented all epics. A year into the program, an issue tracker replaced the spreadsheets. Managers introduced the new tool at the same time as a major project plan revision.

Project participants regularly updated the tracker, and its use was mandatory for all teams. Additionally, teams duplicated their tasks with stickers on a board located in their workspace. This allowed management to easily see the status of the team’s work. Moving stickers to indicate the completion of a task was also valuable for team morale.

Directors required everyone to use a wiki (collaborative website) that hosted all the process description documents, guidelines, and checklists.

img Findings

Among its conclusions, the report presents three main insights for the project management community to consider when adopting agile software development practices for multiteam projects:

img img img
An increase in task uncertainty led to replacing impersonal coordination with horizontal coordination mechanisms and group meetings. Personal coordination proved vital to achieving inter-team coordination in large programs. In contrast to traditional large-scale agile development, which focuses only on the Scrum of Scrums mechanism for coordination, agile methods for multiple teams rely on many mechanisms spanning all three modes of coordination. Coordination practices change over time. Scheduled meetings in the Perform program’s introductory phase gave way to unscheduled meetings and other mechanisms as needs changed.

img OVERALL TAKEAWAY: For successful multiteam agile software development, project managers need to focus on coordination and remain flexible to allow modes of coordination to change over the life of a project.

The knowledge represented here comes from research done by the SINTEF research foundation and from the Norwegian University of Science and Technology in Trondheim, Norway.

To read the full report, visit pmi.org/learning/academic-research.

You can also view the webinar recording about the report:



14 Campus Blvd | Newtown Square, PA | 19073-3299 USA

Tel: +1 610 356 4600 | Fax: +1 610 356 4647

e-mail: [email protected] | PMI.org/research

© 2021 Project Management Institute, Inc.

All rights reserved. “PMI” and the PMI logo are marks of Project Management Institute, Inc.



Related Content

  • Project Management Journal

    Investigating the “Socio” in Socio-Technical Development member content locked

    By Hennel, Phil | Rosenkranz, Christoph We propose a model that conceptualizes the effects of psychological safety and (social) agile practices on team performance.

  • PM Network

    Bridging Ambition and Ability member content open

    By Parsi, Novid Agile is everywhere, but not every organization is ready for it. According to the 12th annual State of Agile survey published by CollabNet VersionOne, 41 percent of organizations cite a lack of…

  • PM Network

    The Right Tact member content open

    By Rockwood, Kate In an agile environment, project teams must communicate and collaborate without missing a beat. But with so many quick-hit standup meetings and blunt talk, thoughtful engagement can often get lost…

  • PM Network

    Leadership Limbo member content open

    By Fewell, Jesse With the rising popularity of agile methods, we see more self-organizing teams and specialized roles creeping into project managers' responsibilities. This raises a question: what does the modern…

  • PM Network

    Agile must-haves member content open

    By O'Connor, Gerald Although agile approaches do not prioritize processes, tools and documentation, agile isn't anarchy. In fact, three factors are required for a great experience with agile: a great coach, leadership,…