by Jeffrey Ries
Progress reports reach managers organically. If your company is using Kanban software or apps to monitor the process, many provide analytics to illustrate the volume of products being constructed and the time frame required for completion. A more integrated Kanban software system can provide a variety of reports to help with improving, organizing, and planning the workflow accordingly.
Decreases archaic inventory. Excess inventory causes a lot of extra work and consideration for a manufacturer. In addition to finding storage space for it, the company must determine how long to hold on to it, and what to do when it comes time to get rid of it. For example, the manufacturer can decide to throw it away or give it away or try to sell it themselves. Also, when there is stagnant inventory, damaged inventory is more likely to continue downstream. Finding a problem during shipping is the worst-case scenario, especially if it has been taking up time and space for several months. Once it hits the floor the options for dealing with it are limited. It is best to decrease inventory that is not being immediately handled.
Overproduction rarely occurs. Pulling only happens when materials are needed. Necessity is determined by the demands of the customer. This process means that all the products are selling, and no excess is created.
Cons of using Kanban’s Inventory Manufacturing Process in Lean Manufacturing
Before jumping head first into a Kanban inventory management system, you need to do a few things that take time and consideration. First, you must observe the number of materials already being used. This will tell you the amount of stock needed for reordering. This observation can take a large amount of time, depending on your products. This means bins and material levels in the bins will fluctuate as you respond to the patterns and needs. This observational period can slow down production. Production can also be delayed if you do not factor delivery time properly for restocking bins. Consider a bin filled with seven materials. The line takes about 14 days to deplete the bin. This means the supplier will need to deliver more stock between 10 to 12 days. Otherwise, your production will lag. It is common to have these types of delays or fluctuations during the initial observation and implementation period.
How to Create a 2-bin Inventory Management System
After you have established a firm grasp on your inventory flow and reordering methods, you will need to implement your 2-bin inventory system. It will take a bit of time to work out the “kinks,” but after a while, you will get it to work seamlessly. Below is a mathematical system developed by Oracle that can assist you:
D * A * (L + SSD) = (C – 1) * S = Amount of Materials per Bin
D = Avg. demand for a particular product each day
A = Apportionment currently
L = Replenishment time required for inventory
SSD = “Safety Stock Days”
C = Quantity of cards
S = Size of board
“Safety Stock Days” refers to a “buffer” of time added between when a delivery should arrive and when it is needed on the floor. This is used in case an emergency arises or there is a problem with the shipment.
Software for Inventory Management
Over the past few years tracking inventory and materials have become easier than ever thanks to the introduction of things like software, RFID, and barcodes. Software has been developed to provide automated solutions to a Kanban process. Using a combination of the two-bin visual system with an integrated Kanban software system, your production line, and inventory management has the opportunity to become efficient and profitable. Integrating and automating a Kanban process helps direct your entire supply chain. Besides watching for the signal and restocking materials when needed, the system can track lead times and replenishment times. It can also alert you if a material will be replenished in time for the line or if it is going to cause a delay. The system provides reports about how well the line is producing and what products are selling. Even in a lean manufacturing setting the Kanban production process crosses several departments, so it is important to manage it properly and allow stockholders to view the process.
Chapter 4: Applying a Kanban Process to Software Development
Software development has been using various project management philosophies for decades now, but that raises the question why you would choose a Kanban system over other methodologies, such as SCRUM, or resources, similar to a Gantt chart? To begin, you need to review the differences between the main methodologies.
Kanban vs. Other Methodologies
SCRUM is still a popular project management process used in software development today. While it is another successful, agile project management approach, there is a major difference between the Kanban process and SCRUM.
For example:
A Kanban system does not include time boxes like SCRUM requires.
A Kanban system has fewer tasks, and they are larger than SCRUM tasks.
A Kanban system does not assess the process often, if at all, as it does in a SCRUM environment.
A Kanban system only considers the average completion time for a project instead of basing project time on the "speed of the team," like in a SCRUM setting.
For practitioners who are used to the SCRUM environment, thinking that a project is made up of the team's speed, increased dimension, and scrum meetings, may find the idea of removing them outrageous. Those activities are the primary methods for controlling development in a SCRUM system! The real problem with this concept is the illusion of control. Managers are constantly striving for this control, but the reality is that they will never obtain it. A manager's supervision and influence only work if the team wants to work. If they collectively decide not to push for a project’s completion, it does not matter what the manager does; the object will fail.
Imagine a different scenario: one where people have fun at work and work efficiently. Managers then need not control the environment. Control in this setting would actually disrupt the situation and raise the cost. In a SCRUM setting, controlling measures add costs by requiring constant discussions, meetings, and time commitments during the changing of sprints. Most sprints require one day to wrap up and one day to start the next. Those extra days could be considered "wasted" opportunity. If you look at it as a percentage, a 2-week sprint requires 20% of the time to be spent in preparing and wrapping up. That is a lot of time! In some SCRUM environments, as much as 40% of the time can be spent on supporting the methodology and not on completing the mission.
The Kanban system; however, focuses on tasks. This differs greatly from a SCRUM process. SCRUM practitioners want a successful sprint. Kanban practitioners want completed tasks. Tasks in a Kanban system are approached from start to finish, not bound to a sprint time frame. The completed work is presented, and the project is deployed based on when it is ready. Tasks do not have an estimated time for completion set by the team. The reason is that there is no need for this time estimate, and an estimate is often wrong, anyway. If a manager believes and supports their team why would an estimate be necessary? Would not the team want to produce the best they can in the fastest time possible? The manager instead focuses their own attention on developing a pool of prioritized tasks. The team's focus is on completing as many tasks as possible from the pool. It is that simple. Control measures are unnecessary. Managers add items to the pool and reorganize the priorities of tasks as needed. That is how a Kanban practitioner runs a software project.
Sample Kanban Lists for Software Development
Sample lists or columns on a Kanban board for software development include:
GOALS. Useful but optional. Major goals can be placed here. This is more for a regular reminder to the team than it is an actionable list.
STORY. On-deck tasks are placed on this list. The card on the top is the highest priority. The team then takes the top card and moves it to the next column, typically labeled “develop.”
ELABORATE AND ACCEPT. Other descriptions can be used for this column before they proceed to the "done" list. Each team and workfl
ow differs from one another. Anything that is uncertain for the team's approach, like an approach to a code that is unfinished or designs that are not determined, can be assigned to this list. The team then needs to discuss and decide on how to handle it before moving it to the next list.
DEVELOP. Until the task is complete, the card stays on the “develop” list. It does not matter what needs to be completed for the card or task, but if there is anything that needs to be done before the task is complete, it is placed on this list.
DONE. Once a card is on this list, it indicates that the task has been completed. It signals to the team that nothing further is needed for this task.
This suggested layout means that any list or column can contain a high-priority task. Each task on the board should be completed as soon as possible. Sometimes there is a column made for only high-priority items. This could be in the “goals” column, or another column labeled “expedite.” This signals the team that all items on the list need to be completed first. This means anything placed on this list are of the highest importance only. All other items should be placed on the “story” list until “expedite” items are finished.
Other interesting features on a Kanban board are the numbers located under each list or column. These numbers determine the number of cards, or tasks, that are permitted to each list. This is also called “work in progress” or “WIP’s.” These numbers are not scientifically determined but are rather chosen by the manager according to their discretion. Typically the number is related to the number of developers assigned to the list. It represents the capacity of the team for work. For example, if there are eight developers, "develop" may be given a number four. Putting two will result in bored team members, and they will talk to each other too much. Putting eight will result in each person working on their task but staying on the list too long. This means the focus on the Kanban process is forgotten; the length of time spent on a task to be completed from the start until the finish is not shortened.
The Benefits of a Kanban System to the Software Development Team
There are several reasons a Kanban process is beneficial to your software development team. To start, several tasks can be completed at one time, cutting back on the time required for completing each of them. The actions taken are only the necessary ones, so there is no switching frameworks or tracking various articles. Planning is unnecessary. Tasks are developed when the project begins, not before. Next, "showstoppers" or problems in the process are identified and solutions are found together as a team to keep the process moving forward.
For example, if a task requires the assistance from another department, but the other department is working on another series of tasks, the production of the project must halt. But an efficient Kanban team recognizes the need for teamwork and will band together to solve the problems so all departments can continue to function efficiently. Finally, it is possible to calculate the completion time of average tasks. Cards can be tracked according to their initiation date, all movements on the board, and when it was completed. Even wait times between each step can be averaged. This information can be valuable to a manager's calculations for planning purposes.
The Rules of Kanban
There are only 3 primary requirements in a Kanban setting, even for software development:
Production is visual:
Tasks or cards are created to divide work. The cards are then added to the board.
The board contains lists presented as individual columns. Cards are located in a column in order of priority.
Each part of production works to minimize WIP, or “work in progress,” which refers to the maximum amount of work being completed concurrently.
Shortening the amount of time spent on the process is the purpose of consistently working to develop the system and determine the average time for a task to be completed. This time is determined by measuring the time for each step in the production cycle.
These are the only three requirements of a Kanban system! SCRUM contains nine primary requirements. XP requires 13. The traditional RUP process has over 120! This alone illustrates the major difference and benefit of Kanban in software development.
Chapter 5: How Kanban Reduces Risk and Creates Improved Software
It is amazing that a pull system created by a supermarket and adapted to a car manufacturing company can help software development companies create quality products with reduced risk, but it works. The largest difference is that instead of pulling physical materials from bins, the Kanban agile project management system improves organizational throughput in a software environment. Tasks are “pulled” into the work pipeline when it is required. Schedules and forecasts are not what “pushes” it into production.
Throughput is improved in a software system by:
Reducing WIP, or work in progress
Every development phase is unassumingly observed
Predictability of an organization is improved through metrics and reports
Minimal impact results from steps towards change that are incremental, evolutionary, small, and continuous
Capacity to self-manage is developed by motivating and increasing opportunity for the teams
The actual management of tasks and knowledge of work processes is promoted through the team
The risks and issues facing the team are discussed objectively and rationally
Software teams accomplish these actions by following a Kanban process.
Work is Visual
The board is the tool used to show the various stages of work at a micro-level. Using this tool highlights the problems and roadblocks before they become a devastating "fire." At a very basic level, the board contains three lists or columns. They are "to do," "doing," and "done." By showing them in columns, the team can easily identify what is left in each phase. This process simply shows the progress of a project without having to update a stakeholder manually by other means like a call or email.
Visualizing the work assists the organizational throughput by:
Breaking down individual steps from “A” to “Z”
Every step includes a column, or list, to facilitate a smoother pipeline execution and delineation
Easier at-a-glance monitoring is thanks to the color-coding assigned to various types of work if used
Work status is available in a central location to inform relevant people of the progress of the project
Cards can be moved from column to column easily, updating team members in real-time so they can swiftly act on any problems or challenges early on.
WIP is Limited
Using up your time multitasking is something to be avoided in an agile environment. Taking on several tasks at one time opens the developer up to making more errors, each deliverable takes more time, and the cycle for delivery takes longer. The limits placed on the WIP means nothing can be added until something is removed and the limit is chosen in relation to the capabilities and capacity of the team. When each phase is able to take on more work, it is pulled from another place, not pushed on top of existing expectations.
Projects are divided into smaller pieces, and each is tackled independently in a Kanban process. This makes workflow steady and swift. Limits clog the pipeline, but for a valid reason. When something clogs the system, the team is in charge of "cleaning" the clog before adding in new work to the pipeline.
WIP limits assist organizational throughputs by:
Maintaining time management through an effective structure and system. No matter the size of the team or how complex or simple the project is there is an unvarying process for each task to be finished in a limited timeframe.
A smooth workflow removes waste from your schedule, resources, and cost. In addition, it eliminates work that is unnecessary. This is the primary function of limits for WIP.
Changes are Incremental
Changes that are completed incrementally develop your current actions in an effort to continually move the project forward. Identifying the joints in the
system that cause work to back up is another benefit of a Kanban system. WIP limits are engaged in an early stage to complete work fast and inject new work in a controlled manner. As work moves to each new stage, the limits placed on WIP are refined and the phases change, the improvements to the workflow are more obvious. "Evolutionary" is the term applied to the Kanban methodology because the approach to the work is completed in bite-sized increments.
Incremental changes improve throughput by:
● Constant improvement accomplished at each stage of the process. All the way until the final, “done” step the results are quality deliverables and final outputs are less prone to errors.
Flow Enhancement
In a traditional environment, sometimes the developers can lack the understanding of what to do following the completion of the task they were assigned. This confusion probably occurs because the earlier work had a bug found in it. If this occurs, the developers do not understand what their next course of action should be because the work is considered finished and they have already pulled new work up and updated the board. Implementing a Kanban system prevents this from happening because the next work task that is pulled onto the board and placed in a list is the highest priority task in the backlog.