«    »

How to Always Get Better: A Framework for Continuous Improvement

If you believe like I do that organizations must develop a culture of continuous improvement in order to flourish, then the question is how to achieve this. Throughout my career and especially in the last few years I have promoted effective software development practices and a philosophy of learning and growing as a professional. I came to the realization that trying to impose these ideas onto teams from the outside or from above is difficult, time-consuming, and often ineffective. Having a single superior or external expert be the sole source of ideas and motivation for growth is not scalable nor sustainable – what happens when this person moves on? It is far more effective to have individuals and teams adopt a culture of continuous improvement so that they can learn and grow on their own.

This led me to investigate and research methods of developing and encouraging this kind of culture. I came across a superb book called The Toyota Way by Jeffrey Liker which explains how the concept of continuous improvement (kaizen in Japanese) is one of the core management principles at Toyota that has enabled its sustained success and growth over the decades. While this book and others do a great job of presenting the philosophy of kaizen, they have fewer details on how to specifically implement continuous improvement. I gleaned what guidance and information I could from these books and combined this with my own experiences in promoting continuous improvement to create a framework for continuous improvement. This framework provides a concrete model for discussing, implementing, and assessing the practice of continuous improvement within a team or organization.

The Continuous Improvement Framework

Fundamentally continuous improvement is about personal and organizational change to move towards the goal of consistently exceptional performance. We cannot, however, jump directly from our current situation into a better changed state: change is a multi-step process, and the framework explicitly recognizes this. The diagram below illustrates the stages of the framework. These stages are explained in the sections that follow.

Current State

The current state represents the starting point: where we currently are. One of the key motivations behind developing a culture of continuous improvement is the observation that a high performing team that is stagnant and remains stuck in this current state will eventually be surpassed by a team that is continually improving.

Moving beyond the current state requires a clear picture of what the current state truly is. A classic management mistake is to attempt some improvement, usually to address some critical issue-of-the-day, by instituting measures that in the end do not work or have unintended consequences due to a lack of understanding of what is really going on.

Gaining this awareness can be done through a number of approaches whose common theme is adopting a critical, analytical, and investigative mindset:

  • Retrospectives (aka postmortems or lessons learned) after key milestones.
  • Quantitative analysis of metrics based on collecting data such as defect rates.
  • Qualitative analysis of the work based ideally on personal observation or through secondary means like surveys or interviews. The Japanese have an expression that translates "go and see" (genchi genbutsu) which reflects the idea that managers need to go to where the work is actually being done and carefully observe.

Being clear about the current state makes it much easier to identify what needs to be changed. This most frequently involves identifying issues with how things are currently done, which advances us to the next stage in the continuous improvement framework.


The identification of issues - what is currently wrong or suboptimal - is the next step leading towards the end goal of change. Issues arise from a number of sources:

  • Problems with the work being performed. In software development these often manifest as defects or production failures. A key activity for each problem is root cause analysis which involves asking "Why?" five times in order to get to the heart of the issue.
  • Identification of non-value-add activities, referred to as waste (muda) by Toyota. Value-add activities are those that directly contribute to a service or product used by a customer. Anything else is considered waste. There are many different types of waste:
    • Unneeded process steps. For example, an approval process for a change that has the supervisor rubber-stamping the request without really reviewing it.
    • Defects. The work necessary to track, analyze and fix defects is all considered waste as it is preventable. In contrast, activities such as reviews and testing that are performed to ensure the quality of the work before it is passed along are considered value-add, not waste.
    • Waiting. Any kind of waiting is classified as waste. This is even true if you are waiting for a machine to do the work, such as waiting for the code to be compiled or waiting for a document to be printed: the machine might be producing value at that moment of time, but you as the operator are not.
    • Misuse of people. This includes overburdening people (i.e. with too much overtime), not having work for people to do (another form of waiting), or having untapped creativity or productivity - a typical result when morale is poor or insufficient attention is directed towards motivation.
  • Management strategic goals or department targets. When the goal or target is announced, if a team is not in compliance with the goal then this becomes an issue that the team needs to address. A variation on this theme is when management believes that while performance is currently adequate (i.e. no significant problems), it could be better and pushes for improvement.
  • Retrospectives (aka postmortems or lessons learned). Reviewing what has worked well versus what hasn't is a good mechanism for identifying issues.

Identifying and clarifying an issue does have some value, but it is really still a precursor to actual improvement which begins by generating ideas for how to address or avoid the issue. This is the next stage in the continuous improvement framework.


A discussion of issues that does not include generating ideas for dealing with them is really nothing more than a gripe session that provides very limited value. Beyond the basic utilitarian benefit of an idea, coming up with suggestions requires a positive, engaged mindset instead of the largely negative mindset associated with griping about issues. Thinking about how to improve a situation is a key shift towards adopting a mindset of continuous improvement. This is one reason many companies have suggestion boxes for soliciting ideas.

Ideas do not have to be revolutionary nor do they need to involve major shifts or changes. Toyota deliberately encourage the submission of as many ideas as possible, no matter how minor, from all employees. Toyota values this so highly that the metric of average number of ideas submitted per employee per year is one of about ten key metrics that is used to assess the health of an organizational unit. This is because it is key to developing a culture of continuous improvement – a true learning organization: everyone (not just management) needs to be involved with and thinking about how to continuously improve what they do and see.

One technique for generating ideas is to start with an issue, analyze and discuss it to understand it thoroughly, and then brainstorm ideas to address it. Out-of-the-box thinking is important during the brainstorming: you do not always have to directly deal with or fix an issue. Can you prevent it from occurring altogether? Avoid the negative aspects so it becomes irrelevant? Convert it into a positive?

Performing a root cause analysis on an issue is another great source of ideas. The answer to each "Why?" question usually reveals an idea for a countermeasure that can be adopted to prevent the issue from reoccurring.

In the majority of cases ideas arise from issues that people are experiencing. Even when you have a "eureka"-style idea that pops into your head out of thin air or have ideas submitted via a suggestion program that do not appear related to an issue, there is most times an unstated, underlying issue. I recommend in these cases spending the effort to uncover the underlying issue. Doing so allows you to analyze the issue (perhaps via root cause analysis) and brainstorm other options for addressing it.

Despite my last point and what my continuous improvement framework suggests, ideas do not always have to be linked to issues or improvements. There can be ideas for trying something new in order to learn about it or to verify that the current approach being used is indeed better. Product innovation often benefits from ideas about new features unrelated to customer feedback.

Ideas are a necessary factor in achieving continuous improvement, but by themselves they do not produce change. You must take actions to implement an idea in order to initiate actual change, and this is the next step in the continuous improvement framework.


To action an idea requires that you develop an action plan for how you will implement the idea. This plan can be simple or complex depending on the nature of the idea. Small-scale ideas are much easier to put into practice, perhaps as a single activity, whereas revolutionary ideas might require a strategic corporate initiative. This is the advantage of smaller ideas: they can be implemented much faster with much less effort which further reinforces that culture of continuous improvement. Slower or smaller but constant improvement is superior to large, intermittent steps.

Actions plans fall into the following categories:

  • Action Item: When the idea requires a single activity to complete it can be assigned as an action item: the activity is assigned to a particular person to be completed by a particular date. The manager for the team is usually responsible for maintaining a tracking list of action items and following up to ensure they are completed. (This is already alluding to the next stage in the framework.)
  • Project: A project is used when a large number of activities, perhaps done in parallel by multiple resources, are needed to implement the idea and there is a clear end point when all the activities will be finished.
  • Experiment: For an idea with a broad or significant impact it is often beneficial to try out the idea first on a smaller scale to evaluate its effectiveness. I call these experiments. They are also referred to as process trials or pilots. I prefer the term experiment because of the stronger connotation that a negative outcome is not only possible but is acceptable: the organization has still learned something.

    Many organizations have dysfunctional cultures where failure is not acceptable, and as a result managers are often unwilling to alter decisions that prove to be wrong. I have seen it myself where a high level manager makes a decision regarding how to change something and the results prove to be a disaster. This manager admits in private that the decision is a mistake, but is unable (unwilling) to publicly acknowledge this, even implicitly, by changing the decision. In such cultures using experiments to verify ideas provides a way of bypassing this problem. In an organization such as Toyota that fully adopts a culture of continuous improvement such political considerations are not necessary, but experiments are still valuable in vetting ideas before they are more broadly rolled out.

    The key point of any experiment is the evaluation: how you will verify that the idea is effective and achieves the desired results. This typically requires that you implement the idea and monitor the results over a period of time before being able to reach a conclusion. For more information see my article Continuous Improvement Experiments.

Taking action – implementing your action plan – is the start of actual change, but more is needed. You need to follow-up to ensure that the change persists, and this is addressed by the next stage of the continuous improvement framework.


Follow-up ensures your actions are being executed and are effective. There are three important categories:

  1. Evaluate: Has improvement happened? Were the expected benefits of the action taken achieved? Were the planned actions actually performed? Was the original idea implemented as intended? Was the underlying issue resolved? Actions frequently have unanticipated and unintended consequences that must be dealt with. In some cases such consequences mean that the original idea is unworkable and must be scrapped or significantly altered. This is a normal part of the continuous improvement process and should not be penalized as failure. Sometimes adjustments or tweaks to the action plan can be made as part of the follow-up phase. In other cases issues found during follow-up initiate a new improvement cycle of new ideas, actions, and follow-up.
  2. Standardize: Once the actions have proven effective, the improvement needs to become permanent, which I define as becoming the officially approved approach that is the normal practice throughout the organization. This is especially necessary if the idea was initially put into action as an experiment. Toyota achieves this by carefully defining standard work processes and policies and updating these standards whenever a better approach is found via continuous improvement.

    The culture in North America, especially in I.T., is generally less enthusiastic about standardization of work (although this will depend in part on your mindset towards rules. While there are a number of factors influencing this, one worth discussing is due to how standards are created and evolved. Too often work standards are imposed from above with limited discussion or training (if any), poorly understood and followed by the actual workers, and difficult or impossible to revise, especially by the workers who are supposed to comply with the standard. Given this, is it any surprise that workers have a negative attitude towards standards?

    Standards may seem to lie in opposition to continuous improvement. You may ask how you can continue to improve a process that has been standardized. Such a question reflects a particular mindset about standards – that they cannot or need not change – which is incompatible with continuous improvement. A different mindset is needed to successfully integrate the two: a standard represents the best but never perfect way we know now - today - of doing an activity. Because a standard is based on our knowledge and understanding which grows over time, the standard should be continuously improved as we identify better ways of doing the activity in the future.

    Toyota considers standardization a key aspect of continuous improvement for several reasons:

    • Standards support the development of a learning organization by providing a basis for propagating knowledge of improvements via training. This assumes you do effective training. After reading the book Toyota Talent that explains how Toyota approaches training and development of its employees, I suspect that most companies are ineffective in their training.
    • Standards provide a baseline for future improvements. If standards do not exist or are not followed, the process being performed will be ad-hoc and chaotic with a high degree of variance. This makes it very difficult to assess what needs to be improved, especially in terms of general trends.
    • Standards help sustain improvements by providing a basis for evaluating whether the improvement is being used in practice.

    Two keys to making standardization work are first to have those doing the work write the process and second to keep the process simple and practical so it is actually followed.

  3. Sustain: Once a change has been evaluated and standardized the last phase of following-up is to ensure that the improvement becomes permanent rather than being a temporary change that eventually fades away. Psychology research has found that 85% of people trying to change will relapse back to past behaviors. So you need to explicitly take steps to ensure a change is sustained.

    The basic approach to sustaining an improvement is do an ongoing assessment of the state of the change by observing whether the standard is being followed correctly. When a deviation is discovered corrective measures should be taken - the most appropriate usually being additional education or training on what the standard is and how to follow it.

    This assessment is more commonly referred to as "auditing", which is a term I am not fond of. Too often the audits I have observed have involved auditors external to the team (usually from quality assurance) only assess the paper trail of what has been done rather than evaluate the actual work or the work products. Usually such an audit merely motivates people to produce the documentation required to pass the audit without actually linking it to the work being done. To be effective, assessments should be done by those knowledgeable about the work and the standard. In Toyota it is the responsibility of management (at all levels) to regularly audit the activities of those under them. Scheduled, random audits are a preferred mechanism for achieving this: once a week select a random person to observe and assess their work.

    One key point is that these assessments are ongoing – the need for them never really goes away. The frequency of assessment may decrease over time as adoption improves, but employee changes (transfers, turnover) and continuous improvement of the standards means that sustaining is an ongoing responsibility.

With proper follow-up an improvement becomes part of the normal job routine. This leads to a new current state and the start of the next cycle of continuous improvement.


The continuous improvement framework presented here provides a concrete model for discussing, implementing, and assessing the practice of continuous improvement within a team or organization. This article only provided a basic introduction to the framework and is almost too long as it is. A discussion of the practical application of the framework and examples of it being applied will have to be deferred to future articles.

If you find this article helpful, please make a donation.

«    »