The Corn Maze Strategy

October 10, 2016


Today was our annual family visit to the pumpkin patch. We go to a local farm that is a sort of pumpkin theme park. In addition to the fields of U-pick pumpkins, they have a petting zoo, pumpkin launchers, halloween themed play structures, hay rides, and a corn maze. It was a beautiful early October afternoon, and the kids roamed through all the usual activities. Finally we got around to the corn maze.

Now you should know that as these things go, this corn maze is pretty decent. I have no idea how large it really is, but my fitbit tells me that it’s at least a few thousand steps or so. I would guess it’s a walk of a mile or two to get through it. You should also understand that it’s relatively robustly built. You really can’t see any nearby landmarks, and the paths are kept far enough apart that you can’t see other adventurers in the maze. So it’s really quite easy to get good and lost.

So I followed the family in and tagged along behind as we made our way through the maze. I was tired, so I was perfectly happy to let the kids make all the decisions and accept the consequences. The pattern usually went something like this: We would come to an intersection and pause. We would look for clues on the ground. Was one path better travelled than another? Did the curve of the path look like it might actually form a loop? Did the path head in a direction that we thought might be the correct destination? We would ponder these questions and consult as a family before moving onward. So some sort of consensus was arrived at as we reached each intersection.

As I stumbled through the maze following my family, lost in my own thoughts, I started to observe how we were making decisions as a team. At each intersection there was usually some sort of debate. Arguments were made for and against different options. The group would informally arrive at a decision. We had the advantage of multiple brains rather than just one, so you would expect some sort of multiplier effect from using those additional noggins. But it really didn’t feel that way.

Instead we were bouncing around the maze, wandering into loops and blind alleys, and as far as I could perceive, we were not much more successful than someone walking the maze and flipping a coin to decide which direction to go. It was quickly becoming apparent that our success rate was hard to discern from a completely random performance. In fact, at some point I joked that we should be using a 20 sided dice to determine our next move. Geek family.

As we came around a bend I saw another family just standing at an intersection expectantly looking down the path like they were waiting for something. The father came running into view from further down the path and I heard him say rather breathlessly, “There’s nothing down that way guys.” We moved on and I couldn’t help but wonder about that approach. That family was using an interesting strategy. They were obviously making an effort to collect some information about the maze before moving on. That seemed to be one level of effectiveness beyond what we were doing. They were trying to look ahead and gather some intelligence that they could use to help make a better decision about the direction to go in the maze.

We continued to ramble about, but it was soon apparent that the kids were starting to get tired. My wife indicated that it was time for us to bring the adventure to a close before we had a riot on our hands. Dad, stop being such a slacker, it’s time for you to make a few decisions! So that’s when I had an idea.

At the next intersection, I sent a child down each avenue with the instruction to continue until they come to another split in the path and then to report back to me. Off they went. I figured I had two children, so I could afford to lose one with this experiment and still call myself a parent.

At the first junction, the kids came back and one reported a dead end, and the other reported yet another junction. Well that made the decision easy, so off we went. At the next junction however, both kids reported the same thing – there was another junction, but no indication beyond that. So it appears that my look ahead strategy had it’s limitations. There was only so far we could see ahead in the maze using my one intersection strategy. So we flipped a coin and moved on.

At the next intersection, we had a choice between an intersection and an obvious milestone, so we continued toward the milestone. A few more choices like that and we found the end of the maze.

As we celebrated and headed back to the car, it occurred to me that wandering through a corn maze is not all that different from the way that we work on projects as teams.
A project has a lot in common with a corn maze. In principle we all know how they work, but the path from start to finish isn’t all that clear when you start (oh you may THINK it is clear, but let’s face it, there are a lot of unknowns). So you kick off your project and get started and before too long you have to make some decisions. All too often when we make decisions as teams, we do it on the spur of the moment, using only the information that is immediately in front of us. Just like me and the family in the corn maze. We are only using the information that is immediately at hand. Decisions are made quickly with a minimum of information. It’s little better than a coin toss. But there is an alternative.

We can be gathering information to help us make better decisions. There are various names for this kind of look ahead strategy, personally I’m thinking of “set based decision making.“ In set based decision making you explore multiple alternatives. You look down multiple paths, but you don’t go too far. You are gathering just enough information to help you make a good decision now before you proceed onward. Just like with the kids running forward reconnaissance in the maze. This is how you improve the information you use for decision making, and this is how you give yourself a chance to make better decisions.

You see, projects have many important decisions to be made. You bump into them daily. Go the right direction and you are increasing your project’s likelihood of success, go the wrong direction and the project is that much closer to failure. These are high stakes decisions with lots of money on the line. So using the corn maze escape strategy is a good one. A small qualification is probably in order here: The look ahead doesn’t give you a crystal ball or a guarantee of success.

The point is that we all might benefit from using a conscious strategy to acquire knowledge that can inform our decisions. It doesn’t have to be very much additional information in order for there to be a substantial benefit. So the next time you find yourself on a complex project where you have to make tough decisions, remember the corn maze. The strategy you choose can make your journey a whole lot easier.

Killing the Buddha

September 10, 2014



“If you meet the Buddha on the road, kill him!”

This is a popular saying derived from an old Zen koan. When it comes to working with Agile projects I find this saying very appropriate. People who do Agile transformations typically talk about finding the Way (the road) and often speak with almost religious fervor regarding Agile processes.

In fact, Agile is really just one short step away from organized religion. You have daily meetings, attend retrospectives where we examine our patterns of behavior deeply, we worship idols with bizarre names like “Kanban” and “Scrum” and fight (flame) wars over them. We anoint our priests as guardians of that process (yes, I’m talking about you, Scrum Masters), and agonize endlessly over whether we and others are following the right path.

Wow, maybe Agile actually is a religion. That’s pretty scary. I’ve got to go sit down now.

OK, I’m back. What were we talking about? Oh yeah, killing the Buddha. So, given my little digression above, it would be pretty easy to rewrite that old Zen saying like this:

“If you meet an Agile Guru while on your journey (to excellence, improvement, whatever), kill him!”

Now aside from sounding terribly violent, what the heck do I mean by that? It turns out, that having an Agile guru around is pretty limiting when it comes to learning and continuing to grow. Whenever we have a guru like that, what do we do? We defer to his expertise. We wait for him to provide the answer and we stall our own learning journey. Having an Agile guru around can freeze an organization’s development. You end up limited to whatever level the guru is at.


Many organizations have these characters lurking in their midst. Heck, I was one once. I still have a business card with a title of “Thought Leader” emblazoned on it around somewhere. I’m here to tell you it can happen to anybody. One day you are a perfectly decent, self-respecting developer and then WHAM! you become an Agile Coach, or a Thought Leader, or a Lean Sensei, or any number of other wacky guru code names.

You become, THAT guy.

And trust me, you don’t want to be that guy. You know the one, the Agile guy? The guy who simply must render an Agile judgment every time he opens his mouth. The guy who everyone defers to when it comes to do all things Agile. To paraphrase the old Life cereal commercial “Is it Agile? Hey, let’s get Mikey. He’ll judge anything!”

…oh brother, I think I just dated myself straight back to the stone age.

So what do you do when you have an Agile guru? You get rid of him! What if YOU are the Agile guru? Now that’s awkward. Well, your mission is to eliminate that perception. How do you do that?

  1. Keep your mouth shut
  2. Stop telling people what’s Agile (see #1). Use pantomime or something instead.
  3. Bring in, find, unearth or otherwise manufacture someone who has more expertise than you do. Understand that by doing this, you will run the very real risk of learning something. Sorry.
  4. Rinse and repeat until nobody mentions Agile in your presence. Ever.

So if you find yourself or someone you love has become an Agile guru, take heart! There is a cure! The best thing you can do to avoid stifling (and annoying) everyone in your organization trying to get work done is kill the Buddha.

The Fractal Beauty of Process

May 2, 2011

There is something about a well designed process that I find mesmerizing. It really doesn’t matter if it’s XP, Scrum, Lean, or Kanban the end result is the same: for some brief period I find myself seeing the patterns of the process everywhere I look. For example, a few months ago I finished reading yet another book on Lean (Poppendieck’s latest or something like that). There I was in the kitchen washing the dishes after dinner and wondering…

…why I always did the dishes in such large batches?

…and what would happen to our dish throughput if everyone washed their own dishes? Is that one piece flow?

…and would my family understand the benefits that would accrue from such a change? Would an experiment back this up?

…should I use a kanban board to reflect my weekly dishwashing progress?’

And so it goes. Sometimes it’s like a fever. Process Geekitus. I guess for some folks a process has the allure of helping to explain how the world should work. That’s a pretty seductive proposition when you stop and think about it. What’s wrong with being passionate about your work? Nothing! I can think of some great examples:

  1. Personal Kanban
  2. GTD (Getting things Done)
These are examples of processes that people have incorporated into their day to day lives. They’ve managed to take a process that works for groups and make it work for individuals or vice versa. I’ve seen it done both ways and I find it equally compelling. Patterns within patterns. It’s really rather lovely.

Silo Busting Strategy #2: Attend, Befriend, Defend

January 8, 2011

There is a simple slogan that we can use when trying to approach groups in silos: attend, befriend, and defend. The idea works like this:


The first thing that we need to do is make ourselves available to the group as much as we can. We need to show up for the team meetings or events. In lean terms, you might think of it as going to the gemba. You need to be where the action is. This may involve getting yourself invited to meetings, usually the most boring and uninteresting meetings. You take anything you can get. Then you have to be there all the time, religiously. They have to come to believe that you are genuinely interested and part of their process.


Once you have the attendance part down, then it is time to make a few friends. You need to be that smiling face in the room that is ready and willing to help with even the most inconsequential problems. In fact, beginning with the small problems is probably the best way to start. We need to be there to offer help, and then when the offer is accepted, deliver. This is really all about building up trust with the new group. It is just trust with only you, but you have to start somewhere. You do everything you can to build that relationship. Go out for a beer, Invite them to your team meetings, join the softball team. Do whatever it takes.


Finally, it is inevitable that they are facing challenges; this is where you can really make a difference. When the opportunity arises, be there to defend the group. Make sure that you radiate the fact that you trust and support the work the group does. Not only does this serve to cement the trust you are trying to build within the group, but it also informs the rest of the organization that you are working together and share common goals.


Personal Value Stream Mapping

September 3, 2010

As a project manager, a scrum master, a team lead, or even as an agile coach I’ve wondered from time to time about the true value that I bring to a team. You see, to me it is entirely plausible that a team could work just fine without any of the aforementioned roles being present. In fact, I know that there are many teams that are quite successful without a project manager on the team. That goes for scrum masters too. It has always been a difficult question to face with any intellectual honesty.

Recently I picked up Mary and Tom Poppendieck’s latest book, Leading Lean Software Development. She uses frames to illustrate some of the successful and unsuccessful approaches to software development over the last 40 years. She deals rather harshly with what she calls the Project Management Frame. Basically, if you accept their take on modern project management it is wrong-headed on a number of different levels and is the source of a great deal of waste and very little value in the overall business value stream. Speaking as someone who basically operates in this role, it’s a pretty harsh toke. Having spoken with her about it, I get the impression that when she talks about project management, she doesn’t make any distinction between scrum masters, XP coaches, or traditional project managers. They are all separated from the work and using “management” to manipulate or measure the teams with metrics that at best serve no useful purpose and at worst cause a great deal of harm. Now I know there are those who might argue these points vociferously, but Mary and Tom are pretty darn smart, so I think there is some merit in considering their viewpoint seriously.

What value do project managers provide to the business value stream? Please note that I’m using the term project manager very loosely. It includes Scrum Masters and other leaders of that ilk. Well, perhaps the best way to answer that question would be to build your own personal value stream map. Take a recent project and see if you can list all of the activities that you engaged in as part of delivering that project. Line ’em up in chronological order, identify the wait steps and the queues and see what your personal efficiency, from the perspective of the team value stream is. It might look something like this:

  1. Release Planning
  2. Sprint Planning
  3. Daily Standups
  4. Retrospectives
  5. Reviews/Demos
  6. Resolving Impediments
  7. Release Coordination
  8. Change Control
  9. Tracking (taskboard, etc.)

So…if I look at that list, what activities are value adding from the customer’s perspective? Oooh, that might be a pretty short list:

  1. Reviews/Demos
  2. Resolving Impediments
  3. Release Coordination

All the other stuff is just “process” overhead without any intrinsic value. That leaves a pretty darn short list. Facilitating reviews/demos is certainly not much of a unique skill. You can do that without a PM. Easy. How about resolving impediments? Well, that sort of depends on how many you resolve…and even then, resolving impediments is not the exclusive domain of the PM/Scrum Master. Finally, there is only release coordination. Some people do that, others don’t – it depends on the organization. And does release coordination represent value to the customer? Would they pay for it? Maybe…

Perhaps that’s a brutal assessment of the value of a team leader. I tend to be that way. Others may be more forgiving. What it tells me is that, at least in my case, if I’m not eliminating a LOT of impediments, I’m probably not contributing much direct value to the team. They really don’t need me for those other activities. It’s the impediment removing that represents the real value. And you don’t need a PMI certification to remove impediments…or a CSM certification…or a title…


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.