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 develop 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 a 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.
Frameworks
There are several scaling frameworks around at the moment with the most popular ones being Larg Scale Scrum (LeSS) and Scaled Agile Framework (SAFe).
Large Scale Scrum (LeSS)
The intention with LeSS is to model and expand on the existing Scrum Framework to enable multiple Scrum teams to work together with a minimal framework, which can be added to later.
Sprint Planning
Sprint planning is more or less the same as using Scrum with the separation being with "Topic 1: What" where all of the teams coming together to determine what they are going to work on.
"Topic 2:How" sees the teams working independently to decompose how they are going to deliver the items chosen in Topic 1.
A common approach is to use "Big Room Planning" where all of the teams do their sprint planning in a large single room with several table groups formed for their respective working areas.
Daily Scrums
These are very similar to the Scrum framework and are often done in parallel, which allows team members to join other Daily Scrums if needed.
Sprint Review
These are also very similar in format to the Scrum framework, although if a number of teams are working in the same area they may opt to demonstrate their work collectively. If the teams are working independently and on independent features then it is common to use a "Feature Bizaar" or "Feature Market Place" approach where each of the teams can demonstrate their wares and obtain feedback from stakeholders.
Sprint Retrospective
Unlike the other events, these are very much the same as when using the Scrum framework, in that, each team will do their own retrospective and inspect their processes to derive improvements. Each team has been on their own journey, and so it seems fitting that they should also do a retrospective on their own for their context.
Overal Sprint Retrospective
Although the Sprint Retrospectives are done independently, it still might be beneficial for the teams to learn from each others' insights and so a separate forum for them to learn from each other is part of the LeSS framework.
Scaled Agile Framework (SAFe)
The intention with SAFe is to provide an all encompassing scaled framework for the enterprise with all of the tools in the toolbox already. This tends to be adopted by large corporate organisations that have multiple programs that need to be coordinated.
See Also
References
- Large Scale Scrum: More With LeSS, Addison Wesley Signature Series (Cohn), Larman C., Vodde B., 2017