I get testy when the software community measures developers.
Many software projects use
Sprint Burn-Down charts (SBD charts)
thinking they are measuring Velocity.
My beef with SBD is that Velocity is misunderstood. I care most about the experience of a software product (e.g., general quality and usability). SBD is, at best, misused, if not useless.
Speed and Direction Define Velocity
We
think we're measuring velocity when we're tracking the
illusion of speed, and all the while, direction is AWOL.
Maybe speed isn't all it's cracked up to be. Here's the thing:
We have already wrung most - if not all - the speed & efficiency we're going to get from the development team.
No more speed. No more getting faster. No more SBD.
If we want better software products, it's time to critique the
Teflon Players in the software equation --
The Business. We'd be way ahead if we figured out how stakeholders can be accountable to the product team and to provide meaningful direction as a software product takes shape.
If you don't know where you are going, it's easy to iteratively not get there. ~David Hussman, 5:40 PM Nov 3rd, 2009 from TweetDeck
Silent But Deadly
The moniker
Silent But Deadly Guy evolved during a software project that recently went up in flames.
Silent But Deadly Guy was a gratuitous Project Manager the developers started calling Sprint
Burn-Down Guy in recognition of his sole contribution to the effort -- the daily Burn-Down chart.
Soon Sprint
Burn-Down Guy was shortened to the acronym
SBD Guy. Then by a simple twist of acronym morphed into
Silent But Deadly Guy.
The
Silent But Deadly story encapsulates how I feel about ceremonial metrics like Sprint Burn-Down that have little to do with making kick-ass software.