One of the hats I wear at work is Scrum Master. In December I levelled up by attending a Scrum.org course, studying, and passing an exam to become a Professional Scrum Master. This article is the first part of a series where I summarise what I learnt so I can share the knowledge with my team and with the Atlassian Community.
There are three Scrum Team roles recognised in Scrum:
- Development Team
- Product Owner
- Scrum Master
Development Team
In Scrum there is a strong emphasis on the "team" part of Development Team. A Sprint Backlog represents the agreement a team makes of the issues the team will complete in the fixed-length Sprint. The team needs to be self-managing, focusing on doing what is best for the team, to reach the Sprint Goal.
While teams in workplaces are often people grouped together in similar roles and/or with shared stakeholders working side-by-side, Scrum does not recognise any skill-specific roles within the Development Team like coder, database administrator, and tester etc. Scrum emphasises the need for individual team members, not just teams, to be cross-functional. This reduces dependencies.
Whether it is called a bug fix, feature request, or potentially releasable increments, the Development Team create and deliver.
Product Owner
The Product Owner I work with is a fan of Venn diagrams, which is interesting given how often Venn diagrams are used in articles and blog posts about the Product owner role.
Each Sprint represents an investment. It is not just time passing and effort expended, there is a financial cost to having Development Teams. Product Owners are responsible for the investments needed to get sprints in progress and completed. They need to consider the feasibility, usability, and value of product changes to make sure the sprint backlog is ordered so the highest value items are delivered first (look, another Venn diagram!).
Agile product delivery allows stakeholders to start receiving value sooner and incrementally. The order of the backlog is critical to delivery value and a well-ordered product backlog can allow a project to end earlier than expected while still delivering value - a sad reality when project funding dries up or organisation drivers change unexpectedly.
Product Owners are subject matter experts so need to be accessible to the Development Team throughout the sprint - not just a visitor at meetings.
Scrum Master
Whether you think of it as being a filter, poop parasol, or shit umbrella - a key role of a Scrum Master is to deflect and translate external communication heading for the Development Team so they can concentrate on the active Sprint. This article is a great overview of this role and the long-term aim to build an environment where this barrier is no longer required. The term 'shit umbrella' was new to me but it is remarkably memorable and I am even considering getting a tee-shirt.
When working with the Development Team another role of the Scrum Master is to be a mirror. The ideal is for the Development Team to be self-managing but even the most efficient team can benefit from reflecting on how they do what they do and why they do things that way.
The never-ending, and most rewarding, part of being a Scrum Master is educating people about Scrum. Often this is focused on the Scrum team and the way the team uses the Scrum framework, but this educator role extends to the whole organisation and all stakeholders (including customers). This can help manage expectations around delivery, facilitate feedback loops that are effective and timely, and lead to improved processes within and outside of the Scrum team.
TLDR:
The Development Team (creates Done Increments and manages itself)
+
Product Owner (manages the product backlog and optimises the value of the product)
+
Scrum Master (manages the Scrum Framework and removed impediments)
=
Scrum Team