Over the last couple of years, I have been active as a Sprint Master within big companies in different sectors. During this time, I have gathered a lot of insight in organizing and working with agile business teams. Within this blog I will share some of these insights.
But first, let’s starts with the basics … what is a sprint master?
A Sprint Master can be compared with a Scrum Master with some substantial differences. The key responsibilities of a Scrum Master are to protect the scrum team and enable them to sprint at full force. He or she enforces the agile way of working and its fixed ceremonies and supports the product owner in the grooming of the backlog. Scrum originated in the IT sector and many of its practices and principles can be used for a business team but not all can be blindly copied.
A Sprint Master shares these responsibilities but is also involved in the content of the sprint. Aside from the Agile methodology, the sprint master introduces a design thinking mindset and methodologies to ensure not only the right way of working but also a customer validated solution.
To keep the momentum high, it’s essential to provide self-organizing teams with an explicit mandate so they can make fast decisions (within the limits of their mandate). The steering comity and project sponsor help define what the project team should do. However, the product owner decides how and when to do it.
From my experience, the elimination of the approval process accelerates time to market while it increases the quality of delivery. It also benefits the accountability and ownership of all the team members in the long term.
One of the conditions to allow the sprint team to flourish is to clearly define what success looks like. Defining measurable success criteria helps the team to focus on the right topics. Important: these KPI’s aren’t an instrument to steer teams in how to solve a challenge. In the same way that good KPIs help accelerate the team, the wrong KPIs minimize flexibility and creativity.
This learning exists out of two parts: you need to have 1. the right people (capabilities) in the team with 2. dedicated time to solve the challenge at hand
Complex cases can only be solved successfully when approached from different angles. A proper multidisciplinary team is key. At least 80% of all the necessary knowledge should be within the core team. If you don’t have the right mix of people you continuously have to align with people outside of the core team. This takes time.
Also, every team member has to see the sprint team as their number one priority. This doesn’t mean that it’s their only responsibility, but the priority should be clear and in favour of the challenge.
At the end of the day, any winning new concept needs to solve untapped customer needs. Great value propositions are built on deep consumer insights and should therefore always integrate the voice of the customer right from the start.
Throughout the exploration, ideation and realization of new concepts our services, you have to constantly connect with customers to validate if you’re on track with your assumptions. We can do this by implementing a test lab, or even live test prototypes in the market to capture real feedback (e.g. smoke tests). By validating with customers, you constantly minimize risk and uncertainty, improving the success rate. Furthermore, it accelerates internal decision-making.
Following the previous takeaway, it’s crucial to have an IT representative join the team to review and challenge feasibility. As with many companies, the IT-landscape has evolved over the years into a legacy of different IT systems and databases. The tension between operations, IT and Innovation should be taken into account from the start.
The number of required (IT)experts can rapidly become too big to join the core team. The best way to solve this is to schedule a sprintly IT roadshow where you include all relevant experts, explain the concept, and stay in the room until the solution is entirely hashed out and the backlog items are identified and planned with the right owners.
During sprints, costs will be made (e.g. customer testing, prototyping, research, new expertise hiring, etc.…). To ensure the team isn’t delayed in its works a yearly budget should be allocated from the start.
Larger costs will most likely pass a steering comity to be decided upon. These delays need to be avoided if necessary, to save momentum and enable the team to deliver as fast and as good as possible.
The last, but definitely not the least, important learning is the role of management. The management team needs to fulfil the role of servant leader. They have a crucial role in empowering the sprint teams by aligning on what success looks like, what mandates the team has, and how the team should operate for important decisions. Next to that, they have to instil a culture of experimentation and constant learning, as well as the proper facilities like a dedicated ‘homebase’, They need to part ways with the traditional roles and responsibilities and trust the team to figure things out themselves without forcing down opinions. They should be present during the sprint demo at the end of each sprint to discuss the delivery and voice their opinions.
These seven takeaways are my main learnings from working as a sprint owner over the last couple of years at large organisations . There are however many more insights that I didn’t include in this blog so feel free to contact me if you would like to discuss the roles and responsibilities of being a sprint master or if you would like to share your own experiences.
