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 software (or what I call “done, done software”) 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.
- 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.”
- 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, often more bad news, sooner).
- 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.
- 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.
No doubt you have other compelling ways of saying this.
This is in part why the Definition of Done is a core artifact of Scrum.