Scrum Master Q&A Fulltime Scrum Master Role

In my Scrum Master training courses, I get a lot of questions about the workload of a Scrum Master. One question I hear frequently is this:

Is the Scrum Master role a full-time job?

The answer is yes! In my opinion, the Scrum Master role is a full-time job. As a Scrum Master, you support the Development Team, the Product Owner, and the organization. You help others understand and master Scrum, and to achieve their potential at different levels.

Scrum Master activities can include any of the following:

  • facilitating Scrum events
  • working on the Scrum process
  • helping teams to become better
  • supporting empiricism
  • promoting inspecting and adapting
  • facilitating teamwork
  • removing and solving impediments,
  • assisting the Development Team to become self-organizing
  • help the Scrum Team to live by the Scrum values,
  • and observing team dynamics.

You will have your Scrum Master radar on at all time. You watch the things that are not being said, and you sense the things that are not on the surface. You can’t do that if you’re not there.

With this in mind, here are some answers to some other frequently asked questions.

Can you combine your Development Team role with the Scrum Master role?

No, you will lose focus and will not be able to excel in either role.

Imagine yourself as a developer, you are in the zone, minding your own business and delivering value. Then, suddenly, another developer has an impediment - the deployment to the acceptance environment did not go well because this environment is down. Your team member has tried everything to get it back up again, but it doesn’t seem to help. He asks you if you could help him. If you do not help your team member right away, he is not able to continue. So you leave your current coding and help your team member. When you finally have solved the impediment, you return to your work and continue. You have to connect with the subject again, since you were distracted for a while. Your focus is lost.

What if your company requires you to combine your Development Team role with the Scrum Master role?

If your company requires you to combine your team and Scrum Master role, make clear agreements with the Development Team about how to interact in the event of an impediment. Make it explicit agreements which role has priority.

Can we rotate Scrum Mastership amongst Development Team members?

No, you can’t rotate Scrum Mastership amongst Development Team members because not everyone on the team is a capable Scrum Master. The Scrum Master role requires certain capabilities, skills, and behaviors. Some of these Scrum Master characteristics can be learned, coaching, listening, facilitating, mentoring, observing, intervening but others are innate, such as servant leadership and being pro-active. If you have a role on the Development Team and you are also the Scrum Master, you will lose focus.

What if your company requires you to rotate Scrum Mastership?

If your company requires you to rotate Scrum Mastership, make sure that you are the Scrum Master for more than one sprint (e.g. three sprints) so you can start developing SM skills before you switch.

Can you combine the Product Owner and Scrum Master role?

No, it’s not a good idea to combine the Product Owner and Scrum Master roles because it creates a conflict of interest.

As a Product Owner, you’re busy with your stakeholders, changes in the market, exploring what delivers the most business value and helping the Development Team understand the requirements you have. As a Scrum Master, your focus is on supporting the Development Team, the Product Owner, and the organization. So, the people you contact the most are different and have different approaches.

 

As a Product owner, you want to deliver business value at the right pace. You can challenge the Development Team to take up a lot of items in the Sprint Backlog. As a Scrum Master, you protect the Development Team from overly demanding Product Owners (believe me, they exist). You do this by helping them asking challenging questions, like: Do we really believe we can finish this? Do we understand what is being asked? It is difficult to approach the team while wearing two hats. You will lose focus.

 

What if your company requires you to combine the Product Owner role and the Scrum Master role?

If your company requires you to combine the Product Owner role and Scrum Master role, make sure you have a clear distinction between them.  It’s also important to clarify which position you’re coming from with those with who you interact.

 

Can you work as a Scrum Master at a different location from your team or the Product Owner?

No, it’s not possible to function effectively in the role of Scrum Master if you are not onsite with the Development Team. You need to be present to sense the things unsaid or feel the vibe in the room. If the Scrum Master and Development Team work at the same location but the Product Owner and stakeholders are at another location, the necessary contact and collaboration are lost.

 

What if logistics require the Scrum Master and Development Team to work in separate locations from the Product Owner and stakeholders?

If you can't work in the same onsite location, interact with each other as often as possible. Make an all-day video connection if possible. Ask Development Team members who work on different locations to work together in the same location for a period of at least one month. The team members will get to know each other a bit, this will help to build trust in the team.

If you’re still stuck in a situation that prevents your Scrum Team from performing at its best, please contact us: info@scrumboosters.com

 

The secret to making people buy your product

There is no greater waste than building something extremely efficient, well architectured (is that a word?), with high quality that nobody wants.

Yet we see it all the time. We have the Agile manifesto and Scrum probably to thank for that (the seeing bit.) “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. It’s the valuable bit that is embodied by the Product Owner in Scrum, or “the value maximiser”.

Lean Startup has taught us that we suffer from cognitive bias and simply assume we know what customers want, and therefor should treat our requirements as assumptions. Get out of the building and ask our customers! We all know that Henry Ford would disagree. But could both be right.

Read more →

Verbal Turn Indicators For Intercultural Product Owners

Jujutsu exams are coming up. One of the things that examiners want to see in jujutsu is the use of go-no-sen, sen-no-sen and tai-no-sen. Go-no-sen means that you respond to an action of your opponent, tai-no-sen means you act simultaneously and sen-no-sen means you take the initiative and act before the opponent has a chance.

When we debate product features, roadmaps, implementations, marketing plans etc. this happens all the time. We listen to what the other person has to say and respond (go-no-sen) or we interrupt and try to take over the discussion (tai-no-sen).
Read more →

Don't Build That Product

At the Agile Chef Conference I facilitated a workshop where participants could experience how Aikido can be used to resolve conflicts on the work floor as well by applying verbal Aikido. At the end of the session someone asked me to demonstrate the best defence against a sword attack; I responded by turning around and running as fast as I could.

So how is that in Product Management? what ideas are ideas you should really run away from?

Read more →

The Best New Years Resolution: Agile Product Management

Agile Product Management is grounded in the Jobs to be done theory and Lean startup principles. In my book “The Product Samurai” I described how you can effectively apply these techniques to be a better Product Manager, but what I didn’t’ cover was why not everybody is doing this already?

Making up for that, and unveiling the seed conditions for the next level of Product Management, I am pleased to give you the best new years resolution: Agile Product Management

Read more →

The Customer Pain Map

Customer Pain

Customer Pain

“Ouch, that really hurt.” “What was it?” my sparring partner replied. “The choke or the overstretching of the elbow joint?” “The quick throw, I had no time for proper fall breaking.” I replied.

It happens in our sport, we try and experiment and try to find the best way to perform a technique. The goal is not to inflict pain but to figure out what works and what not. Knowing where the pain is and whether it affects the recipient is important beyond jujutsu and in fact is the core of Product Management.

Let’s look at a handy visualization of customer pain to help Product Owners and Product Managers to prioritize.

Read more →

Better guesswork for Product Owners

Estimation, if there is one concept hard to grasp in product development it will be when things are done. With done I don’t mean the releasable increment from the iteration, but rather what will be in it? or in Product Management speak: “what problem does it solve for our customer?”.

I increasingly am practicing randori (sparring matches in judo) and find it has increased my agile fu. It’s a constant adjustment of balance, creating opportunities rather than waiting for them to unfold, follow through fast or the opportunity we created is gone. It’s hard work, time boxed and most of the time I loose learn.

The key thing in both situations is that we don’t have a lot of time to estimate what will work or not. We can’t plan very far ahead and we have almost no data to make assumptions on, we do know however the extreme boundaries of the assumptions and iterate from there.

Read more →

OMG They made me Product Owner!!

The face of guy in the hallway expressed a mixture of euphoria and terror when I passed him in the hallway. We had met at the coffee machine before and we discussed how the company was moving to a more Scrum based way of developing their products.

Between euphoria and terror

Between euphoria and terror

“You sort of know how this PO thing works right?” was his first question. When I nodded he confined in me that they had made him Product Owner of a new team, without prior training. In general, not the best start, but I can see why the guys were anxious to start: their Product would address a pain experienced by many of their clients, promising start!

Over coffee and a whiteboard we came up with four steps you can take to kickstart a team that is new to Scrum and the Product Owner role.

Read more →

Guest blog: in response to "The Five Belts of the Product Owner

rey

This is a response to Chris Lukassen's excellent post titled, "The Five Belts of the Product Owner." If you haven't read it, my post won't make much sense, so go read it before you delve further into my post.

Chris's post brought up many thoughts and feelings because it hit the intersection of two of the things that are taking up much of my focus as of late, Judo and Product Management.
Read more →

ISO/IEC 27001:2013 and Scrum 5 Ways to Make it Less Painful

At some point, you get a nose for things that don’t feel right. Things that sound reasonable when explained, yet you get that gnawing feeling it sort of goes against nature. Working with Scrum and compliance to ISO is one of those things. Here are 5 ways to merge a rigid security standard, without violating Scrum values like focus, openness or its pillars, transparency, adaption and trust.

Read more →