Scrum framework : Accountabilities in Scrum

Accountabilities in Scrum

• See the original post her : https://www.scrum.org/resources/blog/accountabilities-scrum
  • Profile picture for user Simon Reindl
  • Author : Simon Reindl
  • June 19, 2017
  • 4.7 from 21 ratings
  • Note: This has been updated to reflect the 2020 Scrum Guide.
• Roles or Accountabilities ?
  • In the 2017 Scrum Guide the authors speak about three Roles.
  • In The 2020 Scrum Guide, roles are replaced by Accountabilities.
    • 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.

Metaphor

• I am enjoying the Vikings series, 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.
  • Viking longship with different accountabilities highlighted the Accountabilities in Scrum using a long ship metaphor.

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 Team has three accountabilities, each with a different focus : Product Owner, Developers and Scrum Master.

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.

Scrum Team

• 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.
  • The Captain
    • However once at sea, the ship had a captain.
  • The Crew
    • 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).

The Captain

• Captain 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 (gouvernail).

The Crew

• 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.

The Bosun (Maître d’équipage)

• Perhaps this is not historically accurate – but it helps in the metaphor!
• Bosun 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.

Problematic

• If :
  • No Developers,
  • No Product Owner,
  • No Scrum Master
  • No Full Scrum Team.
• What could arrive ?
  • 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
  • Without a full Scrum Team, the destination is not achieved, despite of many efforts.

Solution

• As a full Scrum Team (PO, Developers, SM), the destination is arrived at through focussed effort.

May we mix the accountabilties ?

• Mixing is a recurring question is can a person occupy multiple accountabilities?
  • Metaphor
    • 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.
      • Questions
        • Will they go to where they are most needed?
        • How will people know what accountability they are holding?
      • Efforts
        • Sometimes it is more obvious where their efforts should be directed.
          • The key here is that there is clarity inside and outside the team who is holding the accountability.
      • Product Owner and Developer
        • 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.

Metaphor : 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 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 Accountabilities affects the team and the product.
    • The natural tension between product and framework is upset.
       
      Metaphor : May we serve 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
• Statement
  • When the storm hits … wave in deep sea.
  • 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.
• Metaphor
  • 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.

And you how are you sailing ?

Versioning

• Created on 01/09, 2023.
• Updated : 01/16, 2023.