If you’ve been through some kind of an agile transformation you’ve probably heard of the “Definition of done”.
Now, let’s talk about that, since we all have a dictionary. I mean, should we define words that we learned when we were kids?
Apparently we have to.
Anyway. There are all kinds of “done”. Done coding. Done testing. Done fixing the bug. Done watching Star Trek (never!) .
But even if we’re done coding, are we really done? Will we not wander into the code again and change it just a little bit? Are we really done testing, or can we just play with it a little more?
So what’s “done”? Easy.
When you move on to something else. It’s ready (enough). Whatever it was that we worked on, we can focus on something else. A new task, an old-new bug.
Why is that important? We can think about “done” in many contexts. But the main context that’s important is delivery. With agile processes, that’s really important.
For example, if I’m “done coding” a feature, that means it’s not yet delivered. I may think that I can focus on something else. But that doesn’t move the feature into the hands of the customers.
Even “done testing” does not mean that. “done delivery” does. And that’s the “done” that counts.
Well, what does that mean? Regardless of what we think of “done tasks”, more importantly we need to think about “delivered features”. If code is just sitting on the shelf, it’s not done. When the testers gets their hands on it, they will be back at my desk with a vengeance. What I thought was done, really isn’t.
Done means WE, as a team, can focus on something else to deliver. It’s not a personal thing, it’s a team thing. The team decides when something’s done, and until it does, what I think, doesn’t matter.
I think we’re done here. If you want to talk about done-ness, I also can help with scrum and agile implemntation, the simplified version (as you can see in this post). If you want to get more agile with technical practicality, contact me.
0 Comments