I taught a Professional Scrum Foundations for Teams (PSF) class this week.  A core part of the PSF is a series of compressed Scrum Sprints where the students work together to build simple websites.  One of the scrum masters this week's class had fantastic technical skills and was the team's technical lead in "real life".  You'd think that those monster technical skills would be a benefit for that team but, in fact, they were actually getting in the way.

Technically-minded Scrum Masters often have trouble with two things: 1) encouraging self-organization on the team and 2) helping their teams to focus on actually delivering done, working software.

Part of the problem is how we technical people are wired.  All solutions begin and end with code.  We're engineers.  We love to solve problems.  We like the 'fiddly bits' and we like to fix things.  And what do technical people do when they see problems?  They dive right in and try to fix it.

In software, there's never any shortage of technical problems.  If you're a tech lead or a software architect and you're also a Scrum Master, you're probably jumping into the technical "weeds" a lot.  You probably personally lead the charge and apply your natural, laser-focus to knock out that technical problem, too.  This is what you do and you're good at it.

But there are a couple dangers here.  The first danger is that you're probably trying to solve the problem yourself rather than coaching the team to self-organize towards a solution.  The second problem is that you're losing your focus on meeting the Sprint Goal and getting to done, working software.  It's like you're watching a big screen TV from 2 inches away.  That square right in front of their eyes is visible but they're not seeing the other 75% of the screen.

So.  Scrum Masters.  Try to take a step back.  When you see a problem, find a way to point it out to the team.  Ideally, ask questions in order to lead the team to realize that there's a problem.  If the team comes to the realization largely on their own, they'll tend to feel more ownership over the problem.  Next, try to coach the team through the conversation of solving the problem.  "It sounds like we're in agreement that X is a problem.  So what do we want to do about it?"  Avoid injecting your own solutions.  And finally, never lose focus on the big picture goal of delivering done, working software.

Hang back and see what happens.

-Ben

-- Need a coach for your Scrum Masters?  Want someone to help figure out your team?  Looking for Scrum or DevOps training?  We can help.  Drop us a line at info@benday.com.