Avoiding Scrum anti-patterns
There’s a fine line between a rhythm and a rut
Nothing succeeds like success
… as the Alexandre Dumas quote has it. And Scrum has had a lot of success over the last couple of decades. However success can be a double edged sword and so many people have now jumped on the Scrum bandwagon that a number of anti-patterns have now become ingrained into far too many teams doing Scrum.
This blog gives an overview of some of the major anti-patterns I have observed in teams following Scrum and some thoughts on how to have more effective Scrum events. This is by no means an exhaustive list of Scrum anti-patterns, I have just selected a few of the most damaging that seem to be pervasive today.
Scrum’s effectiveness compared to other methodologies for teams and work of various types I will put beyond the scope of this article, which also assumes a basic knowledge of the Scrum delivery process.
Stand up
The most common stand-up anti-pattern is for it be be a short meeting that focuses on administration rather than outcome. These stand ups tend to have a mechanical feel and are quite low energy. This stand up is more focused on joining the dots, ticking off items in an imaginary “good stand up list” than actual team conversation. This can manifest as the team taking turns to say variations of “yesterday I worked on a task”, “today I plan to work on a task”, “I have no impediments”. Another manifestation for teams that burn down hours is a stand up that goes through tasks on a task board, with team members taking turns to say various versions of “yesterday I worked on such and such a task, please burn down two hours on this task. There are three hours remaining.” And so on.
Avoiding this anti-pattern
As with all meetings, we want a stand up to be a high value conversation. A helpful focusing question is “what is our best use of time today, as individuals and as a team?” — where best in this context means the most effective way to move towards our objective.
If your team has a taskboard (such as Jira or ADO), then you will need to decide whether or not to center the meeting around this taskboard. There are pros and cons but on balance I recommend teams not show the taskboard during a stand up. The reason being that the taskboard will inevitably focus conversation around the individual tasks, whereas the conversational energy is best spent on clarifying the work, dealing with discoveries made the previous day and planning out the work of the day — the tasks can then be managed outside of this meeting.
The practice of allocating hours against tasks I have not seen to add any real value at all, and really just adds administrative overhead. Putting hours against tasks is in theory aids forecasting, however the future is of course unknown and attempting to predict the future down to the hour is a fruitless endeavour. Therefore, my recommendation is simply not to do hours-based tasking. See Jeff Sutherland’s (co-creator of Scrum) post on this
Refinement and Planning
I have put refinement and planning together as these meetings are two sides of the same coin — they are both planning meetings, in the conventional sense of the word “planning”, i.e. getting clarity on the proposed road ahead. Keeping a focus on the immediate term and the future at the same time is a difficult challenge. Planning, in today’s complex knowledge work environment is hard to get right and despite hundreds of books and thousands of articles on agile planning, significant anti-patterns remain.
At their worst, refinement and planning meetings focus almost exclusively on attaching points to stories. So stories are plucked from the top of the backlog and the team takes turns estimating effort — almost always by assigning story points. If the team are not aligned in their estimations of effort, a conversation is had (although even this conversation is absent from some team refinements) and the team will agree on an effort assignment. This conversation can be useful, as it speaks to the team’s understanding of the work involved in completing the story. However the practice of assigning points to stories should not be confused with future-focused planning. For a start, almost all points-assignment meetings I have seen will focus on the up-coming sprint, or at most one sprints distance. This means that up-coming roadmap items can simply seem to “appear” in the team’s workflow, and the team can feel unprepared.
Avoiding this anti-pattern
There are a couple of ways of avoiding this common anti-pattern, which one you choose will depend largely on the organization you work in.
Solution One. Team focus on discovery.
In this paradigm the team are given a focus, or mission and they work together to create their own understanding of the landscape they operate in, and to discover the highest value items to work on. For more on this way of working see this article on dual track agile.
In my experience this approach can yield some great outcomes, but it can also be a difficult paradigm for management to accept. For management the question “what is going to be done, and by when?” often looms so large that accepting that a team are simply “discovering their way to value” is often just not palatable.
This approach also brings significant challenges to teams, who need to step into to becoming accountable for realizing product value, not simply delivering features. If this approach is in view (really in view, i.e. with management support) then a complete re-think of all team refinement and planning meetings would generally be required.
Solution Two. Roadmap driven approach
Where a roadmap exists, a big part of the team’s job is to understand this roadmap and execute on it. Roadmaps of course come in all shapes and sizes; take a look at this blog for more on this subject. Where a team is taking a roadmap driven approach, my recommendation is that the team does a refinement meeting every week — and that one out of two refinement meetings does not focus at the sprint level, but rather at the roadmap level. After this roadmap-focused meeting teams, sub-teams and individuals can then create features and stories, these will be informed by the shared team understanding of the roadmap.
And finally on the subject of planning, a word on story points. The Scrum Guide does not explicitly call out story points, but the practice has become a part of almost all teams understanding of how to do Scrum. If your team uses story points my recommendations are:
- Focus on the conversation (as to why individuals have given differing effort estimation) rather than the points themselves
- Effort assignment should be only one part of a team Definition of Ready — just because the entire team agree on the fact that a story is an “eight” does not necessarily mean that all team members understand the story and its intent.
- The “classic” way of using story points is to obtain a team velocity, which is then used to estimate how many items (based on their story points) can be pulled into a sprint. For example, if your team sprint velocity is 40, then you would pull in items that added up to a total of 40 story points in sprint planning. If your team is using story points, but not using them for sprint forecasting purposes then I would personally question the value story points are giving to you.
Sprint Review
I have found that while some team members may initially feel uncertain when it comes to presenting in front of a group of people, with support and some practice teams generally do a great job of presenting work done in the sprint. The major anti-pattern I see is a lack of attendance from stakeholders, particularly senior stake holders. Whereas this seems like a missed opportunity, the reality is that with a number of squads doing reviews, and each review averaging an hour or so, attending every team review is a big ask for anyone, let alone a senior stakeholder. The other reality that not every review demonstrates tangible value delivered to customers. Again this runs perhaps counter to theory, but there can be many reasons for this: impediments, a focus on developing underpinning technology and so on.
Avoiding this anti-pattern
My recommendation is that we meet our market, where the market is senior stakeholders. This may mean doing a combined review (which, yes will be more of a demo than the Review Event described in the Scrum guide), presenting at showcases and the like. The team may also choose to do a separate review, in addition to the combined review; this will be a review to the team themselves and some of their peers and ideally direct stakeholders e.g. the lead of the tribe the team is based in.
Sprint Retrospective
There are many anti-patterns that can trip teams up when it comes to having high-quality retrospectives. The most common anti-pattern is simply to not to put a value on retros, which results in poor attendance or the team often cancelling the retrospective in favour of “getting on with the work” (this phrase may get its own blog in the future!)
Avoiding this anti-pattern
For a full picture of retrospective anti-patterns and how to mitigate these see my blog Team Retro Gremlins
Team process questions
There are many more Scrum practices not listed here of course. As an Agile Coach or Scrum Master, or a team member who has been around the agile blocks a while, you will be familiar with the more common discussions and sometimes debates around different Scrum practices:
- For work items not directly related to the core work of the team, such as craft meetings, other projects team members are involved in, training and general “stuff” — should these be put on the team taskboard or not? If we put these on the team taskboard do we assign points to them?
- How do we handle the cascade of work items. E.g. is it theme > epic > feature > story > task, or do we go for a flatter structure? Or are there extra layers to add?
- How do we create stories (or Product Backlog Items if this is your language) — does the Product Owner create these? Or does the team create them collaboratively e.g. in a Refinement session? Perhaps individual team members create these?
- Are stories assigned efforts / points in the Refinement or Planning Event?
- Many, many more!
There are various approaches to answering the various team Scrum process questions that arise. The more robust the team decision making process the faster decisions can be made, the more high quality the decisions and the more buy-in the team will have, even if some team members need to disagree and commit. A ‘lets give this a try’ mindset can also help here. Decisions on these practices are easily changed if they prove to be not as effective as first thought. So as a coach I may have opinions on all of these things, but my focus will be more on helping the team come to their own decisions by having a high level of trust within the team, and robust decision making processes.
Another paradigm that can help is to have clear expectations from the various Scrum Event types. Consider the inputs required, and the outcomes desired. For example, is the output of a Refinement session stories with acceptance criteria and effort (point) assignment? If so then what inputs to this meeting are required? Do the stories need to have been created before this event or are they created during the event? If before the event who is accountable for ensuring this happens?
At the end of the day
At the end of the day let’s not lose sight of the fact that teams exist to serve customer needs; and customers really don’t care what process was used in the development and delivery of a process or service, they care about the value they are getting for their investment. Its also OK to try a few different things, and have fun along the way!
