Steve Berczuk blogged yesterday about the definition of "Done" for a programming task, and my oversimplification that "The only useful definition of done is that you approved it to release, in whatever form."
In my opinion, most agile teams focus on assembling releases. It's up to the developer to get a feature into a release, which makes it "done", and also makes it useful. I think that Steve is stuck in a theoretical model of Scrum where developers commit in advance to getting something done, and the release is not as important as getting brownie points for being "done." He says that it is important to pay attention to when a task is done, before you release, because:
- Agile methods have a goal of continuously shippable code. Of course, "shippable" might not mean "ready to release" and can mean something closer to "runnable," but you can get there by doing no work since the end of the last release. That isn't the goal of agile.
This is a measure "done" or "shippable" or "runnable" that we apply at the level of a build or a release. It says nothing about whether any one task is "done." In fact, it perfectly describes a process where you reduce the definition of "done" as being ready to include in a build.
- With that large scale definition of "done" you have no way of tracking progress within a sprint.
You can see what is ready to include in the build. That's an accurate measure of progress. You can use this to calculate velocity and improve your iteration planning by counting up the total function points that you actually release in each cycle. You can also see what wasn't delivered, and take corrective action around those hard tasks. Why is it important to track progress inside a sprint? If you have sorted your tasks in priority order, you will be working on the important tasks with or without progress tracking.
- Without an agreement on what you're going to, it's hard to know when you are changing direction. And acknowledging change is an important part of being agile.
Under the simple definition of "done" as "accepted in a release", you are constantly negotiating changes, and acknowledging them, because you are constantly negotiating what gets into the release.
In my opinion, most agile teams aren't doing "Test Driven Development", and they aren't doing scrum iterations where they plan everything in advance. Instead, they are doing "Release Driven Development." They focus on assembling releases, and they do a lot of planning inside the release cycle. That is the consistent theme of the processes that we covered for Google Chrome and Constant Contact. I'm going to put more structure around this in future articles.