Sprint Planning Is Ridiculous

Agile is great.

Watching Scrum sprint planning is silly. It is hilarious to watch a few engineers with no knowledge of the larger system or technology dragging the entire group down a rabbit hole about nonsense ideas and misconceptions.

Generally speaking, the ambient benefits of ensuring that everyone is on the same page are typically worth having a lengthy slug-fest in which everyone gets to submit the group to their ignorance. Personally, I love getting my questions answered in a high-bandwidth way. Having to do it front of an audience who could care less isn't as fun.

Going beyond having well-written stories and foundational knowledge across the team that is a prerequisite, there is a certain pattern in the conversations that a smooth team naturally follows which mitigates the risk that spring planning beomes a morass. Most importantly is identifying technical patterns and practices that the group will pursue with priority.

When we consider that there are lots of ways to model a data structure or class definition we have to allow for each contributor to bring their own preferences to the effort of creating a whole solution. What we would like to ignore is that the choices of one will impact the many. The pattern that a data modeler prefers will definitely drive the implementation of the contributor responsible for the services or the user interface. In our self-centered world view we like to pretend that we can use Separation of Concerns or isolation patterns and that will remove our interdependency. This is fallacy. Just because you say you prefer SOA or hiding implementations behind RESTful interfaces doesn't mean your choices for data structures, invocation patterns, and state management won't impact the work required in my client or integration service.

And don't get me started on how ludicrous planning poker is for actual estimation. Don't misunderstand me. Asking everyone for their opinion of the size for a thing is an quick and effective way to uncover misunderstandings and misaligned expectations. But the idea that the wisdom of the group is better at determining an actual estimate is patently wrong. The issues with group think are many and well understood. Assuming they don't apply to software development is near-sighted and ignorant. So definitely have a round of planning poker and find out who isn't aligned with what the group thinks needs to happen. Then listen to the contributor who will do the work on how long it will take. Allowing a contributor to 'compromise' to group allows them to skirt accountability for estimating accurately, making solid commitments and keeping them. And if you can't ask for accountability and hold people to it, what is the incentive to get better?

Basically, the group rituals have their place and some distinct advantages. But at some point, you have to shift from low-bandwidth group think into high-bandwidth individual performance. Effectively making this transition is the hard part and a common point for many to abandon Agile and Scrum. This is all to reiterate that "Common sense is uncommon" and if something has more than one person accountable, then no one is accountable.