Master... Master...

Table of Contents

The Role of the Scrum Master

In the real world, there are many variations of this role. Sometimes it’s a person from the team, sometimes a manager, sometimes someone from outside the team, sometimes a specialist in being a Scrum Master, and I’ve even seen it as a rotating role within the team. So, who is it really? What’s the purpose?

In the world of software engineers, there is no shortage of great ideas. There are plenty, I would say. Programmers, designers, and architects are incredibly creative people… sometimes too much so. However, there’s one catch. Good ideas mean little. Just like good intentions, I can bet hell is paved with good ideas too. Ladies and gentlemen, I will now reveal a shocking truth, which is the greatest secret of efficient teams: ideas need to be implemented and energy must be put into overcoming all difficulties. In other words - it’s not enough to come up with an idea, you have to execute it! I can already hear the voices: “What a great discovery you made!” Well, indeed I did…

Let me give an example (from life). Once, I worked with a team on architectural changes. After an hour of work, I learned they already had quite a reasonable project plan, drawn in diagrams. So I asked: “When was it created?”
“- Well… over half a year ago…”
“- How much time did you spend on it?”
“- About 2 weeks for four people?”
“- And what did you do with it after that?”
“- Well… nothing really, didn’t know how to start with it…”
“- So you did nothing?”
“- Well… yes…”

And this happens often, especially with architectural changes and refactoring, and many other areas as well. We, technical people, like to solve puzzles, problems, and create solutions, but when it comes to implementing them, especially if a broader plan and interaction with others are needed, it’s a different story.

And that’s what a Scrum Master is for… to make things happen… to add coal to the fire… Even when things are falling apart, not to give up and adhere to the established assumptions. Every change, every project needs a leader because it’s them who make things happen, push matters forward, and help solve problems. They don’t need to be the manager, just ensure that things are progressing.

Therefore, which of the initially mentioned solutions is good? Any, as long as there is someone (a leader) or something (also the team) that ensures that things happen (monitors the process and helps solve problems).

A small addition at the end. Many of you are probably wondering about the rotating Scrum Master… I’ll tell you a secret… although the role was rotating, behind it all stood… a leader, even though he did a lot to make it invisible…

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

Why I Hate These Standups...

Why I Hate These Standups…

I often hear it… that they are a waste of time, just distractions from work, adding no real value…

Read More

A Simple Introduction to BDD Part 1

A Simple Introduction to BDD Part 1

Today marks the premiere of my screencast, which is essentially my initial foray into video blogging and sharing insights in this format.

Read More

A Manifesto Against Developers

A Manifesto Against Developers

I hate you because:

  • You focus on the features of your IDE instead of the features your client/user needs.
  • You consider typing at the keyboard as thinking.
  • You waste countless hours manually testing your code.
  • You spend more time struggling with frameworks than delivering value to end users.
  • You code for hours without asking yourself, “What am I really doing?”
  • You naively believe that technologies and tools will solve your problems.
  • You naively believe that a good algorithm is more important than a good understanding of requirements.
  • You naively believe that your intuition is enough for writing good code.
  • You naively believe that you can manage the complexity of the system piece you’re working on.
  • You agree to unrealistic deadlines.
  • You write poor code and rationalize it with various excuses (because there is no time).
  • In your head, you create code snippets without really knowing what needs to be done.
  • You guess what needs to be done rather than clarifying.
  • You mindlessly follow the technology you use.
  • You don’t understand the tools and technologies you use.
  • You isolate yourself in your piece of code, breaking contact with the world.
  • You think it’s all the fault of managers or clients and believe you can’t do anything about it.

… even though I love you because I am a programmer myself.

Read More