At it-agile we use a Kanban board for acquisition. Once we turned all our tickets on our acquisition Kanban board into fixed delivery date tickets. We wanted to decrease our average lead time by reminding those who where working on the tickets to keep on working. Good intention, bad execution. Here’s why.
At my company we have customer requests like “We’d like you to do a Kanban class” or “Could you help us with developing an iPad app?”. We also have a lot of experts working outside the office most of the time, who answer to such requests. We use a Kanban board to coordinate answering of customer requests. We call it acquisition board. This does not work without problems.
We have a service level agreement for answering the first customer contact. When a customer writes us an email, our team assistants turn the email into a ticket and put it into the ready queue of our acquisiton board. The ticket also gets a due date, which turns it into a fixed delivery date ticket. Now we wait that someone of us pulls that ticket. If it’s not pulled before the due date, our team assistants call the customer and turn down his request by saying that we’re sorry but we actually do not have the capacity to help him.
Now that is what I find a good use of a service level agreement in combination with a due date. So did others in my company, and that’s why they started using due dates for other things than just answering to the first contact. The idea was to decrease our lead time of the whole ticket by having due dates all the time, in all columns. That due date would mean something like “I want to work on that ticket until [due date].” Imagine an acquisition board full of tickets with dates on it – most of them red, indicating that they’re overdue.
Overdue tickets could mean that most of my colleagues pulling those tickets are lazy, uncoordinated or just too busy to keep up working on acquisition, but from a systemic point of view that’s just ridiculous. Maybe it’s because of the due dates all over that it’s not working?
Fixed delivery date tickets are explained by David Anderson in his book Kanban
“Requests of this nature carried a significant cost of delay, whether direct or indirect … There would be a date when a penalty (or fine) would be incurred … [or] there would be a requirement to cease some activity … This second, indirect cost is a cost of lost opportunity – the potential lost revenue during the period of delay.”
Is there a penalty if we do not answer the first contact of a customer? Nope, it’s legal to do so. Is there lost revenue because of a delay? Sure there is, the customer could be upset if we don’t answer his request in time. Like Henrik Kniberg said, a request is like a bun and when it “comes in it is warm, juicy and soft“, but when you wait too long, you won’t enjoy your bun anymore.
But what happens after the first contact? There’s still no penalty. But there could be a cost of delay (e.g. not calling back for a long time), but there does not necessarily has to be one. Often, we talk to customers for months until everythings settled for a training. Sometimes it’s the customer who needs time (because she is on holiday), and sometimes we need time (because we are on holiday), and very rarely that results in four weeks of silence between me and the customer (my holiday was first, followed by her holiday). In that particular event where I didn’t have contact with the customer for four weeks it still resulted in a good business transaction. So there seems to be no necessity to set an arbitrary due date.
Having said so, arbitrary due dates are well known, not in Kanban, but in the Getting Things Done (GTD) community. GTD is a personal organization method, focused on tasks. The idea is, to organize the tasks externaly so you don’t have to remind yourself all the time on all the stuff you have to deal with. Kanban and GTD have lots of similar ideas; there’s even a Personal Kanban book out there which focusses on similar topics.
In GTD, arbitrary due dates are called false due dates or fake due dates. Chris smith wrote on Lifehack about fake due dates, that they are
“… dates that you set up for actions within a project that are due before the actual due date project. In my experience these types of due dates don’t work. What they tend to do is allow procrastinators procrastinate more, because when they see due dates they push everything back to the last minute.”
Procrastinators procrastinate more? Outch, sounds like increased lead time.
Some time ago I used to put fake due dates on all of my tasks in my personal task list. Shortly afterwards I was highly demotivated. It seemed that I wasn’t able to commit myself to the simplest stuff I planned on doing at a specific date, my fake due date. Turns out, it was not because I was undisciplined, but because I used fake due dates.
“[…] I’ve discovered over time that I have a strange habit of arbitrarily assigning due dates to some tasks, not because they must be completed by then, but because I think they might be or should be. This undermines the trust in my system and adds an unnecessary psychic burden, as tasks without a concrete due date begin to pile up in the “overdue” column. That aint good. The reason I haven’t completed those tasks is because I haven’t had the time or energy to do them. Making them artificially overdue is like being punished for something that’s not my fault. That was an important insight for me, enough to make me open my task list and remove due dates from every task that doesn’t explicitly require one. I feel a lot better already.” (by Todd Mundt)
I felt relieved after I threw all fake due dates away and kept only the real due dates (less than a hand full of them).
In another domain it’s the same: If you use your calendar to mark due dates, you are very likely to end up failing:
“Setting up false due dates will not only clutter your calendar, but will also make you frustrated and possibly even less productive. False due dates are those things that you add to your calendar when you say, ‘well, I think that I should have this part of my project done by this date here,’ and then mark it with your fake due date.
What this does is help you put off tasks that are related to that project until you are closer and closer to the date.
This isn’t to say that there is anything wrong with milestones, but to put a hard date a piece of a project when it isn’t actually do will most likely set you up for failure.” ( Chris Smith on Lifehack )
Well, we’re still struggeling in my company with the fake due dates – but I managed to get of the hook, i.e. the need for me to use due dates on the tickets I pull. I assure you, the flow is back now and I work much better on those tickets.
Don’t use fake due dates in Kanban. They put pressure on you, have you feel unproductive and guilty, and increase your average lead time. Only use real due dates.