I had the good fortune to sit in on a day long session with Dave Hussman (who is awesome, by the way) on the topic Agile coaching as a lead in to the Atlanta APLN meeting. It was chock full of tips and I recommend getting out to see Dave if and when you get the chance; he packs a lot of knowledge into a short amount of time in an extremely entertaining way.
One of the questions he asked is: when is a feature done? This is a perennial topic with Agilists and it’s a very valid question; how do we know when a feature is “potentially shippable?”
I piped up with my answer: a story is done when it’s in production use. That was a little different than the answers from the others in the room.
Think about it: we’re not delivering value until that value has been delivered. That’s a very Yogi Berra way of saying that until the user’s using, that feature you made isn’t contributing to business value. In a way that’s one of the original premises of Agile: release early, release often.
This is the reason why I like the cycle time measure over the velocity measure. Cycle time tells us how long the feature took from the time it was green lit to the time it went into production. This gives us a real measure of how long it takes to deliver business value. Velocity simply tells us how long a feature took to develop (unless, of course, we have release-per-iteration)
Agile asked us to work better as software development teams and deliver in tiny little batches. Lean asks us to do the same thing, but put the software team in the context of the larger organization and from the customer perspective. Think globally, act locally. Doesn’t matter how rockin’ a development team is, if those features are being held in inventory until waiting for some deployment event, they’re not done; they’re only done as far as you’re concerned, and, last I checked, there were more than developers and testers involved in the process of delivering software.
+1 to this David. This is where the lean concepts like inventory and value streams really help to cut through the crap. I wrote about this myself a while back.
Totally agree. But it’s much harder to estimate the cost for the whole cycle. Do you have any tips for this?
http://blog.viabrains.com/2008/10/what-is-cost-of-story.html
Great – we’re finally getting back to the Theory of Constraints
– rather than “being agile” just in terms of development.
@Andy
“I wouldn’t even go this far – I think a story is hardly finished even when in production use – this is merely the beginning of customer and user feedback that will lead to further development on the feature”
I guess now you have to define what you understand by “production” use, because I’m sure the customer has a different perspective…
@Scott – The easy (read: cheap) way out of that question is to say there shouldn’t be any bugs if you’re building in quality, talking to the customer along the way, and writing rich and fully automated tests. The realistic answer is to say that when you find a bug in the pipeline you have a couple of options. I have a post coming up on that, but, so as not to cheese out, we pretty much block the item when we find a bug and fix it right there and then. This ensures our initial quality is *very* good. So if we do find a defect it tends to be from use and not really a defect: it’s a feature that represents a change to a feature and, as such, gets its own cycle time / flow through the pipeline.
One thing I have been thinking about is maybe counting a queue a the end of the pipeline that’s something like “monitor.” We more or less have that by having an acceptance queue, but that’s for a limited customer population. This would add a few days to cycle time but would be the ultimate in done. Just a thought at this point…
do you add bug fixes to the cycle time after release?
@Andy – We should involve our customers early and often to ensure we go live with accepted features that were vetted by the customer. Of course we should build in quality so that initial quality excellent. All of this is a goal, a place to get to, of course…
I think I’d have given the same answer. And I’m also a big fan of Lean software development. Certainly it’s true you’re not anything but a cost center (as a developer) until someone is using what you’ve written in a practical fashion.
I wouldn’t even go this far – I think a story is hardly finished even when in production use – this is merely the beginning of customer and user feedback that will lead to further development on the feature. This is especially true for web apps as opposed to desktop apps, but true either way.
I’d say a story is done when it is accepted by the customer (product owner) and/or user (not always the same) as done – and this brings up the importance of being able to measure customer acceptance/feedback.