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.

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

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.