“All our Scrum Master, Bob, does is sit around all sprint. I mean, he’s there for our Daily Scrums, and Sprint Planning. He goes to our Sprint Review and watches the stakeholders, and he asks a lot of questions in our Retrospectives, but what does he do the rest of the time? It’s not like he’s writing code…”

Have you heard something similar to that before? Maybe even said it yourself?  It’s a pretty common refrain, and one of the driving forces behind the idea that we can have part time Scrum Masters, and still be as effective as we think we should be. 

“Part Time Scrum Masters” generally come in one of two forms: Scrum Team members who take also take on the responsibilities of the Scrum Master, or single Scrum Masters dividing their time across multiple Scrum teams.  While in practice we do what we must with the resources we have, each of these have potential drawbacks which either must be accepted or mitigated.  This time, I’ll be talking about the first type, and at some point I’ll talk some about Scrum Masters doing the splits across teams, like Jean-Claude Van Damme in that one commercial.

Scrum Master – Team Member Hybridization

“We all have to wear many hats.”

When we’re just starting in Scrum, and our teams are small, or we’re just having trouble filling positions in general, or we’re a startup, or what have you, we expect workers to fill multiple roles. Boss and product owner, software tester and help desk tech, developer and designer, UX and coffee fetcher (just kidding LS, I know its tough changing all those colors ;-P), so on and so on and so on.  But now we’re using Scrum, and Scrum tells us we have three roles: Product Owner, Scrum Master and Development Team Member. Why is this distinction important?

It’s pretty easy to see, after all, why a Product Owner is important, and how also being a development team member would raise a conflict. We know why the development team is there, some one actually needs to do the work, that’s kinda important.  But that Scrum Master… he/she is there to “improve team productivity” and “remove impediments and blockers” and so on… all of that sounds like fancy talk for “get done faster”, right? So wouldn’t we get done faster if that Scrum Master spent part of the time during the sprint taking on development tasks?

Now when everything is going well, ticking along and doing just peachy, there’s probably not really a problem with a Scrum Master doing some development tasks, at their discretion. However, in my experience, and from research and testimonials I’ve found, long periods of time where no issues, impediments or other time-wasters show up are pretty rare. Team members leave and join, new computers need to be set up, some mental lapses in the last few sprints happened and the team got away from good Agile practices, we tried a new chat system, oh and a major shake-up of team structure… and all of that just in the first few months of this year!  The point being, most of the time, there’s something that threatens to sap your team’s productivity (if you never notice these… congratulations! You’ve either got a super awesome Scrum Master, or you should really buy me a Powerball ticket).

OK, this whole post is just itching for a practical example, so here we go:

A relatively new and young team has been together a few months, and doing a great job. It’s a really small team, so one of development team members is acting as a Scrum Master, with assistance from the Agile Coach, and everything seems to be going smoothly, maybe even moreso than anticipated. They’re on a single platform, churning out features and getting close to a MVP.  Now, however, they need to integrate a portion of this new system into a outward facing legacy system, that a majority of the team has not yet worked with  (My fellow Scrum Masters are already smelling the impediments…).  Now if installation and setup goes off without a hitch, great crisis averted, but lets assume that’s not the case. Let’s look at the thought process of the hybrid Scrum Master:

OK, we’re gonna work on integrating the new tracking system into the page supporting that in our customer portal. No problem, I’ve worked on that system before… Uh oh, Alice and John don’t have CodeGuru 2016 installed or setup on their machines. I’ll ping our IT guys and get them on this, but in the mean time I can get started. John and I can pair program, while Alice gets setup, and then we’ll switch.

Wow, this installation has taken a few days, and Alice still isn’t configured properly, and we don’t even have a CodeGuru license for John yet! I better work on this feature and get it done, no one else can right now! Alice and John can support me, and pick up some of the other smaller stuff. I hope IT and the manager gets this straightened out soon! We’ll pull through this!

In this case, the Scrum Master had the option of doing the work themselves, and so took on the responsibility of completing the feature themselves. Because the Scrum Master had been working sprint to sprint, they didn’t really have the opportunity to look forward at what was potentially coming and get ahead of the situation. Once the problem occurred, with the best intentions they tried to get the feature completed; however, two of their team mates were stuck in limbo, unable to help deliver value.  This Scrum Master was also working on something else when IT made a response, and either had to task switch to respond to IT, or the response to IT had to wait. The Scrum Master got focused on the destination instead of the journey.

Let’s now take a look at a full time Scrum Master, who has the benefit of not focusing on trying to deliver “code” (read, some kind of individual output). First of all, since this Scrum Master, we’ll call him Bob from the original quote, wasn’t worried as much about completing a project at the end of last sprint, he was able to see that stories regarding the customer portal were at the top of the backlog. Bob realized that Alice and John haven’t ever needed to do that before, and they may need some attention in that regard. Bob also never has the thought to do more code himself, to make up for the lack of output.  Since Bob can’t do that, he has to realize that the only way to generate output is to do everything possible to ensure Alice and John can begin creating, Bob will focus the majority of his time finding solutions and being available to react once those solutions are ready.  Because of this, the problem got resolved more quickly, and Alice and John were able to start working more quickly, and in general, actually produced more in the end than our first example was able to.

That’s just a single example of where someone doing less can end up doing so much more. It’s more than just the time, it’s the mindset. It’s hard to be a servant leader, when you’re also trying to be one who you would serve.

Or at least, that’s my opinion on it. I’d love to hear what you think! Leave me a comment and let me know your take on this topic!

Note: After writing this entire post, I found a similar blog post with a very similar title written by Melinda Stelzer Jacobson which touches on a lot of similar points, but with more of a focus on splitting Scrum Masters across team. I recommend reading it, as there’s a lot of great info there, and she gives some practical numbers regarding how a Scrum Master actually costs less for a company in the long run, based on ROI. Great post!