3 Simple Ways to Fail in Scrum

If you are an active Scrum practitioner, you have probably read plenty of articles that give you tips and tricks on how to use the Scrum framework to do meaningful work. I decided to take a different perspective with this blog, which hopefully will give you some insight into what you may want to avoid doing. Scrum is a simple yet powerful framework, and it is easy for practitioners to fall into some common traps. If you can see the traps early, you may be able to avoid them completely.

Failure Technique #1 – Practice only a subset of the events; choose which ones to not follow

Many teams that are new to Scrum feel that it’s too much change to adopt all four team events (Daily Scrum, Sprint Planning, Sprint Review and Sprint Retrospective), so they choose one or two as a starting point. Generally, I don’t have a big issue with this, assuming it’s a stepping-stone towards full adoption. If the team would like to start with the Daily Scrum first, then apply the other practices, that seems reasonable. If a team decides to only adopt one or two of the events, and never strive to change, then the team will have a much lower chance of reaping the benefits of the framework.

Failure Technique #2 – Plan one Sprint at a time only

This may be surprising to you, but planning just one Sprint at a time is risky. I will explain my thinking here. The Scrum Guide suggests that the team should select the most important, most valuable work items from the Product Backlog and put them into the Sprint to be worked. This is fine except there’s something here that is not mentioned and adds risk to the project: the bigger picture (a.k.a. Product Roadmap). Many teams that I have worked with feel that since the Scrum Guide does not require long-term planning, this is not necessary. On the contrary, long-term planning is a critical activity that most organizations need to do in order to ensure the work being done and the product or solution being built is aligned to a broader strategy. Working with the short horizon only creates a big risk of the work becoming fragmented and/or not aligned with the overall product direction.

Failure Technique #3 – Let the Scrum Master coordinate everything

Scrum is designed on the basis of self-organization which fosters teamwork and collaboration. However, more often than not, the Scrum Master is somehow expected to act as a Project Manager and coordinate all the details (such as logistics of the conference room). Is it easier to just let (or ask) the Scrum Master handle this type of task? Probably. However, this takes away from the Scrum Master’s true area of focus – be an effective facilitator of the PROCESS! Being able to guide and coach the team within each of the Scrum events is no easy task! There is significant preparation and pre-work that needs to be done before each Sprint Planning, Sprint Review, and Retrospective. Much of this work is not seen by the rest of the team, which is likely one reason that few teams seem to see the Scrum Master role as a full-time job. If we make the Scrum Master a coordinator, we are diminishing the value of that role and the overall effectiveness of the team.

This concludes a brief article on ways to fail in Scrum. As I continue my own Agile journey, if I come across any more of these, I will share those with you so you won’t make the same mistakes that others already have!