Use Lean Development Principles to Avoid “Traveling Hopefully” Down the Wrong Path

The team was rightly proud of their work in creating an obeya space to manage their project, and their excitement was evident in their faces as we gathered around their schedule wall. But just as obvious were the unpleasant “surprises” that awaited them during the course of their project. I could see those nasty surprises lurking in the long gaps that appeared intermittently in the swim lanes of their schedule and in their “plans” to deliver critical product attributes.

I could see it because it was an error I had seen before and, in fact, had committed myself in the past. It happens when teams insert long periods of “standard” or “block” timing that often consists only of a starting point and an ending date with little understanding of what happens in between. Development examples include drawing release, tool creation, and test completion, but there are many others.

The next time you see schedule voids where monsters might be lurking, ask the team about the work that is being done there. For example, the obeya will typically have a sticky note placed for drawing start and then a single sticky placed 10 weeks later, indicating the date when 200 drawings must be completed and released into the system. Or worse, a sticky showing when tool start will be authorized and little else until 20 weeks later when all the suppliers should have shipped their tools. These huge information gaps can allow a team to get into serious trouble before they are even aware of an issue.  My old boss, John Fleming, the former EVP of Global Manufacturing at Ford, used to call this “traveling hopefully,” and it was never a pleasant journey.

It’s like sailing in a race from Boston to Miami, knowing only your final destination and that the average time is around two weeks. Then calling your sponsors from a bar in Norfolk a couple of weeks later to tell them you are working on a recovery plan. At that point, who cares?

While it’s true that the best sailors know they can’t control the ocean (a mistake conventional developers often make), neither are they willing to trust their fate to the winds and waves. So instead, they continually sharpen their navigation skills, work to deeply understand their route and where they are to that plan at any given time, and employ the best tools possible to increase their chances for success.

In the same way, lean development is less about creating highly detailed plans based on things you can’t possibly know at the beginning of a development program (like conventional development attempts to do). Instead, it’s more about developing an in-depth and shared understanding of the work to be done and increasing fidelity as you close knowledge gaps over time. That means you must start with the actual work you need to do to build a better development plan. This work includes the tasks, the sequence of tasks, and the interdependencies across functions so that the team can recognize looming issues and act in time to stay on course. In lean terms, the team can see an abnormal condition, pull the andon to signal for help and employ effective countermeasures in a timely manner.

Start with the actual work you need to do to build a better development plan.

Jim Morgan

Foundational to this capability are effective milestones with clear purpose statements and quality of event criteria to measure against and guide the team on their journey. And in fact, they often require more than milestones.  Because milestones often serve as key integration points, early indicators should be placed in between milestones to protect the integrity of those points and not affect other “swim lanes.” In addition, these indicators should be reliable predictors of milestone success. Even if you meet in daily stand-ups, if you don’t recognize an abnormal condition, you may overreact to minor things and not even see a major storm on the horizon. Too many stand-up discussions are vague and conversational and will do little to head off problems without these fundamentals.

You can see another example of “hopeful traveling” in how some program teams approach the delivery of critical product attributes. Teams often set attribute objectives and then act as if characteristics like weight, speed, cost, or others will evolve “naturally” out of the development work, only to find out at the end of the project that they have come up short. Achieving such attribute goals requires closing knowledge gaps during the project. Creating a simple glide path that outlines expected progress from the starting point to the ultimate objective based on specific activities designed to close those gaps throughout the program creates a visual tool that can help determine abnormal conditions when the team is off the glide path. Setting up a percent of objective expectations tied to these activities is one effective way to create such a glide path.

So the next time you see schedule voids where monsters might be lurking, ask the team about the work that is being done there. Filling in these black holes can be challenging. After all, you are creating new value, and much of the work has not been done before. There are so many unknowns. That’s okay. Challenge your team. What do they know? Do they understand the tasks in their order or which tasks might be dependent on others? In other words, do they truly understand the work they need to do? If they don’t, you may have a much bigger problem than creating good schedules.