Scrum Master the Mechanic Stance

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 

Hi Curtis,

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.

Hi Daniel,

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