When implementing a change of working a while back in my development team my boss of the time said, “Well, okay, but I want you to show me that your changes are making a difference”. What’s the metric for better software? I knew all about the dangers of measuring things like lines of code — that wouldn’t do anyone any good.
So I opted for something low-tech. I asked people. I asked team members and wider stakeholders once fortnight: “How are we doing?” I broke it down into ten questions, varying depending on the role of person and over time I could chart our progress. We went from around 30% satisfaction to 80% in four months and then plateaued. The plateau gnawed away at me, but by that time interest had moved on — the team was doing a great job and there were more pressing problems elsewhere.
I subsequently spoke to a programme manager who used a similar, but simpler, technique. He asked: “How would you score us out of five this month?” And then the follow-up question, if it wasn’t full marks… “What would we need to do to make it five?”
I much prefer this version, which is simpler, more direct, and there’s more clarity on what to do about the results. It reminds me of the guerilla approach to lean product development: putting a mock-up in front of someone in Starbucks and (eventually) asking “Would you buy this product? What would it take for you to buy it?”
I’ve used lots of other metrics for different things relating to performance, output and productivity: bugs resolved per week; lines of code per class, and so on. But I don’t think I’ve ever found any for this kind of thing which are so simple and connect the work and the output so effectively.