31 January 2023

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.

Leave a Reply

Your email address will not be published. Required fields are marked *