Friday, December 4, 2009

Why working software is important

In a recent discussion Jeff Sutherland was talking about how important it was to have working software at the end of every Sprint.

As a small part of that discussion, I suggested several reasons WHY working SW (or what I call done, done SW) is so important. Here is an excerpt from what I said then. (This happened to be something that one colleague "*really*" (to use his characters) liked.)

So, how do we explain (better) why done, done SW is so important at
the end of the Sprint? Here are the two ways I am focusing on now.
Perhaps not original with me.
1. Bad news does not get better with age. That is, fixing a bug now
is much much cheaper than fixing a bug later. Or an arch or design
issue. So, it has to be "done".
2. I know it when I see it. The users can't give us feedback without
something concrete to look at. So, done has to mean that as well. It
is concrete-enough to enable feedback (yes, usually more bad news, sooner).
3. It ain't over til it's over. Man, have we lived that nightmare in
spades. Only if it is done do we have a clue if we have made real
progress. And thus judge when the release will hit.
4. Don't build on a bad foundation. You don't want to build new SW on top of buggy SW. If we change the stuff at the bottom, the whole house can come tumbling down. So, again, no bugs escape the sprint.
Well, more than 2 ways. No doubt you have yet more compelling ways of saying this.

This is in part why the Definition of Done is starting to be considered a core artifact of Scrum.

1 comment:

ESCOZ said...

Hi Joe,
I totally agree with your arguments. I frequently mention those things when talking to project managers not familar with Agile.

There's another one though, that I use:
Having a definition of what exactly needs to be done during the sprint creates a very specific goal that the entire team can strive for.

We use the three D's variance of done:
- done: code complete
- Done: tested by the testing team
- DONE: reviewed and accepted by the business.

This forces the entire team, and not only the developers, to be working together at the end of the sprint to get all the stories tested and reviewed.

My experience, having worked in teams that do and that do not do this, is that the practice creates a more effective team, that is better at estimating work, breaking work down, and getting business value delivered.