Scaling Scrum

Scaling the Scrum Framework for a large program of work or across an enterprise is really about working with multiple small teams rather than working with one single big team.

Limitation of Team Size

Team size can be represented as a node graph, in that, the number of communications paths x:

where n is the number of people in the team

Hence, with a team of 3 people there are 3 communication paths, but when we add just one more person, i.e. n = 4, then there are 6 potential communication paths, doubling the amount of potential communication.

After a team grows in size beyond 8 people, then you may well find that teams spend more time talking and coordinating rather than doing, as well as team members being reclusive in the group during large meetings.

A general guide, which is also mentioned in the Scrum Guide, is that teams should be between 3 and 8 people.

On a large program of work where we need more people, this may manifest as multiple small teams, and so we need to apply some different thinking to consider how these multiple small teams work towards a common goal, connect together and yet still retain their independence and autonomy.

Independence & Autonomy

Ideally we want teams to be independent and autonomous and to be comfortable at making their own decisions and owning the solution and delivery of the product.

This underpinning idea is to promote teams that are self-propelled, confident in their approaches, and also yielding accurate solutions that delight the customer. The leader or managers' roles are essentially to get out of the way and provide a supporting platform that allows the teams to realise their potential.

Cross Functional

Just like regular Scrum teams, the intention is for each of our teams to be cross-functional so that they have all of the necessary skills within the team to be able to deliver a feature from a written ticket to a production ready delivered feature.

If all of the teams are cross functional in this way, then this will enable them to be autonomous and independent and not dependent on other teams or other skills that we get when we have those traditional silo teams.

Self Organising Behaviour

Within The Team

We try to promote self organising behaviour in the team to help them increase their autonomy, make quick decisions and grow their ability to own those decisions. This may be initially facilitated with the help of a Scrum Master, but ideally, it would be great if the team were comfortable enough to exhibit their own self organising behaviour and utilise their technical expertise where they think best.

Inter-Team

Interestingly, self organising behaviour also happens between the teams as they determine what they are going to work on during Sprint Planning, how they manage dependencies between teams and also how they coordinate their efforts towards a common goal.

A good way to facilitate this inter-team interaction is to allow the teams to sit close to each other and reduce the distance between their interactions.

Race Conditions

If teams are autonomous and can work independently towards the same overall goal, then this also allows for race conditions to form where one team may be held up with an impediment for example, however this impediment does not impact the other teams and they can still move forwards.

Also, if a team is finding the work quite easy and are moving ahead rapidly, then we should allow them to do this and we might get more features delivered.

Team Types

Feature Teams

Feature teams are the "front line" teams that deliver features and are cross-functional, autonomous and independent.

Specialist Teams

From time to time the feature teams may need the assistance of specialists such as architects, DBAs or customer experience for example. These skills are not needed all of the time and so didn't make sense to include them on a full time basis in the feature teams. An alternative is to form a group or "team" of specialists that may work in several modes:

• Embedded in the feature team for a short period for a specialist to provide some dedicated assistance
• Consulting with the feature teams for ad-hoc requests to provide some advice of quick instruction
• Sub Contracted to work in the specialists team on a particular problem for the feature teams. This is usually rare, but when a number of specialists are needed to work on the same problem, then sub contracting that problem or feature to them can be useful. (N.B. Try not to use this too often as it can degenerate into component team behaviour and strong dependencies, which we want to avoid.)

Avoid Component Teams

Component teams tend to be siloed teams either by skillset or knowledge. These were used a lot in traditional project management approaches as means to organise a large number of people by skillset often modelling a layered system architecture.

Although this approach looks good on paper as an org chart of teams and skillsets they tend to form strong dependencies between each other and so features cannot be completed until each of the component teams have done their bit. This can encourage a segmented view of the product leading to poor performance and a disconnected user experience.

The general guidance is to try to avoid using component teams when working in a scaled fashion and opt for cross-functional feature teams instead.