How long does it take you to deliver a feature into production, from inception to shipment?
If you can’t easily answer that question, it’s time to do some measuring. You can work to improve this metric over time, but unless you already know it, you’re just making wild guesses.
It’s easy to get hung up on how to find out this figure. One common method is to ask all your developers to meticulously log every moment of their time against whatever feature they’re working on.
Another option is to hire a crack team of project managers to log and catalogue everything that happens.
But developers (and indeed most other people) hate being measured. It suggests a lack of trust. It suggests that you think they’re lazy. That’s an unhappy situation for anyone.
But I’ll let you into a secret. The accuracy of your measurements probably don’t actually matter anywhere near as much as you think. And that’s because the time things take to be delivered — actually, properly done and working — is almost certainly far longer than you’d guess.
30 days? 60 days? 80? 100? It’s not uncommon. From first idea to last deployment is often a frighteningly long time.
Of course, this isn’t the case for all teams. If you’re already delivering complete features (be honest) in a few days, then measuring and improving is a different matter. But given a scale of tens-of-days, getting your team to log time down to the minute starts to look a bit crazy.
So, as a start, just take notes. Once something is committed to, write down the date. Then once everyone agrees it’s done, write down the date again. In a few months, you’ll probably have a reasonable picture, and hard data you can use to estimate future features, and test the effectiveness of improvements. All without jeopardising your teams’ trust.
Jez Halford is a software development consultant helping teams to deliver better software, more frequently. Visit jezhalford.com to find out more.
Top comments (1)
I love this advice, thanks!