Great Joy

One of the famous phrases from this season (in the so-called Christian part of the world) is this:

Behold, I bring you good tidings of great joy which shall be to all people.

A slightly similar agile saying is: If you are not having fun, you are not doing it right.

This is very true.
And very important.

So, why does the Scrooge CEO want us all, everyone, to be having fun?

Well, there are many reasons. But the most important reason is... only when we are having fun will we be the most inventive and creative.

And our work is NOT about mindless, brutish hard work. But about newish, creativity, inventiveness, and giving them something simple that hits the target. One can argue which comes first: joy or creativity. But they are associated.

Even the managers get to have more fun. In Agile. But that's a topic for another post.

Spontaneous Order

I will not remember this well (knowledge decay), but there is a great quote from Fujio Cho (now Chairman of Toyota) at the beginning of Liker's The Toyota Way. Something like: "There are many things you do not understand, and therefore we ask you, 'why don't you just take action? Try to do something.'" With the idea that you thus cut the gordian knot of inaction, and start real learning.

What happens if we do not? The opposite: "And thus the native hue of resolution is sicklied o'er with the pale cast of thought."

And enterprises of great pitch and moment
With this regard their currents turn awry
And lose the name of action.

I have been in projects like that, and so have many of you. (These last two quotes are from a play, not Fujio Cho.)

The soft spider web of thought can be the hardest, most granite-like roadblock.

Yesterday I finished helping to teach a Certified ScrumMaster course with Jeff Sutherland. So, a couple of related thoughts from several conversations.

1. Spontaneous Organization. In the agile community, we are fond of self-organization and complex adaptive systems. And these ideas go way back. Chuangtze and Laotze taught us that the Tao that can be expressed is not the true Tao. That Tao organizes itself in things great and small. And Chuangtze especially talked about the spontaneous organization of things, nature, people, society. That if left alone, they would move toward Tao; that human meddling would more likely move them away from Tao. Better that they take on that more perfect imperfection of Tao, he seemed to say.

Like many another idea, these ideas were picked up later by others, by Proudon and Hayek for example. Tolstoy speaks of this when he talks about the hive of Moscow after the battle of Borodino in War and Peace. We see this in the things of nature, where Energy and Mass self-organize at the speed of light. (OK, perhaps a play on Einstein.) But there is a natural organic spontaneous organization of things.

Now, in real life, that spontaneous organization might be at a mediocre level or a hyperproductive level. The ScrumMaster may have more influence over this fork in the road than she has accepted yet.

I suggest to you that the ScrumMaster, at least, think deeply on how to put these mere thoughts into action for each team. And stir the pot gently. Maybe start here: http://en.wikipedia.org/wiki/Spontaneous_order

It is by spontaneous order that free enterprise gives you your daily bread. However much we may say (and it is true) that man does not live by bread alone, still we must have bread.

2. The ineluctable contradictoriness of things. We humans have this wish for things, for life, to be simple. And so in some ways it is indeed. "A kiss is still a kiss." But we are everyday forced, if we allow our eyes to see, that in so many things there are contradictions. Male and female. Good and bad. Black and white. Darkly wise and rudely great. Go fast slowly. Achieve by not trying. I must be cruel only to be kind.

Sometimes we see through the glass, darkly, that these contradictions do not need to ensnare us, but rather they give us balance.

So, for a pedestrian example, the ScrumMaster should be a servant-leader. The Team should use velocity to push back at the magical-thinking managers who demand they double output; and the next minute demand of themselves that they push velocity to hyperproductivity. From a certain point of view, these can seem utter contradictions.

In theory, we may think these contradictions should make us fail; in practice, done well, we come to know they do the opposite.

Perhaps a few of you will find the famous Butterfly Dream (see that link) an apt koan for the harmonious contradictoriness of things. Chuangtze has other, perhaps better, stories that deal with this.

ScrumMasters: They can cut through their mental spider webs in a minute. Or in two years. You can be a key difference. This is your great refactoring work. Find that sharp, swift, gentle, liberating sword. And pull it out.

Scrum Success Story

We hear a lot about all the problems of life. People are bad. Things fall apart. The center cannot hold. (Help me W.B. Yeats, you're my only hope.)

Today I would like to share an unsolicited note. Jeff Sutherland and I are doing a CSM class next week (Dec 15-16) in NYC. In connection with that, Jeff is speaking at Google and at NYCSPIN.

In connection with the talks, Gabe Yarra at Wireless Generation started am email conversation with me. Excerpts follow.

Thanks Joe,

Yes, I think we had 6 people train [with Jeff Sutherland and me, a while back], and there are 100+ developers who are very happy about it. We have been completely successful in our scrum adoption. Devs are happy with it, PMs are happy, management is happy. It took awhile for everyone to get it, but we're now completely on board as a company. It saves us a ton of headache in terms of scheduling and managing projects. We still have problems, but a whole class of problems disappeared and there is much less stress around certain areas.
....
Moving to agile was a somewhat bumpy ride that took about 6 months. There was a certain amount of skepticism, or just feeling that certain things wouldn't work, until they did work. It helped a lot that we had management and development committed before we started. Again, the whole company is very happy with the results.

By the way, my company is continuously growing and expanding, so if you know of any top-notch developers who want to work at an agile company with a great company culture, feel free to send them my way.

More detail to come, I hope, about how the Scrum adoption went. And is expected to go.

Wireless Generation does good work, IMO. See wirelessgeneration.com

What's not to like?

Change is tough. We sympathize, to a point. Stick with it. Go after it.
No one said the good stuff was for free.

The best work?

I just got an email where someone said that their group does not have a real project-type project. This got me thinking.

Key idea: How do we know our Agile teams are getting the best work?

It seems to me we have the theory that, magically, "the users" will ask us for the best work we could possibly do.

So, let's parse this a bit. The users might be the business or management or the customer. And the best work might be the most important thing we could do, or the most valuable or the highest business value, etc.

OK, so as soon as we make transparent the hypothesis we can see at least 4 holes.

1. The users are always human, and almost never can identify the highest value things. Consistently, reliably.
2. Identifying the highest value things (product, project, story, whatever) is, in large part, cost-benefit analysis. Only if the decision maker has complete understanding of all the benefits and all the costs (risks), can she make the best decision. If we technologists don't tell the business folks about the costs, how can they possibly give us the best stuff?
3. Do you know what you are really capable of? For sure, most business guys do not know what technology is really capable of. And they don't know what your Dev team is capable of.
4. Are we technologists capable of keeping up with all the extensions inherent in existing technology? Or keeping up with technology innovation? Even less can the business guys do that.

How do we fix this mess?

The issue here is that, although we are doing important work, we are still "failing" if it is not the most important work.

Well, I will suggest we need to get business and technology people together more, and the technologists need to ask: "How could we be more sure that we are getting the best work... so we, together, can make the greatest possible contribution around here?"

There are about 250 business days each year. I bet there are 250 ways to phrase that question.

Scrum Tools

A course attendee asked about Scrum Tools.

First, in the Agile Manifesto it says "Individuals and Interactions over Processes and Tools". Naturally, being geeks, the first the we want to talk about in or after the course is...[drumroll]...tools. We have to have a sense of humor about this.

First, I recommend that people learn Scrum (for the first 6 Sprints or so) using magnetic stick pins and cards on a magnetic whiteboard. Or similar. With maybe an Excel sheet to do some math. Very simple.

I have an Excel spreadsheet I give away. You can find a link to it at the bottom of this page. (BTW, there are MANY other resources on that page.) Pretty darn simple XLS. For example, it creates a graph for the burndown chart.

THEN...if you are distributed, then you likely need a tool.

The last thing to do is scale. And often one team is more productive than 100 people. But many of you will scale anyway. So you often need a tool if you scale (one meaning: multiple teams on the same effort).

Here are some tools:

The two best known are Rally and VersionOne.

Jeff Sutherland likes PivotalTracker for some applications.

I hear many good things about Jira with Greenhopper, an extension to Jira from the same source. (OK, a pun on 'open source', which this SW is.) Jira is a bug/issue tracker and Greenhopper is an Agile PM plug-in to Jira.

I know friends who use XPlanner. Even I have used it a bit.

Advice: All of these products (and many more) are changing all the time. NONE are perfect. Perfection to me would start to arrive if the tool could project "virtual" cards on a glass wall that one could touch and move on a visual scrum board just like 4x6 index cards.

Here is some more info from Boris Gloger...here. Boris is a great guy, a friend, and a very experienced agile coach.

Here is another "tools roundup" that Boris also links to. No doubt there are others.

Let me also suggest that tools are discussed frequently on the ScrumDev yahoo group. You might want to check there.

Last advice, usually worth twice the price: Don't get your knickers wrapped about the axle to find "the best" Scrum tool. The tool will not write code and will not make the team more creative. Spend more time doing Scrum (and your work) and less time "tooling up".

I seriously doubt if a Scrum Tool is your biggest impediment. In any case, don't let it be the impediment you work on for very long.

Getting Senior Buy-in

Questioner: How do I sell my executive team on doing this stuff?
Jim Highsmith: Don't. Just do it. They don't know what you're doing anyway. [1]

Umm. This is taken from a tagline on a Ron Jeffries' email. Ron has many wonderful taglines. Watch for them.

Tom Peters thinks that John Chambers may be the best business leader we have these days. One fairly wise opinion. Ecco homo. (Said not without irony in this season.)

So, do we need permission to live our lives? Often, it is better to ask occasionally for forgiveness, rather than wasting so much time asking repeatedly for permission.

Still, it is usually better if eventually you get the senior guys involved, on-board, on the program, drinking the kool-aid, supporting the new idea.

First, "don't follow leaders, watch your parking meters". Said a long time ago, but true way before then. Leaders are much over-rated. Napoleon met his Waterloo. And his Moscow. Following leaders can get you killed. Leaders are as much followers as anything. If they are smart.

By which we mean "the big guy at the top". The Supreme Leader.

Individual acts of real leadership happen all the time, at all levels, and they are still and always important. But expecting the pronunciamentos of any one person to forecast the weather very reliably (or anything else reliably) is a fool's errand. Not that Leaders are bad, just that they are, well, human. Have you noticed that lately? (In fact, it is in the newspapers daily. Probably hourly or less.) Power corrupts and the more the power, the faster and more complete the corruption. Or so Lord Acton taught us. It's just human nature. We wish to fantasize that we are [pick your superlative] than we are. We would be just like them. Almost every single one of us.

Still, maybe it is worth some time, at some point, getting "some senior guys" to support Agile, Scrum, Lean or whatever. I think I agree with that. So, four suggestions:

1. First, in your own head, don't make it so important. For exmaple, everyone in sports knows that if you try to hard to hit a homer, your likelihood of striking out goes up a lot.
2. Read Fearless Change by Manns and Rising. Lots of good, specific ideas.
3. Read A Sense of Urgency by John Kotter. Short (a virtue) and again, lots of good actionable ideas.
4. It is not one punch, but several rounds. As in boxing.

First, a "leader" is not going to really start to understand agile/scrum/lean until she sees and touches it. Do a pilot so she can. Do not expect to fully convince in the first discussion. Or at first sight. Expect many conversations and experiences. No one knows which one will be the tipping point, and probably will not be able to say accurately later which one was. But truth, told with honesty, will win in the end.

Sometimes, in their fantasy, they want a silver bullet. Never lie that agile/Scrum/lean is a silver bullet.

My Hapkido master once showed me how the stomach can "defend" against one hard punch. But two lighter punches, delivered almost at the same time, set up a vibration in the gut that is most uncomfortable, usually one becomes incapacitated. In a similar way, we know in football, that it you hit someone high with one blocker and low with another blocker coming another way, almost always that man will fall.

Perhaps even more revealing, any 6 year old can throw a 300 pound man, if they apply learned cleverness (from many of several martial arts). If they use the energy of their opponent. The same is true in other parts of life, as story after story tells. David can best Goliath.

5. "People don't resist change. They resist being changed." Umm. Might even apply here. Let it become their idea. 'Nuf said?

Find your lever, Archimedes. You can move the world.

[1] This quote is taken from Fearless Change, by Rising and Manns.  A great book, recommended. See Chapter 6.

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