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

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?

Ready to listen?

From Catherine Louis:

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

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

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

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

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

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

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

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

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

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

http://bit.ly/iH4tC

Hold the mirror

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

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?

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)

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

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

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

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.

Metrics & Velocity

I have received a few comments, both recently and in the past, that tell me some people are uncomfortable measuring velocity. And they are uncomfortable measuring the Team.

They are usually not that clear why they are uncomfortable.

Let me state my position, which I believe is also close to the position of Jeff Sutherland and Ken Schwaber.

First, as a memory device, I say: "Velocity: Don't leave home without it."

Second, any decent Team wants to know if they are really successful.

Third, the Team must measure velocity and it must aggressively be trying to improve it. Doubling velocity in the first 6 months should be a goal. In Scrum, the larger goal is to get the Team to be 5x - 10x more productive than the average Team. (Good data tell us that the average is about 2 Function Points per man-month.) Scrum does not guarantee that every team will get to 5x-10x. But none will if they don't go for it.

Improving velocity means removing the top impediment, one at a time. It does NOT mean working harder. In fact, often one of the top impediments is that we are already working too many hours per week. (To some, this will seem a paradox. Explanation another time.)

How do we use velocity? Many ways, but I will emphasize three. (1) In planning, to plan the release, for example. (2) To push back with a pattern of numbers when magical-thinking managers ask the Team to double their velocity in one Sprint. (3) To challenge ourselves, as a Team, to get impediments removed so we can enjoy some real success around here. (And often we have to ask managers and even senor management to get involved with the impediment removal.)

What are the push-backs that I hear?

Several. This post is getting long enough that I won't state them all hear.

But the cartoon represents one of the major ones, I think. People are concerned that we are putting human lives in the hands of some stupid bean counter (as we say in the South "bless his little heart"). Certainly not a happy thought.

So, a few assertions about metrics (not time here to discuss them):
* the Team does the metrics themselves, honestly because they want to use the numbers
* there should be no "managing from behind the desk" (as Lean would say)
* velocity does not reflect one single factor, but the result of all factors
* when the Team evaluates velocity, they use human judgment (Ex: "the velocity dip last Sprint was mainly due to Vikas being out sick 4 days; he's fine now")
* people want to see clearly and show that they are successful
* velocity is not supposed to be a tool for Dilbert managers to beat up the Team with
* while every metric will eventually be gamed (eg, due to Dilbert managers), these issues are part of the larger imperative of honesty and transparency in Scrum. Occasional gaming is not a reason to never do any metrics
* Velocity is not the only important metric

Fun & Success - Learn Scrum - Durham and Montreal

Fun & Success? In the same sentence?

"You are doing Scrum right if and only if you are having fun. Serious fun."

"You are doing Scrum right if and only if you are having clear success."

How can these both be true? Pushing through success is so stressful. Fun is light-hearted, like laughter.

Well, this is one of the paradoxes of Agile that we explore in the Certified ScrumMaster course. It is only a 2-day course; it is doubtful one could be a true "master" of anything in 2 days. But we do promise you will learn a lot (more than you can possibly take on-board) in 2 days. (Ok, 3 days if you include the Team Start-up workshop.)

Oh, about the Dilbert cartoon. Seriously, we recommend that you have at least some training before starting Agile. The whole team, in fact, is what we recommend (sounds self-serving, I know, but that is the best recommendation). On the fun side, we love to hate Dilbert managers as much as the next guy, but some of them managers actually drink beer and eat pizza like normal people. Who knew they could actually help remove impediments? And lead us toward a more fun life with more success.

For almost everyone, Scrum is a serious paradigm shift. Get ready. (Koan: If you think you have made the shift, you haven't.)

And get ready to have some fun. (Yes, even the course is mostly fun, with, for example, a bunch of exercises and a PG-rated Richard Pryor joke. We leave no stone unturned to help you flip those bits in your wetware. Wetware is the hardest thing to refactor.)

For Durham (Jun 30 - Jul 2), see here and here.

For Montreal (July 8-9), see here.

We have other courses on the same site.

Completing a Release

OK, so we have a known velocity in Story Points. And, having that, it is an exercise for a 6 year old to figure out how many more sprints until the release.

Example: We have a velocity of 20 and the stories in the backlog for this release have a total of 100 story points, so QED, we have 5 sprints remaining until we can release.

[QED is from my old school days, meaning "which was to be proved".]

Fine, for a shark, a simple project manager or a 6 year old.

What's the problem, you say?

In real life, we need to be cleverer than a shark.

It takes a clever, determined Product Owner (in Scrum terms) to land the release.

We know from long experience that the Product Backlog will (or should) change. New features will be discovered, the customer will "know it when he sees it" (a law of software "requirements"). And "stuff will happen" such that the current known velocity will change.

Most importantly, the PO (Product Owner) will be executing the Pareto Rule, which says that 80% of the value comes from 20% of the stories (maybe better to say 20% of the story points). Maybe not a perfect 80-20 rules, but all those stories slated for the release are NOT required.

Side note: What can happen to velocity? First, it should improve as we remove impediments. Second, "stuff happens" and the foreseeable problems (which we refused to foresee) happen. And the completely unexpectable happens with known regularity (and perhaps some unknown frequency as well).

Let me emphasize again: The PO should dynamically be looking at the product as it grows to determine the Minimum Marketable Feature Set (MMFS) to release. This is a very dynamic process of discovery. Or should be. When you are creating something for the first time, there is always plenty to learn. (Or, if you waited for the "perfection" of the so-called requirements, you probably waited way too long.)

For a given product, we hope there will never come a day when we are finished improving it. When all the stories are done. We are always discovering what they want most NOW. Customers always want more (although the "more" that they want is often less...example: less complexity).

Recommended Reading - June 2009

We have a list of recommended books, here.

In addition, we can recommend the following:

A Sense of Urgency by John Kotter.

Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising.

Toyota Production System: Beyond Large-Scale Production by Taiichi Ohno.

Taiichi Ohno's Workplace Management

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)by Frederick Brooks. One of his famous quotes: "How does a project get one year late? One day at a time."

Fit for Developing Software: Framework for Integrated Tests (Robert C. Martin Series)by Mugridge and Cunningham.

Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley Signature Series)by Duvall, Matyas, and Glover.

Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen.

Test Driven Development: By Example (Addison-Wesley Signature Series)by Kent Beck.

Working Effectively with Legacy Code (Robert C. Martin Series)by Michael Feathers.

The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation by Nonaka and Takeuchi.

Good to Great: Why Some Companies Make the Leap... and Others Don'tby Jim Collins.

Software by Numbers: Low-Risk, High-Return Developmentby Mark Denne and Jane Cleland-Huang.

The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni.

Comment: I have given links to Amazon, which has some benefits. There is certainly no obligation to buy from Amazon.

Suggestion: Some of these books are technical (in one area or another) and some are more about people. Mix and match. Consider what you need to learn. Consider what you are most ready to learn. And don't think too much in the sky. Quickly see how much you have really learned by putting your ideas into action.

Breaking the world record

My younger daughter has her last swim meet of the season tonight. I am excited (and still a bit affected by Father's Day yesterday).

When I talk about Agile & Scrum & Lean, I often refer to Michael Phelps' attitude. Not his attitude in SC, whatever you may think of that. (Not that I begrudge him some relaxation.) But his attitude about swimming. He broke the world record before the Olympics, he broke it in the first heat, again in the second heat, and he intends to break it again in the finals. He is relentless.

We ordinary humans must take the same attitude.

Just about now, your colleagues would be encouraged by seeing you break your own best record.

Just about now, the other teams would be encouraged by seeing your team break its own best record.

So, what do we mean practically?

Well, first, we mean sustainable pace. We mean that we will break records in our new product development work, not by working harder, but by working more creatively. By creating knowledge -- faster, better, with more certainty, and more power.

Second, we will admit that half of what we know is wrong. (Cf Taiichi Ohno in "Workplace Management".)

Third, we will double the team's velocity. In 6 months or less.

Doubling velocity (story points done-done in each sprint) usually means we must improve several things:
* a clearer definition of done (or "done, done" if you prefer). Usually we let this be too vague. Vary it must for some stories, but for most SW dev stories it must be very clear and can be consistent. And in my opinion, it must mean "no [known] bugs escape the Sprint". And testing must include at least functional testing.
* we must measure velocity. I still can't believe how many teams I find that don't have some measure of velocity. More on this next time. For now: "Velocity: don't leave home without it."
* we must prioritize the impediments, and keep removing or reducing the top one until velocity is doubled. Hint: We might want to prioritize the impediments by how much the removal/reduction will increase velocity. 25% here, 30% there; pretty soon you're talking a real increase in velocity.

Hint: Improving quality and reducing technical debt are almost always important keys to seriously increased velocity. Not the only keys, but very important.

Who is gonna feel better when the Team doubles velocity (with sustainable pace)? Yes, the Team, perhaps first and most importantly. And customers. And managers. And the widows and orphans who own the company.

Is velocity the only metric in town? Ok, good question, but for another day. Increase velocity now. Show yourself you can do that professionally. Then we talk.

"But, things are so good around here, we can't possibly double velocity." Ummm. My first thought is that your biggest impediment is that people are hiding from the truth. Every place I look, we are using such a small percentage of the potential of people, that doubling the velocity is a task any team can accomplish. Look again, and take Michael Phelps' attitude.

If you really think you can't get any better, declare yourselves the best team in the world, write-up your success, and challenge other teams, anywhere, to beat you. You might just learn a thing or two. And have some serious fun.

What is Business Value Engineering?

I made a post in AgileBusiness (yahoo group). That I thought I would repeat here:

QUOTE
I have been asked to start a conversation about BV Engineering. So, here's a
start...

What is it?

It is a framework for looking at the delivery of business value. It is called BV Engineering for two reasons. First, instead of hand-waving, we believe that BV Engineering should include qantitative measures (although not be dominated by metrics), and, second, it is called that so that it is approached like other engineering practices in Scrum, as something that is not prescribed, except to say one must always have them, identify them, and improve them. And BV Engineering becomes one of those engineering practices.

Where do we start?

We start with a grossly simplistic franework that says: we have
* a box of customers (external and internal typically),
* a box of Business (customer facing people, internal groups like legal and compliance, and perhaps others), and
* a Team (eg, the Scrum team that will produce or improve one product for those customers).

We also start with an assumption that BV Engineering is a round-trip set of experiments that are continuously trying to prove whether our hypotheses related to BV Engineering are useful. Or, more accurately, it is a feedback loop that continuously shows us how far off our hypotheses are. (And since stuff is happening all the time, we are always at least somewhat off.)

And what do we do next?

Next, based on that simple framework, one does a simple drawing, as with Value Stream Mapping, and describes what BV Engineering is in your specific context.

The flow between all the people is diagrammed. The assumptions and hypotheses are described. The business value model is described. We lay out the current state.

Why?

So that, being visible, we can all see it, and make suggestions, little tests, for improving it. Constantly. That is, so we can continuously move toward a future state.

So, what kinds of things are you including?

Well, anything that helps or hinders us from delivering stellar business value to our customers instantly, at a lower price, solving exactly their problem (or fulfilling their need) with no adverse side-effects. And fulfills all our constraints (eg, a good return to capital, etc, etc).

The approach also works if you make the simplifying assumption that "we only want to make money". As Drucker would say, not the correct basis for doing business, but one that some adhere to.

Back to the things. These things include, or might include: communication (who, what, how, when, etc), gathering requirements, the BV model and its assumptions, frequency of release, feedback from the release, how much we do the telephone game, who needs to understand the customer, the role of tacit and explicit knowledge (about what?), how and where we do knowledge creation, how we balance customer needs with legal/regulatory needs, how we do portfolio management, how we start and kill efforts, the Kano model, prioritizing across multiple customers (or customer sets), priority poker, value stream mapping, personas, use cases, etc, etc, etc.

For example, the use of any one of these things has one or more assumptions tied to it. One hypothesis is that these assumptions have often never been articulated, much less challenged, and even less have they been confirmed as accurate for our specific situation.

Two more observations, each fundamental. As soon as one sees this as a feedback loop (or PDCA cycle) that is trying to prove whether our theories and practices are on target, one immediately asks about the frequency of feedback. And almost always it is not fast enough (GM anyone?). And, second, one then looks at this not as a static model, but as a dynamic model that is always adapting to change. So, one asks "how are we building into our BV Engineering appropriate mechanisms for it to be continuously adjusting in a useful way?"

Lastly, let me add a "personal bias" (which I find empirically true), namely:
virtually every team member needs to understand how we do BV Engineering in our specific situation, and where they fit in on the process.

Well, that's a start.
Comments or questions?
UNQUOTE

Your comments, here or on AgileBusiness, would be welcome.