Kanban

Agile software development teams today can leverage JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus on continuous improvement, and transparency throughout the development cycle.

While the core principles of the Kanban framework are timeless and applicable to almost any industry, software development teams have found particular success with the agile practice. Unlike implementing kanban on a factory floor, which would involve changes to physical processes and the addition of substantial materials, the only physical things software teams need are a board and task cards, and even those can be virtual.

The work of all Kanban teams revolves around a Kanban board, a tool used to visualize and optimize the workflow across teams. While physical boards are popular among some teams, virtual boards are crucial in any agile software development tool for their traceability, collaboration, and accessibility from multiple locations.

Regardless of whether a team uses a digital or physical kanban board, it ensures that the team visualizes their work, standardizes their workflow, and immediately identifies and resolves all blockers and dependencies. A basic kanban board has a three-step workflow: To Do, In Progress, and Done. However, depending on a team's size, structure, and objectives, they can map the workflow to meet their unique processes.

Because the kanban methodology relies upon full transparency of work and real-time communication, the kanban board acts as the single source of truth for the team's work.

In Japanese, kanban literally translates to "signboard." Kanban teams represent every work item as a separate card on the board. The main purpose of representing work as a card on the Kanban board is to allow team members to track progress through its workflow in a highly visual manner. 

Kanban cards feature critical information about project tasks, giving teams visibility into who is responsible for which tasks and a brief description of the job, and how long tasks are estimated to take. Cards on virtual kanban boards often feature screenshots and other technical details that are valuable to the assignee. 

Enabling team members to view the status of each task at any moment, alongside relevant details, promotes heightened focus, comprehensive traceability, and rapid identification of blockers and dependencies.

Kanban is one of the most popular software development methodologies agile teams use today. Kanban offers additional advantages to task planning and throughput for teams of all sizes.

A kanban team focuses only on the work that's actively in progress. Once the team completes a task, they select the next task from the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team because any changes outside the current work items don't impact the team. 

As long as the product owner keeps the most important work items on top of the backlog, the development team can rest assured they are delivering maximum value back to the business.

Cycle time is a key metric for Kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team's workflow—from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

Overlapping skill sets lead to shorter cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. Therefore, teams employ best practices like code review and mentoring to help spread knowledge. Shared skills mean team members can take on heterogeneous work, further optimizing cycle time. 

Additionally, this approach empowers the entire team to address any work bottlenecks collectively, facilitating a swift resolution and ensuring a smooth workflow. For example, testing responsibilities extend beyond QA engineers to include developers, fostering a collaborative effort to maintain efficiency. In a kanban system, the entire team ensures work moves smoothly through the process.

Multitasking kills efficiency. Increased workload simultaneously leads to more frequent context switching, impeding the progress of tasks toward completion. That's why a vital tenet of the kanban process is limiting the work in progress (WIP). Work-in-progress limits highlight bottlenecks in the team's process due to a lack of focus, people, or skill sets.

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's a good reason for it. 

Developers often prefer to write new code rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state and review others' work before raising their code reviews, ultimately reducing the overall cycle time.

A cumulative flow diagram shows the number of issues in each state. The team can easily spot blockers when the number of issues increases in any given state. Issues in intermediate states such as "In Progress" or "In Review" are not yet shipped to customers, and a blocker in these states can increase the likelihood of massive integration conflicts when the work gets merged upstream.

Continuous delivery (CD) describes the process of releasing work to customers frequently. Continuous integration (CI) is the practice of automatically building and testing code incrementally throughout the day. Together, they form a CI/CD pipeline that is essential for DevOps teams to ship software faster while ensuring high quality.

Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value. The faster a team can deliver innovation to the market, the more competitive their product will be. Kanban teams focus on precisely that: optimizing the flow of work out to customers.

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. 

Some teams blend the ideals of the kanban method and scrum into "scrumban." They take fixed-length sprints and roles from Scrum and focus on work-in-progress limits and cycle time from Kanban.

For teams just starting with agile, we strongly recommend choosing one methodology and running with it for a while. If your team is ready to use the kanban methodology, use our free kanban board template today!