Accountabilities in Scrum
Note: This has been updated to reflect the 2020 Scrum Guide. In the 2017 Scrum Guide the accountabilities were roles. The reason for the change is to highlight that the Scrum Team as whole is focussed on delivering a valuable, useful increment each and every Sprint. The misconception that the Scrum Master and Product Owner were separate to the Development team was harmful. If we are all on a team, we are all collectively accountable for the successes and failures.
I am enjoying the Vikings series with my wife, and it inspired a metaphor I have been using when discussing Scrum and Agile accountabilities within the Scrum team. The accountabilities in Scrum are like the positions on a long ship, and the purpose was either trading or raiding. The crew of the ship work together to get to their destination and back. The key purpose of Scrum is to build and deliver a valuable, releasable increment every Sprint. The Scrum Team works together to ensure that what they build in each and every Sprint is of the highest possible value to the organisation or purpose that they serve.
The Scrum Team
The Scrum Team is a small cohesive team of people with all the necessary skills to work towards delivering the Product Goal. The team needs to be small enough to be able to work together effectively, and large enough to ensure all the skills needed are present in the team. The Scrum Team collectively owns the Definition of Done (now a commitment), that ensures that the Increment is usable.
Scrum has three accountabilities, each with a different focus :
Product Owner (green figure)
The "What". With a focus on Value, time to market, return on investment and Total Cost of Ownership (TCO).
Developers (red figures)
The "How". Focus on building something that is Done – that the increment is useable and potentially releasable. The context that the product is being built in and the domain of work will determine the skills needed.
Scrum Master (blue figure)
Ensure that the Scrum framework is understood and is used correctly by the business and the team. Helping everyone understand how to use the framework to derive maximum value and respond to the needs of the Market. They will also support the Scrum Team to remove impediments that are disrupting the Scrum Team's ability to achieve their common goal.
There is a supporting interlock between the three accountabilities, with each accountability creating the environment and understanding for the others to perform to their potential.
The Viking Ship Metaphor
One of the defining characteristics of the Viking culture is that of free will (for the free people, unfortunately not for the slaves). The leader would provide a direction, however the position itself would not automatically grant obedience. However once at sea, the ship had a captain. Before setting to sea, the Captain would need to find a crew that agrees with the intent of the journey (where to raid, trade or explore).
Would choose the direction and navigate the ship. They would use their experience and understanding of the conditions to steer the ship towards their intended direction. Storms were to be expected, and there was a need for constant adjustments as in any sailing.
The captain has the authority to steer the ship, and the duty of care to the rest of the crew to find the best destination for them.
In Scrum - this is the Product Owner. The Product Backlog is the steering oar.
When needed, the crew man the oars and row the ship, or manage the sail. They are the ones responsible for keeping the ship moving to and from the destination.
In Scrum - this is the Developers. They are committed to using the tools and environment available to them to deliver a steadily growing increment of “Done” product.
Perhaps this is not historically accurate - but it helps in the metaphor!
There is someone who ensures the right things happen on the ship. Help everyone know what their role is, get the ship rigged for the weather, when to ship oars and bang the drum to row in time, etc.
In Scrum - this is the Scrum Master.
- Without Developers, there is no progress.
- Without a Product Owner, the journey lacks direction and focus
- Without a Scrum Master, the hidden dangers can halt the journey
- As a full team, the destination is arrived at through focussed effort.
Mixing the roles
A recurring question is can a person occupy multiple roles?
Using the Ship metaphor, we can discuss the potential impact of having multiple accountabilities. There is a probability that the person will focus on what they get the most satisfaction from, leaning towards the activities that they like the most. Will they go to where they are most needed? How will people know what accountability they are holding? Sometimes it is more obvious where their efforts should be directed. It is likely that this will disrupt the smooth running of the team. Remember that a functioning and performing team has a dynamic that is characterised by the interactions between the members. There is no fixed rule on this, as each situation is unique. The common effect is that neither accountability is served effectively, or one of the accountabilities is not serviced at all.
The key here is that there is clarity inside and outside the team who is holding the accountability.
Product Owner and a Developer
Do they want to steer or row?
There is probably going to be times when the ship is not steered as they are rowing, or the ship will go more slowly as they are steering not rowing.
Scrum Master and a Developer
Do they want to bang the drum or row?
There is probably going to be times when oars clash as they are not banging the drum, or the ship loses momentum as they are drumming not rowing. It might just happen that the ship moves fastest when they are banging the drum. When there is a new team member, who will help them understand how to work the ship?
Product Owner and Scrum Master
Do they want to drum or steer? The conflict of interest between the two roles affects the team and the product. The natural tension between product and framework is upset.
Serving many teams
I have worked with far too many organisations that encourage one person to serve multiple teams in all accountabilities. When you time share across teams it is challenging to be fair to all the teams equitably. Typically, it is the team that is making the most noise that gets the attention - that may not be the team with the greatest need. This is particularly noticeable when an organisation starts to scale their product development.
In the longship metaphor, they spend most of their time swimming between ships – or the ships have to slow down so that they can climb from one ship to another
When the storm hits...
In sailing when the storm hits, you need all hands on deck. You need to keep steering the ship into the waves, or risk capsizing. If a big enough wave hits from the side, you sink. Every member of the crew needs to perform their duties effectively in order to keep the ship afloat.
If we keep with the metaphor, the storm is the unexpected events that occur in product delivery. When the unexpected happens, without having the people committed and focussed to deliver on their accountabilities then the unexpected may capsize the product - ending it or pushing it off course.
Where the metaphor breaks down…
The Product Owner needs to trust the team within a Sprint and let them focus on achieving the Sprint Goal – this is unlikely in a long ship.
The Developers have the freedom to adapt the architecture and shape of the Product to ensure that the product is useable (previously releasable) – this is not addressed in this metaphor! During the Sprint the Product Owner should allow the Developers to self organise in the way they deliver the Sprint Goal.
The Scrum Master adopts a true leadership style, serving the Developers, Product Owner, Scrum Team and the organisation. They prefer to use an “Ask don’t tell” stance. No Whip, no orders.
How are you sailing?
A special thank you to @N__Hutchinson who created the images for this blog!