How remote working forced us to review the use of our kanban cards

In charge of marketing and communication at No Parking (a web software company based in Lille, France) Chloé works closely with other teams (development, customer relations...) to ensure the production and development of Opentime, a time management and activity monitoring tool. Today, Chloé shares with us her experience of how the pandemic led the company to an in-depth review of its working practices.
Chloé in front of here kanbans board

Lockdown brought to light new problems within the team. Remote working, staggered working hours, and digitalization of visual management inevitably led to new difficulties that the team tried to resolve. Until then, the order of tickets was managed on a daily basis during the physical stand up in the office. But, with digital tickets, priorities have been blurred. No direct visualization of lead time on current tickets, no physical meetings and less regular coordination in the team.

Two problems resulting from this situation were then identified within our organization. On one hand, there was no logic in the order of everyone's cards on the digital Kanban board. There wasn’t any prioritization by value. The kanban cards were then displayed according to the estimated end date and those that didn't have one appeared last: an irrelevant order. On the other hand, it was possible to change the starting and ending dates of the kanbans, which we sometimes did according to our desires or the customers' remarks.

The consequence immediately appeared : many kanban cards were stagnating at the same point in the process for long periods of time. They were also postponed (change of the estimated end date) either because the subject seemed less important than others, or because the tasks were too long to carry out, too complicated or the person in charge did not have the skills to deal with them. The following questions then appeared: Are these really issues that need to be addressed ? Are we behind schedule? What should we do about it? What do we need to test to eliminate this unproductive process?

Driving kanbans by launch date

The solution chosen and applied at No Parking was to drastically change the management of kanbans. From a control by the presumed end date, we have switched to a control by the launch date (the date on which the task associated with the kanban card must start). The second important point is that this launch date can no longer be changed once the date has passed. However, one card, and only one, can be given priority (physically pinned to the top of the tasks pile).

We also eliminated kanban cards that had been around for too long, making sure that the needs were no longer expected by our customers. After this cleanup, we decided we could not repeat the same problem!

Concretely, this change has been materialized by a fundamental modification of the working habits of the team members, in particular for Ophélie in charge of creating the kanban cards for the IT development team. On our digital tool dedicated to kanbans, she now indicates the launch date when creating the card, taking into account the availability of each person and the client's initial request. For example, a customer asks us to add a new validation method for expense reports in the Human Resources tab of our Opentime software. Ophélie assigns this ticket to Laury in 2 days since she does not have any ticket to work on that day. In addition, there are no alerts for the tickets she is currently working on that need to be completed before this new requirement is taken care of.

In the marketing and communication sector, I also had to change my habits. I now have to enter the start date of my tasks knowing that it could not be changed after, which created a new view of my tasks ordered by predefined start date and time. This change led me to several discoveries: I could no longer create kanbans for "later / maybe / if I feel able to do it" and I had to consider much more how much time each topic would take me when creating the kanban.

The organization of kanbans of each member of the team thus evolved automatically, putting the actions that needed to be done first (customer request or critical anomaly which needs to be corrected immediately) on the top of the board. The advantage of working with digital software is that it allows us to have global visibility of the kanbans and to be able to establish rules that are impossible to cheat on !

Better control of lead time

With this start date, our lead time measurement has become much more real and accurate. Through the processing of the discrepancies that we can see on the kanbans’ board, we learn about the real time of each request and have access to a better projection of the duration of future topics.

In fact, piloting requests by launch date has influenced the overall productivity of the team. When it comes to selecting the next task, it is no longer an employee’s choice based on how long a kanban will take or what he/she likes, it is now a choice based on priorities. The Kanban card that comes first in the board is not the shortest but the most urgent/important (value); and this makes our productivity grow.

In general, our average lead time is now lower and more constant. Indeed, until March 2021, our average lead time per week (on all the teams' kanbans) was between 2 days (for the best weeks) and 10 days (for the worst weeks). Since then, with the implementation of this control by launch date, it has halved to between 1 and 5 days per week.

Even so, if the maximum lead time per week has dropped from 100 to 50 days, it still remains high. Having identified these maxima allowed us to define reaction rules through the use of the « andon » and to work on the root causes to avoid this to be recurrent.

What did we learn?

First of all, we learned from this experience that there is a possibility for each person to be more focused on their task if the organization is done at the time of the creation of the kanban cards. The operator will now spend more time creating value than thinking about which task to do first!

This situation leads to a less stressful job, as the IT development trainees pointed out to me. Vincent sharing: "The benefit of having a pre-set schedule, of not having to do it yourself is that you really see it as a schedule and not as a constraint." And Quentin adding : "Since there is not necessarily a closing date, there is less stress about the deadline, we just know that we have to move forward since other kanbans start the next day or the day after. We're less stressed because if we're stuck on a kanban that we've started, there's the andons and the red bin to help us."

In fact, the developer knows on his own that he needs to finish his active kanbans before the next ones start, but for the system to work, he must not get stuck. The use of andons and red bin then makes a lot of sense. Even if one team member is interrupted to help another, the work is completed more quickly than if no support had been provided. For Valentin, "with this organization and especially the fact that I can more easily call on the andon, when I start a ticket I don't think so much about whether I'll be able to do it."

This method has enabled us to better identify our skill needs. The impossibility of changing the end date makes us force ourselves to try to accomplish a task and the andon provides the necessary support to learn from people who actually have the skills, which helps to share those important skills!

In a more indirect way, with the hybrid work that led part of the team to work from home, this method of managing the kanban cards allowed us to highlight a weakness in the versatility of our team, due to a lack of skills. When the only person who can carry out an action is absent, on vacation or telecommuting and difficult to reach, his kanban card stagnates and the lead time increases. Thus, in July, we noticed a clear increase in our average and maximum lead time!

We must therefore ensure that :

  • information circulates easily with constant exchanges within the team
  • we are aware of the planning of different team members
  • we permit skills to spread between team members

Finally, this way of working has allowed us to identify a real link between the internal organization of our customers and our production. In September, for example, one of our customers (who validates the features we develop for them on the software) was on vacation. We did not anticipate this period and the lead time of the cards associated with this customer increased without us having the possibility to do anything.

Controlling tickets according to the launch date has allowed us to positively impact three key points in the functioning of our team: productivity, pressure felt by team members and the team's contribution to each member. We now need to use what we have learned from this experience to reduce the maximum lead time of our kanbans and impact more strongly on the service provided to the customer.

A french version of this article appeared on the Institut Lean France website.

Michael Ballé's definition of Lean

In his latest article Michale Ballé asks a simple but profound question Where do you start with developing people?. Along the way he advocates a definition of Lean.

Overall, this is what lean is about:
- Plan, check where you are against plan, and think through the gap
- Have a team leader, coordinator or coach help you to actually look at the gap rather than avoid it
- Combine both to come up with something new to try and learn to stay cool out of your comfort zone

Andon will give you the frame for on-the-spot routine. Kanbans for a daily routine. Hoshin Kanri for a yearly routine. They are numerous other examples. But the secret sauce of Lean is to repeat over and over such simple steps: sustainability to bridge the gaps breeds success...

Kanbans, and the art of not choosing

X — Look, this kanban is really easy, I’m sure I can do it in less than fifteen minutes.

Me — I’m sure you can but the kanbans board tells you something else, doesn’t it?

— I know, it’s in second position. There’s another kanban at the top.

— And…

— I guess it’s the one I should be working on next. But the problem is I don’t know how long it’s going to take : it’s one to those « red bin » kanban, we never know if it’s a 5 seconds fix or a 2 hours deep dive into old and obscure code.

— And from which one are you going to learn more ?

— Easy… The 2 hours deep dive. The other type is usually a simple condition someone forgot about : just looking at the log trace is usually enough to have an idea of the method that needs updating.

— Is this « 5 seconds / 2 hours » categorization the same for you and the rest of the team ?

— Of course not. For example, if it’s related to Javascript, it’s usually « 5 seconds » stuff for M.

Me, laughing
— And a « 2 hours » nightmare for me.

— But what if I’m really stuck.

— We’ve talked about the other button, haven’t we ? The orange « andon », right next to « red bin ».

— But if I click on it, I’ll be interrupting somebody else…

— That’s exactly the point : making sure you can draw the attention of anybody in the company while you’re dealing with your share of potentially difficult problems or bugs, improving your skills and learning new ones along the way.

— You mean it’s a privilege to be assigned those « red bin » kanbans?

Me, smiling — I hadn’t thought of it that way, but I guess it is…

  • page
  • 1