Hansei and Kaizen in the Second Quadrant

Last Friday night, Ben, Pete and I were having drinks, and Ben mused that we needed to do a better job of training for our software applications. “Perhaps better training videos are the solution,” he mused, sipping from his coke. Ben was demonstrating Hansei. He often does this when we are out drinking, much to the annoyance of Pete and I, who were just trying to enjoy each other’s company and drink.

Addicted to the First Quadrant

I thought deeply about Ben’s statement. Often – too often, I believe – we operate in a hurry-up, get-it-done, meet-the-deadline, schedule-driven environment and don’t allocate enough time to do the things that might actually prevent us from have to spend time in that environment in the first place. Don’t get me wrong; it’s an addictive, adrenaline and caffeine fueled world, filled with excitement, and at the end of the day it leaves you feeling like you got a lot done. But all too often, getting caught up in the rush of fast-paced delivery leads to an environment of poor quality software, unhappy customers, broken relationships and a myriad of other problems that stem from poor planning, lost opportunities and lack of preventative measures. What can be done? What do these Japanese words mean anyway, and what is Dave getting at with quadrants?

The 14th Principle

Hansei is a Japanese word which means “relentless reflection.” It is a central idea in Japanese culture, and it is about acknowledging one’s own faults and always trying to correct them. Kaizen means “continuous improvement,” and practiced together they help to build a learning organization. This is the 14th of as many principles of management practiced at Toyota. We practice a little hansei and kaizen already in our software development today. We have a sprint retrospective where examine how we can improve our processes, and we have a built-in improvement step in the inspection process as well. I have seen this at work in the few months since it has been installed. All of the teams have already been getting incrementally better at estimating and scheduling their work, and measurably improving their quality. I want to acknowledge that improvement that the teams have made here. It’s good, but there is still a lot of room for progress.

The Second Quadrant

Stephen Covey, one of my favorite authors, classifies tasks in four quadrants:


The first quadrant contains those that are both urgent and important. Fighting fires and crisis management are examples of first quadrant activities. The second quadrant contains tasks that are important, but not urgent: planning and relationship building are examples of quadrant two activities. How much of your day is spent in these two quadrants? Do you balance them appropriately? (If you’re spending any time at all in quadrants three or four, you’re probably wasting your time).

One of the problems with operating in the first quadrant is that it’s addicting. It’s very satisfying to go to work day after day and solve a seemingly endless wave of problems. You look like an aggressive problem solver; someone willing to take on difficult situations and get the job done; a “can-do” person. Unfortunately, it is not the best way to deal with the situation, as it usually leads to the same thing happening over and over again (well, at least you have some job security). A better approach is to find and eliminate the root cause. This will drive first quadrant activities into the second quadrant, and bring some sanity to the workplace.

Fix it Once

Kiichiro Toyoda said that every defect is a treasure – but only if the root cause of the defect can be found and corrected across the company so that it does not occur again. The Toyota Company empowers every employee to completely shut the production line down when a defect is found in order to discover the root cause of the defect and prevent it from re-occurring. This is a very powerful paradigm, and in part has led to the highest quality automobiles in the world. Do you feel that way? When you see a problem, do you feel empowered to stop what you’re doing and make the changes necessary so that the problem never happens again? Why not? Wouldn’t that be adding real value to the company? Sun Tzu’s wit is not lost on us when he said, “When trouble is solved before it forms, who calls that clever?” Yet the best employees are those that do exactly that.

It will be interesting to observe Ben as he practices hansei and kaizen in the second quadrant and solves the training issue. I suggested he work with Dave Skender and work to install these pieces as potential deliverables within the MedAssurant Agile Process. These Work Products will need Owners, will belong to a Discipline, and be assigned to a phase of the Process.

More to the point, it will be interesting to watch each and every one on the team as you practice hansei and kaizen in the second quadrant and solve problems before they turn into fires. Franklin was right when he said “an ounce of prevention is worth a pound of cure.” We must, each and every one of us, practice hansei and kaizen in the time that we have, in the place that we are. That, or inevitably be consumed by the unquenchable fire of the first quadrant.

Why Traditional Software Planning Fails

Mike Cohn, founding member of the Agile Alliance, eloquently describes the main reasons that software projects have failed (Cohn, 2006). Here are a few of the main ones:

Lateness is passed down the schedule – traditional software planning processes focus on the dependencies between activities. As a result, best case is that everything finishes on time, but because of dependencies, a slip in any one activity is sure to cause a slip in the entire schedule. What is worse, such slippages are not simply additive. Lateness on one task may ripple over to many other dependent tasks, making all of them late, multiplying the lateness by a factor of the number of dependencies in the system.

We ignore uncertainty – traditional software planning fails because it assumes initial requirements can lead to a perfect and complete specification, and that all unknowns can become knowable at the start of a project. It fails to take into account that customers may change their minds, come up with new requirements, or change requirements during the course of a project. The old school assumes that manufacturing methods can be applied to software development; but studies by the Standish Group (1995, 1998) and others conclusively show these methods don’t work, no matter how rigorously they are applied. Usually we are implementing a new idea or design, which has unknowns and risks, but we need to achieve exacting quality. It’s common sense: we don’t have perfect information, so expecting the perfect estimate or the perfect schedule is silly (I am quoting Eric Brechner, author of “Hard Code,” and Development Manager of Microsoft Office). It is an ill plan that cannot be changed.

Estimations become commitments – when we give an estimate for the completion of any task, implicit in that estimate is a probability of completing that estimate in that time. Armour (2002) points out that every estimate is a probability; but you cannot make commitments to probabilities. You make commitments to dates. Before making a commitment to a date, software teams must be given the chance to use solid estimation techniques such as wide band Delphi estimation to uncover assumptions and risks associated with a project, and develop risk management plans to define how the teams will handle change when (not if) it occurs in their projects (PMI, 2004). These risk management plans must be approved by senior management; otherwise teams are just signing up for failure.

Plans and Planning

Planning is a critical step in any undertaking. We want the problem to be understood as well as conditions allow, and to uncover as many assumptions as early as possible. Why do estimates often fail us for engineering projects, particularly software development? They fail because software engineering is a design activity, not a manufacturing one. There is a common sense understanding of the difference between plans and planning:

A good plan, violently executed now, is better than a perfect plan next week. - Patton
In preparing for battle I have always found that plans are useless, but planning is indispensable. – Eisenhower

No battle plan survives contact with the enemy – Colin Powell

Did you notice the quotes above are from military men? Software teams are equally at war, but it is a mistake to think they are at war with customers, the operational staff, or executive management. They’re not. They (and the customers, operational staff and executive management) are together at war with uncertainty. Agile project planning is all about recognizing that uncertainty exists, minimizing that uncertainty as much as possible, and installing tools and processes that manage that uncertainty and risk within the framework of the business goals and objectives.

Doing it better

In environments that change very slowly, traditional project management methods focus on a full understanding of the product through careful analysis and planning. Before any significant investment is made, the uncertainty is therefore reduced to a level where risk can be comfortably managed.

However, when business and technical requirements change rapidly, often because the business is continually redefined, this full understanding is impossible to achieve. Planning is critical, yet we must be cautious about what we do with the results of our planning phase, and be careful not to fall into the trap of believing we can have perfect estimation and perfect scheduling at the beginning of a project. There will always be a lot of variability in project scope at the beginning of a project, and there will always be change throughout the life cycle of the product. Turing award winners Barry Boehm, Kristen Nygaard, Ole-Johan Dahl, and Peter Naur have all espoused and developed these agile development ideas. We ignore their research at our peril.

Software is not a unique industry in having high uncertainty at the beginning; what other industries do is constantly reiterate and re-plan. They don’t make a big up-front plan and treat it as inviolate. Estimation is a tough but important problem, and we need to be thoughtful about doing it better, as long as we don’t confuse valuable planning with a rigid and brittle plan, or estimates with commitments.

Armour, Phillip. (2002). Ten Unmyths of Project Estimation. Communications of the ACM 45, no. 11155-18.

Brechner, Eric. (2008). Hard Code. Redmond: Microsoft Press.

Cohn, Mike. (2006). Agile Estimating and Planning. Upper Saddle River, NJ: Pearson Education, Inc.

PMI. (2004). A Guide to the Project Management Body of Knowledge, 3rd Ed. Newtown Square: Project Management Institute.

Standish Group International. (1994). The Chaos Report. The Standish Group.

Flexing Iron Triangles

Any Project Manager will be able to quote to you the three vertices of the famous “iron triangle” of project management: Scope, Resources, and Schedule. Every project is a combination of these three elements:

• Scope: What we’re going to do
• Resources: How much money we have to spend to get it done
• Schedule: How much time we have to get it done

I’ve had managers who jokingly said that they want everything yesterday for free. Usually when a manager says this, or a variation of this, they are usually really asking me for options on scope, on resources, or about the schedule. Sometimes these are variable and sometimes they’re not. I need to ask the manager precision questions around the business need for the deliverable to get the right answers and move the levers of the triangle appropriately. What features do you really need? Who is the customer? What is the venue? Who is the presenter? When is the presentation? How many will be present? Sometimes you can narrow the use cases down to a scope that can be accomplished in a given timeframe in this way. When managers become intransigent around these questions, that’s usually a sign you have a bad manager, or you aren’t asking the questions very well.

The idea is that you can often fix any two of the vertexes. For example, if you have a fixed set of resources and fixed cost, your schedule is going to vary; or, you can reduce the number of features in a product to get it done in a given timeframe. A key takeaway of the iron triangle is that you cannot fix all three sides. Such a system becomes over-constrained.

In software development organizations, over-constraining the iron triangle is very common. Something, however, must give. When a software development effort is over constrained, the usual result is:
• High bug rates
• Low morale
• Late schedules
• Cut features
• Failure to adopt new technologies
• Low productivity

What gives is obvious: quality. We have metrics already within our own organization to prove this. We have high inspection yields and high bug densities in our software, which indicates if we spent a little extra time checking our work, our quality would dramatically improve. We can correct this by injecting quality processes as standard operating procedures and setting expectations that this will be the way we will work from this point forward. We will be doing inspections. We will be writing unit tests. We will be doing peer reviews. Code will not be checked in until it passes all of the StyleCop and FXcop rules we put in place. Etc., etc. Software development will appear to slow down, but quality will go up. This is about setting expectations and pushing quality upstream. When doing your estimates, remember wide-band delphi estimation is about uncovering assumptions: did you include testing in your assumptions? Stress testing? Performance testing? Inspections? These are things software engineers do. Coders don't.