The Dedicated Agile Champion job

If an agile initiative is to succeed, one of the best patterns (cf. Fearless Change by Mary Lynn Manns and Linda Rising) is for someone to be named the Dedicated Champion (their title for the position).

(Note to senior managers: If you really want the change to happen, wait until someone volunteers to be Dedicated Champion. And then help them structure it into a real job, not a baloney job. Which is tough, since your firm has almost surely never had a position like this.)

First, why is such a role needed? Well, it would be nice if positive change happened with no effort. Auto-magically. But experience shows that it does not.

Let us say simply: While an Dedicated Champion is expensive, it is minor compared to the benefits of a positive change in the direction of lean-agile-scrum. In our experience. (I won't speak to whether cowboy Agile is worth the benefits, but real and hard Agile is.)

What is the role at the highest level?

1. To lead and inspire the change
2. To help define what the change is, and how we will get there
3. To convince and bring on board others to support the change
4. To help show that the change is happening and giving good results
5. To avoid cowboy Agile and backsliding to Waterfall (or the former approach)
6. To lead modifications to the change
7. To remove impediments to the change (along with others)
8. To lead the people to the next level, if it starts to plateau

This all requires huge amounts of talking to people. Not to tell them what to do, but to inspire them with a vision of where they could be. It is more a role of pulling than of pushing.

Two dangers to speak of first.

One danger is that one is always talking, and no tangible results are obtained. To counter-act this (and for other reasons), we recommend that the Dedicated Champion stay very close to the real Scrum teams (assuming you are doing Scrum). He/she should be, and be seen as, a direct contributor to the success of the Pilot team(s). And later teams.

The second danger is to try to do everything. In fact, 'everything' needs to be fixed. The Dedicated Champion should do two key things:

1. Not do things that others (internal or external) can do as well (or almost as well). Note: This implies that the Dedicated Champion has special ability in certain domains, and should focus on those areas (more).
2. Prioritize!!!! Meaning simply: Do the most important thing first. One at a time. Go to the next one once you have gotten good results from working on the prior thing.

Our view is that there is so much for the Dedicated Champion to do, that it is beyond the ability of one person to do it all quickly enough. Unless, perhaps the company size is 10 people, and 7 of them are pigs in a Scrum team. In that case, perhaps the job is reasonable.

Dear Rob - 1

Let's assume Rob is a senior executive, with some oversight for an Agile initiative. He is a business person, not in any way a techie. What would you say to him? Well, here are a series of posts for Rob; what I want to say to him. Post #1.

[Note: Rob is not a specific person, but rather I have put together several specific people into this one 'character', Rob.]

***
Dear Rob,

We think it is very important for senior executives to set the right tone for product development.

So, as a start, see The Toyota Way by Jeffrey Liker. At the beginning of chapter 1, Fujio Cho (then President of Toyota) gives the quote you will see. It starts:

We place the highest value on actual implementation and taking action.

Read that whole quote.

It discusses how we create knowledge in the fastest possible way: by making mistakes, by admitting to small failures and learning from them. This is in fact the way that Fujio Cho himself learned from Taiichi Ohno, when he was his protege, as everyone in Toyota knows.

The people using lean-agile-scrum need to know that you understand this. Not, of course, that you want them to fail in a big way. But rather, given the nature of their work, especially new product development work, that you understand that acting is usually the fastest way to learn, that mistakes will of course be made. AND, that they are expected to learn from the mistakes.

And often they must learn by discussing the mistakes with managers and other who can help them learn. They must do 'root cause analysis', for example, to enable themselves to learn faster. And fairly quickly, to drive quality up.

By going slow, we go fast.

So, I suggest you ask managers under you to allow everyone to tell more and more of the truth. And not just ask, but show it to them in the way you handle real situations (use real situations to embody the message). Even the truth that we really want to hide our eyes from (and probably have been hiding our eyes from). It is much easier to manage with the truth.

I am sure that you understand there is no implicit criticism of you personally here. But there is an implicit criticism of prior management cultures that your people are so used to. That told them, over and over again, to lie. (No one ever said: "You must lie", but that was really the message. And no doubt this started before they ever came to your firm.) And to pretend they were perfect (which is an awful burden to bear).

To the degree your firm and firm culture have fully embraced Lean, this will be an easy change. My opinion, based on maybe much too little time at your firm, is that...well, let's say that your firm still has a way to go in embracing real Lean. At least in the areas I have seen. (And also, honestly, because your firm does know Lean pretty well in some areas, you have a huge advantage compared to other firms.)

You may find it odd that we ask you to help your people become more honest ('everyone should already be honest', you might say to yourself), but honestly, dishonesty is common everywhere. Even in your place.

Feedback should always go both directions, so please tell me:

1. Is what I have said helpful?
2. There are related things I already want to talk about more, so if you have particular interests or questions, we can tilt in that direction. Please tell me.
   
3. There are completely unrelated things I also want to talk about. Again, if you have particular interests, please tell me.

Regards, Joe

Understanding the customer

In my viewpoint, one of the key things about Agile is bringing the customer and the Team (the implementors) MUCH closer together. So that the Team starts to understand many (most?, all?) of the marketing issues and activities. In effect.

Let me mention two things.

1. While the customer usually knows their own problem (well, pretty well), they typically are rather clueless about what the solution should be. Nonetheless, we typically ask them 'the requirements', and we are shocked, shocked later when they say "Well, now that I see it, it is not what I want."

As one angle to this, most normal people don't want 'a product'. They don't want software or a technology gizmo (yes, there are a few people who do want this, but they are few). They want only what the product will bring, ie, that the problem will go away. As an example: they don't want a music playing thingie (Zune or iPhone), they just want to be able to hear the music they want almost anytime they want to. (Yes, the 'problem-solution' metaphor does not work well in every case.)

Along with this, the customer is a normal human being; meaning, even what they say is not very articulate.

As a perhaps not minor point, no two customers agree.

2. We can't hear what the customer says. This is of course normal human behavior, as, for example, any wife (or husband) knows. And there are also lots of additional root causes for us.
* we put extra people (noise) in the process.
* our topic is very abstract
* we are talking about something that does not even exist yet
* it has all kinds of geeky, fast changing, fast moving lingo around it
* we want to hear features, and the customer wants to talk about his problem
Etc, etc, etc.

To improve this situation, Agile says: Bring 'em much closer together. Even closer than we can possibly imagine. Far from perfect, but hopefully most of the time much better.

(Why still imperfect? Well, for example, even a husband and wife who have been together for 20 years don't perfectly understand each other. As another example, most business-customer types are challenged hanging out with techno-geeks talking a different language.)

Now, it is still terrible, so I think we should enable ourselves to discover more quickly when the cycle is especially stupid.

So, I am suggesting putting in a tight P-D-C-A cycle in there (Plan, Do, Check, Act). That cycle in Scrum is a Sprint and then a Release (ie, two cycles).

With some metrics (which are indeed very hard, but hey, delivering business value is what's important). Example: measuring the BV delivered after each release with some metric. We will still make lots of mistakes, but maybe we learn faster.