Applying the PDCA Cycle in knowledge work
In this article you will find an example of model use for continuous improvements in Kanban by Arne Roock. Want to learn more about continuous improvement in knowledge work? Visit Lean Kanban Central Europe in Vienna, Oct 22-23 www.lean-kanban.eu
“It’s not necessary to change. Survival is not mandatory.” Edwards Deming made this statement more than 30 years ago, but today it is more relevant than ever. Markets are constantly changing; unpredictable events render long-term strategies useless from one day to another; Internet and Smartphones allow the realization of new business ideas over night, thus threatening long-established companies or even entire industries – an excellent example thereof is the Smartphone app “MyTaxi,” which allows people to call taxis without having to contact taxi dispatch.
As a consequence, businesses must change if they want to secure their survival in the long run, but that’s not all: They must learn to improve continuously. “Changes have to become a part of our DNA,” the manager of a big German Internet platform recently told me.
The demand for change is obvious, and hardly anyone is denying it. However, its realization poses an unconvenient insight for teams and for managers: Improvements are difficult to make!
2. Evolutionary Changes
Change initiatives often pursue the following approach: 1) We define our current state, then 2) we define the desired state, followed by 3) the identification of measures that are supposed to take us from the current state to the desired state, and eventually 4) we realize these measures.
Such approaches appear plausible, but in real life they prove to be flawed:
- the desired change is imposed by superiors without consulting and integrating those actually concerned while following the traditional command-and-control approach to management, the creativity of all team members is ignored;
- the planning horizon is projected too far into the future, so that the situation will have changed completely before the scheduled measures have even been touched upon;
- those entrusted with the chosen measures’ execution lack the time to do so, because their regular project work keeps them too busy.
An alternative is Kanban, is relatively young method of evolutionary change management. The evolutionary nature of Kanban manifests itself mostly in two aspects: 1) Changes are made in small steps. 2) In Kanban, we do not focus on the desired state, but on the status quo, while constantly pondering: “What can we do to somewhat improve this state?” Just as species adapt better and better to their specific environment in nature because they evolve, the use of Kanban leads to a better process development by teams that are adapting to the current context.
The evolutionary nature of changes organized in Kanban has several advantages:
1) Usually those involved will show less resistance, because matters are changing slowly and in small steps. In most cases, especially processes, roles and responsibilities are not changed in the beginning.
2) Changes in small steps harbor less risks, because after each change one can determine what kind of effect a change had and how to proceed further.
3) Many small changes allow for a flexible response to a changed environment (e.g., a new product released by a competitor or changed customer behavior).
However, for all the parallels between evolution in nature and Kanban, there exists a vast difference: In nature, mutations will occur completely at random. If they turn out to be useful, they will be passed on to further generations. If not, they immediately disappear from a species’ gene pool. In Kanban, we don’t make any spontaneous changes to observe what will happen as a result. Instead, we formulate hypotheses about what might be a sensible next step and which effects we hope to create by changing particular aspects. As Kanban inventor David Anderson points out: “There is no random mutation in Kanban.”
3. Using Models for Improvements
In Kanban, we wish to make small improvements that often take on the shape of experiments. These experiments are based on hypotheses, and in order to arrive at these hypotheses, it is useful to refer to models. Accordingly, one of the five core practices of Kanban is: “Use models to improve collaboratively.” The idea behind it is: Over the past few decades many smart people have developed various models that can beneficially be combined with Kanban. These models differ in the extreme, but they all have one feature in common: They systematically guide us in making continuous improvements. During the past few years, a pool of models that have successfully been used by Kanban teams to make improvements has formed. The Theory of Constraints counts among these models, as well as the Cynefin framework, the Toyota Production System, the OODA Loop or the Real Options Theory. This list is far from complete, and fortunately many developments and a lively exchange across various communities are happening in this field. We recommend that you select one or two models to begin with and try them. Which models are to be considered depends on several factors like team structure, size and structure of your organization, type of product or service offered, and last but not least on the team members’ preferences. However, in practice it turns out that in most cases the initial selection doesn’t take much time. In the following, we shall introduce the PDCA cycle and its application as a potential model for improvements.
4. The PDCA Cycle
The PDCA cycle was originally developed by Walter Shewhart and later on modified and popularized by Edwards Deming. It was first used in the Toyota Production System, but nowadays the PDCA cycle is often found as a standard in manufacturing whenever process improvements are called for. It is one of the main instruments for achieving a Kaizen culture, i.e., a culture of continuous improvements.
In the phase labeled “Plan,” the next change is planned. In this context, the word “Plan” suggests planning for a longer period, but it actually refers to the next experiment, scheduled in hope of an improvement. Particularly in manufacturing such changes can be rather minute. Part of the plan should a an idea of how we measure whether the change will be successful or not. “Do” is about testing the plan’s feasibility on a small scale. Usually it means that only one worker, one team or one department participates in the current experiment (thus minimizing the risk of a possible failure). Subsequently, the experiment is evaluated in a step called “Check.” Did the experiment yield the desired results? To determine this, metrics are evaluated in most cases. If the experiment was a success, its standardization and large-scale application follow in “Act,” meaning mostly its application in other teams and departments.
Image 1: The PDCA cycle
4.1 The PDCA Cycle in Knowledge Work
The principle of the PDCA cycle is maintained in knowledge work, but its concrete realization must clearly look different from that in manufacturing, because otherwise it is doomed to fail!
Types of Changes
The first difference lies in the types of changes that are relevant. In manufacturing, typical examples of improvements are: a new positioning of machines or tools, their reconstruction or redesign, the optimization of conveyor paths and transport routes. We also find such improvements in knowledge work, but here they are rare and of comparatively little use. In the majority of cases, improvements in knowledge work aim at changes to existing rules. “From now on, a code review must be conducted by a colleague for each developed feature” is an example of such a change.
In manufacturing, completion of the PDCA cycle takes only a short time: often only a couple of hours or even minutes. This is possible because throughput times are short; tasks are very homogeneous and process flows highly standardized. Consequently, the results of changes will often become visible at once. In knowledge work, short feedback cycles are also desirable, but for many changes it makes more sense to schedule several cycles that will take a couple of days or weeks. For exemple it‘s very hard to judge the success of introducing pair programming after 24 hours. In order to do so, one must slice this change very carefully into smaller, yet useful experiments, which requires quite a lot of experience. If you try to artificially reduce the length of these cycles, the result will often be a response such as “We have to wait a few more days” in the “Check” phase, which is demotivating and causes unjustifiably high coordination costs.
The second important difference can be found in the “Check” phase. Other than in manufacturing, in knowledge work it is often very difficult to evaluate an experiment’s effect based on metrics. This has mainly two reasons:
1) A number of experiments are conducted simultaneously, so that the metrics cannot be assigned to one method without ambiguity.
2) In many cases, those involved cannot agree on a certain metric to evaluate the experiment. One reason thereof is the abstract nature of knowledge work: The results themselves cannot be directly seen, which is why proxy indicators must be used (e.g., capacity utilization of employees to determine the productivity of a system). Often, there is no unequivocal answer to the question of whether these indicators make sense and to what extent they should be used. Another problem surfaces if one knows how to measure the change, but implementation of the suitable metric would be too much of an effort.
3) In many cases, the metrics are too slow to be usefully applied in the PDCA cycle. In our code reviews example, we aimed at increasing the code’s quality and at reducing the number of production bugs. However, chances are that this effect becomes measurable only rather late (e.g., in very long release cycles). While waiting for these numbers, one would generate extremely long feedback cycles – a practice that is in conflict with the Kaizen idea.
4) In knowledge work it frequently happens that the selected metrics are only useful if they are interpreted meticulously. At first glance, they often seem to state the exact opposite of what has actually happened. Let us return to the code reviews example: In a real-life case, code reviews clearly reduced the number of new bugs, but as a matter of fact, the chosen metric yielded an increase in reported bugs in the live system, the reason thereof being that now previously ignored bugs were reported. They had been ignored because the prevailing attitude in the company was: “Why should I report this old bug when new bugs with a higher priority are surfacing all the time?” This exemple illustrates that change can be hard even if it is successful, because sometimes it looks like failure and change agents might be blamed for having made the situation even worse.
One way out of this dilemma can be the use of a totally different type of metric: intuition. This might first seem absurd to us, since we work in a highly technology-driven environment. Yet practical experience shows that this approach works surprisingly well (plus we really don’t have any other options). One option would be a meeting in which the team reflects about a newly started experiment. First, team members exchange their experiences and discuss them. Then they convey their personal impressions, i.e., whether the initiated change makes sense and whether it should be pursued further or even expanded on. This can be done via a thumb voting, for example. If all team members agree, the change will be pursued further. If nobody is convinced of the change, it will be abandoned. If the team members cannot agree on this issue, they discuss the possible consequences of this dissent. Whatever your solution will look like. The strategy to take it to the teamt has proven to be helpful if not the only way to make a good decision. Besides it is one more practical example of leadership as a team sport and helps managers to successfully cope with complex and unceratain situations.
Standardization in knowledge work is a double-edged sword. On the one hand, standards create a common understanding and a basis for improvements. On the other, standardization – if it is applied too strictly – soon turns into a straitjacket that unnecessarily eradicates differences, impairs creativity and leads to discontent among team members. For example it might be useful to standardize the IDE within a team when doing pair programming. This makes it easier to change pairs more often (which is desirable in many cases). On the other hand this might lead to dissatisfaction amongst the team members when they feel forced to use certain tools when they don‘t see the use of it. In manufacturing, standardization can be described in this way: “In each situation, everybody works according to these standards.” But in most cases, this approach is too rigid for application in knowledge work and does not yield the desired results. It is better to let the team consider in which cases standardization is required – and to what extent. In many cases, it has proven useful to leave some individual leeway for the team members’ own decisions, depending on the context, instead of creating a detailed catalogue of rules that defines exceptions and how to deal with them. Moreover, we recommend that you make the procedures regarding standards transparent and reflect about them on a regular basis to make adaptations if necessary. Retrospectives are suitable for this purpose – but they need to be facilitated professionally-
Standardization, Abortion, Modification
The phase “Act” focuses on realizing what we have learned from “Check.” This can also mean standardization in the context of knowledge work, but since in knowledge work we lack more knowledge than in manufacturing, here “Act” more often leads to abortion or modification.
Abortion means that we declare the experiment a failure and move on to a new experiment – the PDCA cycle starts again. It is important that we don’t see the aborted experiment as a personal failure or a waste of time, but as a valuable learning experience. We should refer to Thomas Edison as a role model: He is supposed to have tested 10,000 different kinds of filament until he finally succeeded. His comment was: “I have not failed. I’ve just found 10,000 ways that won’t work.”
Often during “Check,” we will notice that we consider an experiment promising, while its current state does not yet lead to the desired improvements. If this is the case, we should modify the experiment, i.e., we agree on modification and try it immediately by starting a new cycle with “Do.”
Image 2: “Act” can mean different things: standardization, abortion or modification.
Practical Applilcation of the PDCA Cycle
Exactly because it is so simple, the PDCA cycle is ideal to discuss improvements with a team or an entire organization in a structured way. How many improvements are being made simultaneously? Do we believe that their current number is adequate? Should we make fewer improvements at once and focus on working more intensively on them instead? Shall we stop the feedback cycle? Or does it often happen in our work that changes are initiated, but never evaluated systematically using “Check”? These and other questions can help us to reach a shared understanding of how changes should be handled in their specific context. Sometimes it turns out that different opinions exist regarding the required amount of changes as well as regarding the timing of their implementation.
In addition, some teams have prominently put up the PDCA cycle in their team room. File cards indicating the currently implemented improvements are pinned to the respective fields for the phases “Plan,” “Do,” “Check” and “Act.” The team discusses these improvements frequently (e.g., every 14 days), moves them to the next phase and agrees, if necessary, on the next experiment to be conducted. We recommend that you limit the number of currently implemented improvements in order to keep focused and to be able to make better decisions regarding the effects caused by a respective change.
Moreover, visualization of both the PDCA cycle and current improvements can lead to seminal discussions with stakeholders and other teams, and this is probably the biggest value in knowledge work! And it‘s a similar effect we also observe regularly when teams have a physical Kanban board attached to their office wall.
Image 3: PDCA visualized on a whiteboard.
The team decided to try “Standup at 10am” and “Pairing”. They agreed to have no more than one change in progress for each stage.
Improvements remain a challenge, but there are hardly any alternatives: Organizations must learn to develop a culture of continuous improvements. If such changes are supposed to take place evolutionary, that is, in small steps, Kanban can provide a suitable framework for knowledge work. To establish a team’s common understanding of changes and to realize them in a structured manner, we recommend the use of models. The PDCA cycle is such a model. It offers a clear structure for driving change, fosters self-organization, and helps to improve shared responsibility and leadership. However, when applying the PDCA cycle, one must always keep in mind that manufacturing and knowledge work are fundamentally different.
About the author: Arne Roock is a trainer and consultant with it-agile in Hamburg. He helps organizations establishing a culture of continuous improvement using Kanban and Lean. He runs the blog www.software-kanban.de and tweets as @arneroock.