{"id":57692,"date":"2016-08-09T10:45:08","date_gmt":"2016-08-09T10:45:08","guid":{"rendered":"http:\/\/www.acmagile.com\/kanban-evrimsel-degisim-s01e01-you-are-allowed-to-think\/"},"modified":"2019-03-22T21:59:25","modified_gmt":"2019-03-22T21:59:25","slug":"kanban-evolutionary-change-you-are-allowed-to-think","status":"publish","type":"post","link":"https:\/\/old.acmagile.com\/en\/kanban-evolutionary-change-you-are-allowed-to-think\/","title":{"rendered":"Kanban; Evolutionary Change \u2013 (You are Allowed to Think)"},"content":{"rendered":"<p>[vc_row][vc_column][vc_column_text]<\/p>\n<h1>Kanban; Evrimsel De\u011fi\u015fim<\/h1>\n<h1>-You are Allowed to Think-<\/h1>\n<p>[\/vc_column_text][vc_column_text]kanban (\u770b\u677f)<\/p>\n<p>\/\u02c8kanban\/<\/p>\n<p>noun<\/p>\n<p>1.Signboard or billboard in Japanese.<\/p>\n<p>2.A scheduling system used for the control of material movements for just-in-time (JIT) production.<\/p>\n<p>3. Information card used in Kanban systems.<\/p>\n<p>Origin: Japan.<\/p>\n<p>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.<\/p>\n<p>&nbsp;<\/p>\n<p>I would like to state that I am not an authority on Kanban. I&#8217;m afraid of the Dunning Kruger effect (<a href=\"https:\/\/en.wikipedia.org\/wiki\/Dunning%E2%80%93Kruger_effect\">bit.ly\/dnngkrgr<\/a>). 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 (<a href=\"https:\/\/drive.google.com\/file\/d\/0B7BwzbFjNXIDMHdhOXpvaVlCeVE\/view\">bit.ly\/vpo2016PDF<\/a>).<\/p>\n<p>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.<\/p>\n<p>&nbsp;<\/p>\n<p>Question everything: this doctrine is adopted by the Kanban community which I follow, with the slogan \u201cNo Dogma\u201d, 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, \u201cYou are allowed to think!\u201d. 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.<\/p>\n<p>&nbsp;<\/p>\n<p>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 \u201cNo Dogma!\u201d and \u201cYou are allowed to think!\u201d. Therefore, do not expect me to mention Kanban&#8217;s basic principles and main practices in this first section. If you don&#8217;t have any information about Kanban, this first article of the series may be a bit advanced for you.<\/p>\n<p>So, let&#8217;s start.<\/p>\n<p>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&#8217;s lean production technique applied in 1953 in Toyota), and which includes systemic optimized approaches such as the Theory of Constraints and Systems Thinking.<\/p>\n<p>In the foreword of the <em>Essential Kanban Condensed<\/em> (Anderson and Carmichael, 2016, goo.gl\/ZbtDIk) booklet, Janice Linden-Reed (President, Lean\u00a0Kanban, Inc.) describes Kanban as \u201ca method that shows us how our work works\u201d. 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.\u00a0<a href=\"http:\/\/j.mp\/brainVis\">j.mp\/brainVis<\/a>).<\/p>\n<p>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&#8217;s go back to our bleeding wounds and the gossip that everybody&#8217;s waiting for.<\/p>\n<p>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 \u201cA version of Scrum without sprint\/timebox\u201d, \u201cit is suitable for maintenance teams but not for project teams\u201d, \u201cit is no better than ToDo list\u201d, \u201ca method that can be used in small-scale transformations\u201d, \u201cit is like Waterfall but agile method\u201d.<\/p>\n<p>I&#8217;ll take only two of the above-mentioned expressions, and please remember \u201cYou are allowed to think!\u201d slogan every time you have difficulty and choose the explanation or comment that makes sense to you.<\/p>\n<ol>\n<li>We will first look at the statement \u201cA version of Scrum without sprint\/timebox\u201d. 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&#8217;s first basic principle is \u201cstart by using the ongoing system\u201d, the timebox or sprint time can also be sustained in Kanban according to the usual condition or requirements of the system.<\/li>\n<\/ol>\n<p>Apart from that, the main point that people miss is that: <a href=\"http:\/\/www.acm-software.com\/acmblog\/kanban-evrimsel-degisim-s01e01-you-are-allowed-to-think\/\">Kanban<\/a>\u00a0is 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 \u200b\u200bcan be 2 or 3 days for some jobs. There are Kanban systems with Lead Time values \u200b\u200bshorter than the lowest sprint time specified in Scrum; imagine you have a release in every 3 days.<\/p>\n<p>Lead Time objectives are calculated with probabilistic predictive planning methods. Little\u2019s Law and Monte-Carlo simulations are some of the methods used in these plans.<\/p>\n<p>So, you don&#8217;t have infinite time when you practice Kanban, you may even have more frequent iterations.<\/p>\n<p>\u201cIt is suitable for maintenance teams but not for project teams.\u201d<\/p>\n<p>Please don&#8217;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).<\/p>\n<p>Now let&#8217;s think about this slogan: \u201cYou are allowed to think!\u201d<\/p>\n<p>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.<\/p>\n<p>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\u2019s concentration and let them keep the promise. Very nice and logical orientation.<\/p>\n<p>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.<\/p>\n<p>How does Kanban solve this? Let&#8217;s remember the first rule again, \u201cstart by using the ongoing system\u201d. Then, let&#8217;s remember two of Kanban&#8217;s main practices, \u201climit the work in progress (WiP)\u201d and \u201cmanage the flow\u201d.<\/p>\n<p>Why can&#8217;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\u2019s Law (L = \u03bbW), WiP = Lead Time (time) * Throughput (work\/time). If I reduce the number of works I&#8217;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.<\/p>\n<p>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&#8217;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.<\/p>\n<p>Do you think that Kanban is only suitable for maintenance teams in the light of these explanations?<\/p>\n<p>I don\u2019t 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.<\/p>\n<p>Scrum is a revolutionary method, and there will be those who cannot keep up as in every revolution and this will cause trouble.<\/p>\n<p>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.<\/p>\n<p>I didn\u2019t 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:<\/p>\n<p>\u201c#<strong>Scrum<\/strong>\u00a0focuses on being #agile which may lead to improving. #<strong>Kanban<\/strong>\u00a0focused on improving, which may lead to being agile.\u201d \u2013\u00a0<strong>Karl Scotland<\/strong>.<\/p>\n<p>&nbsp;<\/p>\n<p>End of Section 1,<\/p>\n<p>Thank you.<\/p>\n<p>Alper Tonga (<a href=\"http:\/\/linkd.in\/NAp6Ro\"><span style=\"text-decoration: line-through;\">linkd.in\/NAp6Ro<\/span><\/a>)<\/p>\n<p>[\/vc_column_text][\/vc_column][\/vc_row]<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Question everything: this doctrine is adopted by the Kanban community which I follow, with the slogan \u201cNo Dogma\u201d, leaving the door open to different ideas to open the way for the community to improve itself. <\/p>\n","protected":false},"author":1,"featured_media":57693,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[34,21],"tags":[],"_links":{"self":[{"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/posts\/57692"}],"collection":[{"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/comments?post=57692"}],"version-history":[{"count":0,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/posts\/57692\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/media\/57693"}],"wp:attachment":[{"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/media?parent=57692"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/categories?post=57692"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/tags?post=57692"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}