MOST Analysis

Mission Statement

The implementation of Kanban can be made more fruitful by fine-tuning the process and adding ways to monitor and measure the success of the method. The implementation of Kanban principles may seem easy but in practice, there may be many challenges that an organization faces. The Kanban method not only affects the program it is being applied but changes the way the entire organization works. Workflows from one desk to the next only when there is capacity. Products will be procured only when there is a need. These practices, though highly beneficial to the organization overall, may be hard to adopt for all employees. So training and knowledge sharing are important to ensure that all employees are able to recognize the real benefits of using the Kanban system. Once the system is rolling, it is also important to measure its progress and its impact. For this, certain metrics have to be chosen which can reflect how Kanban has improved the process. These metrics could be time-based, productivity-based, and so on. For example, the lead time and cycle time shows the average speed of a team on a task during a given time period. Improvements in the lead time and cycle time are indicative of improvements in the process. Another metric commonly used is Throughput, which gives the number of tasks finished with a given time period. Improvements in Throughput also indicate improvements in workflow. These and other metrics can help to continuously monitor the implementation of Kanban and measure its success.

---

Objectives

01. Never Pass Defective Products: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
02. Take Only What’s Needed: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
03. Produce the Exact Quantity Required: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
04. Level the Production: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
05. Process Optimization – Lead & Cycle Time: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
06. Process Optimization – Throughput: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
07. Kanban Metrics Charts: departmental SWOT analysis; strategy research & development. 1 Month

---

Strategies

01. Never Pass Defective Products: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
02. Take Only What’s Needed: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
03. Produce the Exact Quantity Required: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
04. Level the Production: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
05. Process Optimization – Lead & Cycle Time: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
06. Process Optimization – Throughput: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
07. Kanban Metrics Charts: Each individual department head to undertake departmental SWOT analysis; strategy research & development.

---

Tasks

01. Create a task on your calendar, to be completed within the next month, to analyze Never Pass Defective Products.
02. Create a task on your calendar, to be completed within the next month, to analyze Take Only What’s Needed.
03. Create a task on your calendar, to be completed within the next month, to analyze Produce the Exact Quantity Required.
04. Create a task on your calendar, to be completed within the next month, to analyze Level the Production.
05. Create a task on your calendar, to be completed within the next month, to analyze Process Optimization – Lead & Cycle Time.
06. Create a task on your calendar, to be completed within the next month, to analyze Process Optimization – Throughput.
07. Create a task on your calendar, to be completed within the next month, to analyze Kanban Metrics Charts.

---

Introduction

An overview of the history of the Kanban software development methodology and the significance of the fine-tuning stage

Let’s look at the following exurb. It is from David J. Anderson’s blog post titled “A History of Kanban for Creative Knowledge Work.”

October 2004

Dragos Dumitriu seeks assistance from David J. Anderson, manager of Microsoft’s XIT sustaining engineering. Dragos’ team has a pull mechanism that David designed and helped introduce. Dragos then persuaded his four product managers and his four superiors to support the concept.

The system was implemented by Microsoft Product Studio without the use of a physical board, and the engineering team was located in Hyderabad, India.

The method used operated under the assumption that the test was the bottleneck and was modeled after the Theory of Constraints Drum-Buffer-Rope.

2005

Donald Reinersten followed David to his house in Seattle after seeing him present his flow and FDD material in the winter of 2005 at a conference in Chicago. On the Microsoft campus, David was visited by Donald, who persuaded him to explore Kanban methods.

David makes the choice to go back and redo the XIT implementation as a Kanban system. He finds that not much would alter; possibly the WIP limitations would vary significantly.

David starts referring to the XIT implementation as a virtual Kanban system and presents it the next year in Chicago since he finds Kanban systems easier to describe to others.

The XIT sustaining engineering research was presented at TOCICO in Barcelona in October 2005, and Microsoft later released it as a white paper.

2006

In the winter of 2006, David gives a presentation at the same Chicago conference where Donald had followed him home the year before on the finished XIT narrative as a virtual kanban system implementation.

It is the first time that Kanban systems applied to knowledge work have been shown in public. Only Dragos and David were previously involved.

The Microsoft IT solution was read and used by certain people in the summer of 2006. Notably, Eric Landes from Robert Bosch copied it almost verbatim for use by a team responsible for maintaining an intranet website.

David moves jobs in September of 2006 to work for Corbis as Senior Director of Software Engineering.

He acknowledges that the software maintenance procedure is seriously flawed and collaborates with Rick Garber, the team’s boss, to create a Kanban system.

It was intended to take the place of the current project-centric strategy for small application changes.

Drew McLean, VP of Corbis, recommends the expedite capability—which brought the first alternative class of service to a Kanban system for knowledge work—when engaging with stakeholders.

In November 2006, Diana Kolomiyets, the project manager, and Darren Davis, the development manager for maintenance, took charge of the Kanban implementation.

Diana oversees replenishment meetings every week, plans and coordinates releases every two weeks, while Darren is in charge of standup meetings.
Corbis conducts an operations evaluation of its IT in December 2006. Darren Davis explains the evaluation’s findings after implementing the first Kanban system.

2007

In January 2007, Darren Davis made the claim that the seeming high level of variation inflow was caused by the stasis of improvements following a number of successful releases from the maintenance process. Nobody is sure of what to do next.

He proposes using a card wall that has been set up on a whiteboard across the hall from his cubicle to visualize the procedure. One of his team members came up with this concept. A sign is placed on the wall.

Winter of 2007: Additional improvements are being made to the wall, and space has been set aside for internal needs. For green tickets, there is a WIP limit of two.

David observed a pattern of urgent work with predetermined deadlines. As a type of service, he advises providing a “fixed date” notion.

At the end of this season, what is now known as the Kanban technique emerges, with its six practices and hazards displayed and addressed via capacity allocation and classes of service.

At Corbis, Corey Ladas is employed as a process coach for Kanban after leaving Microsoft.

The new CEO of Corbis inquires in April 2007 as to why the new maintenance procedure isn’t being applied to all aspects of IT if it is performing so effectively. David adopts the idea and introduces Kanban to the entire project portfolio.

Under Corey’s direction, the digital asset management (DAM) project implemented Scrum and Kanban. This two-tiered Kanban board with swim lanes is the first of its kind.

Dan is hired as the development manager for the ERP project in May of 2007. Dan has never used Kanban, yet he and Corey created the project’s methodology.

They transfer the DAM project staff to the ERP project while carrying the two-tiered, swim lane Kanban board with them.

Rick Garber and David attend Donald’s Lean New Product Development conference in Chicago in June 2007. Only 55 people were present in the crowd.

It is the first time the now-famous Kanban approach has been shown, and it includes features like operations review, lead time histogram metrics, classes of service, and metrics for those variables.

David delivers the same speech from June at the conference inside a conference at the Agile Conference in Washington, D.C., in August 2007.
The following day, Karl Scotland, Joe Arnold, and Aaron Sanders, representatives from Yahoo!, are present and speak with David.

They express their admiration for David’s evolutionary approach to change and alternate strategy for achieving agility through the use of virtual Kanban systems.

They clarify that they have attempted to introduce Scrum at Yahoo! but have encountered significant opposition. With the organizations who are opposing, they want to attempt Kanban.

They created a Yahoo! discussion forum where they could share their stories. At Yahoo!, the kanbandev group was created today and is still in use.

2008

At the Agile 2008 conference in August of 2008, Corey Ladas offers more thorough implementation examples. The presentation’s second half focuses on applying Kanban in Scrum-based teams and projects. It serves as the basis for what would be referred to as scrumban.

2009

Published in January 2009, Corey Ladas’ book Scrumban describes how to use Kanban to advance Scrum.

The inaugural Lean Kanban conference, an initiative put up by the kanbandev group at Yahoo!, takes place in Miami in May of 2009.

Jim Benson and David had a meeting to discuss the conference in Miami.

They talk about how using Kanban for personal purposes differs from using it for business workflows (currently referred to as the Service Delivery Kanban).

Everywhere, even the Modus Cooperandi office, there had been a case of personal usage emerging.

Jim Benson releases Personal Kanban in July 2009 as a collection of 12 blog postings.
Jim Benson introduces personalkanban.com in October 2009.

2010

It has been published, Kanban- Successful Evolutionary Change for your Technology Business.

It has evolved into the greatest and most comprehensive guide for putting Kanban systems into practice in companies that employ creative and knowledge workers. Well over 40,000 copies have been sold.

---

Kanban at Spotify

This is likely one of the earliest and most well-known instances of how Kanban Fine-tuning functions in IT, excluding the Microsoft scenario that was previously stated. Scalability was the biggest issue, according to Mattias Jansson, an operations engineer at Spotify. He was implying that the operations staff was unable to develop along with the demands of the business.

They made the decision to use Kanban as their workflow management solution as a result. The group decided to start out easy. The graphic below shows how easily they set up a Kanban IT operations board:

• 3 columns (to do, doing and done);
• 3 horizontal lanes. Two for the main types of service: standard type and intangible stories and an expedite swimlane;
• They set a low WIP limit on the To-Do stage to ensure that the internal, intangible tasks are actually done;
• They also set a WIP limit on the Doing column equal to the number of ops team members minus one.

Image credit: infoq.com/articles/kanban-operations-spotify

After all, it appeared that Kanban helped the Spotify Ops team become more efficient. As Mattias said in an interview “We’ve noticed that our lead times are shorter, we get more internal tasks done, and the departments we interface with are happier.”

---

Fine-Tuning Kanban

To make sure your Kanban process is effective for your team, it’s crucial to fine-tune its effectiveness. You may evaluate the effectiveness of the Kanban system using various key measures. Understanding where there are bottlenecks and how to avoid them in the future depends on keeping track of these metrics, especially for your Kanban retrospective sessions. These metrics range from burndown charts to cumulative flow charts.

Kanban Metrics: What to Measure and Why

In this workshop, we’ll go through the precise Kanban metrics & analytics you should be utilizing to keep an eye on your team’s productivity, the effectiveness of your processes, and delivery times, as well as the warning signs of danger to look out for. In the prior workshop, we only touched on these metrics and analytics in passing. Today, however, we will go into further detail and present concrete examples to deepen our explanations.

Good and Bad Metrics: What Does It Mean?

You should be able to distinguish between excellent and bad metrics in order to avoid being duped by the latter. Metrics are excellent if they contribute to system improvement, to put it simply. They are bad if they reward or penalize specific people.

Metrics are Good if they:

• Are actionable and improve the decision-making process
• Lead to better results
• Portray the state of reality
• Improve behavior

Bad metrics:

• Are focused on the past
• Often lead to bad results
• Are used as targets

The expression “what gets measured gets managed” may be familiar to you. The Kanban Method’s fundamental component for tracking projects and gradually improving process efficiency is tracking progress and measuring performance.

Let’s take a quick look at the key Kanban metrics and how to use them to increase productivity.

Cycle Times

Cycle time, a crucial Kanban indicator, counts the number of steps a task takes to complete. In contrast to lead time, cycle time is only measured from the moment your team begins working on the task.

The metric that accurately gauges how long it takes your team to complete a task is called cycle time. Low cycle times demonstrate effective teamwork, while large cycle times point to a process bottleneck. Reducing cycle times also reduces lead times, which increases customer satisfaction.

Source: Getnave.com

A cycle time histogram can be used to chart your cycle times over time and to forecast when your work will be delivered in the future. The percentile lines in the figure above show that once your team begins working on a task, there is a 50% probability that it will be finished in fewer than 6 days and a 95% chance that it will be finished in less than 13 days.

Throughput

The throughput statistic in Kanban indicates the entire quantity of work delivered in a given amount of time, whereas cycle time monitors how long it takes a single job to complete the process. Nothing that is still in process is counted while measuring throughput; only completed work items are counted.

Throughput is an important Kanban metric since it can be used to gauge your ability to produce results. Consider a Kanban team with an average throughput of 5 tasks per week during the previous 5 weeks: 3, 7, 4, 5, and 6. We can estimate that this team can do 5 tasks per week on average without knowing anything about the tasks themselves.

The throughput histogram is used to measure throughput, which is used to track your team’s performance over time. This charts the frequency with which your team reaches a particular throughput over time. According to the graph below, this team has produced 3 items on average every week over the previous 6 months.

Source: Getnave.com

You can observe changes in your team’s performance firsthand by monitoring your throughput over time. A falling throughput suggests that something is negatively hurting your team’s capacity to produce and requires further attention. Ideally, throughput should remain the same or rise.

Work In Progress

Limiting Work In Progress (WIP), as was addressed in the prior workshop, is a crucial aspect of the Kanban Method for increasing team productivity. Consider this: Do you complete work more quickly when you divide your attention between several projects or when you concentrate on only one?

The ideal WIP limit for your team will vary depending on a number of variables, including the size of your team. However, a good starting point is to put the limit at around the same number as your team size so that everyone can concentrate on one work at a time.

Team Performance

Cycle times (how quickly work is completed) and throughput (how much work is delivered) are the two Kanban indicators that best reflect the performance of your team. To make sure you are giving your customers results, keep an eye on these metrics!

Little’s Law relates cycle time, throughput, and work in progress (WIP). Any system that satisfies the requirements of Little’s Law can use this formula.

Cycle Time = WIP/Throughput

The link between the three fundamental flow indicators is demonstrated by Little’s Law, which states that altering one will have an impact on the other two. For instance, WIP must reduce for a reduction in cycle time.

High throughput and quick cycle times are indicators of a successful team, but consistency should also be observed. You can examine the average value of your Kanban metrics as well as how this data is spread over time via the cycle time and throughput histograms. Your future forecasts are inherently more accurate when your values are distributed over a smaller range.

Cumulative Flow Diagram

The Kanban Method focuses mostly on gradual evolutionary advancements. When used over prolonged periods of time, it is most effective. Cycle time and throughput tracking have already been covered, but the cumulative flow diagram is the true star for looking at process efficiency over a longer period of time.

Source: Getnave.com

The distribution of jobs throughout each process state is depicted in the cumulative flow diagram as they build up over time. The number of tasks present in each process state at any given time is indicated by the color of the corresponding band. Although it is possible to determine the approximate average cycle time directly from the diagram, the main advantage of the CFD is how quickly you can obtain a visual evaluation of the stability of your process.

The way the gradients of the bands alter over time can be used to quickly identify changes in your team’s performance. Your team is producing work more quickly if the gradient for the “Done” band increases. Contrarily, a steep rise in the gradient of the “In Progress” band denotes the onset of a bottleneck.

Bottlenecks

The bottleneck, or growing amount of work that is not being finished, is the strongest warning sign that your performance is about to suffer. The bottleneck indicates that your team lacks the resources necessary to complete the workload given to them in a timely manner.

You may identify bottlenecks as they develop using Kanban measurements. Symptoms to look out for include lengthening cycle times, declining throughput, and a rapid increase in gradient in your cumulative flow diagram.

Source: Getnave.com

When you start to notice bottleneck symptoms, it’s important to look closely at the possible causes. Is there an external demand that could be keeping things from moving forward? Has your work-in-progress cap climbed without your knowledge? If your team’s roles have changed, should duties be distributed differently? You should be able to remove bottlenecks before they become an issue by acting swiftly.

---

The Little-Known Facts about Little’s Law: How to Fast Track Your Way to More Predictable Delivery Systems

Stable delivery methods can help to attain long-term predictability. The phenomenon is eventually defined by Little’s Law. Let’s examine some little-known facts about the law to highlight the real benefits it offers to our business procedures.

What is the Little’s Law Equation?

Imagine that you manage a stylish and hip taco truck. Your organic, grass-fed shitake mushroom and carne asada burritos are well-known. Customers adore you because your freshly prepared tortilla chips paired with zesty salsa verde are the flavor of the season.

Let’s say that every hour, 20 individuals visit your taco truck. They stay for a half-hour, eating and conversing with one another. How many clients would be waiting outside your food truck at any one time?

Little’s Law states the following:

Based on that formula we can calculate that the average number of customers you handle at once is L = 20 * 0.5 = 10 customers.

So why does it matter?

The Purpose of the Law in Project Management

Let’s look at how business leaders use Little’s Law in the real world to make their workflows more predictable.

You can determine the capacity of your systems using Little’s Law. In order to achieve this, the formula can be written somewhat differently:

You must keep in mind the following three crucial points regarding Little’s Law:

• Little’s Law is an unreliable approach to making delivery commitments
• Little’s Law is an equation of averages
• Little’s Law is about examining what has happened in the past

Let’s look into all three in more detail.

Little’s Law Is an Unreliable Approach to Making Delivery Commitments

Most people would argue that the true value of Little’s Law lies in being able to make predictions in the future. So the question is, does the law serve this purpose?

Let’s look into the following example. Let’s say you have an average WIP of 6 items and an average throughput of 2 items per day. This configuration gives your team an average cycle time of 3 days.

What happens if we raise our WIP? The fact is, you cannot say that if you increase the average WIP to 12 tasks and keep the average cycle time constant of 3 days, then your average throughput will increase to 4 tasks/day.