Kaikaku or kaizen? (2)

I recently did a mail/internet survey, asking people what kinds of training they might be interested in. (If you would like to respond to this, please tell me.)

Someone responded, "how about adopting a continuous improvement approach?" Now, we don't know what the writer had exactly in mind (although maybe I will learn more). One assumes the writer meant something like: "continuous improvement is at least as valuable as more training." So let's play this out some.

In my view, training should be part of Kaikaku...which is a rapid, large, revolutionary change. In my view, there are times to make large changes. For example, when starting Agile. Or perhaps a new project. And there are also times to make small incremental improvements (kaizen or continuous improvement).

The preferred pattern is to have occasional large Kaikaku and many, frequent small Kaizen.

Now in general I am in favor with learning that is closely tied to, and proved by action. Which is to say. "The learner has not learned unless the actions become more effective."

So, training should be used to prepare for action right away.

But let's also talk about what action is. Not as simple as it might appear.

The hardest action is to change one's own mind. The next hardest is to change someone else's mind. (Proper action in the realm of the mind can lead to tangible improvements in satisfaction for real customers.)

Let's look at one example. One can imagine sending someone who is "resisting" agile to an agile course. The resulting action might be no more than a willing suspension of disbelief, so that the team can move forward without active resistance. So, while from a certain viewpoint nothing is accomplished, yet because the team can now be more functional, much has actually changed.

Agile Leadership - 2

This series on leadership arises from a talk by Mary Poppendieck on Agile Leadership. See our earlier post.

Now let's consider leadership in Scrum. In theory. And then later, in practice.

We are reminded of Yogi Berra's quote: "In theory there is no difference between theory and practice. In practice, there is." (A nod to Nancy Van Schooenderwoert.)

Some in Scrum will say that there is no leader on a Scrum team; everyone self-organizes themselves and things emerge. (See the High Moon video, here.) In a very healthy and capable team one can imagine that things might seem that way, but we rather doubt that is the truth. Or at least, not the whole truth. We suspect that subtle signals of leadership are being given and received within the team. (And then we fall back to...what does leadership really mean??)

We also have had teams that, well, demand a "leader" if not a boss, to guide them in (or perhaps even tell them) what to do. In theory this is not good, but there you are sometimes.

Some in Scrum will say that the Product Owner is the leader. She decides the team's priorities by choosing the Product Backlog items to be worked now and by deciding when they are done. Thus, she is the leader. Or at least a leader.

Others might say the ScrumMaster is the leader or a leader. He is not command and control (as stated in the book), but with his Jedi magic, he is nonetheless in effect leading the team toward higher productivity. Clearly it is an important role, since the ScrumMaster's main job is to manage, and see that action is taken on, the top items on the Impediments List. The role is not a mere process coach for a few Sprints or an MC for meetings.

My own view is that Scrum does not really specify leadership. And that this is a good thing.

First, we need to remind ourselves that there is a whole range of essential things about which Scrum remains silent, expecting the team members to add the appropriate things needed to get the job done in their specific situation. I think leadership falls in this category also.

This is good, because no one-size-fits-all set of answers actually works in all situations. It is good because not all teams require the same dimensions of leadership, and not all teams have capable leaders in the correct roles. This is also partly because not all teams have good followers. (By which we mean not sheepish followers, but those people who can see good leadership and support it.)

Let me remind you (although some may already have inferred this) that when I talk about leadership I tend to mean that group of things relating to vision (purpose, meaning, value), inspiration, and people skills.

Another important area (sometimes included in leadership) is to have the right person make the important decisions. To me, who the right person is must be determined decision-by-decision (or area-by-area). The right person to have the last say on the business value of a story is probably not the same person who should say whether some java code is written well enough.

So, the team should probably define norms about how the various team members will lead. And I would recommend some flexibility in that definition. My bias is that everyone on the team is responsible for leadership in one area or in some way.

Here is the crux, in my view. When the chips are down, on that day when things look worst, who carries the heart of the team? Who encourages that team to stick to it? Who comes up with that one useful, inspiring idea? Who won't let the team fail? Who let's the personal issues get discussed, but then gets the team back on track?

My experience is that this leadership can come from many types of people. It all depends on the people involved.

Although we have no simple answers, the team still needs leadership. (Dang, again we are missing that Agile Cookbook chapter that people can follow and check off to see whether they have a good "leader".)

Agile Leadership - 1

I was pleased to help arrange a talk by Mary Poppendieck at Google in NYC last week. The topic was: "A History of Leadership". The talk will be out in video soon. The slide deck is here.

This is an important topic. And, if I may say so, Mary Poppendieck makes a number of great points. I will emphasize a few below.

To me, the first thing is to tease out the various meanings of leadership, leader, leading.

Sometimes we mean decision-making, as in "who should make this decision."

Sometimes we mean boss-ship, as in "she's my boss."

Sometimes we mean guiding and coaching, as in "he helped us discover this."

Sometimes we mean domain knowledge, as in "she is the leader in x-ray tomography."

Sometimes we mean inspiration, as in "I would follow him anywhere." I will include providing a vision and resolving people issues in this category, although they might easily be placed in their own categories.

It seems to me, as I will discuss a bit below, we need to be very careful about these different meanings (and others).

It also needs to be said that there are principles and patterns of leadership, and then there is taking a group of people, forming a specific team, and discovering that specific leader of that team. Even if he leads only for one day.

This is to say that leadership arises from specific needs, and for specific followers. Another set of followers might be in a different situation and need a different kind of leadership. A good leader in one situation will not necessarily be successful in another situation (or as successful).

For amusement, you may wish to peek at one of Churchill's famous speeches. Here's one.

Perhaps the most useful thing to say right now about IT efforts is that they are ultimately business efforts. And success to a large degree depends upon making the right trade-offs between a fluid technology situation and an evolving business problem shared by a customer-base in flux. So, we must visualize the problem and see where technology (with other things) can make a great contribution. In concrete terms, Mary Poppendieck puts the technology leader and the marketing (business) leader into one person, based on the Toyota pattern of a "chief engineer." Certainly this addresses one of our key problems: a "technical success" that it not a market success.

Now, what do we do if we don't have such a single person?

Mary Poppendieck says (rightly in my opinion) that we need two people in the team joined at the hip; a marketing leader and a technical leader. This of course is not always possible either, but then at least the problem is clear.

And this also makes clear the more general knowledge-creation problem. The people in the team with business knowledge must learn how to collaborate in creating combined knowledge with those on the team who are technically expert. And vice versa. Only when the two domains (to make it very simple) are fully engaged can a truly successful and innovative product be created (or emerge).

More about leadership in the fog of war in a later installment.

Kaikaku or kaizen?

As you know, kaizen means continuous improvement. Implying a bunch of small improvement over some period of time.

Small continuing improvements have many virtues to recommend them.

But what if we need a big change? What if we can make a big change? What if a big change is the only things makes sense? (eg, small changes in isolation won't show any improvement until bunch of other changes are also made.)

Then we have kaikaku. A rapid, large, revolutionary change (as distinguished from a set of small evolutionary changes...kaizen).

In Agile, one example is a 2-day Scrum course for the whole team, followed by immediately diving into doing Scrum.

Even kaikaku does not attempt to change everything at once. But it does make a group of changes "at one time" that together are major.

All the time, the Agile coach is asking..."is it time for kaizen, or time for another kaikaku?"