Kanban is a well-known framework for implementing agile and DevOps software development practices. It demands real-time capacity communication and complete transparency of activities. Visual representation on a kanban board enables team members to view the status of any piece of work at any moment.
While kanban is very popular among today’s agile and DevOps software development teams, the kanban work approach goes all the way back to the 1950s. Toyota started improving its engineering processes in the late 1940s using the same approach that supermarkets.
Since inventory levels correspond to consumption patterns, the supermarket improves its inventory management efficiency significantly by reducing the quantity of surplus stock it needs to store at any one moment. Meanwhile, the supermarket may continue to guarantee that a consumer’s desired product is always in stock.
Case study
Toyota used a similar approach on its manufacturing floors to better match their enormous inventory levels with real material usage. Workers would transmit a card, or “kanban,” between teams to convey real-time capacity levels on the manufacturing floor. When a bin of materials utilized on the manufacturing line was emptied, a kanban was sent to the warehouse specifying the kind of material required, the precise quantity required, and so on. The warehouse would have a fresh bin of this material ready to deliver to the manufacturing floor, which would then deliver their new kanban to the supplier. Additionally, the supplier would have a bin of this material on hand, which it would send to the warehouse. While the signaling technology for this process has changed since the 1940s, the core of it remains the same “just in time” manufacturing method.
Kanban for software development teams
Today’s agile software development teams use these similar JIT concepts by balancing their work in progress (WIP) with their capacity. This provides teams with greater planning flexibility, more productivity, a more focused effort, and enhance scrutiny throughout the development cycle.
While the framework’s fundamental concepts are like any sector, agile software development teams have shown great success with the technique. This is partly because once software teams grasp the fundamental concepts, they may begin practicing with little to no overhead. Unlike adopting kanban on a manufacturing floor, which would need significant modifications to physical processes and the inclusion of significant materials, a software team just requires a board and cards, which may be virtual.
Kanban boards
All kanban teams operate around a kanban board, a tool for visualising and optimising work flow within the team. While physical boards are still popular with certain teams, virtual boards are a critical component of any agile software development tool due to its traceability, ease of communication, and accessibility from many locations.
Whether a team’s board is real or digital, its purpose is to guarantee that its work is visible, its workflow is standardised, and any bottlenecks and dependencies are recognised and addressed promptly. A straightforward kanban board follows a three-stage workflow: To Do, In Progress, and Done. However, depending on the size, structure, and goals of a team, the workflow may be customised to fit its specific processes.
The kanban approach is based on complete transparency of work and real-time capacity communication. As such, the kanban board should be seen as the one source of truth for the work of the team.
Kanban cards
Kanban literally translates as “visual signal” in Japanese. For kanban teams, each task is represented on the board by a distinct card.
The primary reason for displaying work as a card on the kanban board is to enable team members to visually monitor the progress of work through its process. Kanban cards provide essential information about each work item, allowing the whole team to see who is responsible for each task, a short description of the task at hand, and an estimate of how long the task will take. Cards on virtual kanban boards often include images and other technical information that the assignee may find useful. Allowing team members to see the current status of each work item, as well as all related information, guarantees improved attention, complete traceability, and rapid discovery of bottlenecks and dependencies.
The advantages of kanban
Kanban is one of the most widely used agile software development methods today. Kanban adds many benefits to task planning and throughput for teams of any size.
Flexibility in planning
A kanban team requires work that is currently in working completed. Once a task is completed, the team moves on to the next task from the top of the backlog. The product owner is free to reprioritize work in the backlog without causing disruption to the team since any changes made outside of the existing work items have no effect on the team. As long as the product owner prioritizes the most critical work items, the development team can be certain they are providing maximum value to the company. As a result, there is no requirement for scrum-specific iterations.
ADVICE:
When contemplating modifications to the backlog, astute product owners always include the development team. If user stories 1-6 are in the backlog, for example, the estimate for user storey 6 may be dependent on the completion of user stories 1-5. It is usually prudent to validate modifications with the technical team to avoid surprises.
Reduced time cycles
Cycle time is a critical performance measure for kanban teams. Cycle time is the time required for a unit of work to complete its journey through the team’s workflow – from the time it begins to the time it ships. By minimising cycle time, the team can predict the delivery of future tasks with confidence.
Interdependence of skill sets results in shorter cycle times. When a single individual has a certain skill set, that individual creates a bottleneck in the process. As a result, teams use fundamental best practices such as code review and mentorship to help disseminate expertise. Due to shared abilities, team members may take on a variety of tasks, thus optimizing cycle time. Additionally, if there is a backlog of work, the whole team may swarm on it to get the process back on track. For instance, testing is not only the responsibility of QA engineers. Developers also contribute.
In a kanban framework, it is the duty of the whole team to guarantee that work moves smoothly through the process.
Fewer bottlenecks
Multitasking is detrimental to efficiency. At any one moment, the more work items in flight, the more context switching occurs, impeding their completion. That is why one of the fundamental tenets of kanban is to keep the quantity of work in progress to a minimum (WIP). Work-in-progress limitations indicate process bottlenecks and backups caused by a lack of attention, personnel, or skill sets.
For instance, a typical software development team may have four stages of work: To Do, In Progress, Code Review, and Done. They may opt to impose a two-week work-in-progress restriction on the code review state. This may seem like a minor restriction, but engineers prefer writing new code to assess someone else’s. Decreased attention to issues in the review state and examining other people’s work before raising own code reviews. This eventually results in a reduction in total cycle time.
Visual metrics
One of the fundamental principles is a relentless pursuit of team efficiency and effectiveness with each iteration of work. Charts offer a visible method for teams to monitor their progress. When the team has access to data, it becomes simpler to identify process bottlenecks (and remove them). The most widely used reports by kanban teams are Control charts and cumulative flow diagrams.
A control chart displays the cycle time for each problem, as well as the team’s rolling average.
A cumulative flow diagram depicts the total number of problems occurring in each state. The team may quickly identify bottlenecks by observing the rise in the number of problems in any particular condition. A slowdown in these phases raises the likelihood of major integration conflicts.
Consistent delivery
Continuous delivery (CD) is the process of regularly delivering work to clients. Continuous integration (CI) is a development process that automates the process of progressively creating and testing code throughout the day. Together, they provide a pipeline that allows development teams to ship software faster while retaining high quality.
Kanban and CD are an excellent match since both methods emphasize just-in-time (and one-at-a-time) value delivery. The faster an innovation team can promote its product, the more competitive it will be.