Public Impediments List !!!

This is essential in Scrum.

Why public? Well, so everyone can see and offer feedback on what are our team's biggest impediments.

Oh, and the list is prioritized. If the priorities are not obvious, then the ScrumMaster breaks ties.

And the real juice is that the SM is making sure the top impediment is always getting worked.

And there never comes a day when there is not a top impediment. (We never become perfect.)

Now, it may also be that the public impediment list reminds the SM (and everyone else around) why the heck we have an expensive person over there *not* doing "real work." (By the way, I think the SM easily pays his board by removing impediments. But you do the math. Of course, that assumes that the company culture does not stifle all the impediment removal efforts -- which has been known to happen.)

The exclamation marks in the title are there to suggest that way too often we find teams without a public impediment list.

Your thoughts?

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.'

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.

Where to start?

Some of us have been doing lean-agile-scrum for awhile now. And we forget that others are just starting.

So, where does one start?

The first answer is that you start from where you are. One thing this means is that one starts with the impediments one has today. And you use Scrum to help tell you "what is the biggest impediment today?"

And there is always a biggest one today. And it is hard to predict what will be the biggest impediment tomorrow. So many different things can be slowing down the team. So many things can come up in an instant.

Is it useful to work on a less-important impediment? Well, yes, but not nearly as useful as working on the top impediment. THIS IS IMPORTANT. We should always be working on the top impediment (presuming that it can be improved, or that 'they' will allow us to fix it).

Why should you start Scrum? (This gets to the core issue of starting with right intention. As any good Buddhist would want us to.)

Well, some people want a work life that is more fun. Some want to get rid of a bad manager. (BTW, I think very very few managers are 'bad', although I do think lots of managers have been taught badly how to do their work.) Some want money. These are all good reasons.

But I think the best reasons are phrased a bit differently: To make my life better, to make our team's life better, to make our customers' lives better. You will note how that starts from the center and moves outward.

And it raises a fundamental question: what does it mean to make someone's life better? This is a difficult yet important question.

I think it is bigger than software. And I think that important words, like freedom, love and self-responsibility, are in there. And working as a team and at the same time fulfilling oneself as a person. Perhaps we may say a connectedness that that makes us more individuals rather than less. (I am in eastern europe (Romania) as I write.) We do not join a collective to lose our individuality, but rather, seemingly paradoxically, to become yet more our own individual selves within the team.

Within the dualisms we are used to thinking in, this sounds a paradox. But it is the truer organic reality.

Learning how to do this can be painful, but, as the song says, and as every mother knows, a deeper pleasure is on the other side. (See http://www.metrolyrics.com/save-room-lyrics-john-legend.html for the lyrics, if you are interested. Good song too.)

One team recently was going through this pain. One wondered how long it would take. One wondered "will they get to the other side?" Still, one has confidence that people learn from scraping their knees.