Following up on the slightly longer analysis of overfocussing on output and velocity, I think there are a few things that are overlooked with a pure velocity based model. Most of them have been known for decades in the software industry. They are squishy.
- It’s essentially a Taylorist factory where most of the interest is in efficiency, and not on outcomes. by Taylorist, I mean Frederick Winslow Taylor. In fact, Kanban originally came from manufacturing. Cost accounting is the beginning of the imposition of a Taylorist model, to describe something more nuanced than what you see in a factory. (please comment and say why if you disagree). By using velocity as a yardstick, you pervert velocity’s purpose and dilute its usefulness.
- As per PeopleWare by Tom DeMarco in 1987, most new technology development problems are actually people problems, either on the product development team, or with respect to the customers.
- Outputs are assumed to be linear. This is patently not true for knowledge work. Even in 1975 at the time of the Mythical Man Month, it was already acknowledged that adding people tactically is a major blunder in the context of creative work.
- More recently, I’ve fascinated by psychological safety in the team as articulated by Amy Edmonson as an underlying factor influencing actual performance.
At its core, companies care about being able to release quickly. Velocity and story points are just one way to get at what’s happening and why it’s taking so long. But it’s essentially an internal process. At some level, it’s just bureaucracy created to manage product creation…on its own usually not valuable to customers.. So in and of themselves, if the teams provide value and can show they are doing so, then velocity doesn’t matter.
