As the popularity of Agile in large businesses grows, Scrum teams are being trialled by an increasing number of companies.  

Organisations often decide to scale up and create more scrum teams after one scrum team has successfully delivered. They believe this will allow faster delivery overall, however, this is not always the case. Agile then gets discarded before the organisation has obtained any of its benefits. 

So, the question is: what are the key ingredients of successfully scaling up Scrum?

Key ingredients of scaling scrum

There are two factors influencing Scrum on a larger scale: the internal ways the Scrum teams run, and the external environment they operate within.

1. Creating high-performing teamsThe path to being a high-performing team is not a straight line. A new Scrum team needs time to achieve its potential and it’s vital for the team to go through Tuckman’s stages of development – forming, storming, norming, and performing. Friction within the team is the way people establish relationships. Allowing conflicts to run their course enables the team to fall into a natural pattern. Members will learn how to work together and become aware of each other’s strengths and weaknesses. They learn from one another and work out when to provide support. Rushing this process can lead to continuous conflict and siloed working, which ultimately negates the benefits of working in Scrum. Allow time for upskilling the team. We all learn at different speeds and it’s important that the team feels comfortable in the new environment. During this learning period, there is often a lower rate of output and sometimes an increase in defects. This doesn’t mean the team is underperforming – it just means members are learning things in an Agile way – fail fast, learn, and correct your mistakes. It is all part of the learning process and with support and the right skills, the team’s output should increase over time.
2. Preparing the right environment for the Scrum teamScrum teams do not exist in a vacuum. The external environment they deliver within and often have limited control over plays a crucial role in their success. I’ve experienced situations where the number of Scrum teams has increased, but the supporting team structure has remained the same. This increases demand on the supporting team, leading to delays or blockers for the Scrum teams. A recent client had exactly this problem. The team was unable to proceed without decisions and guidance from the solution architects, all Scrum teams had the same dependencies, and the architects became overworked and stressed. There was a lack of prioritisation and they became very reactive to whoever shouted the loudest. Obviously, the ideal solution would be to inject more resources, but that isn’t always an option. In this scenario, we increased lines of communication and prioritised the issues causing delays.

In addition to increased demand on shared resources, there are also challenges with environment access and deployment management. Often, all Scrum teams will need to interact with the same environment. This can cause significant issues if multiple teams cannot work simultaneously in the environment; it may lead to people sitting idle waiting for access or delays deploying into QA and production environments. Testing also needs to be more robust in these situations, as one Scrum team may make changes that affect another team’s work. This can slow down efficiency if this isn’t managed well.

The final external challenge to highlight is the business itself. Can the organisation handle the speed of change? Is the business set up to facilitate the roll-out and change management required for the delivery teams’ outputs? Is the leadership team ready to make the changes required to properly support their Scrum teams?  

If this has piqued your interest, read on to find out more about Agile.

You might also like