In Agile the Scrum framework consists of four events or ceremonies. Sprint Planning, Daily Scrum (or standup), Sprint Review and Sprint Retrospective. It also has three clearly defined roles. Product Owner, Scrum Master and Team.
Scrum is executed in what we call sprints – a duration of time, usually no more than a couple of weeks.
Scrum is not the process in and of itself. It’s the foundation for a team to build their own process on top of. It gives them the framework and structure of how and what gets done.
Teams need to see the successful outcomes of adopting change. So for Scrum to work, it requires three defined roles within the framework.
These three roles in Scrum aren’t job titles. They aren’t a career path. These three roles in Scrum can be performed by anyone assigned to the responsibility within that project’s Scrum framework.
The beauty of the Scrum framework is in the events and the roles within it. It’s a lightweight adaptable system to scale up or down, and flex with the complexity of any given problem.
To provide some further definition on what these three roles in Scrum are, we will look more closely here.
PRODUCT OWNER (or PO)
The Product Owner owns the product vision and represents the customers. This is to ensure that the product or service that we are developing addresses the needs of the customers.
This is paramount in ensuring that the right product/service is built. The PO defines the features and prioritises the product backlog for the teams.
For a team to successfully deliver value, they need to know what they are working on. They need to know how they will deliver and have the ability to work together to get the job done.
The Product Owner owns the overall strategy and direction of the product
1 – THE VISION
2 – THE PURPOSE
3 – THE OUTCOME
That is to say, the Product Owner defines what outcomes need to be delivered. Then prioritises within the overall picture what needs to be done when.
The most effective Product Owners can visualise and clearly articulate the outcome that is expected from the team through good user stories. They do this by using a clear user story format with “who”, “what” and “why”.
If all three elements are clearly described, the team can focus on the best ways to deliver the outcome.
If one of the user story elements is missing – e.g. the “what” – the team struggles to understand what they can deliver to satisfy the business need.
The team (sometimes called the development team) are the ones that get S##$t done! They do the work.
The team is cross-functional and self-sufficient, bringing together different capabilities to develop an end-to-end product/service within the team. They ensure that the product/service is built right. This is a good place to pause. When the project is different from last quarter’s product – this team will change accordingly to bring in different skill sets and knowledge (thus the “flex” angle discussed above).
Another way to say this: The team in Scrum is a cross-functional group of empowered knowledge workers with the collective skills to deliver an end-to-end solution and deliver business value.
The empowered team also accepts accountability for meeting their commitments to deliver each sprint.
The difference for teams in Scrum vs teams in traditional management construct is this: In an Agile structure, the team directs the leader (Scrum Master – see next role) to act on their behalf, in the traditional management construct, the leader directs the team to act.
The team should focus on effectively delivering the expected outcome. Effective work of the team is ensured by:
Ownership – due to all team members contributing to the definition of objectives and user stories;
Commitment – from team members to delivering on the backlog items during Sprint Planning;
Transparency around the ownership, commitment and progress with team boards, daily stand-ups and showcases as well as team and individual goals.
As organisations scale to deliver complex work, it is essential someone champion the team’s cause beyond the team boundary to create the space for the team to work and to remove obstacles across the organisation for them.
If fences make good neighbours, the Chapter Lead is the surveyor who defines each team’s backyard. They provide the overall standards that define how the work should be done.
By having just enough restriction (the fences) to ensure quality integration and overall progress to overarching goals, team members then have the freedom to “play” in their yard to make decisions on how they deliver the work within the provided constraints.
SCRUM MASTER (or SM)
The worst named role in Agile is probably “scrum master”. The SM is not the master of anyone. The foremost role of the SM is to be a “servant leader” who helps the members of the scrum team to grow and achieve more.
The Scrum Master helps the team work together to deliver these outcomes. It’s not an easy feat having the ‘right product/service being built right’. The Scrum Master’s role is to support that through driving agile mindset and processes to achieve it.
By emphasising strong collaboration, enhanced transparency, and iterative feedback, we are able to create not only a product/service that serves the customers’ needs, but also build an engaged and empowered workforce that consistently achieves key outcomes.
Key elements of this include removing blockers and helping teams continuously improve.
In Agile circles, people describe a Scrum Master as a “Servant Leader,” it is an elegant term as it is both simple and yet conveys depth.
The term “Servant Leader” talks to the outcome of providing leadership benefits, like being able to coordinate activities outside the team and across the organisation, while binding that leadership to the team who directs it.
The Scrum Master leads in the service of the team, or in other words, the team provides the direction. This inversion of leadership provides a level of autonomy to team members not available in a traditional structure.
Focused on outcomes
A good Scrum Master helps the team achieve high performance by focusing on outcomes. That also means making sure every team session is focused on outcomes.
In practice, opening the session by clearly stating the expected outcome and the time-box and confirming with participants as well as doing half-time (or quarter-time) checks – what we’ve achieved so far, what’s left on the agenda, how much time is left in the session. These simple habits make a big difference.
It’s important to state here (and we can’t state it clearly enough) – The SM is not a secretary to take minutes, nor organise everyone else’s diaries – but the overall role is to ensure that the team is running smoothly.
They may also add light and colour to the team as well as understand what will motivate the team.
The most nuanced role of all, although it can be shared within the team…there are those who are just naturally gifted when it comes to ‘sticking the team together’… a fantastic role never to be underestimated.