Scrum Master the Mechanic Stance
Scrum never mention how to develop your product in detail and it is so amazing it is very simple, Scrum framework exposes the impediment and where the improvement is needed. Building the process based on Transparency is the recommended approach.
Scrum aims to higher productivity and customer satisfaction by delivering the business value and from here we go.
Product owner as value maximizer working side by side with Scrum Master and Development team.
The scrum master motivates the team, creates a safe environment and serving his team well. that will lead the Scrum team to flourish.
Scrum Master will higher the productivity of the team, the Product Owner will maximize that value.
Do you agree?
Scrum Master as a Mechanic.
More I see the Scrum Master as the mechanic which he is on standby mode to help, fix and advice.
No matter at which stage of Tuckman's stages of group development you (as a team) are.
You will always need a good mechanic to fix or tune your process.
What if your mechanic is skillful, passionate, and committed?
She is always armed with the right soft skill, knowledge and willing to help the team, Serve and be the lighthouse for the team to gain new skills and come over the daily obstacle.
Backlog refinement and the mechanic:
The Mechanic will check do we have everything in a place so we can start sprinting our car.
Enough PBI with just enough information and a common understanding between the development team and the product owner. Any help which he may offer to the PO?
Sprint planning and the mechanic:
- Are we clear to go? (Had we the feedback from the previous sprint)
- Do we have enough gasoline? (Are we cross-functional?)
- The status of the gear and motor? (Team capacity not to be overcommitted)
- Most important do we agree on the final destination of our journey? (Sprint goal)
Daily scrum and the Mechanic:
- Are we still on the right route? (Progress toward sprint goal)
- What’s blocking the road? (Impediment where the self-organize team cannot resolve)
After the long journey let’s talk with our stakeholders.
Be at ease and focus on gathering feedback from our stakeholders by Having the courage, commitment, Openness and respect toward ourselves, stakeholders and organization.
The mechanic Scrum Master stance will be very visible at this informal meeting. In a mean do we understand the scrum value, pillars, and the artifacts.
Sprint retrospective and the mechanic:
Some parts get rusty or outdated and our car is a bit dirty.
- Transparency. Let’s clean it first and see the actual status of our car
- Inspect Then we check which parts need a replacement.
- Adapt. Let us take one step forward and share the most painful point and how we fix it
Kindly note that I meant nothing by having a car here. as an example, it serves to nothing more than the purpose to explain how the Scrum master, may perform and do the right way of serving his team.
How self-organizing would a development team be if they would need these skills constantly on the outer edge of the Scrum Team?
Since when is the SM responsible for fixing the problems? A mechanic by nature is one that FIXES problems. A SM Advises and Guides the team to fix the problem together as a team.
Mechanics do some of the things that a Scrum Master will do. They can listen to an engine and identify that there could be a problem. They listen to feedback from the driver to help uncover opportunities for fine tuning. But they are also the one that does the actual work to accomplish this. It may require that a portion of the engine be completely dissembled, parts replaced and then reassembled. A Scrum Master does not do that with a team. They will never take people out of the team and replace them. A Scrum Master will never change the configuration of a team. A mechanic may put fuel into a automobile but the driver must also know how to do that because the mechanic will not be with them all the time.
I can see how you might come to your analogy but I would caution you to take a closer look before you start using it as a coaching tool. Study servant-leadership. Study coaching. They are much more analogous to a Scrum Master. For example...
A Scrum Master is like a coach on a sports team. The coach will train the team members to be in better physical condition. But the players themselves must do the work to become more physically fit. The coach will draw up plays, educate the team on how to execute those plays and why those plays are useful. The coach will also teach the players how to think while in the game. Because the play that the coach drew up and taught the team will only work if the other team reacts exactly as the coach illustrates. However, the coach from the other team has also drawn up plays and educated his team. So when you get into a real life situation of a game where two teams are pitted against each other, the team that has had a coach teach them how to think and react based on what is happening will ultimately be the victor.
As a Scrum Master you are there to coach. To help the team learn how to think and act on their own based upon the conditions that they face. You do not want to be the one doing the work, you want them to learn how to do the work that they need. In my opinion a truly successful Scrum Master is invisible to a successful team.
There are different takes on roles and stances of Scrum Masters or other coaches - two top examples are Barry Overeem's 8 Stances of a Scrum Master and Lyssa Adkins's roles and stances described in Coaching Agile Teams. Others have written about their own takes on stances and roles, but I've never heard of "mechanic" described as one.
Personally, I'm not sure if it makes sense to use this as a stance. A mechanic is someone you would bring your car or bike to, usually when you have a problem. You may go in for occassional regular maintenance, but the bulk of the work is after something is going wrong. This doesn't align with the Scrum Master who is always working with the team, day after day, week after week. The Scrum Master is not someone you bring your team to once or twice a year for a check-up or when something is wrong, but someone who is right alongside the team always.
The one thing that I would consider is if there is a place for a "mechanic" stance. Perhaps not the team's normal Scrum Master, but is there value in a Scrum Master who can serve as a mechanic for the team? Someone that the team, including the team's Scrum Master, can check in with for a check up or turn to when things go wrong. The idea of that kind of expertise in diagnosing problems and helping to fix them or do some preventative maintenance on the team may be worth looking at in more detail. But I wouldn't describe this as a stance or role for the team's Scrum Master.
I would agree that the role or stance of the Scrum Master will change over time, based on the development of the team as well the team's maturity.
The mechanic can be valuable, as long as it's not the default stance of a Scrum Master.
A mechanic is someone you would bring your car or bike to, usually when you have a problem.
I think of it more like a mechanic on a racing team. There's constant involvement, and focus on the effective and efficient operation of the car, but there's also a duty of safety.
I tried to think how I act as a mechanic, and I believe I'm doing it right now in one specific circumstance for my teams.
For a multitude of reasons, our teams are late defining their OKRs for Q1.
When things like this happen, I consider keeping quiet, and observing whether people step up to take action. If they don't I can help turn this into a learning opportunity.
But in this particular case, I believe there will be more benefit to the teams and company throughout the coming quarter if we get the OKRs right, than from letting this become a learning opportunity.
I'm stepping in, defining a process, making assertive decisions (although keeping them transparent, so they can be challenged). I still expect the teams to be involved in defining the actual OKRs, but by me stepping in, the teams are losing some ownership of the process.
So if there's an awareness of the impact on self-organization, and in the right circumstances, mechanic can be a beneficial stance. But when I think of it in those terms, perhaps it's really just a duplicate of the Impediment Remover, as described by Barry Overeem.
Hi Sander Dur
The Scrum Master, as Mechanic he fix the process keep teams on track by following the Scrum value, artifacts, roles and pillars.
I fully agree with you, that SM needs to be careful as his ultimate goal is to lead the development team to be self-organizid this by no mean will make the SM the sole resolver of team impediment. it is always tricky for the SM master to find the balance
Indeed Mechanic fix the problem after you pay him a visit.
The SM remove the impediment if the Development team can't resolve it.
The SM should be always there for the team to help not only by following the Scrum guide but also by maximising their collaboration and improving their skill. moving them from Silo to T shape to Pi.
I wrote this article in a way to share the knowledge and get the benefit of the scrum community experience, and to gather more insight of the Scrum master finding the balance.
"it is not about being right or wrong,Simply it's about the team & The organisation"
All the best.
" parts replaced and then reassembled. A Scrum Master does not do that with a team. They will never take people out of the team and replace them."
Indeed the development team in this specific case are responsible, Thou they may need the help of the Scrum Master. What I meant by removing that is the process as our goal is to benefit from them not to let the process slow us down as time pass the needs for update/ new process may occur.
Thank you very much for your advice :)
Thank you all for the knowledge sharing.
Merry Christmass to you all and your beloved ones.
Thank you all for the knowledge sharing.
Merry Christmass to you all and your beloved ones.