Lean development practices are based on the lean methodologies that have been used successfully in manufacturing processes. Kanban is a lean software development methodology that focuses on just-in-time delivery of functionality and managing the amount of work in progress (WIP).
If you ever have ordered food in a fast-food franchise, then, you have seen Kanban in action! Once your order is taken by the cashier, it goes into a “To Do” queue. The next worker available in the appropriate station advances the order to the “Doing” queue by preparing the sandwich or filling the drink by working on individual items in the order. As each item in the order is delivered to you and all the items are marked completed, the order goes to the “Done” queue! Kanban is a process-driven framework that stands more for continuously improving the process rather than searching for the perfect process!
Kanban is a Japanese term that means “visual signal.” Constrained by resources and supplies, the automotive industry in Japan always sought to increase productivity and throughput by looking continuously for improving “time to market” while giving autonomy to people closer to work for improving the process (Sugimori, Kusunoki, Cho, Uchikawa, 1977). These two main focus areas were the “Just-In-Time” production concepts and “Respect for Humans” and were present since the 1950's paving the foundation for Lean manufacturing. These ideas emerged as the engineers found that supermarket workers stocked the grocery produce based on the inventory needs rather than by vendors and used visual threshold indicators to request new shipments! This visual signal was the birth of Kanban that first made it to the manufacturing context and then into software development!
The Kanban Method is a means to design, manage, and improve flow systems for knowledge work. The method also allows organizations to start with their existing workflow and drive evolutionary change. They can do this by visualizing their flow of work, limit work in progress (WIP) and stop starting and start finishing.
In essence therefore, Kanban is a scheduling system for lean and other Just in Time (JIT) processes. In a Kanban process, there are usually physical (or virtual) “cards” called Kanban that move through the process from start to finish. The aim is to keep a constant flow of Kanban so that as inventory is required at the end of the process, just that much is created at the start.
The core philosophy behind Kanban advocates transparency to the work that is in process through the system so that individuals can interact on the required processes and tools to perform just-enough experimentation instead of settling for status quo! “This lean philosophy is the foundation for the Kanban principles behind the essential Kanban practices of maintaining flow, eliminating waste, and improving continuous learning,” says our Agile Evangelist, Dr. Sriram Rajagopalan. Let us explore these essential Kanban practices now.
We have heard of the saying, “A picture is worth a thousand words!” because the picture creates a mental model of the current and future states as well as the individual steps through which the input transforms into output. In the world of strategic leadership where product management creates the product strategy, this flow of work can be seen in Porter’s Value Chain on how value is created for the customer through the many business processes.
Similarly, the visualization of work and the workflow allows individuals and teams to observe by witnessing and performing Gemba walks to eliminate any risks to successful value delivery! These risks may manifest as blockers, queues, impediments, or bottlenecks. Visualizing the flow of work (the number of cards in each lane) in the workflows (the stages in the swimlane) as indicated in the above diagram allows everyone in the project delivery team and product organization to preemptively address risks to ensure “flow”.
Although many think multitasking is essential, the concept of leaving one task incomplete to pick another task and return to the original task introduces the possibility of no work being completed. Furthermore, more time is spent in context switching understanding where the earlier tasks were left. Lean highlights that balancing multiple tasks simultaneously causes less productivity due to the waiting times introduced and recommends limiting the work in progress can gain focused attention on the work at hand. In fact, Kanban referred to the concept of “Doing As Late As Possible” limiting working on the requirements that are less clearly understood.
Frequently, when too much work in progress exists, there is a larger overhead to lengthy queues. Sometimes, people think of these WIP limits as a visual checklist. On the other hand, Kanban is not a to-do list but puts limits on the work in process to avoid waiting times and resource bottlenecks. In the diagram above, you can see a WIP limit applied on the “In Progress” column that visually indicates exceeding capacity. The focus therefore shifts from managing many things and finishing fewer things to focusing on few things and completing them fully. This practice is analogous to the statement, “A bird in hand is worth more than two in the bush!”
Once the work is visualized on what delivers value and WIP limits are set to reduce the adverse effects of task switching, one can focus on optimizing the flow! All the items in the Kanban board are part of the “systems thinking” approach to move unprocessed items on the left to completed items on the right. The goal here is to observe where work gets stuck and get them unstuck because the ‘show must go on!” It could be a lack of training on the processes and tools or limited collaboration among team members, for instance.
Managing Flow, therefore, pivots on all aspects of people, process, technology, and organization to evaluate if one should start doing things to improve flow, stop things that are not adding to the flow, and keep doing things different to augment flow. These learnings come from the daily meetings, lessons learned or retrospective sessions, or review sessions.
As the organization identifies opportunities to improve the system, this knowledge is “written in” to the Kanban board itself. This allows us to capture and preserve organizational learning by building it into the system we use to manage our work – the Kanban board. There are many ways to modify a Kanban board to make process policies explicit. One is to redesign the board to specify how the work flows. Another is to use WIP limits to explicitly state our policy about how much WIP we are able to take on.
While managing the flow, lessons are learned. Kanban emphasizes that the systems reveal how work flows through the value stream monitored through the Kanban board for people to continuously improve. This continuous improvement is the basis of Kaizen. Some think of these improvements in terms of measuring lagging indicators like the number of risks impacting flow, WIP limits, and lead time. Therefore, typical discussions in the retrospectives may revolve around the number of cards blocked, total number of blocked days, the number of cards completed per week, and the various areas that block cards.
However, Kanban also promotes qualitative learning, such as the exploratory and experimental approaches to innovations attempted. These innovations may be radical and are called Kaikaku. For instance, this new knowledge gained from radical innovations may lead to a new product development, promote better understanding of the processes for faster implementation of feedback loops, and aid the cross-functional team knowledge for capacity, transition, and succession planning, and foster team cohesion to collaborate on business value.
Lean Software Development is a set of principles to deliver software according to the principles of lean manufacturing. In a lean environment, activities or processes that result in the expenditure of effort and/or resources towards goals that are not producing value for the customer should be eliminated. Essentially, lean is centered on preserving value with less work. Lean approaches are the building blocks of Six-Sigma and Just-In Time (JIT) development.
When used for software development, Kanban uses the simplified stages in the software development lifecycle (SDLC) to represent the different stages in the manufacturing process. The aim is to control and manage the flow of features (represented by Kanban cards) so that the number of features entering the process matches those being completed.
Kanban is an agile methodology that is not necessarily iterative. Processes like Scrum have short iterations which mimic a project lifecycle on a small scale, having a distinct beginning and end for each iteration. Kanban allows the software be developed in one large continuous development cycle. Despite this, Kanban is an example of an agile methodology because it fulfils all twelve of the principles behind the Agile manifesto, because whilst it is not iterative, it is incremental.
The principle behind Kanban that allows it to be incremental and Agile, is limited throughput. With no iterations a Kanban project has no defined start or end points for individual work items. Each work item can start and end independently from one another, and work items have no pre-determined duration for that matter. Instead, each phase of the lifecycle is recognized as having a limited capacity for work at any one time. A small work item is created from the prioritized and unstarted requirements list and then begins the development process, usually with some requirements elaboration. A work item is not allowed to move on to the next phase until some capacity opens up ahead. By controlling the number of tasks active at any one time, developers still approach the overall project incrementally which gives the opportunity for Agile principles to be applied.
Kanban projects have Work In Progress (WIP) limits which are the measure of capacity that keeps the development team focused on only a small amount of work at one time. It is only as tasks are completed that new tasks are pulled into the cycle. WIP limits should be fine-tuned based on comparisons of expected versus actual effort for tasks that complete.
Kanban does not impose any role definition as say, Scrum does and along with the absence of formal iterations, role flexibility makes Kanban attractive to those who have been using waterfall-style development models and want to change but are afraid of the initial upheaval something like Scrum can cause while being adopted by a development team.
Although Kanban systems emerged from the automotive space, they are equally important in software product development and management. In this section we will discuss some of the key benefits of using the Kanban methodology.
For many companies, the strive for business agility is driven by the need for flexibility. With no prescribed phase durations (unlike other Agile methodologies such as Scrum), features are released as soon as they are completed. Kanban therefore supports the “release on demand” considerations even in scaled agile implementations. By using a Kanban roadmap rather than relying on a rigid general project plan, product managers are free to reassess immediate priorities based on changes in the market. The Kanban Method suggests an approach of backlog management that helps teams become more self-managing whilst bringing transparency and consistency to the decision-making process.
Limiting WIP and limiting each column of the board's WIP limits helps team members finish what they're doing before moving on to new things and sends a message to the customer and other stakeholders that there is limited capacity. In practice, this discipline was found to result in reduced cycle time (the time taken to complete a task on average).
Kanban paved the foundation for how value can be maximized in a process by limiting scope to fit a schedule. By limiting the flow for specific process steps that have high contention for resources (e.g. software integration testing), Kanban avoids bottlenecks at key processes in the software development lifecycle.
The “visualize flow of work” concept of Lean and Kanban focuses on transparency to the process by which work items will be formally recognized. The use of a backlog with full transparency of work item flow coincided with, the “definition of ready” and “definition of done” to pick an item to enter the and exit the workflow queue. Kanban helps facilitate a clear definition of the queue itself because of this “visualize flow of work” practice, thereby increasing the visibility of flow in the entire software development lifecycle.
The goal of continuous delivery is to rapidly, reliably and repeatedly deliver new features and bug fixes at low risk and with minimal overhead. The goal of Kanban is to optimize the flow of work through incremental change. Both approaches share the common objective of delivering value to the customer faster.
Kanban and continuous delivery also complement each other with their shared objective of process improvement. Continuous delivery, which can be delayed by manual effort and human error, often uses automation to make processes more efficient.
Implementing WIP limits and ensuring the Little’s Law assumptions are met keeps your process operating as a stable system. According to Little’s Law, the customers stationary in the system (WIP) is the product of long-term effective arrival rate (Throughput) and the time the customer spends in the system (Lead time).
To improve throughput, the rate of tasks being pulled in should be roughly equal to the rate of tasks leaving. A stable system is a predictable system – one that enables you to make data-driven decisions. Most importantly, Kanban doesn’t require you to revamp your process to begin seeing these benefits. It works by implementing incremental, evolutionary change to make your workflow more efficient and your team more productive.
In any software project, there are dependencies on work items. Kanban offered support in these areas by looking at impediments to flow! Whether it is a overworked process, undocumented procedure, untrained people, or poorly calibrated system, Kanban used the combination of managing flow and continuous learning to relentlessly avoid anything that contributed to any type of waste.
Kanban cycle time is calculating the actual work-in-progress time. It tracks how long a task stays in the different process stages. Keeping track of your cycle times enables you to measure your team performance. Low cycle times mean that your team is efficient. High cycle times indicate stalls, bottlenecks, and backlogs. Keeping cycle times down keeps lead time down – and fast lead times mean high customer satisfaction. So a side benefit of the reduced cycle times explained earlier, is the fact that it will lead to improved overall customer satisfaction.
Both Kanban and Scrum facilitate projects to deliver value incrementally and iteratively. Each approach here has so much rich history and practical considerations that the discussion on Kanban versus Scrum requires a separate blog. However, to complete this blog with some key ideas, some ideas are advanced.
SpiraTeam® is a complete Kanban project management system in one package, that manages your project's requirements, releases, tasks and bugs/issues. Designed specifically to support agile methodologies such as Kanban, it allows teams to manage all their information in one environment.
SpiraTeam provides a Kanban view of the project, where you can see all of the requirements planned for each release organized according to their position in the lifecycle. This view lets you see the flow of the requirements and identify then rectify any bottlenecks:
SpiraTeam has dedicated Kanban boards for tasks and incidents / defects, so that it makes it easy to run both development and maintenance projects using the same system:
SpiraTeam lets project managers define the Work In Progress (WIP) limits for each of their releases (and sprints).
Work In Progress (WIP) limits set the maximum number of requirements that the product team can efficiently manage at each stage of their Kanban process. Using WIP limits can be a useful way for teams to manage their work, allowing them to get through their work faster. This is done by focusing only tasks that can be done now (in other words, the work that can in-progress at any one time).
When you have WIP limits configured in the Planning Options you will see the new WIP X/Y pill shaped badge in the planning board headers when you choose Group by Status:
This pill shaped badge is displayed on each relevant status, along with the number of requirement cards in that status for that release/sprint.
SpiraTeam® provides reporting dashboards of key project quality and progress indicators - requirements test coverage, task progress, project velocity, as well as top risk and issues – in one consolidated view that is tailor-made for Kanban projects as well as supporting your legacy/hybrid waterfall projects.
In addition, we provide superb technical support that ensures that enquiries and questions are dealt with in a timely and professional manner.
To learn more about SpiraTeam and how it can improve your Kanban project management methodology, please:
One of the key tenets of both Kanban and Lean methodologies in general is that continuous improvement is central to improving the flow of work through the system. The unrepeatable nature of manual testing (whilst great for finding unexpected issues) is not sufficient for a commitment to continually improving quality.
You need a test automation solution that can be integrated fully into your development process and that be adapted to your changing needs and be used to increasingly automate your testing process through each release, improving repeatability and consistency:
Rapise is the most powerful and flexible automated testing tool on the market. With support for testing desktop, web and mobile applications, Rapise can be used by testers, developers and business users to rapidly and easily create automated tests that integrate with your requirements and other project artifacts in SpiraTeam.
One of the obstacles to implementing test automation on an agile Kanban project is that the application’s user interface may be changing frequently, with new pushes to production daily. Therefore, it is critical that tests created one day, continue to work seamlessly the next.
Rapise comes with a built-in machine learning engine that records multiple different ways to locate each UI object and measures that against user feedback to determine the probabilistic likelihood of a match. This means that even when you change the UI, Rapise can still execute the test and determine if there is a failure or not.
To learn more about Rapise and how it can improve your Kanban software testing please:
And if you have any questions, please email or call us at +1 (202) 558-6885