TL; DR: Ignoring the Capacity Check during Sprint Planning
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, the Developers are ignoring a capacity check during the Sprint Planning, and as a result, the Scrum team creates a Sprint Goal that most likely cannot be accomplished.
Join me and delve into the effects of this trust-shattering practice in less than 80 seconds.
If you value agile practices, it is crucial to know if a job offering or a prospective business partner that claims to be “agile” really keeps its promises. Unfortunately, as agility usually cannot be observed directly, and certainly not from the outside of an organization, there is no way of knowing in advance if you will enter an agile environment that serves your own working needs or if a lot of frustration lies ahead of you. Therefore, we ran an extensive survey throughout 2020 and 2021 with more than 1,000 participants from all walks of agility: the Agile Metrics Survey 2021.
With the Agile Metrics Survey 2021, we present the first results and conclude with some thoughts about possible application scenarios of our instrument as well as possible next steps in our research.
TL; DR: Maximizing Utilization as a Relic from the Industrial Management Past
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, what if the focus of the organization is on the maximizing utilization of the “workers” of the Scrum teams? What if the organization is still stuck deeply in industrial paradigm thinking, ignoring the benefits of slack time for the creation of value in the field of knowledge work?
Join me and delve into the effects of this outdated management principle in 60 seconds.
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, what if the stakeholders—who bring the budget that is funding your Scrum team—insist on calling the shots by overruling the Product Owner’s prerogative to define the composition and the ordering the Product Backlog? What if your stakeholders suffer from the “my budget, my feature” syndrome?
Join me and delve into the effects of overruling the Product Owner in less than 140 seconds.
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.
TL; DR: Estimates Are Useful, Just Ditch the Numbers
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.
