Scaling Agile Teams by Ivar Jacobson

Traditionally many large software organizations have one group to write requirements, other groups design and code, and still others to test, etc. Thus, every group has some form of specialist competency.  This is a kind of “siloed” organization. Project work is moved from group to group, with hand-offs between groups that result in  delay and inefficiency due to loss of time and important information at each hand-off.   This is not agile.

Agile teams tend to be smaller, for instance seven participants, who have broad yet deep skills that cross the traditional “silos”.  Just as every good soccer team has all the necessary competencies to win, agile teams have all the competencies to build good software. In these teams everyone can understand everything and most members can work with everything.  At the very least the testers can make sure that the requirements are testable, the analysts can design and at the least they can understand the code.

Every agile team delivers working code every two to six weeks.  These periods of work are called iterations or sprints.  Usually an agile team starts from one or more scenarios (a user story, a use case scenario) or features and does all the work to implement and test this user requirement.  For the sake of subsequent discussion, let’s call these teams feature teams.

This works very well in a small organization, where all the team members are located together, where the product is relatively small and where teams work on one single project. In a larger organization (for instance a telecom vendor or a bank) or on larger projects we still want to keep the agile teams, but since we may build whole product lines or complete enterprise systems with many parallel projects, we also need more.

To effectively scale the work of many agile teams across many iterations require an organization with two very different, but complementary kinds of units – feature teams and competency groups.  To understand their roles and how they interplay is very important to a large organization.

  • A feature team is an agile team and the fundamental engine of software development, developing software that gives direct value to its users, such as features or use cases.  To build a large software product often requires many feature teams to work in parallel across a number of iterations in a coordinated way. The number of required feature teams and iterations depend on the size of the product.
  • A competency group is a self-managed group responsible for a functional area on the business analysis of the product (loan processing for example), a larger component, such as a subsystem, a function area for test, or any other kind of expertise.  Just as an example, there will be as many competency groups as there are larger subsystems/components in the architecture of the system.  Competency groups are accountable to the same executive as the projects.

Thus, groups and teams are entirely different kinds of organizational units.

For larger systems the feature teams must not only include the basic competencies (analysis, development, test, etc.), but it must also have expertise from the different functional areas of the existing system, such as billing.  Without such expertise, changes to the system cannot be made with confidence.  Some team members are recruited from the subsystem groups, while others come from similar expert groups within analysis and test.

Just as the members of a soccer team return to their own homes after playing, the specialists return to their competency groups when the project is over. In addition to participating on feature teams, the members of a competency group maintain sets of reusable components, for example a large subsystem that usually includes many minor components. Competency group members are experienced in working in ways that achieve a high level of reuse.  In order to achieve substantial reuse, the development of subsystems or components needs to be funded separately from projects.  Thus the funding of the competency groups comes from the top of the development organization, whereas the funding of the feature teams and their associated projects comes from the endeavor (eventually the customer).

As with soccer where the players stay for many matches and for several seasons even, the members of a feature team work together over many iterations (matches) and over many projects (seasons). This encourages effective team collaboration.

People should either work fulltime on a feature team or work fulltime in a competency group - you want them to focus working on one or the other.  Sometimes, the choice is not black or white, but we have to find solutions that give a good balance.  There are many ways to find this balance such as time-boxed responsibility (working for a team 100% during a well-defined period shorter than the rest of the team members), split responsibility with a colleague within a competency group (basically planned rotation), etc.

The interplay between the feature teams and the competency groups is crucial to get good software, quickly and at low cost.  I have used this approach since my time at Ericsson and although this has been challenged many times, it is now a widely used approach for the organization of large software companies.  See for example the presentation by Dave Thomas, Lean and Agile In The Large: Best Practices Beyond Agile Development Teams, JAOO Sydney and Brisbane, 2009.  There is no shortcut!

Although feature teams and competency groups are at the core of scaling agile, we need at the least two other supporting units: the project and the architecture board:

  • A project does all the work that is required for the next release of the product (for a single customer or for the market).  Most of the work for a release is performed by the feature teams, but the project itself synchs up the teams and provides direction to the teams about what they should do during an iteration; it makes sure that the teams don’t overlap, that they work towards an agreed upon architecture roadmap, and it integrates the results from all the feature teams to a deliverable product.  Thus, the project has a coordinating function. A feature team is usually accountable to one project.

Projects are accountable to the beneficiary of its result is set by standards coordinated by an executive.

  • Finally we have an independent architecture board which is small and consist of the technical leaders for the most important subsystems.  The responsibility of the architecture board is to guarantee the integrity of the system and to make decisions on proposed changes to the architecture.  Project managers may be invited when concerned by a decision.    Decisions affecting only a component are made within the competency group itself.

The architecture board meetings, are an important means for spreading knowledge about the system and the significant technical decisions that affect it.  They should occur regularly -- weekly or biweekly -- and usually last a couple of hours; they are not stand-up meetings to ensure the flow of information and effective decisions.  The board is accountable to the same executive as the projects and the competency groups.

Of course, we can scale agile to larger organizations.  The agile teams are still there but there is much more.  Competency groups are needed to own components and to maintain critical knowledge needed by many feature teams. The agile teams now called feature teams recruit its members from the competency groups.  Feature teams work in parallel with other feature teams to form projects.  Technical governance is the responsibility of an architecture board.  All this obeys the Albert Einstein observation: “Make it as simple as possible – but not simpler”.  This is smart!

  1. Ivar Jacobson | July 18, 2009 at 3:45 am Reply


    The competency groups should be structured in practical way which means that some competencies with few members may be included with other related competencies just to become less of specialists.

    Specifically, the competency groups on subsystems may be grouped in a competency including all subsystems. Within a subsystem competency group the individual being the expert on a component within the subsystem have a home. In this home he and his colleagues will agree on architecture, messages, new components, etc. for that subsystem.

  2. Rajaram Parimi | June 26, 2009 at 10:38 am Reply


    Unlike Soccer there are multiple compentencies in Team doing Software Development i.e. Developers/Tester/Functional Designer/Technical Writer.
    Is the concept of “Competency Group” applicable to all the compentencies? If yes, how in your opinion?

  3. Ivar Jacobson | May 28, 2009 at 4:37 pm Reply


    Dear Evan,
    Sorry for my late response…I have been on the road and very busy.

    This is a huge topic and I would like to write much more about it. Right now, I don’t have the time, but I have given several presentations on the subject. A better approach would be that we have a chat on the phone. Please send me an email at [email protected]

  4. Evan | May 21, 2009 at 9:16 pm Reply


    Can you talk about that experience in particular? What pitfalls did you encounter? We’re considering a similar model at my workplace right now.

  5. Ivar Jacobson | May 21, 2009 at 9:14 pm Reply


    We used a very similar model at Ericsson back in 1972 for the AXE system. It was refined over the next ten years or so. Yes, it works.

  6. Evan | May 21, 2009 at 6:53 pm Reply


    Do you have any empirical evidence that this kind of organization works?