March 31, 2010
Sometimes when I talk to people about impediments, it feels as though the conversation gets pulled down into despair. It’s particularly acute with the “big” impediments – the ones that it seems we have no hope of solving. Sometimes the conversation dies right there.
But I’ve learned that it doesn’t have to.
There is a different set of moves that we can use in this dance. We start off exploring the boundaries of the the situation. How pervasive is the problem? how extensive is the damage? But we don’t stop there. We continue until we get that signal, that feeling in the pits of our stomaches that says, “I’m not sure we can fix this.” Then we switch gears (I’ve learned this is the hard part). We go into elaboration mode. We describe the problem in as detailed a fashion as possible – the very act of describing the problem helping to reduce uncertainty. We start to brainstorm all of the options that we have for dealing for that problem (or in many cases what is actually multiple problems). Now, not only are we looking at a problem, but we also have an array of solutions.
What if you have no idea how to solve the problem? Google it. If you can articulate an impediment, you can bet that someone has proposed a solution.
Finally, once you have a set of alternative solutions to the problem, pick your favorite and create an execution plan. Flesh it out in as much detail as you can. The more vivid you can make it, the more likely it is that you will be successful.
You see, if you use an approach like this, then for any given impediment, you have a strategy. By doing so you have eliminated a great deal of the uncertainty and have set yourself on the path to executing a solution – that is a much better place to be. Whatever you do, don’t stop half way.
March 31, 2010
What if we uncover impediments, we make their impact visible to the organization, but we don’t have the authority to make any changes to alter the state of affairs ourselves? How does it make you feel?
It can make you feel very, very, small.
This feeling is especially acute the larger the organization you are part of is. You feel like a lone voice in the wilderness. It’s tempting to give up. That’s when we need to switch gears and put on our change agent hats (in my case: a pith helmet). There are some great guides for effecting change in large organizations (e.g. Linda Rising’s Fearless Change). It requires building a long term adoption strategy, getting a mentor, obtaining sponsors, and generally girding ones loins for a long term effort.
Taking on the corporate Goliath is real work. It requires a stubborn streak of truly epic proportions. It ain’t easy being David, but the rewards, for you, the organization, and ultimately your customers, are worth it.
March 30, 2010
Ken Schwaber tells a story in his second book, Agile Project Management With Scrum, about a key contributor on a project who goes on vacation (hiking in Yellowstone park). Of course, as soon as he leaves, the critical component he is responsible for goes down in flames. The team is demoralized, the project is jeopardized, an impediment is born.
What would you do?
Apparently, if you have enormous brass balls and your name rhymes with “Schwaber”, you hire a former FBI agent as a private detective to go into Yellowstone and track down your missing developer and bring him back to the team to fix the problem. No joke (see page 117).
How many project leaders do you know would have that kind of audacity? I think there is a lesson for us in that story. All too often we turn away from problems that challenge our teams because they seem too great, too daunting to face. I think Ken is trying to tell us that a certain amount of boldness is required to lead great teams. You have to be willing to slap down the credit card and make things happen. That’s how you build a reputation for delivering success (and perhaps a little insanity). The story could easily have gone much differently, but I don’t think anyone would argue that Ken was committed to the success of that team.
I think he’s inviting us to be audacious too.
March 29, 2010
If you are trying to resolve a particularly difficult impediment, try calculating the cost of the impediment to the team/customer. Often putting the damage into dollars and cents will help translate the problem into something that business stakeholders understand and respect, namely profit and loss.
I have a cost column in the spreadsheet that I use for tracking team impediments. I can’t always fill it in with a number (which is usually a signal to me that I need to better understand the issue), but when I can associate a cost with the impediment, I find it much easier to garner attention to the issue from executives and other key project stakeholders.
In fact, if you grab your dusty old copy of Kerzner, you will find an entire chapter on assessing the costs of risks and using it for decision making (Monitoring and Controlling Risks). We can incorporate this work into impediment management for agile teams.
The fact is, meaningful impediments cost your project, your company, and your customers money. Impediments are a threat to a team’s ability to rapidly deliver value. You could probably put it into an equation:
Stories – Impediments = Customer Value
March 27, 2010
In the Tipping Point, Malcolm Gladwell talks about a phenomenon called Fundamental Attribution Error. Basically, FAE is attributing success to the wrong things. His point was that we often fail to take context into account when making judgments. He gave an example of a study where subjects were asked to judge the performance of two basketball teams, one playing in a darkened auditorium and the other under normal lighting conditions. The subjects were asked, which team is better? The answer: the team in the well lit auditorium of course.
The only difference between the two teams was the context (lit vs. unlit). Both teams were equally skilled, but the team playing in the dark missed many more shots. That led me to ask myself, “Is my team playing in the dark?”
The context that software development teams work in has a profound affect on how they perform. I’m not just talking about physical context, but also the culture, the technology, and even their social context. I suspect that there are many fantastic teams that are working “in the dark”. It’s our job to turn on the lights.
March 26, 2010
In this wonderful blog post, You Are The Impediment, Mike Cottmeyer argues that there are three different levels of impediment management required of a good scrum master/team leader:
- The Tracker
- The Remover
- The Anticipator
He characterizes this as a sort of competence hierarchy for agile managers: Tracking being the minimum one could do, Anticipating being the desirable thing to do. I strongly agree. I see it this way:
- Tracking = History
- Removing = Managing/Problem Solving
- Anticipating = Risk Management
Each level has a valuable skill set associated with it.
Having a history, whether it is a history of sprint velocity, a history of stories, or a history of impediments, is essential to creating the necessary level of information for the team to learn well. Like they say, those who ignore history are doomed to repeat it.
Removing impediments is really about problem solving. Problem solving is all about root cause analysis, building hypothesis, and tracking the results of experiments. It’s common to see teams rush at solutions without taking the time to understand the problem well. We need to get better at using problem solving techniques to help us resolve impediments.
Anticipating impediments that have yet to happen is also known as risk management. Risk management is poorly understood in the agile community. Look for it in books regarding Scrum and XP and you won’t find any mention of it at all. Fortunately, there are some great books on risk management like Waltzing with Bears, that should be required reading for all team leaders.
A good leader needs to cultivate all three skill sets in order to maximize their team’s chances for success.
March 24, 2010
I heard someone say that the best project managers were the ones who were capable of “seeing around corners” on a project. These were the project managers who were checking to see if there was an oncoming truck before trying to cross the road. At the time, the ability to “see around corners” was treated like some sort of sixth sense. It was as though certain people had an innate capability to detect issues that would threaten to derail a project that the rest of us didn’t have.
Of course there are two things you can do to acquire this magical ability for yourself:
- Ask the team what issues are blocking (or going to block) them. A team is an amazingly smart and remarkably intelligent beast. As a collective, it will detect danger long before any individual will. It works in the office just as well as it does for a herd of gazelle on the plains of Africa.
- Pay attention. That means keeping track of the issues that block the team. Follow up and review the impediments at reviews & retrospectives. Keep the impediments visible to everyone. Do everything you can to insure that the team learns and doesn’t forget.