The “Stop starting - start finishing”-slogan has been the call to action for kanban practitioners for a long time. In Stockholm there’s even a conference each year named just that.
And we used it as our first picture in the book.
It’s a great saying and teaches us a lot, and lately I’ve got a new practical experience of the implications of “stop starting - start finishing”. The meaning of “Stop starting - start finishing”, to me, like a guiding star and policy that we agree on in the team, or in the company: here we try to complete things before we start new things.
I think it was Karl Scotland said it like this:
It's not the more we start the more we finish - it's the more we finish the more we finish.
The reason for us doing whatever we do, creating software features for example, is for some end customer to use them. To reach that state we need to complete the entire job required to be complete.
Here is where I often see team trip up. The definition of entire. It’s sooo nice to move on to the next thing that we tend to forget or skip the last percentages. In fact, in many cooperate cultures I’ve been in, having many things going on is the mark of success.
Ask any big company project manager how his project is going and you’ll see what I mean:
Our project is doing just great - there's a lot of things going on right now
The obvious question is then: Interesting - but how much is finished?
In a flow-based process, visualized it’s easy to see and understand the implications of not completing one job completely before moving on to the next. Here’s one example for my current client: we had a renovation job to do (fixing a leaking roof). One morning meeting when we went through the status we marked it as DONE. Because they were done with the job… so they said.
We put another, very small (replacing a sink, 4 hours), job for the same people to do on the board. Three days later there were still no progress on the small item. When we asked why the answer was that they had not yet finished the leaking roof. As it turned out the last parts of finishing leaking roof up, required some electrical work, and that specialist had other things to do.
Now this is normal. But this waiting time now ended up slowing down the “replacing sink”-job. Considerable.
By not completing something completely we put a slab of that work onto the next one. If we continued like that it would be a slab on unfinished work piling up on each new thing we started. After awhile we’re mostly finishing “old job” and do nothing new.
And this is because we are basically lying to ourselves about the true status of the work we are doing.
Our approach to handle this is twofold:
-
first we try remind ourselves that the board and the work status is not for anyone else than our team. Nobody has told us to use a board - it’s just for us. Let’s be honest about the status of the work too then.
-
secondly we use a definition of done for each, often by describing a desired end-state. Here’s a few examples:
-
when the roof renovation is completed no stains or water will be visible even during heavy rains (they ended up simulating a heavy rain by pouring loads of water onto the roof)
-
this change in the working process for the nurses is completed when we have communicated that to the nurses, written the new operating procedure and that document is signed by the director. (This caused us to wait 2 extra days, until the director came back from a trip and could sign it - but it was not completed until it was)
-
The new reporting feature is completed when we have data from 10 users using it in our database
-
The renovation of this room is completed when one patient has used it again, after the renovation.
-
Summary
Let’s not lie to ourselves about the status of our work. It’s a tool for us and it’s not working properly if it’s doesn’t operates on reality.
And before you head out there:
Stop starting - start finishing