Using Lean Techniques to Improve Your Presentations

August 19, 2009

presentationI’ve found myself applying lean techniques to some of my writing and presentations. Here are a few of the techniques I’ve used:

  1. Splitting large things up into small batches: This one is a beauty. Queue theory tells us that when processing work, lots of small batches are easier to process than a smaller number of large batches. All too often in my writing and in my presentations I tend to unconsciously go into “Large Batch” mode – the document gets larger and larger and I start to lose the tight cohesiveness that you would find in a smaller document. As the presentation or the paper gets larger and larger, I find it increasingly difficult to keep my focus, and it is harder to keep the quality high. So I break my presentations down into separate “modules” – groups of slides with a common theme and work on them in relative isolation (I break out each one as a separate slide deck, then merge them later). The same principle applies to writing. I break the document down into individual paragraphs and treat each one as an independent deliverable.
  2. Applying the “5 Whys”. If you know me, then you know I tend to be the kind of person who is most comfortable talking about the big picture. Often I find it difficult or tiresome to dig down into the myriad supporting details needed to support the argument that I’m trying to make. This is where the “5 whys” come in. I look at the problem I’m trying to solve and ask myself, “Why is that a problem?” Usually one or more underlying issues are at play and they are often revealed by asking this question. But I’m not done, so I repeat the process, you guessed it – 5 times. The idea is to drive down to the root cause of the problem. Using the “5 whys” technique helps me to constructively drill down to the important details that I need to bring to the attention of my audience. It’s also useful for irritating the crap out of people.
  3. Applying 5S. 5S stands for:
    1. Shine – go through your document or your presentation and make sure that it is clean. By clean I mean that not a single excess word is present, every concept is clear, every image is well presented, every paragraph aligned – you get the idea.
    2. Sort – make sure that all of your slides are in the right order. Insure that the concepts flow smoothly from one to another. Everything needs to be in its place.
    3. Standardize – Use a common theme or style that ties the whole thing together. It may be the corporate logo on every page, it may be some document standard (IEEE).
    4. Systematize – Make building this document into a process. It may be something that you iterate over time and time again. Even a simple process will allow you to see opportunities for improvement.
    5. Sustain – Schedule your time for working on the document. Make sure that you regularly take time to improve the process you are using and check your work
So there you have it – a complete system for lean document development!

Standard Work for Personal Improvement

August 16, 2009

checklistStandard work is a notion from the lean manufacturing world that refers to having some sort of pre-defined standard way of doing things for a given activity or process. Actually, in the lean lexicon there is an awful lot related to standard work. Perhaps the most concise definition I’ve seen is this:

“Standardized Work is an agreed upon set of work procedures that establish the best method and sequences for each process. It defines the interaction of people using processes to produce a product. It is centered around human movements, it outlines efficient, safe work methods and helps eliminatemuda/waste.”

– cited from The no-nonsense guide to Standard Work

It can be as simple as simply documenting the work that is already done. It can also be used as part of a continuous improvement effort (you have to have a standard process so that you can measure the impact of changes). In much of the literature that I have read, the typical examples of standard work are taken from processes from the floor of a manufacturing plant. It seems pretty easy to define all the steps in a process when all you are doing is processing widgets. Compare that sort of work to the kind of work that is typically done by your average knowledge worker. Naively, they seem as though the two contexts are worlds apart.

For example a worker in a factory may do the same thing over and over again all day long. On the other hand, a knowledge worker never does the same thing twice – and certainly never the same way. Consider also that a typical factory worker works on a fairly rigid schedule that does not admit to many interruptions. The knowledge worker by comparison is sometimes referred to as “interrupt driven”, often suffering a non-stop stream of interruptions and changes in focus (depending on your situation of course). So how is it that we can apply the same sort of techniques for standard work to the knowledge worker that we would apply to the factory worker?

There was an interesting article over on InfoQ, Lean ‘Standard Work’ Applied to Software Development, that outlined some of the issues in trying to understand what it really means to apply the concept of standard work to knowledge work (or more specifically to software development). A few things become clear from this discussion:

  1. There are different ways or levels of understanding how standard work can be applied to knowledge work. For example: scheduling, task completion, process performance, coding standards, etc.
  2. Some would even assert (I believe incorrectly) that standard work does not exist in Agile software development.

I might even argue that in order to really understand how standard work can be applied to software development we have to take it down to the individual level. The question becomes: Where can each of us find standard work in our everyday lives? Here are some ideas:

  1. The daily schedule – imagine standardizing your daily calendar in outlook. I saw an amazing version of this in a presentation done at the LEI lean conference by the folks at Group Health.
  2. Meeting management – a well run meeting can be run according to a standardized structure. In fact that’s what a lot of management books are all about.
  3. Quality checklists/templates – what are the criteria that we use to assess the quality of the work we have done?
  4. To do lists/chores – what are the things I need to accomplish each day?

As you can see there are an awful lot of opportunities for standardization in a person’s day. Right now I’m playing with these ideas. This standard work stuff seems to border on time management (Stephen Covey, David Allen) as well as with Lean, and other process management methodologies. Exploring this sort of thing, especially at the individual level is a form of self-experimentation that can be very valuable. It can help reveal the principles behind these concepts in ways that our deeply meaningful to us in personal ways. It is through discovering that deeper meaning behind many of these principles that makes each of us better at bringing these concepts to bear in a work context. So I’m going to continue to play with this stuff, and if it interests you I would encourage you to do the same thing. You might find a lot of standard work lurking in your life.


Using Mistakes to Build Team Cohesion

August 3, 2009

trip-and-fall-case-lostSo I’m working with this team and it’s a really daunting situation. There is every reason for things to fail big time. So I play it safe. I work really hard to make sure that I don’t make any mistakes (social, political, you name it). And I feel like I can’t build up any relationship with the team. Nothing. Nada.

So I scratch my head and wonder, “What’s wrong with these people?”

There seems to be this invisible barrier – they accept me because they have to, but they really don’t want me around. Me? I’m going nuts. Every day feels a little bit more aggravating than the next. Nothing seems to get through to them. Finally, there comes a meeting where I totally screw the proverbial pooch. Nothing major, no fights, no cursing, but something I say really pisses off the whole team. And they are mad, really mad.

So I get the team together, I apologize to everyone involved – take full responsibility for being a jerk (pick myself up off the floor, dust myself off) and we move on. Funny thing happens though…the barrier is gone. That’s right, the quality and tenor of the conversation immediately takes a jump toward the positive.

It wasn’t until I tripped and fell that the team started to show some signs of accepting me. It took me three months. Note to self: I’ve got to remember to fall flat on my face faster next time. I think they were waiting for me to show some signs of being human (and not some sort of Agile Superman) before they were willing to accept me on the team.

Or I could be over analyzing the whole thing. Who knows? All I know is that I feel a whole lot better working with that team since then.