Scrum Master Mistakes

Depending on who you talk to, scrum is either a standard industry practice, a panacea for all that ails development, or is a total waste of time taken on by people who want to talk instead of work. Depending on your environment, any of these may be true. Scrum is like any other tool, use it well and in the appropriate context, and it’s helpful. Use it poorly or where it doesn’t fit and you have problems.

Many developers have had awful experiences with scrum. Many of those who haven’t, end up becoming scrum masters and providing other people with awful scrum experiences. But what if you are an aspiring scrum master, or (worse yet) got saddled with the task with no preparation? What do you do so that your conduct as a scrum master doesn’t make your team miserable.

Scrum is a helpful process, but is more harmful than not when done badly. There isn’t a real fix for many of these problems, other than avoiding them in the first place. Scrum done well can be very helpful, but you do have to watch for some of the pitfalls if you want it to work well for your organization.

Episode Breakdown


Trying to do it all at once

Transitioning to scrum takes time. You cannot do it all in one sitting. At the very least, just getting people used to processes is going to take a while and is going to slow things down in the interim. If you dump a bunch of process on people, they’ll forget half of it. Habits take time to build.

Not taking steps in a logical order

If you system is a dumpster fire, without work being scoped, and without other good dev practices, scrum is just going to make it worse. If you are going to add the additional ceremonies of scrum, or any process, you’re going to have to free up time to do so, either through reduced workload, added personnel, or added efficiency. Some ceremonies are going to require team organization first. Daily standup, for instance, is ineffective on teams with nothing in common, even if they report to the same person.

Trying to do it without management buy-in and understanding

The team probably can’t implement scrum unless the manager is onboard, understands scrum, and is open to learning more. There are a suprising number of managers out there who read about scrum in some business journal, decide their company is going to do it and then pump out a braindead plan to make it happen. Additionally, managers need to learn more about it as they go, both from books and from experience. If they aren’t willing to do that, scrum is nothing more than more meetings and process for dubious results.

Ongoing Processes

Not allowing the team to own the scrum process

Allowing product owners, managers, etc. to drive meetings just alienates the developers. Not allowing the team to adjust their process, because a consultant told you “the one way”, tends to make the team disengaged. They’ll do the minimum they have to to make you leave them alone. “Not having time” to adjust processes because you confuse “refinement” with indecision is another common antipattern. If you can’t adjust when there is good reason too, you’ll frustrate and drive off your good developers and create a dead sea.

Allowing the team to be overloaded

Too much work means that processes get rushed, which leads to too much work. The burnout cycle will eat your team alive. Concurrent sprints are an even dumber practice, where you decide that sprint starts and ends move around arbitrarily and not to all team members at the same time because sales is driving your development process and “we need to put this work in a new sprint”. Fighting fires while not adjusting workload will burn out your best people. It will also result in more mistakes, which cause more fires.

Backlog stupidity

Constant shifts in priority over time periods shorter than the sprint mean that estimates are a waste of time, and that focus will be discouraged. Not adequately prioritizing work, or evaluating prerequisites for work means that you waste a lot of time on context switching. Overly large backlogs make things hard to find, are intimidating, and tend to lead to a lot of stale ideas being considered when they should have disappeared long before.


No or too few stand-ups

With these kind of processes, you do need fairly regular check-ins with the team to make sure no one is stuck, discuss potential problems/solutions, and to get everyone on the same page. Some teams will drastically reduce the number of stand-ups in order to get more work time. It works for a while, but eventually the drift in understanding will cost more time than the meeting. The main replacement for stand-ups is random interruption by management. It destroys team focus. There is no alternative to regular communication, however you implement that.

Stand-ups with the wrong people in them

Another common problem is having too many people in a standup, or the wrong people. Upper management probably shouldn’t be there, especially if they aren’t technical. If you have multiple teams with different responsibilities, you can really make a mess of things by bringing them together for a standup simply because they have the same manager. It wastes valuable team time. You also need to make sure to limit how long people can talk in a standup, as it is common for some people to go on and on about minutiae simply to look busy. They hurt the whole team when they do that.

Inability to concretely express what has been completed.

A lot of businesses have scrum-like processes with standups/meetings that don’t actually give useful information to management. You want hard numbers and actual data. A team member should be able to tell you what they’ve gotten done, what they plan to do next, and any blocks. If they can’t, you have to press them until they do. At the end of the meeting, someone should be able to relay the results of the meeting to management. This is easier if the meeting is limited in scope and duration and remains focused.

Book Club

The 17 Essential Qualities of a Team Player

John C. Maxwell

The ninth quality of a team player is enthusiastic. “Your Heart is the source of energy for the team.” Maxwell starts this chapter with something near and dear to my heart, motorcycles. While I do own a “cheaper, more reliable” Japanese bike, one day I plan to buy a Harley. He talks about how the company almost went under after being bought by AMF, but was saved by Harley enthusiasts. This included executive members of the company who bought it back in the 80’s. They formed the Harley Owner’s Group, where the term HOG originates. Maxwell talks about how the enthusiasm of the executives, employees, and customers saved the Harley company. He lists ways to recognize enthusiastic members of a team. First they don’t rely on anyone else for their own enthusiasm. Next they act before feeling. If you wait to feel like doing anything you’ll never do it. {Just ask me about cleaning the house…I never “feel” like it.} They also believe in what they do and focus on those positive beliefs. Finally they surround themselves with other enthusiastic people. In order to increase your own enthusiasm Maxwell gives three suggestions: increase your urgency, go the extra mile (do more than you are asked), and aim to excel.

Tricks of the Trade

Antipatterns aren’t there as something that is purely negative. Rather they are often the best way to unlock best practices in a way that consultants selling something will never do for you. That’s the reason we have as many episodes as we do on this sort of thing – it’s because it does a better job of exposing best practices.

Tagged with: , , , , ,