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.

Process

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?

Responsibility

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 - http://agile.ee/. 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
  • Booking.com 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 – www.commitment-thebook.com

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

Part 3: When and Why to Fire a Scrum Master? – Planning and Analysis

Previous post about Decision making can be found here. Let’s continue comparison.

Long term vs Short term planning

soccer-champions

When you watch teams playing serious tournaments every game is not played like the Finals. In addition world-class teams participate in more than one tournament. Do you think it’s possible to win Bundesliga, domestic Cup and Champions league when you plan only one game ahead? If you don’t “save” your players and “force” them play at maximum level in every game you will not achieve such results.

For sure football coaches care about every game, but trend is more important for them. Last game might be an exception or just a bad luck. As the result all games are analyzed keeping in mind the whole tournament: how many games are played? how many games are left to play? what is the result of recent 3 games? ant etc.

What you can often see with software teams that sprint results are discussed without taking into account the whole roadmap. This leads to short-sighted actions or local optimizations, which is not necessarily the best choice. Good Scrum Masters must bring attention to this and make sure everybody recalls that team wants to win the “tournament”. What is your “tournament”?

Analysis

Either i was lucky when was playing football at young age or it happens everywhere, but even kids coaches analyze games afterwards. So i bet that professional teams also do that. Game analysis is the only way to improve and learn from mistakes. And I was really surprised when found out how much time and effort is spent on that in football (including various kind of software and hardware that gathers necessary information). Of course various visualizations and statistics are not the ultimate answer to all the problems, but in good hands it can give you very good insights on how to continue.

analysis 1 analysis3

No (powerful) retrospectives is the first signal that team is not improving, stuck or fell into a comfort zone. It means that Scrum Master is not doing his work and not focused on improvement. To have powerful retrospective team needs input, problems or results visualization, but it’s often teams are scared of any kind of metrics. Because of often abuse, when metrics are used by management to decide on salaries and bonuses, but not as additional information for the team to notice where to improve.

Football vs Software Development

Is it because football has predefined rules all these good practices are in place? Is it because Scrum is incomplete we have so many things depending on team’s maturity and Scrum Master’s experience? How do you handle that?

p.s. full presentation is available here. I will go through it in further posts.

Part 2: When and Why to Fire a Scrum Master? – Decision Making

As I mentioned in previous post main question is changing a bit – “What and Why to Fire a Football Coach?”

Would you fire a Football coach when he makes all the decisions for the team on the field? Why? The answer seems very obvious. If this happens – team loses opportunity to get better as they don’t learn by making own failures. All decisions are made by players during the game: tackle, shot on goal and etc… Of course principles and tactics are agreed before the game, but when the game starts a lot of things can change and a lot of things depend on players. What coach can do is to assist the team and make maximum 3 substitutions if things get out of control.

130525160147-champions-league-final-14-horizontal-gallerycoach

Main reason why it happens this way in football is the “system” itself. Rules don’t allow coach to run on the field and instruct everybody how things should be done. Unfortunately nothing prevents us from doing that in our daily routine. That’s why it’s so easy for “new” scrum master to fall into micro-management and “break” the sprint. And if such behaviour continues, probably even the team spirit can suffer in the long run.

What could be alternative of such “system”  in software development that prevents micro-management? I have such thoughts:

  • focus on providing as much information as possible, so team could make proper decisions
  • walk away :)

Could you help to come up with more ideas?

Next post on this topic: Part 3: When and Why to Fire a Scrum Master? – Planning and Analysis

p.s. presentation is available here. I will go through it in further posts.