Kanban; Evrimsel Değişim

-You are Allowed to Think-

kanban (看板)

/ˈkanban/

noun

1.Signboard or billboard in Japanese.

2.A scheduling system used for the control of material movements for just-in-time (JIT) production.

3. Information card used in Kanban systems.

Origin: Japan.

I think that starting with the meaning of the word will be a good starting point. I will share my thoughts about the Kanban Methodology in the Information Technologies sector, I will refer to that as KANBAN in short. I wanted to write this article because there are not enough Turkish sources in this subject and many of them cause false perceptions.

 

I would like to state that I am not an authority on Kanban. I’m afraid of the Dunning Kruger effect (bit.ly/dnngkrgr). However, I and my friends received the second prize in the Medium Sized Enterprises category in Efficiency Project Awards 2016 organized by the Turkish Ministry of Science, Industry and Technology Directorate General of Efficiency, as a result of my experiences and knowledge acquired with my studies on Kanban and adaptations made in the company since 2012. This may be a reference point for you as readers to evaluate me. You can see the award application document here (bit.ly/vpo2016PDF).

In accordance with the Kaizen philosophy, I continue to go into the depths of Kanban by questioning my experiences with new knowledge. Therefore, I would like to warn you in advance that my ideas expressed here may be invalid or need updating later.

 

Question everything: this doctrine is adopted by the Kanban community which I follow, with the slogan “No Dogma”, leaving the door open to different ideas to open the way for the community to improve itself. Another slogan is the title of this article, “You are allowed to think!”. This slogan is one of the catalysts that I tell myself again and again when I practice and interpret the methodology; it helps me come up with solutions.

 

You can imagine that it is not possible to fit this topic completely into an easy-to-read text. Therefore, I am sharing this article with you as the first part of a 3-part series. In this section, explaining what Kanban is not, rather than going directly to the heart of the problem and focusing on what Kanban is will be more appropriate to the slogans “No Dogma!” and “You are allowed to think!”. Therefore, do not expect me to mention Kanban’s basic principles and main practices in this first section. If you don’t have any information about Kanban, this first article of the series may be a bit advanced for you.

So, let’s start.

Kanban is a lean/agile methodology, which was applied for the first time by David J. Anderson in the early 2000s, which takes its characteristics from Lean Production principles (especially Taiichi Ohno’s lean production technique applied in 1953 in Toyota), and which includes systemic optimized approaches such as the Theory of Constraints and Systems Thinking.

In the foreword of the Essential Kanban Condensed (Anderson and Carmichael, 2016, goo.gl/ZbtDIk) booklet, Janice Linden-Reed (President, Lean Kanban, Inc.) describes Kanban as “a method that shows us how our work works”. Both the definition I stated at the beginning and this statement are enough to explain how much importance Kanban places on visualization. When we visualize something, we can better understand it. The best way to realize a problem that obstructs flow or causes blockage is by visualizing the system (our brain is a visual entity. j.mp/brainVis).

I have told you that I would not go into definitions, principles, and practices in this article, but we kept the tradition with a brief history and definition. Now, let’s go back to our bleeding wounds and the gossip that everybody’s waiting for.

As in many other subjects, we are about 10-15 years behind. Kanban has gained popularity among agile groups in Turkey as well as Scrum, after the agility culture started to spread slowly in our country. But unfortunately, people try to define Kanban with absurd statements such as “A version of Scrum without sprint/timebox”, “it is suitable for maintenance teams but not for project teams”, “it is no better than ToDo list”, “a method that can be used in small-scale transformations”, “it is like Waterfall but agile method”.

I’ll take only two of the above-mentioned expressions, and please remember “You are allowed to think!” slogan every time you have difficulty and choose the explanation or comment that makes sense to you.

1. We will first look at the statement “A version of Scrum without sprint/timebox”. I think that this is the situation that teams, which applied Scrum before, realize first but cannot fully understand when they meet Kanban for the first time. Kanban does not suggest that sprint or timebox should not be applied. Since Kanban’s first basic principle is “start by using the ongoing system”, the timebox or sprint time can also be sustained in Kanban according to the usual condition or requirements of the system.

Apart from that, the main point that people miss is that: Kanban is flow oriented. It provides an environment to see and eliminate the bottlenecks and waste points within the system and finish the works as soon as possible. So, it tells us to reduce our Lead Time values. Lead Time values ​​can be 2 or 3 days for some jobs. There are Kanban systems with Lead Time values ​​shorter than the lowest sprint time specified in Scrum; imagine you have a release in every 3 days.

Lead Time objectives are calculated with probabilistic predictive planning methods. Little’s Law and Monte-Carlo simulations are some of the methods used in these plans.

So, you don’t have infinite time when you practice Kanban, you may even have more frequent iterations.

“It is suitable for maintenance teams but not for project teams.”

Please don’t say that, a kitten dies every time someone says that. I think it is an opinion that was put forward after the problems experienced in the maintenance teams within the structure of inexperienced organizations that tried to apply Scrum or decided to disseminate Scrum (see the end of the article if you think I slam Scrum).

Now let’s think about this slogan: “You are allowed to think!”

I expect a method that works in maintenance teams to work in project teams too, because they work in an easier system than maintenance teams.

Scrum says that the items included in the Sprint backlog include the works to be done during that sprint, and the team promises to finish these items: commitment. No new works are taken into the sprint backlog after sprint starts not to disturb the team’s concentration and let them keep the promise. Very nice and logical orientation.

However, most maintenance teams cannot create a predictable system because they are drowned under the workload and cannot see where a problem will occur. They cannot get to the root of the problem and find a permanent solution due to this workload. Therefore, the sprint backlog prepared in the planning event is sabotaged with more urgent jobs, the promise cannot be kept. This is true not only for maintenance teams but also for a continuously disturbed project team; imagine your general manager keeps sending you new works.

How does Kanban solve this? Let’s remember the first rule again, “start by using the ongoing system”. Then, let’s remember two of Kanban’s main practices, “limit the work in progress (WiP)” and “manage the flow”.

Why can’t we create a predictable system? Because there is a lot of work waiting in line to be finished. Then apply WiP limits. According to Little’s Law (L = λW), WiP = Lead Time (time) * Throughput (work/time). If I reduce the number of works I’m working on, my Lead Time value shortens. If Lead Time gets shorter, the product output goes up (throughput). I can produce works with higher quality by limiting my workload and I can spend more time on root problem and create slack time.

Since I start by using the ongoing system, I continue the previous process and I can take action by seeing the points of improvement; kaizen. I don’t enforce a sprint to the team at the beginning, because it will take time to get used to the new order. It is easier for the team to focus on the points of improvement within the usual system.

Do you think that Kanban is only suitable for maintenance teams in the light of these explanations?

I don’t try to discredit Scrum. The starting point of the cases discussed above has nothing to do with the Scrum framework, and they all have a solution in Scrum. Scrum can be applied to all types of teams without a problem if you can perform organizational transformation quickly in all units within the Scrum framework. I think the only reason for this is the organizations that have not adopted the Agile culture or that are at the beginning. I think it is hard to find the combination of an organization that will adopt this culture quickly and people who will manage change properly.

Scrum is a revolutionary method, and there will be those who cannot keep up as in every revolution and this will cause trouble.

Kanban is an evolutionary method. In its simplest form, it aims to improve and alleviate the system by examining the ongoing system and by eliminating the points that create waste and workload via lean manufacturing, the theory of constraints, and systems thinking approaches. With this alleviation and simplification, the organization will be able to give more agile reactions. Due to its evolutionary nature, there will be minimum reactions caused by the organizational culture that we observe in other methods.

I didn’t intend to make a clear Scrum-Kanban comparison in this article, but it seems like I had no other choice. Although they are independent and incomparable methods, everyone does that. I think Karl Scotland makes the best and most straightforward comparison between Scrum and Kanban. He says:

“#Scrum focuses on being #agile which may lead to improving. #Kanban focused on improving, which may lead to being agile.” – Karl Scotland.

 

End of Section 1,

Thank you.

Alper Tonga (linkd.in/NAp6Ro)