Public Impediment List: “We don’t want to see the bad news.”

Posted on May 3, 2013 by Joe Little

The Scrum Guide does not mention it, by I strongly advocate a public impediment list.

The simple idea is: visual management, and single piece flow off the ‘top’ of the list.

What’s the problem? There are several, and let’s discuss two today.

1. Some impediments are personal and should not be put on the list.

To be this is easy. An example that is fun to talk about is that Sarah and Sunil are having an affair. And some or all of the team knows about it, and it is ‘disrupting’ the team in some way.

The issue: listing this specific personal impediment on a public forum will not help. Fair enough.

And the easy solution is that those ‘personal’ impediments should not listed, at least in the wrong way, on the public impediment list.

2. ‘We don’t want to see the bad news.’

This is actually a very common and a very hard problem.

Often members of your organization — while they may never say it this way — will not want to see the problems in the organization.

Sometimes this will manifest as a denial of some of the impediments. And, to be fair, there should be a healthy discussion about whether all things mentioned are really impediments. But certainly we see people ‘defending’ things that are really impediments.

A related factor, though, is the wish to feel good about ourselves. And the impediment list makes us, often, see that we are….more imperfect than we sometimes want to admit. This is hard on the organizational ego.

So, building in some humor, and showing the value of always striving to be better… these are very important things to discuss.

The importance of a real team

Posted on May 17, 2012 by Joe Little

Scrum requires a real team.

The word ‘team’ is often used, often in different ways. So, let us define it.

According to “The Discipline of Teams” by Katzenbach and Smith, this is what you should look for:

1. A meaningful common purpose that the Team has helped shape.

2. Specific performance goals that flow from the common purpose.

3. A mix of complementary skills. Including technical/functional, decision-making, and interpersonal.

4. A strong commitment to how the work is done.

5. Mutual accountability.

For more discussion, see The Discipline of Teams.

The team needs to be small (~7), stable, cross-functional, and self-organizing. The team is in it together. And should help each other.

In general it is best if the team is fully dedicated to one missson, one purpose, or at least the one team’s goals.

All of these team characteristics together are key to starting Scrum. Got to start with a real Team.

Note: Not everyone wants to be on a Team. And for sure, not everyone walks into the office knowing how to act in a real Team.

We must have working software at the end of the Sprint!

Posted on February 14, 2012 by Joe Little

This is a common failing (not enough working software). Jeff Sutherland has said this is the biggest problem in the Scrum community, that too many teams don’t have working software at the end of every Sprint.

If we include cases where 1or more PBIs (Product Backlog Items) or stories are not completed, this is a very big problem. And very common.

So, how do we fix it?

Well, the root causes at your place or your friend’s place may be very different from mine. But here are some likely suggestions.

1. A better definition of done.

First, have one. Second, let it actually be what people are committed to doing (rather than just some pretty words on the wall). Third, put in a process format rather than an “end-state” format. Show how the team will get to done.

To me, a minimum definition of done for a software product includes the following: Requirements (of course), Coding (of course), Unit Testing (typically by the coder), and Functional Testing (by a qualified professional tester, of the functionality in that PBI, at least), and Product Owner Review (ie, the PO likes it once ‘complete’). And all bugs or problems are fixed. And re-tested. This is the minimum, IMO.

2. Your testers are used to slow manual, non-agile, testing.

They may not say it out loud, but they don’t really understand agile. They are still expecting to do it the old, waterfall way.

3. Lack of good automated testing, and automated testing frameworks.

This could include a lack of people who understand automated testing, why it is needed, and how to do it well.

4. Smaller stories.

It is very common not to complete stories of one or more stories (or PBIs) are too big. One rule of thumb: If the Sprint is two weeks (10 business days), then any story that takes more than 5 ideal person days of effort is too big. And the average story should be in the 2.5 ideal person days range. Total for all people working on that story. Put another way, I want at least 8 stories in each 2 week Sprint. All about the same size.

5. The Team is over-committing in Sprint Planning Meeting (or being over-committed later).

This is very common. They should not take on more work than they can do. Period.

6. The Team does not understand well-enough why working software at the end of the Sprint is important.

Often, they forgot. They knew 3 months ago (when the trainer told them), but they have forgotten since then. Not all of them, but maybe most of them.

Often they will admit to one of the 1-5 root causes (or some others), but they won’t put much energy into fixing it or them, since they don’t really agree that the problem is all that important.

***

Well, if you can identify the problem, the root cause, usually you are more than half-way to fixing it.

More on the fixes to these problems later….

Public Impediment List !!! – 2

Posted on December 21, 2011 by Joe Little

There is a good Scrum trainer who thinks that a public impediment list is not important. So, if he can mis-understand, then we all can. See here is a yet better explanation. I hope.

****

I find that the lack of a public impediment list is a prime indicator of a lack of focus on removing impediments.

This is essential in Scrum. Why?

Well, first it is important to say that the public impediment list is not the main deal. The list must be acted on. But, like 12 lawyers at the bottom of the ocean, it is a good start.

The real deal is removing impediments, and making the lives of yourself, your team and your customers better. And the impediment list is one way to do that. Or, better to say: fixing impediments is one way to do that. And the impediment list (public) helps you do it better.

Why have a list? Well, we believe in doing one thing at a time, and getting relatively quicker results from that. Rather than working on many things and usually not making any tangible progress.

So, the list enables the team and the firm to order the work on the impediments.

How? Well, first an impediment is anything, anything slowing the team down. Or, if fixed, would speed the team up. (Speed meaning both higher quality and higher productivity.) The team gets greater benefits sooner by working on the top priority impediment.

But we forgot to mention that the first one might be the one that gives us the greatest bang of the buck, meaning “business value” divided by effort. (Business value for impediments might, too simply, be thought of as the velocity increase for the team.)

So, we can always be working on the top item on the list.

And, by the way, every team has not reached anything close to optimal velocity, so there is always a top impediment. In fact, always a list.

Why public? Well, so everyone can see and offer feedback on what are our team’s biggest impediments. Otherwise, Brian thinks he told George about Item X, but George forgot to put it on his personal list….so, it was forgotten. All these little human errors are less likely with a public list.

And we mean everyone. People in the team and people outside the team. And including the higher level Impediment Removal Team (IRT). Anyway can make suggestions, and help us get better. [I call it IRT. Ken Schwaber and Mike Cohn and others have their own names for it. I assume you are in a company with 4 or more Scrum teams, where an IRT starts to make sense.]

A public list reminds everyone that someone should be working on the top item, well, and that would be today! “Has anyone started?” “Oh, yeah, I’m about to start that!” Human nature again.

And a pubic list enables Mary… who was sure her Item B should be number one, but shows as number 10 now…. identify the problem. So, now she knows to go to George the ScrumMaster and make the case why her Item B should really be #1 on the list. Otherwise, she might just guess that George “got it” after their hallway conversation (where he actually was thinking about the Christmas presents he needs to get).

****

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 indeed someone is fixing one almost daily.

Again, 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 (the SM) over here *not* doing “real work.” (By the way, I think the SM easily pays for himself 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.)

For you all into Lean, a public impediment list relates to Visual Management and to Kaizen. Two big practices (or ideas) in the Lean community.

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

Finally, let me recommend a public list of impediments already fixed. How quickly we forget our successes. Oh, yeah, that’s why we have the stupid ScrumMaster around….

Your thoughts?

Public Impediments List !!!

Posted on May 24, 2011 by Joe Little

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

Posted on January 23, 2011 by Joe Little

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

Posted on January 17, 2011 by Joe Little

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?

Posted on September 28, 2010 by Joe Little

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.

One impediment at a time

Posted on July 28, 2009 by Joe Little

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?

Small teams

Posted on October 16, 2008 by Joe Little

I was just looking at The Discipline of Teams by Katzenbach and Smith. These are the same gentlemen who wrote The Wisdom of Teams.

First, my strong bias (which I find is reinforced in many places, including this book) is that all “real work” these days takes place in teams. (Yes, Virginia, I need to add some caveats, but it’s still basically true. IMHO.)

Chapter Five of their book is titled: Applying the Team Discipline: Number & Skill. Subhead: “A small number — ideally less than 10…”

They then give 6 long reasons why large groups are not teams (or, at least, don’t have the discipline of a winning team, as they [and I] see it). I will summarize:

Large groups cannot easily or frequently meet together.
Large groups are biased toward efficient meetings. [Why is this a bad thing?!?! Well, efficiency is not creative, for one.]
Large groups are biased toward hierarchical leadership.
Large groups are biased toward stable roles.
Large groups usually fail to build common understanding and commitment.
Large groups often subdivide …[and] create smaller teams [sub-teams].

If your culture does not immediately know that a team is 9 or less, you need to study in this area. [IMHO] Get all the help you can to knock down this impediment.