Conclusion: When and Why to Fire a Scrum Master?

coach_talksI was covering “Process and Responsibility” topics in my last post.
To finish my analogy with Football Coach i want to suggest three main aspects that will help you to distinguish great Scrum Master from mediocre one.

1. Process is more important than value

Process is only a tool that can help to achieve results. Great Scrum Master will experiment with various practices and approaches to find what fits best his team, which depends on team’s maturity, experience, mentality and etc. And what is more Great Scrum Master will always think about the value being created by the team.

2. Suggests decisions only, but provides no information

Great Scrum Master will work towards increasing the transparency and bring as much information as possible to the team, so they understand the problem and would be able to participate in the decision making. Great Scrum Master will make sure big picture is not lost and everybody knows what is important and why it’s important.

3. Maintains status quo

Great Scrum Master is always focused on improvements. Without challenging status quo nothing much can be achieved. You can’t win two tournaments in a row if you are not going to change tactics and strategy.

What is next?

Professional Football team has several coaches. This is another interesting discussion to have… But remember – Scrum Master is team member with different skills set. Good luck in finding a great Scrum Master and right balance between number of team members and number of “Scrum Masters”!

Presentation is available here

Agile Saturday X – Metrics

Continue sharing notes from Agile Estonia event - Previous post about Staff Liquidity

  • Lagging metrics – the ones you can’t affect [e.g. weight]
  • Leading metrics – the ones you can affect [e.g. what food you take]
  • The best way to influence the team is to visualize the data
  • Avoid vanity metrics. Use AARRR metrics: Acquisition of customer; Activation – are the active? Retention; Reference; Revenue
  •  Don’t use metrics as target
  • Make sure everybody understands what is behind this data and how it’s gathered
  • Use balanced set of metrics, e.g. Revenue, Ability to do more work, Happiness of employees, Happy customers
  • Keep in mind the cost of metrics gathering. Will you be able to make decisions based on that?
  • Metrics expire!

Last part is going to be about improving the whole value chain. It was very interesting keynote by Mattias Skarin.

Part 4: When and Why to Fire a Scrum Master? – Process and Responsibility

Last post was covering Planning and Analysis. Before conclusion I want to cover two key areas from my point of view. It’s about process and level of responsibility.


In most definitions Scrum Master is the person who helps the team to achieve best results: this can involve removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the next sprint.

trophy celebration

Unfortunately everybody focuses mainly on process and completely forgets about the real purpose of team – create value for the customer, build great product. The real value of Scrum Master is that he has other skills and knowledge that can help the team to do that.

Have you seen Football Coach that doesn’t care about the Trophy? It’s not even a discussion. It’s weird. Both the Coach and the Team have exactly the same target! Why do we have Scum Masters who only cares about the process than? Don’t forget - Scrum is only the tool. Are you the fool with the tool?


Soccer Euro 2012 Spain FranceWhen team doesn’t win no one cares what the Coach thinks he takes responsibility and leaves (or fired). There is a saying in football:

Team wins the game, but coach loses the game

What do you often see in organizations? It’s so easy to find whom we should blame, but not the Scrum Master: Developers, POs, Other teams, Culture, whole organization, stupid users…

p.s. full presentation is available here

Agile Saturday X – Staff liquidity

I visited another great event organized by Estonian Agile community - It was pretty much great event with interesting topics. Even though my notes are taken out from the context and include my thoughts also, I still think they might inspire you for new ideas and improvements in your company. I will continue with notes in further posts. Here we go with part 1:

Real Options – Introducing Staff Liquidity
  • Options have value
  • Options expire
  • Never commit early unless you know Why! Commitment kills options
  • Jumping from a cliff. At the very start it’s an option, afterwards it’s a commitment
  • monetize options. You get better price if you commit your arrival. If you want to have possibility to cancel the reservation – price is higher
  • When you start doing something it’s a commitment
  • Decision making: 1) everybody wants to be right 2) people are willing to be wrong rather be uncertain
  • Total uncertainty can be “solved” by bounded uncertainty – e.g. let’s try something for one sprint, validate output and make decision afterwards
  • What can we learn from lions? They sleep 20 hours a day and commit only to good options. They don’t rush and run around like insane. Why do we rush than?
  • Decision making: hierarchy alienates people who make decisions from real action
  • Staff liquidity: Give tasks to least able person (just above his possibilities). It will allow most skilled people to find time for teaching and solving critical situations! Counterintuitive, but it makes a lot of sense!
  • Value stream mapping helps to eliminate waste. 2 biggest wastes in development: bugs and delays.
  • Track queues that form in front of the constraint and gaps that form after the bottleneck
  • Staff liquidity: self score the team to identify weak and strong spots of the team
  • TOC: 1) specify the goal 2) find the constraint 3) prioritize “around” the constraint 4) move staff based on decisions above
  • Specify the work and assign value to it. Manage work, not people
  • Move people to work, not the work to the people
  • Focus on flow of work, not people utilization
  • If it’s a commitment – think how to make this an option
  • Scrum is more about commitments, Kanban is more about options

If you find these ideas interesting i believe you can read more about it here –

p.s. if you decide to share these notes, please use #agilesaturday hashtag as reference to this event