Could one Development Team working on a single product have two different Scrum Masters for this product?
If not, Would this be a good reason to document a ScrumBut using (ScrumBut)(Reason)(Workaround) to make the exception visible to senior management?
What purpose would having 2 scrum masters serve?
Why would 2 people be needed to do 1 persons job?
There should only be 1 scrum master for each Scrum Team.
I would recommend reading the scrum guide to help understand what the role of the scrum master is.
Well, one obvious purpose would be to have the second scrum master as a trainee, so he can learn what the job implies. I was considering doing this actually.
I see that you have had some formal training in Scrum (outside of Scrum.Org or the ScrumAlliance). If you don't mind me digging a little deeper, can you first confirm whether Scrum allows for multiple Scrum Masters' on 1 Scrum Team?
What you're asking may not be a "ScrumBut" -- it may be a "ScrumNot"
I can think of an exception to your scenario ,as a ScrumNot (or perhaps "Other") but I'd like to get some more insights to your scenario first.
> Could one Development Team working on a
> single product have two different Scrum
> Masters for this product?
Many people in a Development team may demonstrate Servant Leadership, but a Scrum Team should have only one Scrum Master at any given time.
Certain risks can be expected to arise if there were to be multiple Scrum Masters on one team. Can you identify what the risks might be?
First of, Thanks for your feedback and responses.
A little background ...We got into this precarious situation as part of poor transition and succession planning. The brief transition plan of shadowing a Scrum Master has turned into months leading to becoming an "informal" defacto on this particular internal software product (1 PO only).
My bigger concern is I'm noticing increasing signs of approval within senior management with this structure formation.
I wish to bring this SCRUMNOT (Thanks, Nitin was not aware of this construct) practice to an end before it becomes an acceptable norm/culture.
Having two masters cannot be a good thing. Ian, some risk include lower team morale, conflicting direction, strain on time-boxing, emergence of power struggle and eventual reduction of business value.
I'm hoping to provide senior management with a stronger and compelling case to nip it in the bud.
Yes, This is a "ScrumNot" bordering on "Other."
I would consider talking to both the Scrum Masters' (SM) in this case, and get a consensus to the scenario from them.
(i.e. are they of the opinion that both can serve as a SM?)
I do not know your role on the Scrum Team, but would ask them both to approach the people who formulated the Team to figure how temporary this "shadowing" was intended?
"I'm hoping to provide senior management with a stronger and compelling case to nip it in the bud"
Here's possibly one good compelling case
Scrum.org and Scrum alliance and scrum.inc were aligned the scrum guide from Sep 2014.
If it came from either organisation could be worth asking who decided on two SM if its scrum your really adopting
(or intending to adopt) Scrum as its a common guide its one set of rules, which one did for your organization?
This comes from a transition so a change to the business, what reasoning did the transition team come up with for two SM, as it the rules are binding if its a pure Scrum deployment.
This Guide contains the definition of Scrum.
This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.
SCRUM is a flexible framework with intentional gaps to allow it to be modelled to your organisation. SCRUM is mechanical (think of it as an engine) and a means to achieve agility (take you from A to B to C .. etc )– the definition of agility (the end state) varies from organisation to organisation. Anything interfering with its mechanics (the engine) is holding back SCRUM from enabling agility in your organisation – this is when you get your ScrumBut/ScrumNot book out. In this scenario ScrumBut/ScrumNot isn’t relevant. Succession planning is a key process in organisations around motivating individuals and identifying the future leaders of the organisation and this is what your are doing.
Focus on coaching the senior management teams on the SM role, SCRUM and Agile and how it enables agility in organisations. You are naturally doing a coaching role so why not position yourself as a coach and ensure that the “trainee SM” simply becomes the “SM” – the point here is to remove the “trainee” title so that he/she can play an effective SM role within the team with you playing a supportive coaching role.