Scaling-182x182Scaling. A problem that faces most Agile projects and one that is still talked about within the Scrum community and the proposed solution is the “Scrum-of-Scrums” concept.

Before we go any further however, let’s step back and ask ourselves what exactly is the problem? In any organization with large projects the general approach is to solve the magnitude of the problem through “divide and conquer”. As such, we split our projects into smaller, more manageable activities.

Typically this is by knowledge domain or function. In large waterfall projects, we may well have several teams containing a specific skill. e.g. A project would contain a number of teams containing only developers with each team responsible for a particular domain.

With the arrival of Agile and the preferred approach of building teams that are self-organising and cross-functional we remove the dimension of skill-specific teams.

We are then left with a number of domain specific teams. It is these teams that need to co-ordinate.

Scrum-of-Scrums-of Scrums-of…

The Scrum-of-Scrums concept evolved to address this. An individual from each Scrum-team is elected to represent the team in the Scrum-of-Scrums to co-ordinate activities across the teams. This is theory scales further to enable a Scrum-of-Scrums-of-Scrums and so-on.

However, in large corporate organizations there is little trust in this concept.

Scaling Agile Project

Agile Project Management, based on DSDM Atern, solves this problem in another way. This method maintains not only the classic role of a Project Manager but also a single Business Visionary and a single Technical Coordinator for the project. The latter two are peers and they are responsible for the business solution, as a whole and for keeping the technology chosen consistently applied.

This way, one individual has an overview on how the solution will look from a business point-of-view and one individual keeps the technology aligned. They are also the final decision makers of any escalations that occur in the teams. They are therefore ultimately responsible. These roles are highlighted below, in a project that has just one team:


Multiple Team Projects

If a project has three teams, each responsible for a different domains, these three teams would have a common Business Visionary and Technical Co-ordinator. As shown below.

(Click on image to enlarge)


Because the roles are “built into” the method, the roles do not need to be artificially created and in large projects these roles become full-time jobs.