Agile2016 is Coming!

July 9, 2016

hands-people-woman-meeting-large

“This is where the Agile tribes meet.”

Agile2016 is swiftly approaching. I’ll be there in Atlanta doing a couple of talks this year. If you are going to be there you should definitely come check them out:

The Self-experimentation workshop is something that I originally developed a few years ago for XP2013. It is very hands-on, each attendee contributing their own experience to the workshop. To date it has been very popular. Some attendees have described it as one of the most invigorating talks they have ever attended. That’s pretty high praise – it’s probably my all-time favorite workshop.

If you are interested in getting a bit of a sneak preview of what this self experimentation stuff is all about, you can check out the experiments that I have run on the onestandardman blog. There is also background material here and here.

On the impediments front, there is a lot of material that you will find right here in this blog. For example there is this, and this and this. And then of course there is The Little Book of Impediments. There will be copies of the book at the bookstore for purchase at the conference. Catch me and I’ll be happy to sign one.

There will also be an Agile Management Conference meetup that will be held in the Open Jam area (time & date at the conference is TBD – check the Open Jam Board) so please join us for that if you are interested.


Make Resolving Impediments a Habit

October 17, 2014

David_City_Rey_grocery_store

I’ve talked a lot about the rigors of finding and resolving impediments for a team. There is one thing that I have left out: the people part. I learned this lesson at a conference that I was co-hosting. I had been in charge of setting up the food for the event. Getting the caterer, arranging for meals, that sort of thing. As you might imagine, it’s a pretty tough job to satisfy the dietary requirements for a very large group of people. I learned of whole categories of food allergies and needs that I had never even imagined existed! There was a little bit of every imaginable combination. Everything from your standard gluten free diet all the way to lacto-ovo-pesca-leguma-veganitarians (OK, I made that last one up).

We did the best we could to satisfy the needs of most folks and pretty much called it good. About halfway through the conference, someone mentioned that there was no food that fit in their dietary needs. I expressed my sympathies and referred them to the grocery store around the corner. I really didn’t give it another thought. A few minutes later, I heard the same complaint made by the same person, but this time the reply was, “I’ll get you something, I’ll be right back” And that person ran off to the store themselves. Wow!

I was humbled. The difference between my reaction and theirs was the difference between someone who could empathize and take action to resolve the impediment, and someone who couldn’t. The lesson I learned that day was that in order to help people with their impediments, it takes empathy. You have to feel their need, and be receptive to doing anything to help them out. I think I had missed that before. That willingness to serve the needs of others is really important. All the strategies in the world for resolving impediments won’t help anyone if you don’t care.


When Impediment Management Won’t Work

September 6, 2014

IMG_2191

 

 

 

 

 

 

 

 

 

I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.

Some signs you may have a problem introducing a change:

  • Taking action requires getting permission (this is straight from Pawel)
  • Stating the desired change is too risky
  • Action can’t be taken because projects are too important
  • Only certain people can take action

I’m sure this could be a much longer list. The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.


Those are Not MY Impediments!

September 5, 2014

Army Boots Stand Out in a Crowd

 

 

 

 

 

 

 

 

When trying to find impediments there is a trap that awaits those of us who are outside of or observing the team. Often, when you are observing a team as an outsider, you may think you see patterns of behavior and obvious disfunction. Naturally enough, not being part of the system often gives us a fresh perspective from which to see problems within a team. Often I have found myself able to rattle off a list of issues that I see a team dealing with after observing them for only a few minutes. Some patterns of team disfunction are suspiciously easy to detect. But wait, here comes the trap. So you make a list, maybe write up a few recommendations and share your “gift” with the team. What team wouldn’t appreciate someone kind enough to share a list of all the ways they suck?

Nobody.

It doesn’t matter if you are right (and you probably are at least 50% of the time). Best case, the team thanks you for your honesty. Worst case, they kick you out of their standup and tell you never to come back. In any case, they aren’t very likely to take your suggestions seriously. The thing about impediments is, in order to really own them and take them seriously, they need to be something the team genuinely care about – and most likely they should be the team’s idea. Ownership is important, because often impediments are pretty tough to deal with, so you need to be really committed if you expect to resolve them.

Often, what I think I see are two different lists of impediments: the scrum master, coach or manager’s list, and the team’s list. The scrum master is scratching their head wondering, “How can I get these guys to engage with these impediments?” Meanwhile, the team is thinking, “Do you really want to eliminate an impediment? Fire a scrum master!”

So I guess the lesson here is that often nobody is all that interested in what you think the impediments are. They already know what the impediments are. They’re just waiting for someone to really listen.


Culture Eats Impediments Too

March 3, 2014

hippo

I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.

Some signs you may have a problem introducing a change:

  • Taking action requires getting permission (this is straight from Pawel)
  • Action can’t be taken because projects are too important to risk
  • Only certain people can take action

I have a great example of this happening recently: The group I was with raised an impediment. I had a nifty new impediment display that I wanted to try out (impediments displayed on a big monitor that everyone in the company could see). I sat down to add the impediment to the list, and then I had to pause…because the impediment called out something that might upset some folks. It might REALLY upset some people. I ended up not displaying that impediment. Why not? Was I just a chump? Was I too scared to make an impediment visible? Maybe…

Or perhaps I understood the culture well enough to know that certain things were acceptable to display as impediments, and others weren’t. That’s just the way it works at some places.

The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.

 


Impediment Spotting

April 8, 2013

wolf in sheeps clothing

So there I was in a meeting the other day (saving the world…yawn). Everything was going smoothly (too smoothly) so I did a quick spot check for impediments. You know, “Hey folks, before we wrap things up, are there any blockers we should be aware of?” There was the usual pregnant pause and then:

  • “The teams aren’t talking to each other. I think we should have a wiki page to share what we are doing.”
  • “We need a common defect tracking system. I have to look in too many places to find bugs.”
  • “We don’t do test driven development.”
  • “Bob’s not helping.”

Oh brother…Me and my big mouth. Where to start? One of the first things that I often encounter when soliciting impediments is the dreaded vague problem statement. Some aren’t even impediments at all. They’re just statements of opinion. Let’s take the TDD one as an example:

“We don’t do test driven development.”

Really? No kidding? That’s too bad. Why should I care? Seriously, I know TDD is supposed to be good for you (like motherhood and apple pie), but why should I care if we are doing TDD or not? Why is not doing TDD a problem? Do the teams do any unit testing? Do they have a high defect rate? Is there a lot of staff turnover? Now where did I leave my tiny little violin?

Let’s pretend for the moment that the problem gets a little further refinement:

“We can’t quickly validate our code and spend hours in debugging. We should do test driven development.”

Ah, I see…that’s a little better. Now I think I understand your problem. You’ve even gone so far as to offer a solution (how thoughtful). In fact, what we’ve done is mix up the problem statement and the solution. Ugh! In one fell swoop we have managed to describe the problem and eliminate a whole world of potential solutions from consideration. Brilliant! How about we just limit ourselves to the problem for now, shall we?

“We can’t quickly validate our code and spend hours in debugging.”

Now THIS is a problem statement (OK…impediment) I can work with. I know who is affected. I know what they are doing, I know why it’s a problem. I know where they end up. There’s a lot of information here. So now that we have a decent statement of our impediment, what do we do about it?

Well, you have a couple of options:

  1. Do some root cause analysis (dig into that impediment and find out what’s going on)
  2. Skip the root cause analysis, because you already know the answer. (No, I’m serious, why screw around? When you know, you know – you know?)

From there we brainstorm a few potential solutions and then we are off to the PDCA races!

You can get all of this from a crappy problem statement. Well, actually you can’t. That’s why you need to take the time to refine the problem statement. Notice that I didn’t just throw out the impediment in disgust in the very beginning. Sometimes an impediment is a clue and we end up the detectives.

Happy sleuthing!


Announcing: The Little Book of Impediments

March 4, 2013

Impediments have long been a topic that is near and dear to my heart. I’ve just published the first draft of a book dedicated to managing impediments on Leanpub. It’s an idea that I’ve been thinking about for years and finally decided to execute on. The book is a collection of many of my ideas on dealing with impediments from this blog, as well as from presentations and tutuorials that I have done at many conferences. There is still a long way to go, but if you are interested, you can get an advance copy from Leanpub (https://leanpub.com/ImpedimentsBook). You can also provide comments and get updates on twitter using the hashtag #impedimentsbook