In our book, Lean-Agile Software Development: Achieving Enterprise and Team Agility, we mention that the "inspect and adapt" is not the same thing as Plan-Do-Check-Act. Yes, they sound the same, but they are manifestations of different causality models. To fully understand the differences in inspect and adapt and PDCA, we must look at these causality models (which we will do shortly).
Scrum portends that because we are working on non-deterministic systems, our own process should be a controlled black box. See The Scrum Papers, pg 58. We disagree. A simple example of this is driving a car. I think we'd all agree that driving is a non-deterministic system. When you leave your home for work you do not know exactly what will happen – who will cut you off and how you'll have to drive defensively, or perhaps who you will cut off in an attempt to make up some time. Yet, most of the time, you get to where you wanted to get to in about the time you expected to get there. The "process" you use – keeping a certain distance between the car in front of you and your car (except, of course, when you are really trying to speed up the idiot), driving on the right side of the road when in the US on two-way streets, pressing the gas to accelerate, pressing the brake to slow down, threatening the kids if they don't shut up, … While simply knowing the rules doesn't mean you know how to drive, knowing the rules helps you drive better.
In an earlier blog (Types of Processes by Don Reinertsen), I discussed how the degree of visibility of your process is a separate issue from the level of randomness of its output. A third, separate, issue is how much feedback you need to control things.
While we agree that software development is a non-deterministic process, we do not believe that there is no causality of the actions involved. We also believe that it is important to create visibility into the process (what we call transparency) and not just visibility into the results (I've stated this several times on user groups but will write an upcoming blog to focus on this shortly). This is a significant difference in flow based systems (e.g., Kanban) and Scrum.
At a cursory level, the project boards for both flow based systems and Scrum look the same. One can see work entering the system, different stages in which the work is in and when the work is done. We call this visibility – that is, we have visibility into the results of the team. Incredibly important, but insufficient in our minds.
As important is the answer to the question- how does the work flow from one end of the board to the other? Is it just up to individual member's decisions on when to work on things or is there a visible set of decisions at work? While no complete definition of Scrum exists, the aforementioned Scrum papers as well as many blogs and user-group comments from CSTs (certified scrum trainers, presumably the highest authorities on what the Scrum Alliance's stance on Scrum is) continuously state the supposition that a defined process is not a good idea (if it were even possible). In other words, most Scrum boards will show you stories waiting to be worked on, those in process (including varying states) and those completed but having a defined set of rules for how things go from one column to the other is not a part of Scrum. It is just left to the team members' judgment. Teams are supposed to pay attention to the effectiveness of their actions and adapt accordingly. You can, of course, add your own rules. Good thing to do in our mind if you are doing Scrum – but then you have a variant of it (we call ours Scrum#).
PDCA is a bit different from "inspect and adapt" in that it requires the team to consider how things are actually working. In other words, we don't want to just inspect and adapt, we want to understand, at least a little, about the causality of things. For example, agile teams often experience a backlog of tests for testers at the end of a sprint. Developers have done the coding but the testers don't quite seem to be able to keep up. A good Scrum team will try to figure out what actions they can do to help here. Perhaps they try to pair developers together with testers. Perhaps they decide to specify their tests before writing code. Both good things. But what they haven't done is to try to understand the dynamics of what is going on by creating a model of it – something they can then try different things against to see what works better. Given one tenet of Scrum is your process is black box, i.e., it shouldn't (can't) be defined, this is not a surprise.
Lean takes a scientific approach. It believes you can understand the affects that your actions have. Lean suggests that one should consider how they are working to be the best way they know how. In this regards, their method of working is an hypothesis – "this is the best way to do our work." We make improvements to how we work by suggesting new a new hypothesis and seeing what happens. That is, we see how our actions affected our results. In Kanban, we focus on managing work in process levels. Our process hypothesis typically includes a set of limits of different types of work plus service level agreements. We adjust these to maximize value delivered to the customer.
In our developer / tester disconnect example, we might also consider pairing developers and testers, but we should also see if we get any improvement. This is how the PDCA cycle works. Our "plan" is "pairing developers with testers." We are hypothesizing that this will be an improvement. Our "do" is trying this out for some time specified by the team. We then "check" to see what happened (validate or invalidate our hypothesis). And then we "act" accordingly – make a new model, way of working, etc. Note, in knowledge work a somewhat equivalent model - Look, Ask Model, Discuss, Act (LAMDA) – has been offered. This probably provides a better metaphor, but is essentially the same intent.
While Scrum treats the team's process as a black-box, Lean treats it as a transparent process which requires feedback to keep it under control (since we are working on a non-deterministic system). We call this characteristic transparency.
Let me illustrate the difference between inspect and adapt and PDCA in a non-software world example. I'm a beginning sailor (have been for 30 years ;) ). I'm not really that skilled, but I do know a few things. When I first started sailing they said to look at the little ties on the sail to see which way the wind is blowing from. As the ties blow around, you adjust the sails to meet where and how strong the wind is coming. This is a simple rule of sailing. Note how it is reactive.
Now, pretty soon, you notice how it'd be great if you could get some sense of what the wind is doing before it hits your sail. Unfortunately, you can't see wind. But you can see the affects of the wind. I remember being told to look at the waves. But I, at first, did not find that very useful. Eventually, it started making sense to me. The primary affect of wind on water is the size of the waves and direction of the waves. But these are due to the prevailing wind – what I needed was the more micro changes that were affecting my sailing. Abrupt wind changes do not change the general height or direction of the waves. However, these do set up ripples on the waves. I started wondering if I could see a pattern between how the wind changed and how the ripples appeared. In other words, if there were different ripple patterns approaching me, did that mean the wind was changing? I would make guesses in my mind and see what happened. I would then see how I could respond to this. Over time I learn to "see wind coming at me." I wasn't merely inspecting and adapting I was PDCAing. J
Why is this important? Three reasons I'll just claim now, and follow up with blogs shortly:
I'll be writing blogs on all three of these topics shortly.