Using Lean Techniques to Improve Your Presentations

I’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

Standard 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

So 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.

How to Fail Without Really Trying

Having been working on software projects now for more than a few years I feel as though I have explored many of the most common (and a few of the not-so-common) ways of failing on a project. The good news is that you can do it with any project. It really doesn’t matter which methodology you choose to use: waterfall, scrum, XP, Kanban – you can fail spectacularly with them all. It’s deceptively easy to do and in fact, in my experience teams do it all the time. According to the people who measure these things, like in the 2004 Standish CHAOS report, we seem to be getting better at failing projects over time. I like to think that somehow, in my own small way, I’ve helped to contribute to those statistics. The good news is that you too can contribute to our long and not-so-distinguished history of software project failures. For those who are just starting out at failing software projects I have a few tips to help you along.

First things first, you have to pick or become part of a project that you really don’t have much passion or interest in. Nothing beats raw, unadulterated apathy to guarantee the failure of a project. There are all sorts of clever ways to justify our presence on projects that we really don’t care much about:

1. It’s a down economy and I’ll do whatever it takes to keep a job. No, really – anything.
2. It’s too hard to do the work required to find something we’re really passionate about that pays the bills
3. Let someone else make the decisions about what we work on. This has the added benefit of enabling us to point the finger of blame for our situation at someone else!
4. Adopt a strategy of learned helplessness. This isn’t as easy as it sounds – it takes literally years of really hard work to completely stifle a person’s initiative and will to fight. But hang in there, I’m here to tell you it can be done. Persistence matters.
5. Join a team of people you really don’t particularly like or admire. If you have trouble with this, try taking on a superior attitude. That way they won’t like you even if you don’t find them particularly offensive.

If you are unfortunate enough to come across a project that perhaps your team does have some interest in, don’t despair – there are some things you can do to fix it so that nobody will want to be a part of the project in short order. First, you need to cultivate a very selfish attitude. Try the following:

1. Just go through the motions. Show up at the daily team meeting and avoid sharing anything of any use to others on the team. Make it all about you. Just like show and tell in first grade. As far as I can tell, this seems to be the natural state of affairs for most standup meetings, so it should be easy to manage.
2. Avoid the elephant in the room. Elephant dodging is truly an art form. I’ve witnessed teams go through contortions similar to dancing the “Limbo dance” in order to avoid tangling with the team pachyderm.
3. When in meetings, be sure that you attend without making any significant contribution or preparation. I find sitting quietly with my arms crossed and occasionally nodding off during a meeting tends to discourage people from inviting me to more meetings – and that’s generally a good thing – for me.
4. If someone solicits your input, give it grudgingly if at all. If people have a hard time getting your contribution, they’ll see it as a rare commodity and value it more highly.
5. Whatever you do, don’t make the classic mistake of getting frustrated and asking more of others – otherwise they’ll start to do it too, and then eventually they might do it to you!
6. Be very quiet. Don’t speak up unless asked, and when that happens, be sure to answer using monosyllables. “No” is always a good start. Even better – just shake your head.
7. Don’t *ever* rock the boat.

Oh, one more thing: I know people are going to need help with some of this, so I want to offer my services as a consultant. If you really want to fail the easy way, give me a call – my services are available for a very high price. In fact the steep price alone may be enough to guarantee project failure. Of course as far as I can tell the competition is pretty fierce these days. There are a lot of people out there who will cheerfully escort you down the well trodden path to failure while taking your money and spouting meaningless managerial advice.

Continuous Improvement & Risk

I witnessed an interesting pattern today while running Boris Gloger’s “The Ball Game” exercise with a team. The basic idea is to iterate a team activity, stopping to make improvements each iteration. The idea is to practice and measure the impact of continuous improvement on team performance of a task. In general, the team did as you might expect: the first iteration things were pretty rough and their performance wasn’t very good. In subsequent iterations, their performance continued to steadily improve until they were nearly perfect at peforming the task.

Here is what I think I saw happening: with each iteration the group became more stable. They eliminated variation until they reached a plateau in their performance. They found stability, but they also reached a plateau where they were not making significant additional gains with each iteration. It felt very much like they were playing it safe. They didn’t want to do anyting to risk their “score” each iteration of the game.

Now I knew something that they didn’t – as facilitator I knew about other rather creative ways of configuring the group that would have given them a quantum leap in performance. There was an opportunity to take a chance and rethink the problem and make some stunning gains in performance – but at a very real risk to their short term performance. What I saw was a group that was tweaking the small stuff and missing the opportunity to change the big things that would make dramatic differences performance. It felt like there were competing pressures that were impeding the teams ability to see opportunities for performance improvements. Now of course this was just an exercise, so there really was no risk if they didn’t perform well – so any pressure they were putting on themselves was basically self imposed. And that may have been enough to blind them from seeing the opportunity for greater change.

How often do we do this on our own teams? We make improvements that fine tune the status-quo until it feels reasonably stable – and then we stop. I know it happens to me. Add a little pressure from management, and I very quickly can’t discern the forest from the trees any longer. There may be opportunities for change that offer dramatic improvements, but I will very likely not even consider them if it means potentially risking my team’s established performance.

I think this is all the more reason to focus on making the team feel “safe”. As managers we sometimes need to protect our teams external pressures so that they can keep relaxed and flexible – open minded enough to see all the possible alternatives.

Or I could be nuts. You decide.

Learning Games

What’s up with the cupcakes? So there was this wacky little session at Agile Roots 2009 that I really enjoyed that was put on by Chris Sims. It was called “Agile Learning Games”. It was one of those sessions where everyone gets to try out the games as a participant and get a feel for the kind of learning that takes place. I loved the games that he chose to demonstrate, and he was kind enough to provide some references for places that you could look for more learning games – one of which was called, “TastyCupcakes.com”.

I think these learning games are very useful because they allow teams/groups to experience or play with an idea rather than having it preached to them by some sort of expert. I find that I learn things much better when I can participate in a hands on fashion. So as a facilitator and coach, I find these kinds of exercises to be especially powerful when working with teams.

These games can form an important part of any facilitator’s toolkit. I’ve been collecting a list of sites that catalog these learning games for a little while. Here are some references that you might find useful:

http://blog.tastycupcakes.com/

http://uoleadership.uoregon.edu/exercises/energizers

http://www.businessballs.com/teambuildinggames.htm#leadership%20management%20exercise%20for%20teams

http://www.squarewheels.com/scottswriting/mission.html

http://www.nasaga.org/

http://industriallogic.com/games/

http://www.funandgames.org/Games_icebreakers.html#2TruthsAndLie

http://www.isnare.com/?aid=193973&ca=Business+Management

The tastycupcakes site has games that are most relevant to Agile Development, so I would start there first. This list is by no means comprehensive, but if you are looking for some games that might help you get an idea across, this list should get you started.

Understanding “There Is Only Us”

This was a panel discussion with some remarkable names in the agile community including Alastair Cockburn, Brian Marick, Diana Larson, Israel Gat, Polyanna Pixton, and a few others. Much of the discussion was about the role of trust on Agile teams. This topic resonates for me because I have recently started to look for trust issues on teams *before* I look for whether or not they have adopted agile practices. Without trust, the rest is hard to do. When there is an issue with trust on a team everything slows down. It creates a kind of social friction that makes even the simplest tasks more difficult. Team members who don’t trust each other will argue more, revisit old disputes, avoid supporting each other, and even go out of their way to undermine each other. Simple issues that should be resolved by the team end up getting blown out of proportion and escalated to management on a regular basis.

The amount of distraction and friction that is created can be really quite stunning. I don’t profess to have any superior insight into trust and team dynamics – I suffer the same disfunctions here as anyone else. But when I find a team that at a fundamental level is having obvious trust issues, then I know that as a Scrum Master or Coach, I’m in for a rough ride. Nor do I have any particular insight into how to solve the problem. I know that making the team do trust falls probably isn’t going to resolve anything. If I’m honest, I’ve failed as often as I’ve succeeded when it comes to dealing with trust issues on teams.

There are few things that I need to remind myself of when in a situation where there is a paucity of trust:

1) This is going to take a long time. Short of firing people, trust issues don’t go away overnight. While sometimes there is merit in removing someone from the team, for the sake of this discussion I will focus on the more constructive aspects of working with a team to build trust.

2) If you are just starting with the team, you have to become just another member of the team. Often when I start with a team, I often find myself using terminology that separates us. “They” have problems. “I” will fix “them”. Now you might fault my language, but to me language like that simply tells me that I haven’t yet fully integrated with the team. I have to move from refering to “them” to talking about “us”. That takes me a while. I have to live with the team, work with them for a while and basically become part of the team ecosystem. I need to “go native” and stop looking at them like an outsider.

3) You have to be willing to make and admit mistakes – a lot of them. Things will get messy when you are dealing with trust issues. I want the team to see that I’m just as committed, dedicated, messed-up and neurotic as they are. It’s a hell of a lot of work. But if you can open up and be vulnerable in front of the team in some small way, I think you win the trust of the team that much faster.

4) In a very real way, what I’m trying to do is get them to trust me, even if they don’t necessarily trust each other. Part of the game of being a coach is becoming a connector for people. Helping them to find other people who can help them out. If they can come to trust me a little, then I can begin to connect the dots and point them to others on the team who also trust me – a little.

These are the kinds of things that are going through my mind when I’m working with a team that appears to have significant trust issues. I’m looking for connections, seeking ways to hilight my own mistakes, watching my language for symptoms of “me” and “them” and most of all, being very patient. I make no claim to to any sort of stunning insight into these issues. However, I’m a little surprised to see how much I have to say on the topic!

These were the thoughts that were rebounding about my skull as I was listening to the panel talk about the myriad issues surrounding trust on Agile teams. It was a good discussion and I almost wish I could have joined in the conversation they were having. At first I didn’t really understand the title of the discussion, “There Is Only Us” (how weird!), but perhaps now I understand it better. For me, working with a team is best when it is not “me” and “them”, but rather when “There Is Only Us”.

There was an interesting panel discussion on the first day at Agile Roots 2009 that included some remarkable people in the agile community including: Alastair Cockburn, Brian Marick, Diana Larson, Israel Gat, Polyanna Pixton, and a few others who deserve mention but their names escape me. The title of the session was “There Is Only Us”. I thought it was rather peculiar title. Much of the discussion was about the role of trust on Agile teams.

The topic of trust resonates strongly for me because I have recently started to actively look for trust issues on teams *before* I look for whether or not they have adopted agile practices. Without trust, the rest is hard to do. When there is an issue with trust on a team everything slows down. It creates a kind of social friction that makes even the simplest tasks more difficult. Team members who don’t trust each other will argue more, revisit old disputes, avoid supporting each other, and even go out of their way to undermine each other. Simple issues that should be resolved by the team end up getting blown out of proportion and escalated to management on a regular basis.

The amount of distraction and friction that is created can be really quite stunning. I don’t profess to have any superior insight into trust and team dynamics – I suffer the same disfunctions here as anyone else. But when I find a team that at a fundamental level is having obvious trust issues, then I know that as a scrum master or coach I’m in for a rough ride. Nor do I have any particular insight into how to solve the problem. I know that making the team do trust falls probably isn’t going to resolve anything. If I’m honest, I’ve probably failed as often as I’ve succeeded when it comes to dealing with trust issues on teams.

There are few things that I try to remind myself of when in a situation where there is a paucity of trust:

1. This is going to take a long time. Short of firing people, trust issues don’t go away overnight. While sometimes there is merit in removing someone from the team, for the sake of this discussion I will focus on the more constructive aspects of working with a team to build trust.
2. If you are just starting with the team, you have to become just another member of the team. Often when I start with a team, I often find myself using terminology that separates us. “They” have problems. “I” will fix “them”. Now you might fault my language, but to me language like that simply tells me that I haven’t yet fully integrated with the team. I have to move from refering to “them” to talking about “us”. That takes me a while. I have to live with the team, work with them for a while and basically become part of the team ecosystem. I need to “go native” and stop looking at them like an outsider.
3. You have to be willing to make and admit mistakes – a lot of them. Things will get messy when you are dealing with trust issues. I want the team to see that I’m just as committed, dedicated, messed-up and neurotic as they are. It’s a hell of a lot of work. But if you can open up and be vulnerable in front of the team in some small way, I think you win the trust of the team that much faster.
4. In a very real way, what I’m trying to do is get them to trust me, even if they don’t necessarily trust each other. Part of the game of being a coach is becoming a connector for people. Helping them to find other people who can help them out. If they can come to trust me a little, then I can begin to connect the dots and point them to others on the team who also trust me – a little.

These are the kinds of things that are going through my mind when I’m working with a team that appears to have significant trust issues. I’m looking for connections, seeking ways to hilight my own mistakes, watching my language for symptoms of “me” and “them” and most of all, being very patient. While I have no claim to expertise, I’m a little surprised to see how much I have to say on the topic! Funny how that happens.

These were the thoughts that were rebounding about my skull as I was listening to the panel talk about the myriad issues surrounding trust on Agile teams. It was a good discussion and I almost wish I could have joined in the conversation they were having. At first I didn’t really understand the title of the discussion, “There Is Only Us” (how weird!), but perhaps now I understand it better. For me, working with a team is best when it is not “me” and “them”, but rather when “There Is Only Us”.

How I Discovered “Gordon The Guided Missile”

Alastair Cockburn gave the opening keynote speech for the conference. He mentioned that the conference was a product of a local user group called the Salt Lake Agile Round Table. I looked it up and here is where you can find more information if you are interested:

http://alistair.cockburn.us/Salt+lake+city

If you live in Utah, you are very lucky to have a high powered group like this around. You can also find likes to other agile groups in the area as well as their mailing list. There are a whole bunch of them in the Salt Lake area. I’m thinking I may have to create another one here in Seattle just for the fun of it!

Alastair started off with a story called “Gordon The Guided Missile” that was originally told by John Cleese. It is a marvelous tale and you can find it here: http://www.contextmag.com/archives/199806/innerGame.asp?process=print

The point of this funny little yarn is that making many little mistakes is OK. In fact it is necessary in order to make the adjustments necessary to succeed. As Cleese points out, you can’t say, “Well, I got that right, so now I’d better fix it.” It’s ridiculous. Cleese urges us to rediscover a sense of playfulness with our ideas that will allow us to be creative.

Now I don’t consider myself a particularly playful person. I can be downright stodgy at times. But I love creativity. Maybe that’s why I like software development so much. Writing code, what I like to think of as creating “castles in the mind”, requires us to create dazzlingly complex logical structures using only 1’s and 0’s.

So for me it comes down to this: If these ethereal software structures are a product of creativity, and if creativity is a product of playfulness, then we software developers need to get out and play more! And John Cleese, in his own wonderfully silly fashion provides some tips on how we might do this:

1) Admit mistakes freely. In our particular community of development process fanatics, this means that we need to create a safe environment where this can be accomplished. Scrum, XP and other Agile methods have “built in” this support for discovering and admitting mistakes.

2) Fight the tendency to identify with ideas. This is essential for fostering collaboration on a team. When we identify too closely with an idea it becomes harder to share it with others.

3) Create an atmosphere of tolerance of mistakes by becoming a model. Discuss your mistakes. Share them with others. Who knows? Your mistake could be the genesis of the next great idea.

The rest of the keynote was quite good, but  ”Gordon The Guided Missile” was definitely my favorite part!

Alastair Cockburn gave the opening keynote speech for the Agile Roots 2009 conference. He mentioned that the conference was a product of a local user group called the Salt Lake Agile Round Table. I looked it up and here is where you can find more information if you are interested:

http://alistair.cockburn.us/Salt+lake+city

If you live in Utah, you are very lucky to have a high powered group like this around. You can also find links to other agile groups in the area as well as their mailing list. There are a whole bunch of them in the Salt Lake area. I’m thinking I may have to create another one here in Seattle just for the fun of it!

Alastair started off with a story called “Gordon The Guided Missile” that was originally told by John Cleese. It is a marvelous tale and you can find it here:

http://www.contextmag.com/archives/199806/innerGame.asp?process=print

The point of this funny little yarn is that making many little mistakes is OK. In fact it is necessary in order to make the adjustments necessary to succeed. As Cleese points out, you can’t say, “Well, I got that right, so now I’d better fix it.” It’s ridiculous. Cleese urges us to rediscover a sense of playfulness with our ideas that will allow us to be creative.

Now I don’t consider myself a particularly playful person. I can be downright stodgy at times. But I absolutely love creativity. Maybe that’s why I like software development so much. Writing code – what I like to think of as creating “castles in the mind”, requires us to create dazzlingly complex logical structures using only 1’s and 0’s.

So for me it comes down to this: If these ethereal software structures are a product of creativity, and if creativity is a product of playfulness, then we software developers need to get out and play more! And John Cleese, in his own wonderfully silly fashion provides some tips on how we might do this:

1) Admit mistakes freely. In our particular community of development process fanatics, this means that we need to create a safe environment where this can be accomplished. Scrum, XP and other Agile methods have “built in” this support for discovering and admitting mistakes.

2) Fight the tendency to identify with ideas. This is essential for fostering collaboration on a team. When we identify too closely with an idea it becomes harder to share it with others.

3) Create an atmosphere of tolerance of mistakes by becoming a model. Discuss your mistakes. Share them with others. Who knows? Your mistake could be the genesis of the next great idea.

The rest of the keynote was quite good, but  ”Gordon The Guided Missile” was definitely my favorite part!

Day 2 of Agile Roots Conference

I did my “Impediment Hunting” presentation yesterday and had a blast! I’ve put a copy of the presentation up on the Papers/Presentations tab if you want to take a look at it. It’s a big download. I have to say that this conference exceeded my expectations in every way! I’m still digesting it all. A huge “THANK YOU!” to the entire team that put the conference together!

Day 1 of Agile Roots Conference

This conference has an awesome speaker lineup for its relatively small size (~200). It’s really great! Great first day. Lots of notes. I’ll have to take some time to try and synthesize some of it and share. My presentation is tomorrow, so I’d better get my beauty sleep!