Agile has recently become a buzz word in large businesses, and more and more companies are researching and trialling ways to run their own Scrum teams.
What tends to happen is that, when one Scrum team successfully delivers, organisations decide to scale-up and create more Scrum teams in the belief they will deliver faster as a whole. Many times, this fails, and the organisation discards Agile without having reaped any of its benefits.
So, the question is: what are the key ingredients of successfully scaling up Scrum?
There are two types of factors influencing Scrum on a larger scale: the internal ways the scrum teams run, and the external environment they operate within.
- Creating high performing teams
The path to being a high performing team is not a straight line. The first thing a new Scrum team needs is time to achieve its potential and it is vital for it to go through Tuckman’s stages of development – forming, storming, norming and performing. Friction within the team is part of the way people establish relationships, and accepting that is key to allow those conflicts to run their course and enable the team to fall into a natural pattern. Members 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.
The second thing to allow time for is upskilling the team. We all learn at different speeds and it is important 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.
- Preparing the right environment for the Scrum team
Scrum teams do not exist in a vacuum, and the external environment they deliver within, and often which they 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 were 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 an 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 which affects another team’s work. If this isn’t managed well it can lead to issues which slow down the teams’ efficiency.
The final external challenge I want 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?
In my next blog, I will talk about how to overcome some of these challenges and a few scenarios to consider if you’re thinking about scaling Scrum.
Assess the maturity of your Agile product team but completing our short questionnaire here