Continual improvement according to the PDSA cycle brings scientific thinking to the team level. In my earlier blog post I have highlighted the importance of autonomy for continual improvement. Most important conclusion there was that a team should have the right competencies and skill levels to be able to be truly responsible for their work and the improvement thereof. But to be an autonomous team, more comes into play. True autonomy also implies that the PDSA cycle — in most cases — can be fully completed within and by the team. And this is where I see many issues. In many cases, the PDSA cycle seems to be broken…
PDSA
Most people are aware of the PDCA cycle of Plan, Do, Check and Act, introduced by Deming based upon earlier work of Shewhart. With Lean folks, PDCA is also sometimes referred to as PDSA: Plan, Do, Study and Act. Personally, I also prefer the word “Study” as I feel “Check” doesn’t do justice to what this activity should really be about. It should be about studying the results of “Do”, and particularly studying the possible deviations from the expected results, as postulated during the “Plan” phase. This makes the “Plan” into what it should be: the team’s theory or hypothesis about how the work could be working better, and “Do” into the experiment that tests the team’s claim. “Study” also implies that the team is learning: the team builds up knowledge and experience about how their work actually works. Form this perspective, continuous improvement could be seen as continually going through the PDSA cycle.
PDSA and Autonomy
Continuous improvement using the PDSA cycle brings scientific thinking to the team level. In my earlier blog post (see Autonomy: condition for continuous improvement) I have highlighted the importance of autonomy for continuous improvement. Most important conclusion there was that a team should possess the right competencies and skill levels to be able to be truly responsible for their work and the improvement thereof.
But to be an autonomous team, more comes into play. True autonomy also implies that the PDSA cycle -in most cases- can be fully completed within and by the team. And this is where I see many issues. In many cases, the PDSA cycle seems to be broken…
The Broken PDSA Cycle
In many organizations, the PDSA cycle seems to be “broken” in one way or another. First of all, in many organizations there is a lack of understanding that the PDSA cycle is about testing a hypothesis. It is mostly seen as making a plan in terms of setting targets or required numbers. Furthermore, the theory about the way the work should work often is determined in a far away head office or by a distant, functional support team. And then the theory is mostly not seen as something to be tested, but as a prescription to be followed. The teams actually doing the work should then preferably comply and their performance is subsequently monitored and assessed by yet again a different organizational section. This assessment typically focuses only on the resulting performance and does not take into account the effects of the theory and the actual compliance with the theory during the execution. In this way, theories actually are not being tested and conclusions about whether the new theory works better than the previous one cannot be drawn. Shortly, continuous improvement will be a difficult if not impossible task when working like this. And at the same time, the team that actually is adding value to the customer is frustrated and standing on the side, deprived from the opportunity to learn.
Closing the PDSA Cycle
Autonomy of the team not only implies alignment between responsibility, process, authority, competencies and skill levels, but also that the team has the ability to go through the integral PDSA cycle within the team. This means that the team defines their theory about “how their work could work better”, tests their theory during execution (understanding the importance of compliance if they really want to test their theory), studies the results in the light of their theory, and consequently adopts, adjusts or abandon their theory. The truly autonomous team then also becomes a learning team, the nucleus of the learning organization. The role of the more specialist, supportive teams is to bring in existing theories during the “Plan” phase based upon the earlier lessons and from other teams, and to help translating the learnings from the experiment into better theories.
Too many organizations have allowed a too large a separation between teams defining organizational policies and teams actually doing the value adding work within their organization. In this way, they have broken the PDSA cycle of their teams and deprived their organization from the opportunity to effectively and continuously learn. Organizations that have the ambition to become a truly Lean organization should cross the chasm between using the tools and truly continually improving. This will, however, require a more profound understanding of the Lean philosophy and principles, beyond the current often shallow copying of the tools.
So what about your Lean initiative? It is about doing Lean or being Lean?