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 Transitioning 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,