Agile & Business

Scrum Success Story

noreply@blogger.com (Joe Little) — Fri, 11 Dec 2009 22:49:00 +0000

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?

noreply@blogger.com (Joe Little) — Thu, 10 Dec 2009 17:08:00 +0000

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

noreply@blogger.com (Joe Little) — Tue, 08 Dec 2009 14:04:00 +0000

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

noreply@blogger.com (Joe Little) — Mon, 07 Dec 2009 14:03:00 +0000

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.

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.

Is Scrum perfect?

noreply@blogger.com (Joe Little) — Fri, 04 Dec 2009 20:29:00 +0000

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

noreply@blogger.com (Joe Little) — Fri, 04 Dec 2009 20:17:00 +0000

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

noreply@blogger.com (Joe Little) — Fri, 04 Dec 2009 20:12:00 +0000

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

Agile Principles

noreply@blogger.com (Joe Little) — Mon, 30 Nov 2009 16:17:00 +0000

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?

Ready to listen?

noreply@blogger.com (Joe Little) — Tue, 13 Oct 2009 16:12:00 +0000

A guest poster:

I'm getting ready for a 4 day training session in Mt. Hood Oregon, teaching new handlers how to work with their K9's towards becoming an operational Search and Rescue team.

One of the "ahaaa!" moments in training is teaching the handlers how not to ignore the K9's innate behavior. One very small example of this what I will call the K9 "shake off". Everyone has seen a wet or dirty dog do the crazy "shake off" and peel around the house at Mach III. Here's a video from Discovery as one example. Or this one of a bulldog, also quite entertaining with all the extra skin.

Doesn't that look amazing? Like it feels great? It is as if they walk through an imaginary wall from one state of mind to the next, twisting their way through the wall.

We don't have a distinct human equivalent of the shake-off, it's much harder to see in humans (stretching by the coffee machine tends to be the common one I see.) A Hapkido kick in the hall is another one that I've seen.

There is an important reason to look for the "shake-off" equivalent in your Agile teams.

Dogs don't only perform this shake because their fur is unkempt. In searching, most dogs, upon making a "find", will do a shake-off. There are a lot of theories why it happens. My take on this: there's a lot of tension and stress in searching. Upon making the "find", the dog can come down off of any adrenaline, and "shake off" all tension and stress. It indicates the dog is has shifted gears, and is in a different emotional state. If I'm training a new dog, I make it happen: ruffle the fur in the opposite direction, the dog will shake the fur back in place, with the side effect of the dog being relaxed and responsive and ready to learn something new.

Search dogs wear a bell while searching. Searching at night you may not see the K9, but if you tune your ears to the bell, you'll hear the constant and regular bell chimes while the dog is searching, then a silent bell when the dog makes the "find", and a loud RINGGADINGGADINGGADINGGA when the dog performs the shake-off. Many new handlers working night problems don't have their ears trained for this and miss out on learning that their dog had actually found the lost subject. The dog post-shake-off, then immediately moves into a thinking and responding state, may appear very calm and approach the handler as if to say "well that's over, what's next?"

The corollary to this is one we've all experienced: when you hear someone say "she's not ready to listen", or "she's listening, but he's not hearing", the person needs room for a shake-off before having the conversation.

It's a huge clue in K9 searching, and if you can notice the "shake offs" in human form, it's also a huge clue to how the team is really doing. As a leader, if you're able to communicate with the teams in "post shake-off" state, you've got yourself an unbelievable opportunity to hear their challenges, and to communicate your business challenges, as humans will have moved into a relaxed, thinking and responding state.

The first challenge you have is to look for what the shake-off is in your team. If you don't have it, make it happen. It can be as simple as hanging out by the coffee machine and do some stretches, make spaghetti arms twisting your spine. Tell folks you're shaking off and from what. After you're done, check your mood and theirs. They may think you're crazy the first couple of times, then after a couple of days you'll have them all doing spaghetti arm stretches.

And because we might be a bit more complex than dogs, you have to ask the team members what their shake-off equivalent is. Perhaps plan your shake-offs outside the office, and remember to enjoy the shake-off with them, and if you think about it, share back the results.

---by Catherine Louis

The doctrine of sufficiency

noreply@blogger.com (Joe Little) — Sun, 04 Oct 2009 02:49:00 +0000

Agile and Scrum start with the assumption that a team is sufficient for the task set before it.

This is a bit wacky unless we allow the truth, which is that humans are very inventive.

Thus, a given 7-member Scrum team can do many things to gain success:
* change the team
* get other impediments removed
* work with the Product Owner and maybe customers to redefine what is wanted

Etc, etc.

So, the idea is only common sense. By yourself, you have some power but it is limited. But 7 people, believing in themselves, can do almost anything. If they believe in themselves, they can be almost irresistible. They can reinforce each others' resolve. They can find new resources. They can redefine the problem.

Now, is every team always irresistible? No, not if they do not believe in their mission.

So, Agile and Scrum presume that the doctrine of sufficiency applies. It does not assert that that must always be true, but rather that that is the best going-in assumption.

They assume that by taking action, we can make our lives better. Rather positive, no?

The CSM Exam

noreply@blogger.com (Joe Little) — Sat, 26 Sep 2009 12:30:00 +0000

As you may know, the Scrum Alliance is implementing a CSM Exam on Oct 1. See scrumalliance.org for details.

This causes us to make a few basic statements.

First, our real purpose is not certification and all that alphabet soup. It might be helpful, it might not. But the real purpose is improving people's lives. The customers, the workers (which includes the managers), and the stakeholders (eg, the shareholders, those widows and orphans).

Second, we have to comment that in some ways, the ScrumMaster title is not fortuitous. It implies, to some, that a CSM is a "master" of something, possibly Scrum. Almost any intelligent person, with a modicum of investigation, sees that that is not true. But some people want to get wrapped around that axle.

Third, we think the CSM Course is a very good course. And, today, the CSM title means you have taken that course. I think taking the course should be viewed as a necessary but not sufficient condition to becoming a ScrumMaster, and probably even to doing Scrum. Other conditions must be met also.

Ok, now on to the Exam itself.

First, putting together a good Exam is very hard. The Scrum Alliance has my sympathies. Even if the initial version is not good enough (it might not be).

Second, the Exam has some practical benefits. It will cause some people to read more. Good, mostly. (Partly bad, because Scrum is more about action than mere knowledge in the head.) It will cause some people to pay attention in class more. Good, mostly. (Partly bad, since they may be paying attention to things to pass a test, and not to the broader meaning and the interconnections and how to make it work in real life.)

Third, the Exam creates a relatively quick feedback loop. Scrum is all about fast feedback. The Exam is not perfect feedback, but better than none.

The Exam is partly bad also. It puts more emphasize on Explicit knowledge, and implies less importance for Tacit knowledge. Certainly the Tacit knowledge about Scrum is very important; I think more important than the Explicit knowledge.

Metaphorically, the Exam suggests that documentation (knowledge unused) is an important measure of progress. But Agile and Scrum say the true measure of progress is working product. In this situation, putting Scrum into practice. In the case of the test, it is ok to test Explicit knowledge, but we need to say that we do not agree with the metaphor. The more important test is: Can you really do it?

In the real world, potential employees and hiring managers want to see "can this person do this thing well". It is reasonable, as I said, to view having a CSM as a necessary condition to becoming a ScrumMaster and probably even to doing Scrum (or a CSPO for Business types), but it is not sufficient. Only in action can you prove that you can do it.

So, I think the CSM Exam is a small positive (despite its drawbacks). We should not get too distracted by it from the main goal. Let's make people's lives better. We need that just about now.

To know ourselves

noreply@blogger.com (Joe Little) — Sat, 19 Sep 2009 17:00:00 +0000

We are in a recession, so we think especially now that money is important.

Some of us are introvert technical guys. People skills are not our strongest skill set maybe. So we think strong technical thoughts are the most important things.

But at the end of the day, I believe we live for other people.

One of deepest human desires is to know others, and also to be known.

The famous quote goes like this: "For now we see through a glass, darkly; but then face to face. Now we know in part, but then shall I know even as also I am known."

To me, Scrum is a journey to know the customers and what they really want. And to know the Team, and what they really can do. And, in the Team, we get to be who we really are, and to be known for what we really are. Well, within the bounds of workplace norms.

This is very important and profoundly satisfying.

The ability to create knowledge together

noreply@blogger.com (Joe Little) — Sat, 22 Aug 2009 13:49:00 +0000

I would like your opinion.

I have for the last few months been toying with these ideas.

To create a new product, the Team is all about knowledge creation. Not management of existing knowledge but creation of new knowledge.

Note: The picture to the right relates to Nonaka's ideas about knowledge creation, and tacit and explicit knowledge. Nonaka and Takeuchi are the godfathers of Scrum (per Jeff Sutherland).

So, in forming a Team, it is not about bringing together people who have existing knowledge, but about bringing together the right people to create knowledge.

My hypothesis is that, if we really believe that, then who we bring on the Team changes fairly substantially.

Now, we don't do this foolishly. There is Explicit and Tacit knowledge in several domains that is important. That takes years to develop. It is probably not wise to start a team with six really smart 18 year olds. But I do think our criteria have been much too skewed toward: "who has explicit knowledge" at the start of the project. Rather than "which group of people, together, would create the most knowledge, the most creative knowledge" over the course of the project.

There remains still some sort of magic in pulling together a great team.

So, how important is the knowledge creation part?
And how should it affect the Team members chosen?

Against Central Planning

noreply@blogger.com (Joe Little) — Tue, 18 Aug 2009 14:47:00 +0000

In general, it seems simpler to have one central brain plan everything. And to assume that that brain has it right. And "everything will work out for the best in this best of all possible worlds" if the Central Planner plans it for us rationally. (Cf Candide.)

Suffice to say I do not buy this horse hockey stuff.

Complex adaptive systems rule. You add a few basic constraints and the "system" (with multiple decision units) figures out the rest in real time, and continually adjusts.

This is not to imply that CAS's are perfect. The world is a tough place. Stuff happens. Any given CAS can not always figure it out fast enough nor always adapt fast enough. But a decent CAS will whoop a very good Central Brain every time. Ok, over a reasonable span of time, like a year.

My hypothesis is that one of the key problems is that the world (even one domain of it) is so complex that one brain cannot envision the whole elephant at one time. (See the 6 Blind Man and the Elephant story.) Thus, a CAS, with multiple "views", has a much better chance.

The is true for humans. (Taken as a whole, each of us is a CAS, although some of us seem intent on dominance by one "logic" unit.)
For families.
For Teams.
For small firms.
And, if done at scale, for larger firms.
Clearly the free enterprise system in the US is a CAS (or what is left of the free enterprise system).
The world economy is also a kind of CAS.
(Not to mention other modes (than economics) of how groups interact across the world).
Perhaps there is a higher scale too.

A few people, with Scrum and similar approaches, are enabling CASs to develop at the Team level. Once we have multiple Teams in a firm going hyperproductive, what is far less clear is how to be effective in having Teams interact in a CAS way, as parts of one higher-level CAS. In Scrum we have some approaches to this (Scrum of Scrums, etc.), but it is less clear that we can have a group of 5 Teams then jump to "hyperproductivity" for that group.

This is normal. We have not learned to walk; we really don't need to worry about running well yet. In scaling Scrum.

Let me note in passing that, in the economy, more and more firms are working in explicit partnerships. And the partnerships take many different patterns. The Lean guys talk about "full" value stream mapping, across all the partners needed to bring customer satisfaction. So, we in Scrum perhaps have some more ideas yet that we can borrow from.

Most of us, I included, continue to be seduced by the notion that the overall firm (say, of 10,000 or 100,000 people) must also have some "overall" plan. Which would need to be prepared centrally, right? Certainly it seems this would be more efficient. (At least in one use of that term.) And then I think about efficiency and the firm, and in real life I find firms do quite well being extremely, obviously very inefficient. (In one or two meanings of that term.) They do something or things well, but maybe efficiency (in the way I am thinking of it) is not the key. Umm, maybe the oak tree's innovation approach is wiser than we knew.

Perhaps eventually we will completely give up on the Central Planner "fixing things" for us.

"Calling Dr. Jung, calling Dr. Jung."

Knowledge Decay & Tacit Knowledge

noreply@blogger.com (Joe Little) — Mon, 17 Aug 2009 15:43:00 +0000

Daniel Brown did an interesting post on this topic. His main area is testing.
Disclosure: He mentions my talk about the Lean within Scrum.

See here.

Learning more

noreply@blogger.com (Joe Little) — Fri, 31 Jul 2009 22:04:00 +0000

If you are looking for more to learn from...
May I suggest, Alice, this rabbit-hole here:
http://leanagiletraining.com/AgileInfo/Agile%20Info.htm

Many rooms to visit. With people of many persuasions. All of them with one voice saying:
"Go, and do. Better than we have done yet, can you.
Some pain, yes, but with a far greater joy."

Suggestion: It is best to keep the cycle of thinking and acting tight.

One impediment at a time

noreply@blogger.com (Joe Little) — Tue, 28 Jul 2009 17:24:00 +0000

Why is it important to focus attention on one thing at a time? One impediment?

Well, there are many reasons. But let's take a few. And others may add other reasons in the comments section.

First, get something completed. So often we try to do "everything" and nothing gets done.

Second, we need fast feedback. For example, sometimes our "improvement" is a stupid idea. Only by limiting the number of changes can we begin to see how stupid we are. Or how brilliant (and maybe share the idea with the next time).

Second, we need fast feedback. (sic) We want improvement now, not in 6 months. (A related reason is the impact on team motivation.)

Third, to see better. We have kind of already said this. But let's expand a bit. In the Gemba (the team room) it is difficult to see specifically what is working and specifically what isn't. And it is very difficult to see through the tangle of inter-connections to what the second impediment is.

Only by doing the top impediment and then seeing the results, can we then decide what the next top impediment is. (Cf TOC.) Often, after we make a change, the next top impediment is in an area totally unexpected.

Fourth, blindness and fear. One example: We naturally want to think that the top impediment is in an area where we are competent to fix it. So, naturally we see those impediments and we ignore the others. (We are blind, and at the same time, we fear getting into, for example, "people issues" where those dreaded "feelings" might get involved. Or, some of us may fear getting into SCM or TDD or whatever.)

So, we recommend not taking a waterfall approach to impediments. But instead take a lean-agile approach to impediments.

Comments?

Thinking for Yourself

noreply@blogger.com (Joe Little) — Mon, 27 Jul 2009 17:36:00 +0000

Here is a good blog post about why thinking for yourself is important in Lean.

http://bit.ly/iH4tC

Hold the mirror

noreply@blogger.com (Joe Little) — Sun, 26 Jul 2009 19:53:00 +0000

How do we get managers to change? (You know, if it were not for them, everything would be just fine.)

We got this question in a class on Friday.

My immediate answer, maybe an intuition, was to quote part of this:
"...the purpose of playing, whose
end, both at the first and now,
was and is, to hold as 'twere
the mirror up to nature:
to show virtue her feature,
scorn her own image, and the very age and body of the time his form and pressure."

These are part of Hamlet's instructions to the players. Before they perform. "The play's the thing wherein we'll catch the conscience of the king." For the fuller instructions, see here: http://bit.ly/17DEOL

So, like the little boy in the old story, it will become clear that the emperor has no clothes. And the foolishness will be clear to all.

ScrumMasters, just hold up the mirror. Make it transparent.

We will say, in passing, that Scrum is a drama in real life.

Now we come to the Man in the Mirror. And these days, many of you will immediately recognize a reference to a Michael Jackson song. I personally am not the biggest fan, but one must say "in form and moving how express and admirable!" And so many wonderful songs. Such great dancing. And such fun in his performances.

So, these lyrics:
"I'm Starting With The Man In
The Mirror
I'm Asking Him To Change
His Ways"

Less poetically, "I am starting with myself."

See here: http://bit.ly/pcXcE And a video here: http://bit.ly/oGyDC (The song is wonderful; the video is somewhat over the top, but one can feel the yearning of the people to be free. Such yearnings also have been used by the dark forces.)

By your own actions, you can show them. And, despite some things, their better angels will often lead them to follow you. Not because you became their boss, but because you are right, and you carry the truth. The truth is not yours, but you carry it for awhile. And with that illuminating power (again, not your own), the darkness fades away.

And we thought business was all about facts, and money, and power, and share prices. No: it starts with getting people to stop being stupid (which we always are, part of the time).

For a more common-sense way of expressing the same thing, read Taiichi Ohno. For example.

If you feel, now, within your heart a sense of urgency, go and make one small change. Today, or maybe tomorrow. Love is less that drug emotion than the work of days and hands.

***
PS. The early phrase -- that the managers are to blame for everything -- was said with irony. They are people, just as we are.

Defining Business Value // #2 Customer Smile

noreply@blogger.com (Joe Little) — Wed, 22 Jul 2009 12:46:00 +0000

Imagine that you want to make a new camera. And in the first release you will make 1,000 cameras and basically "give them away". Give them to key influencers, etc. So, all that that work does is make the customer smile.

Imagine that the picture here is not of Scarlett Johansson. Just a girl. And it represents all 1,000 customers who buy your new camera. You don't make any profit, just the smile. In fact, you lose $10 on each camera.

How do we evaluate the Business Value of that smile? Or those smiles. There are many ways one could approach this problem. Without explaining all my assumptions, let me quickly say this.

Well, presumably the smile is worth something later. You provided customer satisfaction, and they will come back and buy the next camera from you. Or tell their friends to, etc, etc. If you were clever you could estimate that.

But let's imagine that the Product Owner is not that clever.

Let's imagine you have 5 stakeholders, stakeholders who understand the business intuitively and have lots of experience of Business Value in all its aspects. Let's imagine that you have them to vote on the BV.

Earlier I recommended getting the list of stories for building this new camera, and having these experts play priority poker for those story cards. Relative value compared to a small reference card of 1 (the card that you all initially think has the least BV). Using the Fibonacci series up to about 1,000.

You do this exercise, even though the real number you need for business decision-making now is the total dollar value of the effort (eg, to judge whether to invest here or elsewhere).

Why do that? So that the team of 5 creates knowledge together about what the effort really is. If you are already sure they have a common view of the effort, and a fair amount of detail about it, then maybe you don't take this step of priority poker yet (eg, until after the project is "approved").

OK, now to estimate the overall dollar value.

Again, there are other techniques, but the one I will recommend first is have each of the Delphic experts write down their personal opinion on a piece of paper. Before being influenced by anyone. And some comments about why "my" number is right.

And then all flip the cards at once. And compare. The two extremes talk most, about why each had the highest (or lowest) number. The assumptions, and the issues they see with the other extreme. They might compare to previous efforts. "Project X had $20 million and I just don't see this as better than Project X, so I don't see how you can get to $24 million." Maybe they vote again, and eventually reach some closer consensus. Maybe they discuss again, and vote a third time. Then, however close they get, average the answers they give. Use that.

There is no harm if one or more of the "experts" wants to use a mathematical formula of some sort. They should share that formula.

You might, particularly in the first few months of using this technique, have a senior manager do a "sniff test". They bring him in and say "We decided this effort is worth $17 million, plus or minus about 100%. Seem reasonable to you?" If he can accept it as probably the best guess at this time, then they did a good-enough job. Or they might take his input, do a bit of scratching of the head, and estimate again.

Finally, as they get closer to production, someone should be working on a formula for BV, and how to prove, or at least get indicators about, whether that formula is relevant. Let's say a key aspect of the formula assumes that 900 of the first 1,000 users have a broad smile. So, they might use the Net Promoter Score to confirm that assumption. Etc, etc.

BV is hard. Like any prediction of the future, it is difficult, and likely to be off. Still, we need to learn how to be less and less off in our estimates. While all estimates are "terrible" compared to the precision of what reality will later give us, still it is better to make business decisions with the best info we have today than with no info at all. Even though very imprecise, and sometimes inaccurate (leading us in the wrong direction). Making no business decisions is not an option.

What is Scrum?

noreply@blogger.com (Joe Little) — Fri, 17 Jul 2009 14:53:00 +0000

I am excited to be giving a Certified ScrumMaster course with Jeff Sutherland next week. In Richmond.

So, I was thinking: what is the essence of Scrum if you would play the game well?

(Remember that Scrum is named for the Scrum formation in Rugby. We often show a video of the famous All Blacks team doing the Haka and playing Scrum. We think Takeuchi and Nonaka, who originated this metaphor, were thinking of these great teams.)

To me the essence is that team spirit that is willing to face a rough opponent and a difficult situation, and overcome any obstacle to win.

I sometimes call this the Michael Phelps attitude. He is thinking: "I broke the world record in each of the last three heats. And now, in the finals, I want to jump in the water and break it again."

There are many things from art and science that we give the teams in the course. But we must convey this essence. Without this tacit knowledge, it avails almost nothing to have all the explicit knowledge in the world.

Value of Training (CSPO)

noreply@blogger.com (Joe Little) — Sat, 11 Jul 2009 14:00:00 +0000

What's Scrum training worth?

I am about to lead a Certified Scrum Product Owner course. (2 days, in NYC and a bit later in Saratoga Springs.) The question comes up...what is this course worth?

I explain this in more detail in the course, but here's the summary.

In the course we talk about many things, and hope to get many improvements. Imagine, though, that we only make 2 improvements to a Product Owner. And that PO manages only one Team.

Assume the Team costs about $1 million all-in per year. Team of about 8 people.

Assume the Team currently produces about $3 million per year in NPV (net present value, a core way of measuring business value). (Microsoft seems to be averaging about a 5:1 ratio or better overall.)

OK. We teach Sam, the PO, how to create 20% better stories. So, instead of $3 million per year, the team can get $3.6 million per year.

Now, we also teach him the Pareto Rule, and how to work it all the time. (80% of the value comes from 20% of the work.) Now, we and Sam aren't perfect, so Sam comes back only able to execute the 85-33 rules, ie, 85% of the value in close to double the 20% of the time that Pareto's rule calls for.

OK, this means in 33% of a year, the Team can get 85% of $3.6 million. Let's round down and call that $3 million. We assume Sam (and the firm) can find more work of the same value. So, in the next 33% of a year, the Team produces another $3 million in BV. And in the last third of that year, the Team produces another $3 million in BV. So, now we have $9 million in BV in one year. A 3x improvement. (I will note we assume that the Team did *not* increase Story Point velocity at all. No other impediments removed...very conservative assumption.)

Even if we (the teacher and Sam) don't immediately achieve quite the same level of improvement we assumed (which itself was far from perfection), I think you can see that, a million here, a million there, pretty soon you're talking real money. And, in my opinion, those improvements alone justify the costs for the 2-day course. Even in a serious recession.

What do you think?

Defining Business Value // #1 Risk

noreply@blogger.com (Joe Little) — Mon, 06 Jul 2009 16:34:00 +0000

I hear many people complain that it is hard to define business value. So they won't do it. Or they won't try any harder to do it.

That it is hard and always changing is true. That fact does not, though, give us sufficient reason not to work hard to get better.

I won't reiterate here all the reasons why understanding business value really well is very, very important. Suffice to say that one can argue that there is no more important thing to understand. (Yes, one still has to actually build the new product.)

One comment I hear is "I can't define what risk is worth." So, today, let's take risk as an example.

My main reply is "well, get an actuary...those people define the dollar value of risk all the time. It is called an insurance premium."

Then the response often is: "There is the business loss from an 'event', and there is the harder to quantity 'loss of reputation'."

This is correct, as far as it goes. "Loss of reputation" can often be harder to quantify. But nonetheless, you must take a stab at it. And prove to yourself whether your theory of what it is worth was high or low. Only by taking a stab at it, do you force yourself to learn.

Wide-band delphi. I cannot too strongly recommend this technique. As the Romans said, to predict is difficult, particularly of the future. So, we want to get the best ideas possible on the table so that we improve our odds. By improving our odds, we improve the likelihood of overall business success.

So, risk, as one example. Let's say risk (in several forms) is the main driver of the business value of a large effort. Here is one way to estimate it. Based on assumptions I will not articulate here.

Get Fibonacci cards that go to 987 (several orders of magnitude). The 5 "experts" (the best experts you have) go through the Product Backlog, and use the basic planning poker technique, but this time they are estimating the Business Value of each story. (I assume the reader understands basic planning poker.) For each story, the experts question and discuss the underlying assumptions about Business Value. They take an aggressive attitude that they are tryingto uncover Pareto's 80-20 rule within this population of story cards. The BV is relative to the smallest reference story (marked with a BV=1). Ideally, a small set of reference stories. The experts reach a reasonably close consensus (within 3 Fibonacci numbers of each other), and then average to score each card. By and by they complete all the story cards.

But to make a lot of business decisions, you need to know the dollar value of the "whole" effort. (Discussing "whole" is a rabbit hole we won't jump in just now.) So, having had a good discussion of the stories, we ask the same experts: "Ok, write down in secret what you think this whole pile of cards is worth. In dollars. If you need to do a calculation, do it. If you can't think about it any other way, what is the maximum our business should consider to pay for this stuff? How long for you to estimate this? And any questions now for the Product Owner, before you start?"

They might ask the Product Owner about some assumptions. "How many people will this affect? What is the average size of an account? How many accounts do we project we will have in 3 yeras? What's the largest fine the Federal Reserve has ever given?" Whatever they think is relevant.

Regarding the timebox, anything more than 1 hour is too long, almost always. (If the calculation is really important, and will take longer, then maybe.)

Each of the 5 experts writes down his dollar number on a piece of paper, in secret.

Now the fun. You bring all five experts back together, and have them turn over the pieces of paper. They won't be the same. As with planning poker, you have the 2 extremes talk. Then they all discuss what the best assumptions should be. Like a Scrum. But in some sort of timebox. Typically there is a good "fight". This is good. Also, typically, they each need to go back and re-estimate. You might do a couple of rounds of this.

You want a reasonable consensus, but not perfect. I will recommend that the least degree of consensus is within one order of magnitude (eg, $11-99 million). Ideally a good deal more than that. Normally, once within some reasonable consensus, then average the numbers they give you.

Example: 3, 4, 7, 8, 9. The average is $6 million or $6.2 million. (I would not pretend we have more precision by extending the number of decimal places.)

Sometimes it is good to go to the next higher level of management and discuss how the $6 million BV estimate was arrived at. And ask them: do you think this is a reasonable estimate? If not, how would it be improved?

Is the number derived perfectly accurate? Of course not. There is no end to improving our BV estimates.

Is the number better than we currently have? Almost always.
Is the number useful enough to make business decisions with? Yes.
Is the number good enough for us to start learning from? Yes.
Should we revise the number later? Certainly. The key question is how many times.
Should we try to do an experiment in the real world that tries to prove that the estimate was (or was not) reasonably accurate? Yes.

***
Note: The diagram about risk management is borrowed from techrepublic.com. The point, for me, of the picture, is only that it is about risk management. I am making no point now about whether the ideas embedded in the picture are good or bad. Still, the fear of risk often leads people to take no action ("deer in the headlights"). This is often the worst of several options.

Freedom

noreply@blogger.com (Joe Little) — Sat, 04 Jul 2009 17:36:00 +0000

Man is born free, and everywhere is in chain.

Rousseau, certainly a man of some well-known weaknesses, was brilliant to say this, just a few years ago now.

Of course it was then far from literally correct. And he said this as a citizen of Geneva, arguably one of the places on this planet with the most freedom in that day (~1762). Still, it was more true than literal physicality, both then and to this day.

Today, July 4th, it is most appropriate for any Virginian, and indeed any citizen of the world, to honor the Declaration of Independence and a certain birth of freedom in this nation. This is arguably the one document that has given people more freedom than any other single act of mankind. And, of course, not just people in the USA.

We know several phrases well.

When in the course of human events...
...
We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.
...
...appealing to the Supreme Judge of the world for the rectitude of our intentions,
...
with a firm reliance on the protection of divine Providence, we mutually pledge to each other our Lives, our Fortunes and our sacred Honor.

We too must continue to fight for freedom. We may fight for it using Scrum or Agile or Lean, and certainly this is an important fight. But we cannot say that the courage these daily fights require of us can measure against the courage of a red-haired man in Philadephia in 1776. He and John Hancock and their fellows knew, for a certainty, that if they did not win the war, they would be killed, probably hung in public.

Let us learn again from this. Let us rededicate ourselves to the fight, that freedom, which can so easily in the search for security in a difficult world roll backward, will with our arms, and backs, and voices, continue to roll forward.

New, special Classes - I'm excited

noreply@blogger.com (Joe Little) — Fri, 03 Jul 2009 16:09:00 +0000

I am particularly excited about the following courses or workshops.

One: Jeff Sutherland in Richmond, VA. Certified ScrumMaster (CSM) course. Dr. Sutherland (he has a PhD) is a great guy and of course the co-creator of Scrum. I always learn more when I do these courses with him. This a great advanced course for many people. Great for managers, too.

If you do not follow Dr. Sutherland's blog, you should.

Two: Poppendiecks in Chicago. New Leading Lean Software Development workshop. Mary & Tom Poppendieck are of course the thought-leaders in Lean Software Development. Again, I always learn when I help with their courses. This course is new, and will be based on their new book (coming out soon).

For an outline of their new book, see here.

Three: CSM for ScrumU at Notre Dame. ScrumU is a group of people who do SW dev (etc) for the universities...using Scrum (and other Lean-Agile stuff). This is a special course only for those kinds of people, at a "university" rate. And it is for professors who teach IT subjects. Kristine Gianelli, leader of ScrumU, is the mastermind behind this course.