zx
I recently was invited to a Scrum.org Webinar, and I picked a topic close to my heart: the worst Scrum anti-patterns. So, without further delay, here are my top ten of the meanest, baddest Scrum anti-patterns I have experienced.
How hard can Scrum be; the manual has 13 pages? You may have heard something along this line from skeptics in the past, dismissing the complex nature of an intentionally incomplete framework. The point is that exciting discussions happen when you start digging a bit deeper. Supposedly simple Scrum questions often return a broad spectrum of answers, ideas, and opinions.
Therefore, for some months now, I have run polls on LinkedIn. The polls address topics like the implications of self-management, how the management or corporate hierarchy fits into the picture, and the relationship between Scrum and agile coaching.
Let me share some of the controversial findings and discussions with you. As always, there are no simple answers in complex environments.
Despite decades-long efforts of the whole agile community—books, blogs, conferences, webinars, videos, meetups; you name it—we are still confronted in many supposedly agile organizations with output-metric driven reporting systems. At the heart of these reporting systems, stuck in the industrial age when the management believed it needed to protect the organization from slacking workers, there is typically a performance metric: velocity.
In the hands of an experienced team, velocity might be useful team-internal metric. But, when combined with some managers’ wrong interpretation of commitment, it becomes a tool of oppression. So when did it all go so wrong?
Many people dislike estimating work items as estimates supposedly open the path to the misuse of velocity by the managers, reintroducing Taylorism, micro-management, and excessive reporting through the backdoor. To them, for example, the proponents of #noestimates, estimates conflict with basic ideas of agile product development such as self-management, becoming outcome-focused, or leaving the feature factory for good.
I like to suggest a different, less ideological approach: estimates are useful at the team level, just ditch the numbers. How so? Estimation of work items is a fast way for a Scrum team to figure out whether all team members are on the same page regarding the why, the what, and the how of the upcoming work. The numbers are a mere side-effect, probably still valid to inform the team, though. (Indeed, the numbers are not intended to be used beyond the team level.)
By the way, similar to the fact that you cannot “not communicate,” I am convinced that people will always “estimate,” whether they talk about it or not.
There are plenty of failure possibilities with Scrum. Since Scrum is an intentionally incomplete framework with a reasonable yet short “manual,” this effect should not surprise anyone. For example, how do we communicate with members of the Scrum team that take the Scrum Guide literally? What about a dogmatic Scrum Master?
Join me and delve into the effects of Scrum dogmatism in less than 120 seconds.
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. One area that typically flies under the radar is improvements. While the Scrum Guide encourages addressing the most impactful ones as soon as possible, it is up to the Scrum team to figure out how to improve. One manifestation of this core team task we often encounter is picking unsmart improvements, though.
Join me and delve into the consequences of picking unsmart improvements as a Scrum Team in less than 90 seconds.
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. One area where Scrum’s nature of being intentionally incomplete causes issues regularly is whether Scrum teams shall stick to the event schedule even if the team’s life is uneventful? For example, is skipping Retrospectives okay?
Join me and delve into the consequences of skipping Retrospectives in less than 90 seconds.
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. One of Scrum’s first principles is self-management. It is based on the idea that the people closest to a problem are best suited to find a solution. Therefore, the task of the management is not to tell people what to do when and how. Instead, its job is to provide the guardrails, the constraints within which a Scrum team identifies the best possible solution. Join me and explore the consequences of a management ignoring self-management and what you can do about it.
There are plenty of Scrum stakeholder failures. Given that Scrum is a framework with a precise and concise yet short “manual,” this effect should not surprise anyone. While the Scrum Guide makes numerous references to stakeholders in Scrum, stakeholders themselves are no official role (accountability), no matter their crucial contribution to a Scrum team’s overall success.
Explore with me three widespread examples of how stakeholders fail their Scrum teams in three short video clips, totaling 6 minutes and 5 seconds.
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. When Scrum becomes an element of an agile transformation, a lack of agile leadership qualities on the incumbents’ side may impede its overall progress significantly despite the best efforts of all other change agents.
???? Join me and explore the consequences of a lack of agile leadership qualities and what you can do about it in less than three minutes.
