Ironically, Scrum is a wonderful tool for micromanagement. Jeff Patton said it well, “contrary cultural values may lead people to use their new found agile process and techniques for evil instead of good.” Scrum provides a convenient façade for organizations with fundamentally anti-Agile values, culture and mindsets to achieve new degrees of micro-management, while simultaneously flying the “agile” banner. Too frequently teams become hyper-obsessed with tasks, task estimation, iteration commitments, and iteration burndowns, believing these (relatively unimportant) practices are somehow the essence of Agile. Scrum makes it a little too easy to focus on “process and tools” without fundamentally re-evaluating whether culture is consistent with Agile values.
As Ani Difranco says, “when you sit right down in the middle of yourself, you’re going to want to have a comfortable chair.” Transitioning to an Agile culture should be a cathartic experience for the organization; it’s tough, messy work examining who you are and who you want to be. If it’s not painful and disruptive, with copious degrees of wailing and gnashing of teeth, be suspicious that you are missing the point. Process can change quickly. Values, behaviours, thought-patterns and interactions can’t.
Scrum doesn’t help, as it fails to make a clear delineation between which practices are designed to form the “external interface” of the team(backlogs, planning, prioritization) and those which are “private,” encapsulated within the team, and subject to use at their own discretion. The business cares about frequent delivery of value in the form of user stories; everything else is merely a suggestion to assist team collaboration. The following practices are particularly subject of my ire, particularly because teams too easily fall into the trap of believing that these are the “point” of Agile:
- Task Estimations (often in hours)
- Individual capacity planning
- Iteration commitments
- Iteration burn-downs
- Daily Stand-ups
Is your individual and team value defined by how well you perform these activities? Do you invest significant time in these practices? Are you getting value out of them? Does the team feel they have the empowerment to stop doing any of these?
To be fair: the real issue is how Scrum is (mis)applied, rather than Scrum itself. However, how many times does Scrum have to be misapplied before we treat it is a fault in the framework itself?
My suggestion: don’t practice any of the above. With the exception of the Stand Up, I don’t teach them to teams. Rather, focus on what really matters: pick the most important user story, collaborate on delivering it as fast as possible, and move on to the next. If you can never get anything done, look real long and hard at yourself and figure out why; guaranteed it’s not because you aren't doing task estimates.