LEI Lean Transformation Summit – Day 2

March 6, 2009

lei_logo1_white

 

 

 

Started off the morning kind of groggy – day two is always harder. Had breakfast and an interesting conversation with David Meier (apparently a big name in the Lean world). He worked at the Kentucky Toyota plant for many years and now he is a Lean consultant. He was doing a presentation on implementing Lean in hard times. He was a very nice guy and we seemed to have very complimentary viewpoints. It made digesting the breakfast that much easier…

The morning got started with a session by a guy from Gorton’s seafood (the frozen fish filet guys). It was mainly manufacturing related stuff, but it was still pretty interesting. It was impressive to see how much money his and some of these other companies have invested in making the Lean transition. They must have paid a gazillion dollars in consulting fees. I say that in jest, but it was obvious that they were incredibly dedicated to making Lean work at their companies. It gave one pause when you stopped to think about it. Obviously change doesn’t come easy – that’s no surprise, but it was rather dramatically illustrated here. There was a lot of talk about practices backsliding and having to do a lot of work to make them stick.

Then we had a breakout session presented by Group Health. That presentation was REALLY impressive. They are doing a bewildering number of amazing things there. Just incredible. It was especially interesting to me because I had worked for them as an Agile consultant back when I was at SIQ. It was great to see how far they had come. They even brought along their information radiators (If there is one thing these guys do very well, it’s information radiators). It really was one of the highlights of the conference.

I saw a few new information radiators:

  1. Kamishibai board
  2. Kaizen board

And I still haven’t figured out what they are talking about when they refer to “Water Spiders”…

Then I followed that up with a visit to see the Lean dentist! This guy had used Lean techniques to improve his dental practice. He was all self taught and it was very impressive what he had done. It was another great presentation (so good that I recorded the whole thing with the tiny little video camera that they gave us for the conference). He also gave away a draft copy of a book that another guy was writing about his experience.

The afternoon was finished up with a presentation by Jim Shook. He is one of the big thought leaders behind the LEI. He worked in Japan for Toyota and now of course he is a consultant (see a pattern here yet?). He gave a great presentation – this is a guy who has an incredibly deep understanding of Lean and the history behind it all. It was great to hear him speak (And we got another book on the history of Lean – I got a lot of books out of this conference). After he was done they wrapped up the conference and that was it.

Two days is just about the right length for a conference like this. My brain is full and I need some time to let it all sink in. This conference does a good job of giving you a nice exposure to multiple disciplines attempting to implement lean. I’d recommend it highly. There is also a conference that focuses explicitly on Lean Product Development – it would be much more specific to the kind of work we do (Poppendieck is speaking at that one). I got to know the chairwoman who is running that conference and it sounds really good. Not this time though – perhaps next year.


Managing Impediments

March 4, 2009

 

ruler

 

 

 

 

As many have already pointed out, identifying, tracking, and resolving impediments are some of the most important things you can do for your team. The question that naturally arises is, “How?” In my experience both observing and working with teams, often impediments are jotted down during the daily stand up on a post-it note or listed on a whiteboard. There is nothing wrong with those techniques if the impediments are addressed in a timely fashion. However, if we really have our act together we can do a lot better than these relatively crude techniques. Impediments play an important role throughout the entire scrum process and I think this is under appreciated by many practitioners. 

I would break down impediment management into the following areas: Process, Tracking, Scaling, and Roles. In each case we can explore how impediments are managed and examine how this benefits the team.

In most texts that describe how scrum works impediments are given pretty short shrift. Impements are described as being captured during the daily standup and then they are to be resolved by the scrum master. There really isn’t much additional attention given to the topic: identify the problem and then magically resolve it. End of story. However in practice, impediments play a much more pervasive role in the development lifecycle and they need to be managed accordingly at different stages in the process.

It turns out that impediments have different lifespans. Some impediments are very transitory and are dealt with or resolve themselves very rapidly. Other impediments, especially those that are related to the culture of an organization are much more persistent and can require substancial time and effort to resolve. It would be convenient if impediments were all resolved the same day that they were found – and that is certainly the goal to strive for (as suggested by Jeff Sutherland). However, my experience is that in practice impediments can take some time to resolve, no matter how dedicated the scrum master may be. This is especially the case in organizations that are just adopting Agile.

Process

So given that impediments are in different stages of resolution (and different severities) it makes sense that we track them throughout the scrum sprint cycle. Let’s start in the middle where we are most accustomed to finding impediments – the daily standup.

Every day the team is required to get together for 15 minutes and answer three key questions:

  1. What did you do yesterday?
  2. What are you going to do today?
  3. What is holding you up?

Of course it is the third question that leads us to the impediments. We need to make a note of these impediments as the team does the standup. Then after the standup we can get together with the affected parties and gather more details about the impediment. Hopefully your team will provide you with impediments. The standup is the primary source of new impediments in the process. However this is just the beginning as far as tracking is concerned.

So we go through our sprint, and we get to our review with the product owner. We can demonstrate our small unit of “potentially shippable product” and gather their feedback. However there is an additional opportunity in this meeting to share the impediments that the team overcame in delivering that product (or realistically, in perhaps not delivering that product). Sometimes the team has to jump through some pretty amazing flaming hoops to deliver the product – the product owner might want to know about these things. Why? First, it will help to set their expectations in the future if they understand the kinds of challenges that the team faces. Second, the product owner is an important ally of the team and may be able to help the team out with resolving those impediments. We should take advantage of that potential. Being transparent means sharing all of the struggles that the team encountered in delivering the product.

Next we go into the retrospective as a team and review our own performance over the previous sprint. What went well, what needs improvement, kudos, and so forth. This is an opportunity to review the list of impediments and the progress that the team made in resolving those impediments – I see this as an important measure of the teams ability to overcome challenges. The retrospective is an ideal place to check in on this performance. Are there impediments that are consistently not getting addressed? Why not? What can the team do about it? We can use the lessons learned from the impediments that we encountered in this sprint to modify the way we act in the next sprint.

So we wrap up the sprint and we take the weekend off. We come back on Monday ready and fired up to start a new sprint and we go into the sprint planning meeting. Impediments can play an important role in the planning meeting too. When the team is reviewing the stories in the product backlog, they will find impediments that prevent a story from being worked on in the current sprint (often the impediment is that the story is not well understood yet). These impediments are important for the team to track as well. The other opportunity we have in the planning meeting is to put in place plans for actions that we believe will help us address or avoid impediments in the upcoming sprint. Sometimes simply avoiding impediments is just as important as recording them after they have hit.

So as you can see, impediment tracking really is pervasive throughout all of the scrum lifecycle. There is real value in making sure that impediments are considered along every step of the process, not just the daily standup.


LEI Lean Transformation Summit – Day 1

March 4, 2009

lei_logo1_white

 

 

 

Wow, this has been a pretty cool conference so far. I really wasn’t quite sure what to expect. It all started off innocuously enough at breakfast. I grabbed my ration of melon bits and yogurt and proceeded to the nearest table. As I immersed myself in my morning repast (insert gross slurping noises here) I realized that I was sitting at a table with some folks who were old hands at this lean stuff. Everybody knew each other by name, and fortunately they didn’t seem put off by my early morning feeding behavior (which would put a hog off slop for a week).

So there I was, a heathen in polite company at the LEI Lean Transformation Summit. Note to the unwary: no one other than my wife and children should see me trying to feed myself at 7am in the morning. It ain’t pretty…or particularly sociable. Even so, I found the company quite good, and we had a nice conversation about our respective experiences with implementing lean (maybe I should capitalize the same way I do with Agile: Lean). Anyway, with the exception of the coffee, the morning got off to a good start.

We proceeded to the main ballroom where we got the obligatory remarks from the conference organizers (I can’t remember a single word they said). I was sitting next to a fellow from Wells Fargo – one of a couple of banks that was present for the conference (in rather large numbers – this lean thing seems to be catching on in the banking business). Fortunately the opening remarks were relatively brief and we got on to the experience reports/case studies. There was a great presentation by some guys from Cessna. They had obviously bought into Lean – big time – and they had all of the success, scars, and failure stories to prove it. 

The thing that I enjoyed about the Cessna presentation was that they shared a lot of what worked for them. I saw things that were completely new to me like:

1) A Kaizen Newspaper

2) A Scheduling Wheel

3) A Cross training matrix

4) Stand up meetings held at the beginning and end of each day

5) A “no problem is a problem” mentality

They were doing simply amazing things at Cessna. They freely acknowledged that they were just getting started on the journey (but they made it sound so interesting that I wanted to join). It was obviously an enormous effort on their part and I sure hope it pays off. Did I mention they have been at it for 10 years now?

Throughout the day I met some pretty interesting folks. This conference attracts attendees from a broad spectrum of different industries. You get exposure to a lot of different ways of interpreting Lean ideas. As a result, although I don’t know anything about manufacturing and the details of managing the factory floor – I was exposed to scheduling mechanisms that I had never seen before. These were the kinds of things that were unique enough that I want to try them back home and see if I can reinterpret some of them for software.

The afternoon was a presentation on value stream mapping. However it was value stream mapping with a twist: they focused on gathering the unstated assumptions of the group (come on now, I know you have some). This is almost more of a facilitation technique than it is about VSM. The contention was that capturing the assumptions before VSM would allow you to get the “elephant in the middle of the room” exposed  before you wasted a lot of time on value streaming exercises. Having just finished facilitating a VSM exercise with two groups (with somewhat antagonistic viewpoints) I found this to be an important missing piece in my personal facilitation repetiore.

After that, perhaps the jetlag was starting to kick in, because in my notes the rest of the day was reduced to a series of anecdotes:

1) “We see together, we know together, we act together”

2) “Create a burning platform”

3) Deep learning takes longer than change

4) Continuous improvement != operational excellence

And so on. I’m not saying that the time wasn’t well spent, just that my capacity for absorption may have been seriously diminished. There was a final presentation by some folks from Group Health Coop that was very interesting (especially becuase I had a brief opportunity to work with them a while ago, so I had some previous experience). They are, and continue to have an amazing journey. They are a very impressive group of folks.

After the main shindig was over, there was a reception. I met a lot more folks (I actually had to restock my supply of business cards!) and had a good time in the evening. The food was even good (although I refused to try the oysters…). I can’t wait for day two.


Finding Impediments

March 1, 2009

magnifying_glass_01

 

 

 

I’ve been thinking a lot about impediments lately. OK, maybe obsessing is a better word. I know it’s the word my wife would use. Note to self: do not refer to the kids as impediments…in public.

I was on a trip recently that involved a really long drive from Seattle down to Northern California. That’s rougthly 12 hours of quality time behind the wheel. It gives a guy a lot of time to think. Somewhere around the time that I hit the Columbia Gorge, I started to obsess about what I had forgotten when packing for the trip. You know how it is, you start a mental checklist that goes something like this:

  • Underwear
  • Socks
  • Pants
  • Shirts
  • Shoes
  • Belt
  • etc.

Of course as I was racking my brain to figure out what I had forgotten (I just knew that there had to be something) I was anticipating all that could go wrong on the trip. You know – all of the impediments that could possibly arise to ruin my vacation.

Of course I started to do what I think most of us do at that point. We tell that little voice in our heads to shut up. That insane, paranoid, little perfectionist voice telling us that things are not quite perfect. That’s when it hit me, that little voice was my perfectionist side trying to talk to me – trying to identify the impediments around me! That voice might be useful after all!

Perfection

It was at that moment that I realized that perfection was part of the answer to finding impediments. You have to be sensitive to anything that might go wrong – anything that isn’t completely perfect in every way. It’s those imperfections that are the impediments that you are looking for. Of course that means you have to have some idea of what perfect looks like in your own mind. For example, we probably all have some notion of what the perfect apple looks like. Mine is red and shiny (Granny smith). So when I look at an apple, I’m comparing it to that prototypical perfect apple that I hold in my mind. That’s how I know the blemishes when I see them.

If we didn’t have that notion of the perfect apple, would we care if there was a blemish on our apple? Would we even notice at all?

So it turns out that this perfectionist mindset might be very useful to us in our search for ways to seek out impediments.

Plato’s cave

Of course much of what I have outlined is pretty old stuff. So old that a guy name Plato have a pretty similar idea. Plato described a metaphor for how we perceive things that seems to resonate here. He was talking about people sitting in a cave and watching shadows on the wall projected by actors in the entrance of the cave. Maybe the actors were creating impediments to the light entering the cave. Perhaps the shadows were the imperfect representation of the objects held up by the actors. Needless to say, these reflections on how we perceive the world are certainly nothing new.

Using standards

So much of what I have been talking about is really concerned with having something to compare to. If you don’t have a plan, it’s hard to go wrong. As soon as you put together a plan, you are creating golden opportunities for impediments. If you still don’t see impediments, then add more detail to your plan. Sooner or later you will find the impediments – and size really doesn’t matter.

And what are these plans we are making anyway? They are standards that you use to compare the progress you are making on any given task with where you thought you should be. Just like the perfect apple in your head. Standards can be very useful for helping us to identify things that are impediments. They are a template for comparison with the reality that we are dealing with.

Of course, standards aren’t the end of the game. They have to continously evolve toward the ultimate goal (the one we can’t reach) perfection.

Accountability

Now there was a project a little while ago that I refer to as the “Train Wreck” project. It wasn’t really the end of the world, but at the time it sure seemed like everything that could go wrong did go wrong. It was amazing. Afterwards, I had ample time to reflect on the project and consider how I could avoid such a fiasco in the future. I realized that part of the problem lay in my sphere of influence. Naively speaking, I’m responsible for only a very small portion of the actual product release process. There are many activities both upstream and downstream from me that I have absolutely no control over.

I realized that even if the events within my own sphere of influence were absolutely perfect, the release could still be disrupted by either upstream or downstream events. In essence, there existed a class of impediments that were outside my field of control. If I can’t find impediments in my own small domain, I guarantee you that there are plenty more of them lurking both upstream and downstream of me in the process.

That’s when I started to take a much more active interest in seeing the big picture. I wanted to know more about all of the activities involved in getting a release out. Suddenly I cared passionately about things outside my control – in terms of how I could help others identify impediments to the overall release. This didn’t meant that I was somehow going on a control freak rampage. Not at all. Instead, I was simply broadening my own sphere of influence in order to provide myself with a different perspective – a perspective that enabled me to see more impediments.

Risk

As I’ve been keeping my daily log of impediments, I’ve noticed a strange thing happening. I have the list of today’s impediments – the impediments to the here and now. And then I have all of my historical impediments. Yesterday’s impediments and the day before and so on. And if I look into that history of impediments I start to see some repetition – impediments that come up over and over again. And if I’m really honest with myself, I have to admit that the odds of seeing those impediments again in the future is pretty high. So now we have three separate classes of impediments that we can track:

  1. Impediments to what we are doing right now
  2. Historical impediments
  3. Possible future impediments yet to come

Of course those future impediments have a name in the project management world – risks. I find that very interesting. Using impediments I can actually tie risk management into Scrum. In fact, it’s sort of built right in. So not only are we tracking today’s impediments, but we are also keeping an eye on impediments that may arise in the future (risks).

I’ve had many discussions with people who had questions about how risks were incorporated into agile practices. At the time I didn’t have a good answer. Now I do.