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.
« « Certified ScrumMaster Course with Jeff Sutherland Dec 15 || Is Scrum perfect? » »
One thought on “Why working software is important”
Leave a Reply
You must be logged in to post a comment.
Subscribe to this blog
Interested in a Lean-Agile-Scrum course or Workshop?
Recent Posts
Categories
- agile
- agile business
- Agile principles
- Better Agile
- business value
- BV Engineering
- Change Management
- courses
- Events
- freedom
- Getting started
- impediments
- Innovation
- Jeff Sutherland
- Kanban
- Key problems
- knowledge creation
- leadership
- lean
- Lean Software Development
- learning
- Listings
- Little's Law
- Little's Second Law
- managing agile
- Misc
- Nokia Test
- Paying
- People issues
- Recommended reading
- Release Planning
- Resources
- scaling
- Scrum
- Scrum Intro
- Scrum meetings
- Scrum roles
- ScrumButt
- ScrumButt Test
- Self-organization
- Talks
- Teams
- Uncategorized
- video
- WIP
- Yogi Berra
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.