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.

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

Monday, November 30, 2009

Agile Principles

I often say that you can't do the dance if you don't feel the music.

In a discussion list now, there is a heated discussion about the principles that underlie Scrum. I hope no one hurts themselves. By which I mean to jest that we often have the biggest fights about abstract things ... about which we want, or at least tend, to disagree.

About concrete facts that all can see with their own eyes, it is harder to have arguments.

OK. Here are some principles that I see at play in Lean-Agile and in Scrum. Part of the fun of putting this list out there is the hope and expectation that you will discover for me yet better ways of expressing these or other principles at work. My list was done hastily, so you are welcome to complain. Also.

A quick list....
* all work-in-process is waste (and we want to eliminate as much of it as we can possibly imagine)
* two heads are better than one; three are better than two
* with our work, the productivity of the individual is fairly meaningless (no individual alone can produce the product); the productivity of a small group is meaningful
* bad news does not get better with age
* truth and love are the true foundation
* how hard we work is not important; what is important is making a few people's lives better
* we have failures in communication all the time; the problem is to identify the biggest ones as fast as possible, and correct them quickly
* the best way to communicate about this very abstract work is to make it as concrete as possible. And then get as full and direct feedback as we can bear.
* in theory there is no difference between theory and practice. In practice there is. Yogi Berra. One Meaning: In our minds all our ideas seems to work. In practice we all always see many mistakes and problems.
* knowledge creation is what it's all about
* "There are many things one doesn’t understand, and therefore we ask them: why don’t you just go ahead and take action; try to do something?" Fujio Cho.
* You learn fastest by small mistakes.
* Where there is no vision, the people perish. Proverbs.
* People are remarkably good at doing what they want to do. (Little's Second Law)
* I know it when I see it. Judge Potter Stewart.
* How does a project get one year late? One day at a time. Fred Brooks.
* You don't need to motivate them. You need to get the de-motivators out of the way.
* People work best when allowed to make small promises.
* Don't over-stress the system (the team).
* Because business and technology decisions are inter-dependent, business people and technologists must work together daily.
* There will never come a day when there are no impediments. We can always improve. We must work on the biggest impediment each day.
* "Depend upon it sir; the prospect of being hanged in a fortnight concentrates the mind wonderfully." Samuel Johnson.
* To predict is difficult, particularly of the future. (A Chinese proverb?)
* We are organic, transient animals. We are not machines nor are we constructs of the mind.
* There is a lot of variation amongst and between individuals. And perhaps more so amongst and between teams.
* Man is "a being darkly wise and rudely great". (Alex. Pope) Of a mixed nature. None of us will be perfect soon.
* Micro-managing workers never helps. A bit of coaching might help some.
* Pretending to be more productive by lowering quality is just pretending.

Your comments?