The Key Principles of Kanban for Software Developers
For the right kind of work, Kanban is a very simple scheduling system to learn and implement. Here are the principles on which it operates:
- Visualize the Workflow: The simplicity of Kanban emerged from Toyota’s realization that people understand visual cues better than they do text or other modes of communication. In a Kanban framework, each piece or batch of work is represented by a colored card called a Kanban card, which is moved across a Kanban board that represents the entire production or development workflow.
- Limit Work in Progress: Using Kanban cards on a board makes it easy to track the number of work items in any stage of the production process at a given moment — provided, of course, that you track progress regularly. Having too much WIP makes it hard to identify bottlenecks, and may also result in a loss of focus or increased defects and mistakes.
- Enhance Flow: By limiting the amount of WIP and identifying bottlenecks, you can optimize the progress of work through the workflow (the flow) so that work items spend less time being processed.
- Pull Work: One of the defining characteristics of Kanban is that it determines output by actual demand rather than by output targets. Overall, this approach reduces inventory costs, especially in conjunction with a JIT system. (Of course, this particular benefit may not apply to software development.) The pull production system is also more responsive to customer demand and typically results in less waste, even in the production of intangible goods.
- Measure and Shorten Cycle Times: Improving flow is a data-driven process. Actions such as reducing the amount of work in progress and improving the rate at which work items are processed are most effective when they are part of a larger strategic effort to measure and shorten the length of production cycles. This effort may necessitate steps, such as adding resources to remove bottlenecks.
- Implement Feedback Loops: Since Kanban is associated with the Lean methodology, the idea of continuous improvement is built into its philosophy. Feedback loops allow team members and other stakeholders to compare expected with actual outcomes. Based on what they learn, they can implement improvements to reduce waste.
- Make Policies Explicit: Communicating policies clearly and effectively is one of the core Kanban properties identified by Kanban pioneer David Anderson in his book Kanban – Successful Evolutionary Change for Your Technology Business. Practitioners say this principle is essential in order to successfully implement Kanban and harness its potential for incremental improvement. Policies refer to the rules that apply to workflows and processes to make sure they stay efficient. Examples include limits on change requests and WIP. You can make policies explicit by discussing them with the team and your customers as well as by writing them on the Kanban board. Some electronic tools also allow you to set automatic policies.
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
The Origins of Kanban in Japan
Kanban is an element of the vaunted Toyota Production System (TPS). Once termed JIT manufacturing, TPS was the precursor of what would come to be known as Lean manufacturing. The system was developed by Toyota industrial engineer Taiichi Ohno, the acknowledged “father of the TPS” and the theorist behind the concept of the seven wastes.
Kanban was introduced as a sort of manufacturing communications system to facilitate JIT manufacturing. The idea originated in Toyota’s 1940s studies of supermarkets, where customers only purchased what they needed at that time and the supermarket only stocked what it expected to sell. This approach optimized product flow between supermarket and customer and matched inventory to demand, thereby reducing inventory costs. The exercise led Toyota to visualize downstream processes in a production chain as “customers” of their upstream processes; that is, they drove the demand for upstream processes to produce intermediate products. For Toyota manufacturing, this meant aligning inventory with the consumption of materials.
Early iterations of the Kanban system consisted of passing a physical Kanban card to work teams upstream to signal that manufacturing capacity had opened downstream. The card represented demand for a known number of intermediary products. For example, if a bin of materials used in production was emptied, a Kanban card was passed to the warehouse that detailed the type and quantity of materials needed to replenish the bin. The warehouse would restock the bin and then pass the Kanban card on to the supplier, who would request a new stock of materials.
Toyota had six rules for their Kanban system. Although Kanban has evolved over the interim decades, the concept of JIT production is still central to the model. Customer processes (i.e. downstream processes) draw items in the precise quantity specified on the Kanban card. Likewise, upstream processes produce intermediate products in the precise quantity specified on the Kanban card. Items are not produced or moved without a Kanban card, and a Kanban card is always attached to items. Defective items are never passed downstream, so, in theory, the end product is always defect-free. The number of Kanban cards increases the system’s sensitivity to change or problems.
Kanban’s History in Software Development
Software practitioners began to harness Kanban’s benefits for software development around the turn of the millenium, and their writing about these experiments drew widespread attention. One of the earliest uses was described by David Anderson in his 2010 book Kanban, spanning projects from 2004 to 2007 at Microsoft and Corbis that went from Kanban-type pull systems to the card system we’re familiar with today.
Books in 2009 by Don Reinertsen and Corey Ladas helped spur the method’s rise to popularity. Reinertsen describes Kanban adoption as part of a second-generation Lean product development methodology, and Ladas posits Kanban as an improvement on the Scrum methodology for software development.
In their 2011 book Personal Kanban, Jim Benson and Tonianne DeMaria Barry took the Kanban concept and applied it to individual and small-group production processes. Mike Burrows’ Kanban From the Inside in 2014 explains what makes Kanban tick and how it relates to preceding models of development. Klaus Leopold’s and Siegfried Kaltenecker’s Kanban Change Leadership in 2015 explores Kanban from the perspective of managing change. Among other contributors to Kanban’s adoption for knowledge work were Net Objectives’ Alan Shalloway, Lean and Agile consultant Karl Scotland, and 2010 Brickell Key Award winners Alisson Vale and David Joyce.
As in Kanban for manufacturing, Kanban in software development — and in other knowledge work applications — seeks to manage and improve product delivery systems. The emphasis remains on JIT delivery and controlling the amount of work in progress. Work items are visualized as Kanban cards on a Kanban board. The board must be kept up to date, which requires real-time communication of capacity and full transparency.
If you follow these requirements, team members across the workflow can see the progress of specific work items at any given point in time. This visibility enables staff members to balance demands with capacity and systematically address bottlenecks in the workflow. Ultimately, the visual nature of Kanban makes it easy to determine where work is piling up.
How to Apply Kanban’s Values to Your Software Process
For some teams, Kanban might seem like merely a method for task communications. While the Kanban system certainly does this, Kanban is a Lean method, so the mission of continuous improvement, known in Japanese as kaizen, is central to its values. Lean software development thought leaders Mary and Tom Poppendieck argue that effective software development, though practically dissimilar from Lean and the Toyota Production System, shares the same principles as those management philosophies. Three principles power a Kanban workflow improvement process:
- Start with What You Do Now: Kanban does not dictate an optimal workflow from scratch; instead, it improves on existing workflows. Knowing that Kanban does not entail sweeping changes can make the system easier to adopt for some teams.
- Pursue Improvement through Evolutionary Change: At the heart of the Lean methodology is continuous improvement. Realize that continuous improvement isn’t a matter of throwing the entire workflow out and starting fresh, but one of identifying specific areas where waste might be reduced. Target these one at a time in an evolutionary process.
- Encourage Acts of Leadership at Every Level: At Toyota, the upper management realized that inspiration for kaizen came from those closest to the work processes: the shop floor workers themselves. This helped empower workers throughout the organization to refine work practices. Of course, software development teams don’t have shop floors, but the principle of empowering those closest to the work in order to improve processes still stands.
These three principles are, in turn, built on a set of nine values. The Kanban values separate teams who use Kanban merely as a communication method from those who harness it as a Lean evolutionary technique.
The first of these Kanban values is transparency — in terms of the visibility of work processes, decision making, and customer insight into how the workflow operates. The first two of these are integral to visualizing workflows, while the third enables processes to be better tailored to customers’ specific needs. A related value is customer focus, since development processes ultimately seek to satisfy customers, and it’s important to know which workflow processes are creating value for customers.
Workflows cannot be changed without an understanding of exactly what that change entails, as well as an assessment of what a development workflow looks like before Kanban is adopted and kaizen is applied. And, when change is deemed necessary, it must be founded on agreement and respect, or it runs the risk of being divisive and disruptive. Ultimately, change through Kanban must be a harmonious, collaborative process that focuses on all stakeholders in a development process.
Another Kanban value is balance, which can be thought of as the result of managing work in progress so that focus is maintained, if not increased. To borrow a phrase from Taiichi Ohno’s book The Toyota Production System: Beyond Large-Scale Production, teams “stop starting and start finishing” and create a flow of work that allows for predictable outcomes, which keeps both the customers and the workers happy. This is true whether the eventual product is a car or a software application.
Lastly, a kind of grassroots leadership — empowering participants in a process to take charge of and initiate improvement — remains a treasured aspect of kaizen and hence of the Kanban process.
How Kanban Benefits Software Development
We have covered a lot of theory, but you’re probably interested in knowing what Kanban can do for you. Here are the benefits that the system offers a typical development team:
- Planning Flexibility: By reducing WIP and focusing on completing projects already underway instead of beginning new ones, developers can stay focused on the tasks at hand. If the product owner (who determines what the released product is supposed to look like) maintains the backlog by reviewing and prioritizing user stories so that important items stay at the top, the development team’s work remains uninterrupted. The system simply pulls tasks from the backlog as capacity opens up, which makes prioritization easier. In Kanban, the fixed-length iterations (called sprints) seen in Scrum can seem redundant, since tasks are completed and delivered in a continuous sequence. That said, product owners shouldn’t keep developers in the dark about backlog prioritization either. Oftentimes, estimates for items in the backlog are contingent upon other work. Reprioritizing may impact those dependencies and make estimates inaccurate.
- Shortened Cycle Times: The cycle time, which is how long it takes for a unit of work to travel through the workflow, is a critical metric for Kanban teams. While shorter cycle times have obvious benefits on their own, optimizing cycle times can also improve the accuracy of delivery forecasts.
In general, having team members with overlapping skill sets will shorten cycle times. Depending on the size of the team, having only one or a handful of individuals who possess a specific skill can create bottlenecks and extend cycle times. To remedy this problem, specialists can train teammates in skills that are in short supply — this not only removes bottlenecks but also allows developer teammates to pitch in where needed with more flexibility. Developers may also take on nontraditional tasks like testing. In a Kanban system, maintaining the flow of work is everyone’s responsibility.
- Fewer Bottlenecks: Aside from a scenario in which a team possesses overlapping skill sets, Kanban recognizes that multitasking is a productivity killer. That’s why the system seeks to minimize work in progress. The limits enable team members to dedicate their full attention to accomplishing a task. Limiting the work in progress also makes it easier to spot bottlenecks and backups, especially given the visual nature of the Kanban system. But limiting work in progress doesn’t have to be needlessly complex. For example, setting a limit that no more than two work items are in the code review stage at once can help developers stay focused on the unappealing task of reviewing other people’s code. In the long term, this tactic can improve overall product quality.
- Visual Metrics: While a Kanban board provides transparency into the system design process, it’s not the only aspect of Kanban that lends itself to visual management. Tracking a few straightforward data points can produce important insights for a Kanban system. Two tools commonly used to report these points are the control chart and the cumulative flow diagram.
- Control Chart: The control chart is simply a tracker of when tasks (or issues) are undertaken, how long each takes, and the average and rolling average of the processing time. All of these data points exist on the same axes, so it’s easy to spot deviations in cycle times. A decrease in average cycle time is an indicator of increased development efficiency.
- Cumulative Flow Diagram: The cumulative flow diagram tracks the cumulative total of issues in the to do, doing, and done stages over time. Stacked issues in the to do or doing stages is a good indicator of a blockage or slowdown. Teams can use this information to identify problems.
- Control Chart: The control chart is simply a tracker of when tasks (or issues) are undertaken, how long each takes, and the average and rolling average of the processing time. All of these data points exist on the same axes, so it’s easy to spot deviations in cycle times. A decrease in average cycle time is an indicator of increased development efficiency.
- Continuous Delivery: Continuous delivery is the practice of releasing work to customers frequently — as often as daily or even hourly. Since Kanban originated in JIT, it lends itself quite well to continuous delivery of value. Moreover, taking a product to market quickly is an undeniable competitive advantage for any development team.
There are other advantages to Kanban, too. In projects where priorities change quickly and frequently, Scrum can be problematic. Kanban, on the other hand, allows for frequent priority changes. By balancing demand against throughput, Kanban remains centered on the customers. And, as we’ve touched upon previously, it doesn’t require an organizational shake-up to implement, but rather focuses on small incremental improvements to existing processes.
As a Lean method, Kanban facilitates waste reduction and the elimination of activities that don’t add value. A smoothly running Kanban system shortens lead times and increases productivity.
In addition, Kanban mitigates the start-stop nature of non-Agile development practices, like the old Waterfall method. Some Kanban advocates suggest building slack time into a Kanban system, which can enable pause for thought and the ability to swarm to bottlenecks when needed. These strengths can help form a high-maturity organization that can consistently meet its delivery goals. Furthermore, the kaizen-inspired empowerment associated with Kanban improves employee satisfaction.
The Kanban Board and Cards Offer Visual Cues
The Kanban board and the colored Kanban cards are iconic elements of the traditional Kanban system. In Japanese, the word Kanban translates roughly to “visual card,” though the English term that comes closest might be “queue limiter.” At its simplest, the Kanban board is a bulletin board or whiteboard with sections (typically columns) that represent different sequential sub-processes in a workflow. However, software tools simplify the process of creating, sharing, and maintaining the Kanban board.
Each column represents a value stream (the steps taken to create value for a customer). A simple board might contain only three sections: to do, doing, and done. Of course, though, you can make them much more complex depending on the work process and the size and structure of the development team. At higher levels, for processes that span multiple teams or workflows, Kanban boards can support entire departments or even organizations.
A typical Kanban board for a development team might contain the following columns: goals, story queue, elaboration and acceptance, development, test, deployment, and done. Another might include product backlog, requirements, design, development, testing, deployment, and done.
The colored Kanban cards — notecards or Post-It notes in a physical Kanban board — each represent a work item. The cards are moved across the board from left to right, tracking the progress of work items through a workflow as they’re completed. A card may also feature information about the work item, such as a brief description, an estimate of cost and duration, and the staff member who is working on it. High-priority items may be marked as such or given a special color, and they may be added to a parallel expedite column on the Kanban board.
The Kanban board is valued for how it visualizes work and optimizes flow. It communicates the capacity of the software development team in real time and makes it easy to identify blockages. A well-maintained board can be thought of as the single repository of information about a development team’s work.
Virtual boards offer many advantages: They make work progress traceable, they simplify information logging, and they’re easier to access from different locations. You can also clip information to cards on virtual boards, including screenshots, work logs, emails, and other data.
One critical element of using a Kanban board to track work progress is imposing limits on work in progress. Depending on the workflow and on the development team, a WIP limit might be put in place as a limit on the number of cards in each stage or simply a limit on the total number of cards in the workflow at any given time. Determining the WIP limit can be tricky. While it’s possible to use arbitrary numbers or gauge an appropriate figure based on your experience of team capacity, you can also use formulas to compute the limit. Check out this article by Evan Leybourn on The Agile Director site to learn how.
How Software Development Teams Put Kanban into Use
For a software development team, Kanban serves the same function as it does in a traditional manufacturing line — the only difference is that physical boards and cards are still used in the latter and rarely seen in the former.
The concepts of Lean management are more tricky to apply to software development than to a physical manufacturing process, mainly because of how difficult it is to conceptualize waste for a process that’s mostly sedentary and digital.
For a digital workflow, there’s little wasted material and movement. There are, however, other types of waste: defects, overproduction, waiting, and unnecessary processing. By imposing quality checks on work items that are being moved to downstream processes, prioritizing the backlog, and matching a team’s capacity to a permitted amount of work in progress, a Kanban system can help mitigate quality issues, delays, and excess work. This results in a clearer focus on the important, customer-valued work items at hand and a more efficient development line. While Kanban is considered an Agile system, the Kanban board and cards can also help scheduling in Waterfall development models.
The values and principles of traditional Kanban remain the same when applied to software development. Kanban remains concerned with evolutionary improvement of existing workflows and empowerment that facilitates team self-direction. (Kanban, in fact, is easier to apply to software development than to manufacturing, where it may entail changes to physical work processes.) The visual workflow management technique facilitates rapid, accurate decision making about what to work on and how and when to work on it. And, the values of transparency, customer focus, respect, balance, understanding, agreement, collaboration, flow, and leadership remain central to Kanban software development.
Another benefit of a Kanban ecosystem is a natural byproduct of the process itself: minimizing risk. Because Kanban necessitates clear and early communication — because everyone needs to know what they’re doing at each stage of the development process — it has the welcome advantage of compelling teams to discuss risks early on.
How Kanban Aids the Review and Feedback Process
Although Kanban is implemented as a combination communications-scheduling tool, with little need for systemic change of the workflow at the outset, the system can be used for feedback and review. These steps can change work practices or, ultimately, even the structure of the workflow.
Take, for example, W. Edwards Deming’s System of Profound Knowledge, a philosophy that says management holds responsibility for optimization by balancing the interrelated processes and people that comprise a system’s components. Creating a System of Profound Knowledge has four prerequisites:
- Understand the system.
- Understand variation in the system.
- Have a theory of how to act on the system.
- Understand human psychology.
Understanding the system entails moving from a siloed perspective of the system’s components to a holistic understanding of how a system reaches its eventual goals. This is a key principle of systems thinking, as demonstrated by John Seddon and Peter Senge. This understanding of a system involves comprehending the pathways by which an organization attempts to achieve its goal as well as the boundaries and constraints between and upon the system’s components.
Kanban, which by its nature shows individual members of a work process where they fit, helps develop not only an understanding of the system but a strengthened commitment to its goals by creating a sense of purpose and responsibility to shared objectives. It improves buy in to the system and its outcomes.
One frequent criticism of Kanban in software development is that it implies a uniformity in knowledge work that doesn’t actually exist. In manufacturing, variability in process outcomes is a no-no, but in software development, work items often have more variability. Yet, in both manufacturing and knowledge work, uniformity and consistency of delivery times remain vital. Kanban mitigates the impact of variation in knowledge work by decreasing the amount of work in progress, reducing the knock-on effects of variation, reassigning human resources to smooth unevenness, and managing the average lead time without micromanaging individual work item lead times.
Kanban’s visual nature also simplifies the feedback and review process such as PDSA (Plan, Do, Study, Act) in part because it makes waste easier to spot. This ability, in turn, provides grounds for improvement. In Lean Thinking: Banish Waste and Create Wealth in Your Corporation by James P. Womack and Daniel T. Jones (who also wrote The Machine that Changed the World), the authors articulate five principles of Lean thinking: value, value stream, flow, pull, and perfection. While Womack and Jones described these principles in 1996 with reference to manufacturing processes, the importance of creating value that customers want, minimizing work in progress, and eliminating defects are relevant to software development processes, too.
The Theory of Constraints is one management technique that can be applied to maintain the pace and flow of work across a system (developer Eliyahu Goldratt’s Drum-Buffer-Rope method). In this technique, the drum is the slowest workflow step and limits the rate of delivery. It sets the pace like a drumbeat. To prevent upstream processes from moving too quickly and building up work in progress, their pace is constrained by a rope. The space maintained between consecutive processes is the buffer, which is time built around workflow sub-processes, especially the drum, to account for the variability that is inherent in knowledge work.
Although a Kanban system doesn’t by default incorporate Scrum’s sprint retrospective (in which participants in a two-week sprint discuss how it went), many software development teams who use Kanban build regular checkpoints into their schedules. Examples of these include the quarterly strategy review, monthly operations review, monthly risk review, biweekly service delivery review, or weekly replenishment meeting. Many Kanban teams have also adopted the Scrum practice of a daily meeting, known in Scrum as a daily stand-up meeting.
Defining Agile, Scrum, and Kanban
In the complex, ever-evolving world of Agile methodologies, it can be hard to keep track of what each entails. So, what is Agile, and how do Scrum and Kanban fit into Agile?
Agile is a family of software development methodologies, all of which are iterative development approaches designed to satisfy evolving customer requirements. The classic Agile development project is carried out in a series of iterations (sprints) with incremental goals agreed upon at the beginning of each iteration. Agile projects do not have fixed scopes; rather, their requirements are guided by user stories (descriptions of features or functionalities that users want) and therefore, are constantly being updated.
Scrum is a specific Agile methodology based on prioritizing a set of requirements and working to meet them over a fixed time period. Over a number of these sprints, a software development team will work its way through the list of requirements. For some products, the list of requirements is constantly updated, so a Scrum project may not actually have a foreseeable end.
Kanban is not a methodology or a structured process framework like Scrum: It’s effectively a set of communications and scheduling tools and principles designed to improve existing workflows. So, where a team using Scrum has to set up according to the Scrum framework — forming Scrum teams, creating and maintaining a backlog, conducting and reviewing sprints, etc. — a team can use Kanban on top of other development methodologies and frameworks, including XP, Scrum, Crystal, Waterfall, RUP, DSDM, and FDD, by investing in a few Kanban tools and setting rules for how work is to be performed.
Scrum is an Agile methodology by definition, but there is debate over whether Kanban is Agile. There are some similarities. Kanban is iterative like the Agile methodologies, but it’s not specific to software (as are Agile methodologies). The ideas behind Agile methodologies were solidified before Kanban came into use for Agile development projects. Some developers believe Kanban is not Agile because it is a set of process improvement tools that have nothing to do with improving agility. And, as Charles Bradley at the ScrumCrazy blog notes, Kanban was designed originally for manufacturing, a field entirely dissimilar to creative software design. Meanwhile, others argue that Kanban is Agile because it fulfils all 12 principles behind the Agile manifesto.
Regardless of which side of this debate you fall on, most experts agree that Kanban does work well in areas in which Agile iterative delivery models have struggled, such as in routine IT operations and within teams that fix bugs and create enhancements to existing systems. Here, the flow of Kanban produces value that working in batches simply cannot.
There are more clear-cut differences between Scrum and Kanban. Here is how the two compare in various respects:
- Cadence and Release Methodology: Scrum iterations are conducted at fixed-length intervals called sprints. At the end of each sprint, a new release is made upon the project owner’s approval. Kanban delivers iterations continuously by pulling project-owner prioritized issues from the backlog as capacity opens up.
- Metrics: The key metric for Scrum is velocity, which is the number of story points delivered per iteration. The key metric for Kanban is average cycle time, which is how long it takes, on average, for a task to be processed.
- Change Philosophy: In Scrum, changes cannot happen mid-sprint. In Kanban, changes can be made at any time by shifting the order of work items on the backlog.
- Task Size: Kanban tasks can be more variable than those in Scrum.
- Periodic Assessments: Regular evaluations are built into Scrum via the sprint review and sprint retrospective, but they are not by definition part of Kanban. However, this is not to say they’re never incorporated into Kanban.
- Roles: All Scrum projects feature a set of clearly defined roles, such as the service request manager, Scrum master, and service delivery manager. Kanban projects, since they may be overlaid on existing development frameworks, don’t have a consistent set of defined roles.
This seeming lack of control in Kanban is sometimes questioned, but the counter argument is that the system itself creates a team that is efficient and committed. And, because Kanban thrives when it deals with relatively repeatable issues, it has no need for excessive control.
- Cost: Another differentiating factor between Scrum and Kanban is cost. Scrum, with its fixed framework, regular meetings, and time losses at sprint intervals, spends a substantial amount of time on efforts that really only support the actual software development process. Kanban, on the other hand, has fewer supporting functions and focuses on completing tasks, so it tends to get more things done in the same amount of time. According to author Sergey Laptick, Scrum’s sprint launch meetings and retrospectives, as well as daily meetings and sprint transitions, mean that 30 to 40 percent of the time in Scrum is spent on supporting the process.
For a fascinating look at a real-life implementation of XP, Scrum, and Kanban, check out Henrik Kniberg’s Lean from the Trenches: Managing Large-Scale Projects with Kanban, which explains how his team implemented a software system for the Swedish police.
For a summary of how Scrum, Kanban, and the traditional Waterfall style of development compare in these key areas, refer to the chart below:
| Elements |
Scrum |
Kanban |
Waterfall |
|
Cadence |
Repeating fixed-length work periods called sprints |
Continuous flow |
Sequential achievement of phases and milestones |
|
Release Method |
End of sprint |
Continuous delivery |
Project end |
|
Key Metric |
Velocity |
Cycle time |
Time to delivery |
|
Change Philosophy |
Flexible, cannot happen during sprint |
Flexible, anytime |
Inflexible, all aspects of project are defined by inception and do not change except through extraordinary measures |
|
Roles |
Clearly defined |
Varies by team |
Clearly defined |
|
Task Size and Prioritization |
Variable, work backlog can be reprioritized before start of sprint |
Uniform, work backlog can be reprioritized at any time |
Defined during initial project phase |
|
Feedback Process |
End of sprint |
Set by team |
Project end |
Top Tips for Implementing Kanban in Software Development
Thinking about transitioning your software development team to Kanban? Here are some key steps and top tips to help you succeed:
- Ask Why You’re Introducing Kanban: Discuss what you’re hoping to get out of a Kanban implementation. Are you going to layer Kanban over an existing process development framework? If so, what is it going to bring to your development process? Or, are you planning to use Kanban on its own, for development tasks of a more repeatable nature?
- Divide the Development Process: Your development process needs to be split into sections, so you can track where the work is. To start, you’ll have to identify the scope of the workflow that will be managed by the Kanban process. Depending on the nature of typical development tasks, the process can be split simply into to do, doing, and done categories or into a more complex workflow with specific steps for developing, testing, and deployment. You can also create horizontal swim lanes to characterize work items using other criteria, such as work item types or classes of service.
- Create the Kanban Board and Set the Rules for the Kanban System: Use the newly subdivided development process to set up your Kanban board. Meet with team members and stakeholders to agree on WIP limits and to establish policies regarding prioritization and release mechanisms. Teach the team how the board and system work, and set up a daily stand-up meeting in front of the board to discuss and update work item progress.
- Find the Bottlenecks: Careful, regular inspection of the Kanban board will quickly show you where any systematic bottlenecks exist. Look for places where work items are piling up.
- Optimize the Work Process: Removing bottlenecks by adding resources or removing systematic constraints is an easy way to optimize the development workflow. You might also want to study the demand for each category of work item and allocate resources based on a risk profile of whether delays will be tolerated. Other improvements, such as increased focus and a priority on finishing, tend to come with the Kanban territory. Educate the development team in the principles of Lean thinking, so they learn what waste is, how it affects process outcomes, and what they can do about it.
- Map the Value Creation Network: The value creation network is the set of pathways through which developers marry knowledge, information, and creativity to create value. In software development, this complex network is much more difficult to map than its cousin in manufacturing, the value stream. A value creation network can only be roughly visualized, but even a rudimentary representation of the network showing handoffs and queue times can drive efforts toward optimization. Redundancies or bottlenecks, for example, may become logically evident here. Remember that the value creation networks for different types of work items are not likely to be identical.
How to Choose between Kanban and Scrum in DevOps
As you get going, you may be unsure of which framework is right for your team. Here are some key questions to ask yourself when deciding between Kanban and Scrum
- Is Your Development Team Just Getting Started with Agile? If so, choose Kanban, which can be overlaid on top of your existing development framework to ease the team’s transition into Agile processes. Kanban is also significantly less complicated than some of the other popular Agile frameworks. It has three basic rules compared to Scrum’s nine, XP’s 13, and Rational Unified Process’ (RUP) 120.
Regardless of Agile method, let the new framework run uninterrupted for a while before you consider alternative frameworks. There’s a period of adjustment during which benefits might not be evident. Also, making too many changes at once can impede team members’ developing focus and maturity.
- Is Your Team Experienced with Agile? If you have a team that’s knowledgeable in Agile frameworks that are working reasonably well, using Kanban tools can help identify areas for potential Lean improvement over time. The Kanban board and cards are the most obvious choice; at the very least, they’ll facilitate the flow of work items through your Agile framework. The Kanban board can be used to visualize work during sprints, or you can simply do away with sprints and use the board to establish continuous delivery. Kanban metrics, such as cycle time, also hold value for other Agile setups.
- Is Agile Working for Your Team? If the Agile framework is not working for your team, or if you need wholesale change, go with Scrum. The resulting shake-up to the development framework can be just the jumpstart you are looking for.
- Does Task Priority Matter for Your Developers? If the nature of your team’s development work involves varying degrees of prioritization for different work items, Kanban is a better choice because you can re-prioritize simply by rearranging the backlog or by putting work items into priority swim lanes. Since the project owner decides priority, this tactic doesn’t interfere with the work of the developers — provided that the reprioritization isn’t illogical. For work that can be processed in batches, Scrum is a better choice since sprints lend themselves well to processing batches of similar work items.
- Are You Seeking a More Flexible Agile Approach to Estimating? If so, choose Kanban, which uses absolute values when estimating Kanban tasks. (Scrum uses the relative-value system of story points.) Where Scrum uses relative values to compute sprint velocity, Kanban breaks down work items into “pieces” of roughly equal size and measures velocity by calculating the number of units completed per unit of time. So, Kanban is a better choice if you’re dealing with tasks that can be broken into similar constituent items. (For precisely the same reason, Scrum is better suited to high-variability tasks.) While Kanban doesn’t do away with estimating completely, it does offer more room for flexibility.
- Still Not Sure? If you’re on the fence about choosing between Kanban and Scrum, remember that the type of organization, the organizational culture, the typical nature of the work, and the development team’s dynamics also help determine which is the best fit. And, if that isn’t sufficient, bear in mind that choosing between Scrum and Kanban isn’t an either/or decision. Scrumban combines features of both.
That said, perhaps it’s wise to end on a cautionary note: Kanban, used by itself, isn’t a development framework. Some critics say that applying Kanban to the software development process is a mistake — even Kanban-in-development pioneer David Anderson agrees that they have a point.
Keep in mind that Kanban comes from manufacturing, while Scrum was made for creative product design. Kanban, the argument goes, works well with clearly defined, repeatable processes — not those you’re likely to see in software development.
To borrow from the Cynefin decision-making framework, Kanban is for complicated work that is best solved through good practice, while formal development frameworks like Scrum are suited to complex work in which participants learn through experimentation, failure, and feedback. Without focusing on business value and how the users take to software, Kanban on its own doesn’t tick all the boxes for software development endeavors. Scrum is about software development, whereas Kanban is about managing change.
Improve Your Kanban Deployment with Smartsheet for Software Development
Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change.
The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.
When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.