20 Jun 2017
I am enjoying the Vikings series with my wife, and it inspired a metaphor I have been using when discussing Scrum and Agile Roles within the Scrum team. The roles in Scrum are like the roles on long ship, and the purpose was either trade 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 potentially 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.
Scrum has three roles, each with a different focus and accountability:
Product Owner (The green figure)
The "What". With a focus on Value, time to market, return on investment and Total Cost of Ownership.
Development Team (The red figures)
The "How". Focus on building something that is Done – that the increment is useable and potentially releaseable
Scrum Master (The blue figures)
Ensure that the Framework is understood and is used correctly for 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 remove impediments that are disrupting the Scrum Team's ability to achieve their common goal.
There is a supporting interlock between the three roles, with each role creating the environment and understanding for the other roles to perform to their potential.
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 Development Team. They use 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 oarsandbang the drum to row in time, etc.
In Scrum - this is the Scrum Master.
Using the Ship metaphor, we can discuss the potential impact of being in multiple roles. 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 role they are performing? 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 role is served effectively, or one of the roles is not serviced at all.
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.
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?
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.
I have worked with far too many organisations that encourage one person to serve multiple teams in all roles. 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
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 role 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 focused to perform their roles then the unexpected may capsize the product (product cancellation) or ending it or pushing it off course.
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 Development Team have the freedom to adapt the architecture and shape of the Product to ensure that the product is releasable – this is not addressed in this metaphor! During the Sprint the Product Owner should allow the Development team to self organise in the way they deliver the Sprint Goal.
The Scrum Master adopts a Servant Leadership style, using an “Ask don’t tell” stance. No Whip, no orders.
A special thank you to @N__Hutchinson who created the images for this blog!
APD will help improve the way you build products in an iterative and incremental way. Get in touch today for a free 30 minute consultation.Contact Us