Do we need Scrum Master in the Project?

Exactly, is Scrum Master needed in a project? After all, we do Scrum, we do everything agile, we have a Project Manager, and we fit within the deadlines. In this article you will get the best TIP from me that will make your product grow like never before. And best of all, most companies in the market do the opposite.

Why do we need a Scrum Master role?

Lately, there has been a thought on my mind. Why do so many companies claim they “work” in Scrum but don’t have the most important role a Scrum Master a person whose job is to introduce Scrum and teach the company how to use it. Why do many businesses ask questions about Scrum when recruiting for a Project Manager? They ask about events, artifacts, what is needed if that is not the Project Manager’s job, and there’s no such a role in Scrum.

In this article I don't want to judge the approach, philosophy, or what roles are needed in projects, but I want to show you what we achieved by adding a Scrum Master role to the project. I will show you with numbers what the project, the customer and the development team gained. At the end, I will leave you to judge if the role of the Scrum master is needed. Many people wonder if Scrum Master is a role or a philosophy.

Let's start from the beginning. I wrote about the Scrum framework itself in another article -> "The power of Sprint Retrospective. Improve your organization by retro, not by the rules." From the article, you can learn how we introduced Scrum to projects and reinforced our agile approach in project delivery. In the text, I will also refer to the sprint retrospective because a lot of companies don't implement this Scrum event, and it gives the most value at the end of a sprint.

What changed with the introduction of Scrum Master role?

I promised it would be short, so let’s cut to the chase. At some point, we decided to implement Scrum with a Scrum Master to better structure the development and develop the product even better with the customer.

How the Scrum Master helped us:

  1. Each Sprint has a goal that the scrum team is working towards.
  2. Sprint goals include a clear business objective
  3. Structuring the sprints to two weeks
  4. Systematic refinement that enables us to plan 4 weeks ahead.
  5. Thes scrum team feels they’ve got a real impact on the evolution of the product.
  6. Even greater involvement of the Product Owner
  7. ... and more

And now, let’s see the most important numbers we achieved thanks to a Scrum Master.

  • 1 Sprint Retrospective carried out on a desk.

  • 14+ Completed Sprint Retrospectives Online.

  • 282+ Suggestions for improvement.

  • 23+ Improvements implemented by the Scrum Team.

  • 18+ Anticipated future risks associated with the product. We started thinking ahead, and we looked at what could jeopardize the product, not just what didn't work for us.

  • 132+ Scrum Team Thanks that the people exchange among themselves. It"s always great to hear a good word from a colleague.

Looking at the numbers, you might think that it took us a long time. Nothing more mistaken. This is what our meetings for this article look like in terms of time:

  • Refinement – 1 hour per week. We usually do one per sprint. Of course, apart from this meeting, communication takes place within the tasks.
  • Sprint Planning – 1 hour every two weeks. If we don't get the whole thing done, we finish the rest during Refinement.
  • Sprint Retrospective – 1 hour every two weeks. In the beginning, sometimes it took longer, but now it goes very smoothly.

There aren’t that many hours, so they’re worth investing.

How did we start with the SCRUM retro?

From a friend's desk! That's right, the first scrum retro was done on his desk. And the elements of importance we had selected were glued on the wall. Our sprint retrospective also evolved and changed to meet our needs, but it's all in one Miro file, so we can always go back and see how our needs changed. Some of the changes were introduced by a Scrum Master, but most were suggested by other scrum team members.

Approach 1 - Office desk

Scrum Start

Our first sprint retrospective, whole development team with the Scrum Master in one room. This was in pre-pandemic times when we all worked together onsite in the office. Later we moved all our SCRUM meetings online, with use of tool called Miro.

Approach 2 - Online board with tables

Tablica do Retrospective meeting

Second approach was an online version of our desk sprint retrospective. Simple table-like board, with "keep doing", "stop doing", "do more/less of" fields for virtual post-its.

Approach 3 - Our current retro board - SCRUM SEA

Scrum Sea

Curren version of sprint retrospective, quite popular among scrum masters concept called Scrum Sea Retrospective. Suggested by a Scrum Master, but very well received by the development team.

What's most important?

How to start work with Scrum

Don't try to Google the best tools for retrospectives, or how to do a sprint retrospective, or what 5 best tools for sprint retrospectives are. Just get started. Sit down and talk to your development team. It will give you the most value, and then you can see how the whole thing unfolds.

To sum things up:

The Scrum Master showed us how important it is to have the right approach to events in Scrum. Our own example showed us how much we can still achieve with our customers, and how we can constantly improve our work or the product we work on. Is Scrum Master necessary when we use Scrum? We think such a person is really necessary because he or she can point the scrum team in the right direction.

What do you think? Let’s talk about it. -> [email protected]

Finally, here’s a look at what the scrum team and Product Owner say about the role of Scrum Master and the Sprint Retrospective.

Amadeusz - Frontend Developer

Actually, the impact on the project was huge. Planning itself gives you a lot, because then it's obvious what you should focus on. It's also much easier to tell the client who wants changes during a sprint (e.g., due to some evolution in the design) that it doesn’t work this way, and it has to be planned. Previously, my reaction to such changes was, "Sure, I'll change this". I would sit down to work, and everything moved in time. Now it is still moving, unfortunately, but at least this one factor has been eliminated. It also often turned out that such changes are made several times in one place, now there is less of this. In fact, we almost never implement the first accepted version of the design. Scheduling is nice because it makes the client's expectations more realistic. Although we have set sprint goals that create pressure and mental discomfort, when the end is approaching and there is no end in coding, there is less stress. Thanks to Retro, in which we all take part, we know where our bottlenecks are, and we eliminate them effectively. Retro has also reduced the distance between the client and the developers. It is easier to work, there is more understanding, and there is not so much tension. Thanks during Retro are encouraging. It's nice to know that someone appreciates what you do. They give a little kick for the next iteration. We still need to work on the size of the tasks so that they are, let’s say, max 4 hours long. It will be difficult, but we have to strive for it, and that's what refinement is for.

Irek - Frontend Developer

In my opinion, it is important to organize Retro systematically because it allows you to present problems and identify product development risks. This way, you can take appropriate countermeasures. Retro also helps to see beneficial patterns that accelerate work. I like the fact that the development team chooses the most important issues by voting and discusses possible solutions to reach a consensus. Subsequent retrospectives verify progress in implementing solutions, which I think is also important"

Krzysiek - Backend Developer

I used to wonder what is the role of Scrum Master in our projects and I was not even sure if we needed such person. It took some time but now I know what his role is, and I also know for sure that we need Scrum Master. Thanks to him I know exactly what to do, what is the team goal for upcoming sprint and when we should achieve that goal. And because us, developers do not like to do too many things not related to programming, it is good to have someone who will guide us through that process and show us that putting a little bit of effort in refinement, estimations and planning will make our work easier, more enjoyable and satisfying. There is one more thing introduced by Scrum Master, that I really like, retrospective meetings. From time perspective I can say that this one hour call each two weeks helps us a lot. It allows us to spot many problems and we also come up with many nice improvements thanks to that. We are always finding many positive things to mention during this meeting, but we are also able to find something that not went so great. And what is most important, we are able to find solution for these problems. I always have positive feelings after the retro, probably because our meetings have very well organised form, everyone is engaged, and it not feels like we are wasting time.

Michal - Software Architect

We had some approaches to Scrum in the past, but in most cases it was far from being ideal, and we always ended up with a different approach. When we introduced a separate role of Scrum master both our clients, and our development teams was rather skeptical. One year forward and the situation is turned upside down. Our clients and developers love all our scrum sessions and organize them even when the SM is on holidays. I think it had a great influence on how we run our projects. I can now leave for a 3-week holiday knowing everything will run smoothly. Same applies to other team members. Value is constantly delivered, and the team is always up-to-date with current goals. I can now say with full confidence that during this one year, our process became more mature, more enjoyable and predictable at the same time. This would not happen without a scrum master for sure.

Gustavo - Customer Success

I would say that the scrum sessions give the opportunity of every team member to share their thoughts and solve issues that they think are important. This helps a lot in preventing problems from escalating by not being solved in the first place, and the team becomes more engaged and productive.

Reinder - Product Owner

To make progress its important to find the balance on the different aspect that influence everyone's hapiness and productivity. Its not only about delivering new features or update the product, its also important to reduce technical dept, focus on internal processess and have the right balance with customer success. The retrospective brings this together to give clarity on where everyone is, and what is needed to change the balance in the right direction.

Recently I asked another company if they have a Scrum Master role in their teams. They said they don't because customers are not willing to pay for that role. I think that approach is deeply wrong. Scrum Master is not for the customers and they are not to be asked. Scrum Master is for the team, to make their work together simply better, more enjoyable, and efficient. And it works at Accesto, people like working together and stay with us for many years - see Why developers work 7+ years at Accesto?.

Need help with your project? Want to take your developmeny to the next level? We are here to help.


Ready to make your SaaS Scalable?

Fix most important issues within days from the kick-off


Related posts