Is Scrum perfect?

Sometimes I want our Scrumming to be perfect.

I want everyone to be happy, I want no arguments, I want ultimate Business Value, no mistakes, no wasted time, no re-work, no stupid ideas, no mis-understanding what the customer wanted, no muss, no fuss, no confusion, no chaos.

Then I heard again for the first time this song by Frank Sinatra. http://bit.ly/8Cyaml

Here is an excerpt of the lyrics:

The broken dates,
the endless waits,
the lovely loving and the hateful hates,
the conversations with the flying plates
I wish I were in love again!

(See here for the rest of the lyrics: http://bit.ly/7QoNA6)

If you ever have to go back to waterfall, you might say:
"I wish I were in Scrum again!"

What Scrum opens up and makes plain is all the ugly wonderfulness of real life. Where things are messy, where creation happens, where ideas are invented from who knows where. Where we fall in love for God knows what logical reason. It's crazy (to some degree), but c'est la vie.

C'est la Scrum.

Scrum stoops to wallow with us in our complex, blessed imperfectness. And helps us correct ourselves as we go.

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.

Certified ScrumMaster Course with Jeff Sutherland Dec 15

I am next looking forward to doing a CSM course with Jeff Sutherland on Dec 15-16.

Should be lots of fun. I hope Jeff (or I) will take enough time to talk about The Concept of Ba, by Takeuchi and Nonaka. You might want to Google that.

I truly enjoy working with Jeff. Lots of reasons.

If you are interested, see here: http://leanagiletraining.com/Sutherland%20NYC%20CSM/Sutherland%20NYC%20CSM.html