Today a colleague at work described his experience with one of the principles of Scrum: "Done means done".This very simple phrase has very deep implications. One is that you are never really done until a feature is ready for release. Some teams will define that differently, but his team defined that "ready for release" meant that all major bugs in the feature should be solved and only small issues could be left out of the feature if needed.When they planned the schedule for that feature they were over-optimistic (like it invariably happens in software, according to my experience), they had 1 week scheduled for the feature but by the end of a 4-week sprint they still had many major bugs waiting to be fixed. Instead of succumbing to the temptation of calling that feature "done" (after all they had spent already 4 weeks with it, not the original 1 week) they faced the stakeholders and said: "we are not done and we need more time for this feature". As it happens they had a pretty convincing argument for continuing with the feature, it really had been more complex than they thought and in the process of fixing bugs they had found other non-trivial issues that really needed to be solved before they could honestly call that feature "done". The project management agreed, and the new sprint started with them looking again at the same feature and fixing all the issues they thought were required.Now, a few weeks after the end of the second sprint for this feature they are happy about the decision they made and have said that not only did they actually get that feature really "done" (i.e. they feel they do not need to touch it until the end of the project), but they also found many issues that normally (based on historical evidence) would be found only 2-3 years later in a customer environment.What I get from this story is that I've seen this pattern repeat itself over and over again with teams that give Scrum (in this case) or Agile a good, honest try. Invariably Agile software development leads to:- Teams growing and learning new things about the software development process that they were not aware of before;- Software being produced with higher quality due to the "done" rules that the teams set for themselves. Posted by

Today a colleague at work described his experience with one of the principles of Scrum: "Done means done".
This very simple phrase has very deep implications. One is that you are never really done until a feature is ready for release. Some teams will define that differently, but his team defined that "ready for release" meant that all major bugs in the feature should be solved and only small issues could be left out of the feature if needed.

When they planned the schedule for that feature they were over-optimistic (like it invariably happens in software, according to my experience), they had 1 week scheduled for the feature but by the end of a 4-week sprint they still had many major bugs waiting to be fixed. Instead of succumbing to the temptation of calling that feature "done" (after all they had spent already 4 weeks with it, not the original 1 week) they faced the stakeholders and said: "we are not done and we need more time for this feature". As it happens they had a pretty convincing argument for continuing with the feature, it really had been more complex than they thought and in the process of fixing bugs they had found other non-trivial issues that really needed to be solved before they could honestly call that feature "done". The project management agreed, and the new sprint started with them looking again at the same feature and fixing all the issues they thought were required.

Now, a few weeks after the end of the second sprint for this feature they are happy about the decision they made and have said that not only did they actually get that feature really "done" (i.e. they feel they do not need to touch it until the end of the project), but they also found many issues that normally (based on historical evidence) would be found only 2-3 years later in a customer environment.

What I get from this story is that I've seen this pattern repeat itself over and over again with teams that give Scrum (in this case) or Agile a good, honest try. Invariably Agile software development leads to:
- Teams growing and learning new things about the software development process that they were not aware of before;
- Software being produced with higher quality due to the "done" rules that the teams set for themselves.