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.

Impediments Management - 2

A bunch of us got together in Ottawa recently to discuss different issues for managers.

The issue (one of three) chosen was Impediments Management across multiple teams. Including how an management Impediments Removal Team (IRT) would operate.

The example we drew is one of four regular Scrum teams, each with its own impediments list. Each team worked on its own impediments. In addition, all impediments are visible to the IRT. The IRT chooses one impediment at a time to work on, from the teams' impediments, based mainly on the benefit-cost ratio, as discussed in an earlier post.

Several points were made, as we discussed:

1. Communicate the Impediments Management Regime.

Tell everyone about how the impediments are being managed in this overall group. In the teams, by the IRT. So that everyone handles impediments in the most useful way. How they identified, how they are 'approved', how the fixes are implemented, how results will be communicated.

2. Linkage of Impediment work to real improvements (to increase Team motivation).

Sometimes teams become tired of removing impediments. To help motivate them to continue on, the teams need to see, overall, that all the work on impediments has paid off.

The usual situation is that the work pays off mainly in terms of increased velocity of the teams.

Making the linkage is not necessarily one-to-one. It is the net improvement after several impediments that is really important.

This requires collecting data, 'normalizing' it (to some degree), and communicating it back. Honestly.

3. Success.

One manager said that setting up the impediments management regime and an IRT was the first thing he did for adoption across a group of, eventually, 750. A key to his success in the overall adoption.

And, we think, measuring and talking increasing the velocity of the teams by removing impediments is key to overall success with Scrum.

Now, the real success is more business value delivered per month or quarter. But improving velocity is a key supporter of that. So, the goal is to move to a culture that understands that and executes on that. (Yes, metrics are a part, but only a small part of that culture.) And, yes, this cultural change is not easy nor does it come overnight. There is thinking, then action, then more thinking, then more action. They reinforce each other.

4. Next biggest impediment; "If they aren't breaking rules, they aren't trying hard enough"

At least in the firms represented, the feeling was that "the people" were not aggressive enough in identifying impediments. One might say: The next biggest impediment is that they can't imagine that some things can be changed.

In part the issue is motivation and focus (which are helped as described above). But the bigger issue is fixed mental ideas, lack of creativity, past negative reinforcements, fear, etc.

So, we encourage managers to challenge them to 'break the rules'. (Often usefully out that way.) Not break the rules foolishly and/or thoughtlessly. But 'we are willing to consider anything, anything, if it will improve things around here.'

The Unbearable Lightness of Being

Just finished The Unbearable Lightness of Being by Milan Kundera. As a start, see this: http://bit.ly/gdfnRF

A few observations from it about our work.

1. In our work, we too feel everything is unbelievably 'light' and transient. At least some of us do some of the time. And, with all the change, a sense of meaninglessness can creep in. In the scheme of life, it is perhaps a minor observation, but Scrum does many things to put meaning back in our work.

2. The lightness also reflects how many things are in constant change. Which is what we need to adapt to in business. Some of these changes are 'bad' or at least unwelcome. And some are good (for example, new learning). But adapt to both, it seems to me, we must do. To minimize the damage and to maximize the advantage.

3. Toward the end of the book, Kundera talks about how Tereza loves the dog completely and without reservation. And also let's him be completely free. She does not require the dog to love her (although it does), nor to love her exclusively. She allows the dog to be a dog, just as it is.

In business, it seems that it is often hard for people to admit and accept that each and every person is free. We (as managers) must always ask them, for example, 'do you want to do this work?' Just because we pay them, they do not suddenly become our slaves.

To me, Scrum is quite clear how important this notion of freedom is. And does many things to work in harmony with that notion, rather than against it.

* * *

Not everything is about 'work'. I also recommend the book for many reasons that are outside the boundaries of work. Please enjoy. May your heart (and perhaps our parts of your being) be touched by it.

Impediment Management

I was talking today with Martin Drapeau at PlanBox.com, brainstorming "what do managers need"?

So, I have let the cat out of the bag: I am not one of those agile guys who thinks all managers are evil. (Yes, I have in my career seen more bad managers than I want to admit...not bad people, but "not-so-good" managers. Yes, it is a problem.) In fact, I think some managers are quite good.

So...one thing we talked about is how important it is to manage the impediments.

I say: Typically our first big impediment is a lack of focus on removing impediments. I talked about this in a recent post.

What's next? Well, I like to ask ScrumMasters..."where is your public list of impediments?" And all too often I get: "Ummm.......(long pause)" Which is usually not a good sign.

Then I like to ask somewhat experienced Scrum people in my classes: "OK, how do you prioritize impediments?" Often I get "Ummm....(pause)". [I don't give them time for a long pause.] You can guess by now: this is not a good sign.

The simple answer for impediments is: We prioritize the ones, which if improved or removed, will increase the velocity of the team the most. The more complex answer is: "The ones that give the best cost-benefit ratio." And the benefit is the improved velocity (mainly) and the cost is (mainly) the cost to reduce or remove the impediment. (Always apply the most uncommon thing: common sense.)

Do managers have a role? Yes, most assuredly, in removing impediments.

And, typically, there is a management team (or should be) whose main (only) job is removing impediments. I will call it the IRT (Impediment Removal [scrum] Team [of managers]), but other writers give it a different name. And that IRT team should see a list of all the impediments from all the teams, and try to prioritize them across the whole group. And then organize the removal of the biggest impediments for the group.

(And all the members of the 'real' teams should see all this too.)

Could a tool help here? Yes, after about two or three teams, we think a tool could help.

So, for management reporting, would it be good to relate the impediments removed with the increased velocity? Yes, rather obviously as soon as you ask the question, although exactly how might be a bit of a problem. But, if managers had this info (and teams too), would it affect behavior in a positive way? We think so, strongly.

(Yes, Virginia, it can be abused. And, perhaps far less likely, people can drink too much milk too...everything has some risks.)

Reminder: Do not do lots of management reporting. Too many numbers running around can be confusing, and NOT helpful. We only report what is useful; things that help us all make better decisions and act better, more usefully. Numbers never tell close to the whole story, but often tell us non-obvious things that can be very useful.

ScrumMasters: One of your biggest impediments is getting some managers to understand the new reporting and to use it well, operating from lean-agile-scrum values and principles. As some of you know: This can be very hard work for you.

Make sense so far?
What are the most important things I have left out? (I know there are many common questions I have not answered here).
More generally, your comments are wanted. Please comment.

I will have more to say on this topic shortly.

Complex Adaptive Systems

Self-organization, which we just wrote about, is only one of the ideas that we know contribute to the success of complex adaptive systems.

While we are not convinced that CAS (complex adaptive systems) have been fully figured out, we think it has a lot to add. (In fact, our hypothesis is that that E=MC(2) is only a working hypothesis (as are all the so-called scientific laws) soon to be revised...and soon might be 1,000 years). But we think anyone working with creative teams must be studying CAS. Well, and thus, self-organization.

Another key related idea is Knowledge Creation. We cannot talk about this too much.

In our businesses of new product development, the key thing is the amount of good new knowledge created and per unit of time. And good, in overly simple terms, means high business value (along with lots of other constraints).

We think self-organization is key to high levels of knowledge creation. As anyone who has done brainstorming knows, you cannot command-and-control creativity. Or, if you do, you should expect very low creativity, creativity smothered in a prison jump suit.

We think CAS and knowledge creation are key to better Scrum teams.

This leads me to this thought, said earlier a different way: Our biggest impediment is refactoring our wetware.

Now, one of my missions in life is to reduce and reverse de-humanization. (Sounds quite high-minded and daunting, but it is not; it is just a daily struggle, like brushing one's teeth. Or mostly it is.) De-humanization is where people are not treated as being fully human, with all the good and bad and other stuff that implies. Where, for example, they are treated as a thing, maybe a computer. So, I am not in love, as a lover of words, with words like 'wetware' that take a computer model to explain the human CNS or mind. But, if it makes you happy...(as the song says).

PS. Takeuchi and Nonaka, the godfathers of Scrum, have spent much of their later careers studying knowledge creation. Seek and ye shall find.

Self-organization

Some smart people are discussing self-organization on the Lean Software Development yahoo group. You might want to listen or talk there.

Here is what I said today:

****

First, we must recognize that self-organization happens willy-nilly all the time. The only question is when does it start, and where or why does it stop. (Thanks to Tolstoy and War & Peace for explaining this to me. And I am not just a slow learner; it's a great book in many ways.)

That is to say, whenever a 'boss' gives someone an order (big or small), that person must figure out how to do that (assuming they agree to do it... lots of self-organization very smartly ignores the boss' stupid orders).

At a high level, an 'order' could be an initial vision of a product: "We need a hybrid car pronto...figure it out." I think none of us would call that command-and-control, but it could be called an 'order'.

AND...with a Scrum Team there are rightly times and places for them to say "geez, we don't know what to do next, can someone help, please?!!?" Not exactly classical self-organization.

Yes, self-organization is magical and is changing all the time (to a lessor or greater degree). But it is quite real and indeed happening all the time. And we all have many experiences of it.

Now, when asked, I don't think that a 'capable team' that kinda sorta wants to do the work will ever refuse to self-organize. Assuming they are not dysfunctional also. From their background (company culture), they may at first not believe the request to self-organize (how did the manager allow that to happen??). But after a Sprint or two, I have always seen them self-organize.

And I have seen more than one mediocre team need a manager's 'nudging' (that's the official term) to get them started. This is partly because they are relatively inexperienced, not used to power, and not used to being in the project this early in the process. It feels odd to them so they feel unsure what to do. But, once started, they self-organize pretty well.

Now, one more thing must be said or asked. Will a team of 7 always come up with the best solution on their own?

Asked that way, I think it is clear the answer is No. Even if they give themselves some feedback (eg, the Scrum demo). So, the Team should be encouraged to ask for more feedback and advice. And indeed, there is room for managers to provide leadership. It might be called 'coaching' or something else (so that all of them are less likely to fall into command and control). But,
despite what some agile people say, what I see is that smart and good managers have a real role. (OK, yes, there are fewer of them than we want. Agreed.)

And that these good managers are not contrary to self-organization at all. Once mutual respect is built up (and, as Taiichi Ohno might say, mutual humility: "Half of what I know is wrong" is pretty close to his quote).

The goal

Elihu Goldratt wrote a book called The Goal, which we recommend. TOC (theory of constraints) is embedded, to some degree, in Scrum, for example, we think.

But we wanted to talk about "the goal" a different way.

What is the goal of our courses?

Being shy and modest by nature (ok, yes, we act a different role if the part requires it, but this is our nature)...we do not think the goal has much to do with us. It is not, for example, what we say in the course.

Nor is it what the attendees learn. I really don't care about that anymore. Up, down, sideways: it is not really key. Necessary probably, but not key.

Nor is it the actions that the attendees take after they attend the course/workshop.

The goal: That they make their own lives better, that they make their team's lives better, that they make their customers lives better. And more than that, but that is enough.

We want results.

Now, our talking, their learning (Tacit and Explicit), their actions --- these are probably all necessary conditions to getting the results. But not sufficient. And maybe we want the results to also include money, but we agree with Peter Drucker that the purpose of the firm is to satisfy customers (not to get shareholder returns).

Now, what is our vision of the goal for Scrum?

Certification? Certainly not.

More 'scrum'. Well....no.

More good Scrum (with no Scrum-But). Well....still no.

Again, to us the only worthwhile goal is better lives for the people involved.


Now, again, we do think more certifications, more courses, more Scrum, better/deeper Scrum, much less Scrum-But, etc, etc probably are necessary conditions to getting better real results. In fact, let me say that more strongly: Based on real experience, I am convinced that Scrum and better Scrum are key to better results for all new product development teams I can imagine. And for other kinds of teams as well. But not the sufficient, sole key.

(Unless one assumes that by starting continuous improvement, the team will necessarily go as fast as possible in the direction of positive change. A sweet assumption in some ways, but not one that attracts me as correct. In this "best of all possible worlds" -- meaning I think Voltaire satirized this sweet viewpoint quite well.)

And some other things are also needed (a nod to Ron Jeffries and others re this comment, to be discussed later).

"Where there is no vision, the people perish."

Meaning: If we all do not articulate a clear, strong, good, and bright vision, Scrum could be far less successful than it by rights ought to be. And "we all" are the Scrum community, speaking to ourselves and speaking to those who look to Scrum for some improvement. If we fail in this or do a poor job, many many people will have poorer lives than they deserve. And, god knows, there is so much improvement to make in our lives. Even in 2011. (smile)

PS. The picture is of the Blue Ridge Mountains. I go to them sometimes, when I need a moment of peace, of inspiration. "I lift mine eyes up unto the hills..." They are said to be the oldest mountains in the world, and this is almost actually true. Surely they have some majesty. Surely this is not without meaning.

CSM + Workshop: Why so successful?

At the insistence of my good friend and colleague, Catherine Louis, I started doing Certified ScrumMaster courses (2 days) followed immediately by a 2 day Workshop.

This experiment (which it was for me at first) has proven completely successful.

I am now convinced that this is the best way to learn Scrum. Period. And I am convinced mainly because everyone tells us this is so. ScrumMasters, Product Owners, Team members, Managers. Including the managers who insist that it is a MUCH better value to pay extra to get them into the full 4 days.

What do we mean?

First: The best is to have the whole team and some closely related managers attend the whole 2 day Certified ScrumMaster course. Obviously, it isn't just for ScrumMasters anymore. (Was it ever?)

I won't describe that course here, but suffice to say that the way we do it includes lots of interaction, some challenging questions, some improv, some team exercises, including a very realistic Release Planning exercise.

Then, we have the same real team (well, teams, really) do the 2 day Workshop. Each Workshop is a little bit different. But the focus is on two things.

Complete a good (decent) Release Planning for the real project or effort that the team is working on. It is best if the team is just starting the effort. And it is best if the team has access to all the people and resources to make the Release Planning effective. Release Planning includes (over-simplified): Vision, Product Backlog development, Business Value (points), Story Pointing, Risks-dependencies-other, Ordering the work, Deciding the scope-date trade-off, Budget. We also talk about infrastructure, architecture, and design (IAD).

Second, complete a version of Sprint Planning. Over-simplified, this includes: Agreeing on the PBIs (product backlog items, or user stories) to commit to in the Sprint, and breaking the Stories into tasks. And fully committing. (I define this as: "We believe, 9 times out of 10, with the usual "stuff happens" around here, we can get all these stories done, in our best professional judgment. And maybe do more.")

Why is the Workshop so important?

Well, in theory, it should not be. But in practice, it is very important for almost every person.

Because it takes the "theory" of the course, and puts it into ineluctable practice. (Ineluctable is a fancy word from James Joyce, meaning "incapable of being avoided".) So that the stark and real meaning of the ideas becomes so much clearer in the real world of the team's real work.

The Workshop is done under the guidance of typically two very experienced coaches (Catherine Louis and myself, so far). We offer has much coaching as we think appropriate, which is more than directly asked for. We keep in mind Yogi Berra's advice (about hitting in baseball): "Think? How am I gonna think and hit at the same time?" That is, too much advice can actually hurt beginners more than help them.

The head-bobbing in the course no longer is good enough. One either "gets it" (to some degree) and does it. Or not.

Some times some resistance becomes more obvious. But usually in the 2 days of the Workshop, that resistance is overcome. Not by the teachers talking at them, nor by anyone else just talking at them. But because their concerns, which maybe have some basis, are soon seen to be minor compared to the benefits. (I do not wish to suggest that all resistance is always and completely overcome. Just that it is addressed much more effectively.)

Does that help? Is that enough?

FAQ

Here are some frequently asked questions.

1. What if I am not attending with my own team?

We can form a Team of people, and you can participate with that Team. Or you can join a real team, for the Workshop, as a consultant (with their permission). If you are partly of an ad hoc team, then we want the Product Owner of that team to be working on his real project or product or effect. So, at least for him or her, it is very real. And that person is responsible for making it real for you.

Is it less effective? Yes, probably somewhat. Is it still useful? Yes. We have had no-one in this category say it was not useful.

2. How many teams are you coaching at a time?

In the workshops, we think it is best to have about two teams per coach, maybe three. So, if there is a large group, there typically will be two coaches.

3. Do we need to prepare?

Yes! As much as you can. It will still be useful even if you do not prepare at all. But the more the Product Owner is prepared with all the information the team will need to do Release Planning, the more effective will be the use of your time. This ideally and typically means including the other key business stakeholders (SMEs) in the workshop team. If you can.

But "if you wait for perfection, you might wait too long." Do what you can before the Workshop, then, wherever you are, do the Workshop.

For a client perspective on the workshop, see here.

How much should we sharpen the saw?

You probably know the classic story of the man sawing the tree. You walk up to him.

You: "How's it going?"
Sawer: "Wow. It's really hard. This is one big tree, and I have been working at it for hours now."
You: "Sounds tough. Why is it going so slowly?"
Sawer: "Well, this is hard wood. [He is still sawing.] (Puff.) And my saw has become dull. (Puff)"
You: "Why don't you take the time to sharpen it?"
Sawer: "Can't. (Puff.) (Puff.) I am in a rush."

And the point is that the sawer is not thinking well. He could easily have saved time by sharpening the saw.

But, they always feel that sharpening is taking too much away from doing 'real work'.

And the truth is that sometimes "they" are right about this.

So, how much team time should we allocate to 'sharpening the saw'? In Scrum, say.

Some of you will notice that I have a picture of Coach K above. Coach K, for those who don't know, is the ScrumMaster of the Duke Blue Devils basketball team. A real team. His team won the NCAA Championship last Spring (in what they call March Madness). And his team is #1 in US college basketball today, as I write this. And is undefeated. He is a very, very, very good coach.

So, if we use him, his team, his other coaches, his managers, his trainer, etc, etc, as an example, what is a reasonable allocation to "impediment removal" for one team? If you really want to win.

My answer in practical Scrum terms: one full-time person (ScrumMaster) on impediment removal per full-time team of 7 people is quite reasonable. Probably an under-allocation, but quite reasonable.

And I take the view that none of us has won the NCAA Championship yet (or our equivalent), so until we do, we have plenty of impediments to remove. (And by the way, our team members virtually always do not join the team with the same raw ability in our sport with which Coach K's recruits join his team.)

And I notice that Duke does not fire Coach K after they win the NCAA. And New England does not fire Coach Belichick after they win the Super Bowl. Just repeating at that high level is almost impossible. But again, I personally have never seen a Scrum team that could argue that it was the best team (or even thought that it might be), so this worry that we have 'topped out' seems like an issue not worth talking about for a long time.

Now, if the SM is not very good or if the organization or some other factor means that the SM's efforts will not increase team velocity, then maybe 1 to 7 is too high an allocation. But it is often the first job of the SM to learn how to remove impediments effectively, and to teach the organization (the managers) how worthwhile that can be. Those are the first two impediments, sometimes.

Doesn't this allocation seem reasonable now?

The biggest impediment

To start the new year, perhaps we should focus on the biggest impediment.

Now, of course, we don't know the biggest impediment at your place.

But we can tell you what we see at clients, and what makes sense to us, given human nature.

In our view, it is human nature to feel, "We canna push it any faster, captain." (See the picture of Scotty.) Meaning: We feel we are going as fast as we can. So, we ignore impediments. We don't even see them. Now, there is actually a lot more to say in this vein, but we will ignore that for now.

The biggest impediment, in our view, that we most commonly see is a lack of focus on removing impediments. Now, this has several manifestations and several root causes. We have just mentioned one of the key root causes. (To which maybe we could ask more "whys".) But, we think that is a useful way to describe the impediment.

Here are some of the manifestations:
* No public impediment list (Do you know where your public impediment list is?)
* No or poor prioritization of the impediments
* A retrospective that focuses too much on the 'pluses' and on lots of impediments (without a focus on the one top impediment now)
* No effective action taken after the retrospective to reduce the impact of the impediment
* No serious thought about the whole impediment removal process (eg, an assumption that the simple framework of Scrum tells us everything we need to know about removing impediments)
* Too much work on the wrong impediments
* No transparency about the group's (or firm's) overall impediment management regime
* Not enough allocation of the ScrumMaster (and perhaps others, perhaps $) to removing impediments
* Comments like "Why are we working on impediments? We should be doing 'real work'?"

This is serious. We think a decent ScrumMaster, with decent organizational support (helped along by the SM being persuasive), can double the velocity of a team in the first 6 months. You do the math. Would that be worthwhile at your place?

PS. Because of possible misunderstandings, we must always repeat that doubling velocity does NOT mean that the Team works harder (No death march). Often it means that the Team works fewer hours than what has become 'normal'. In fact, the Team should feel that removing impediments is kind of a fun activity.