A recruiter recently tried very hard to get me interested in an opportunity at a large organisation. He gushed about my passion for truly Agile development, telling me how I’d be perfect for this key role at a prestigious firm, and attached a job spec. And that’s where it all fell apart. The company shackled everything in metrics, rigid processes, Sprint performance tolerances, blah blah blah. Apart from the fact that I’m very happy in my current role and would only consider leaving for a six-figure salary and a two-hour working week (on a tropical beach), there’s absolutely no way I would consider a post with a company that boasts about Metrics Driven Agile Development, with major emphasis on the Metrics Driven part. I’d run a mile in the opposite direction. Well… I’d stroll. I’m a big fat bloke with a dodgy ankle, so running a mile isn’t really an option. But I digress…
When I come across things like this, my head goes straight to The Agile Manifesto, and its twelve principles. In particular, number seven:
Working software is the primary measure of progress.
All too often, this basic, foundational, core principle is swept aside by well-meaning metrics-mavens who live by the rule “to measure is to know”, and get a little carried away. I say “well-meaning”, and they really are. There’s no malice here, they’re genuinely working hard to help the organisation. Or so they think. But when the mandate comes down to measure Velocity across Sprints and Teams, and hammering those teams which don’t fit within somebody’s concept of “the norm”, something’s gone badly wrong. What problem are you trying to solve? If you don’t have an immediate, clear and meaningful answer to The Engineering Question™, then there’s a good chance you’re wasting effort with this sort of metric.
Is your team producing code fast enough, with enough features, to the expected quality? Yes?
- Well done.
- Buy them all a beer.
- Seek ways to improve.
Is your team consistently working within 7.3% of the company’s target Sprint Velocity? Yes?
- Whoop-de-doo. You do realise that Story Points Don’t Matter, right?
- What does that mean in your life?
- How much engineering-time have you burned, introducing and enforcing this nonsense? Wouldn’t that time have been better spent doing actual, you know, engineering? Ask yourself The Engineering Question™.
Your developers want to produce high-quality code as quickly as possible. Let them!
Grumpy
Let me explain that I’m not against metrics as such. There is a place for them. Just don’t get carried away in a metrics-frenzy, trying to quantify and normalise everything to fit within some theoretical model of perfection. People don’t work that way. They’re not robots who crank out x quantity of product for every y quantity of time. They’re people, not resources. Output will vary depending on a myriad of factors, but mostly the human one. When in doubt, refer back to the very basics of truly Agile software development: Working software is the primary measure of progress. Your developers want to produce high-quality code as quickly as possible. Let them! If your measurement processes aren’t directly and visibly aligned to helping them do that, you’re just getting in the way. If there are a few things that you actually get real value out of measuring – I’m all for that.
The postings on this site don’t necessarily represent the views or opinions of my employer, professional organisations, political party, family, car manufacturer or anybody at all, really. I don’t know where they come from. It scares me sometimes.
4 thoughts on “Agile Metrics: Ask yourself WHY.”