How to replace the timebox-based motivation when using Kanban/ScrumBan

I recently pointed a customer to a discussion around motivation when using Kanban compared to Scrum and other timebox-driven approaches. This blog post is a slightly edited version of my comments on that discussion, since I find myself getting into similar discussions quite frequently.

The question/context originally posed by Victor on kanbandev was: “We kind of dropped our previous Scrum process (or rather we decided to pay less attention to it because it was becoming less relevant once Kanban was in the picture. But one thing good about Scrum was that developers knew their story was due in 2 weeks so they paced themselves. With our Kanban system their isn’t an end date, so that motivator is gone. Can anyone suggest a replacement or remedy (other than Scrum, I really don’t want to go back)”

Here is my original response more or less verbatim:

When I was starting to advocate Kanban at AgileSparks, we were mostly a group of hard core scrum coaches/trainers, so we saw the sprint deadline and commitment as THE way to ensure high energies and self-organization within constraints and get rid of Parkinson’s law (work fits the container it is given). Over time, we saw that it is A way, and not necessary always the BEST way (due to the reasons quoted below, also see https://yuvalyeret.com/2011/10/13/scrum-sprint-commitment-rant/)

What we saw through experience with different client environments were that there were some alternative ways:

A frequent delivery cadence on its own is typically enough to drive the right level of energies, even without a commitment to finish everything based on a sprint commitment. You can see this described in the FiftyOne.com case study in the Beyond Agile book.
A frequent DEMO cadence can be enough as well, believe it or not! not even delivery… It is sometimes enough to create too much pressure and technical debt, even WITHOUT any commitment to finish a certain package of work. People are motivated to show they are done if there is some opportunity to show and boast it.
Continuous Delivery seems to be even a higher motivator. I’m not working with enough people doing this, but those that do report a kind of rush that creates great motivation to complete things just to see how they perform in real life…
Working with small units of value (e.g. Stories), Visualizing and managing flow is many times enough. But only if not, you can consider visualizing and managing “lagging/stale” cards more explicitly. I like for example the “Zombie Cycle Time” approach and talk about it and some of the other issues here in my Lean Kanban Benelux 2011 talk
Purpose - clearly understood real external reason to deliver on a certain time. Whether it is a big deliverable built of many small things - where it is important to see whether you are on track towards that delivery using something like a CFD with release forecasting (trend lines/montecarlo/whatever), or a single value item that has a special delivery requirement. If people are aware of the deadline, realize the cost of delay, and ideally believe in the plan to deliver to that deadline, they will be highly energized.

Since you are coming from a Scrum environment, what seems to work for many teams as a starting point is to keep the cadence only relax the commitment to clear the table as well as to plan ahead exactly what will be the contents of the sprint. This is many times enough. You should look at the actual flow of work and determine whether there is a problem or not.

Regarding talking to the team - I would first try to go to the gemba and see what is going on, before bothering the team with it. If there isn’t a problem, even talking to them might create a Hawthorne effect affecting how they work, and not necessarily in a good way. Depends on the team. Only you know…

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.