There’s been some discussion this week in the comments over on It’s a Team Game about a software team whose internal and external customers don’t seem interested in their product increments. No-one seems to care whether the team delivers anything at all. In response, members of the team are concluding that they need more of a focus on delivery, as recommended by Alistair Cockburn in Are Iterations Hazardous to your Project?. They reason that frequent delivery (and demonstration) of running tested features will create belief, and then demand will follow.
This got me thinking about the RTF metric, and in general about the attributes of the product increments delivered at the end of each iteration. Certainly they should consist of running features – which I take to mean that they provide (possibly small) chunks of meaningful, cohesive, user-visible behaviour. They should also consist of tested features – which I take to mean that there are no defects in them. But which features?
In order to turn around an indifferent audience, it may not be enough to demonstrate delivery. The lack of bugs will definitely help the team’s credibility, but there needs to be more. The features must be valuable to someone, and they must be fresh. It’s no good delivering something that has only marginal benefit; and it’s no good delivering features more than a few months after they were requested. Stuff has to be relevant to today’s customers today.
So it seems to me that, even in the early days of creating a relationship with customers, each increment must deliver at least one running tested feature that was asked for only recently. Ideally a feature that was requested at the previous end-of-iteration demo. Nothing will get customers hooked more than meeting their demands quickly and perfectly. And once they’re hooked, they’ll want to steer too.
And so I feel that the RTF metric is incomplete. We need to augment it with a measure of turnaround time for features – perhaps Kent Beck’s software-in-process metric. And we need to add a measure of the value delivered – perhaps Ken Schwaber’s revenue earned per $100k spent. Value, quality and speed – do they provide a complete measure?
SteveM
October 22, 2005
That’s basically what I was trying to say on Gav’s blog. There’s a timely comment at the start of Ron Jeffries latest blog – “Delivery of the running, tested, features the customer wants is the purpose of the development team” (my italics).
Sometimes I think we focus so much on the running, tested, features we forget about the last part. My real point, though, is that even when we remember that last part we misunderstand it: we focus on giving the customer what they asked for rather than what they want. It’s a subtle distinction, but I think it’s one that explains the lack of excitment we often see even when delivering exactly what was asked for, on time and bug free.
floor jack
March 14, 2009
This is the first time I comment here and I should say that you provide genuine, and quality information for other bloggers! Great job.
p.s. You have a very good template for your blog. Where have you got it from?
Kevin Rutherford
March 15, 2009
@floorjack: It’s just one of the standard themese (Simpla) on wordpress.com