Kanban is a popular agile method for managing software projects, but it also comes with some challenges and risks that need to be addressed. In this article, you will learn how to deal with some of the common issues that arise when using Kanban, such as prioritizing work items, handling dependencies, managing work in progress, and ensuring quality.
Kanban is a visual system that helps teams to organize and optimize their workflow. It is based on four principles: visualize the work, limit the work in progress, focus on flow, and continuously improve. Kanban uses a board with columns that represent different stages of the process, such as backlog, ready, in progress, testing, and done. Each work item is represented by a card that moves across the board as it progresses. The team can see at a glance what is being worked on, what is waiting, and what is finished.
One of the challenges of Kanban is to decide which work items to work on first, and how to balance the demand and the capacity of the team. A common way to prioritize work items is to use a value-based approach, such as the MoSCoW method, which categorizes work items into must-haves, should-haves, could-haves, and won't-haves. Another way is to use a cost of delay approach, which considers the impact of delaying a work item on the value delivered to the customer. Regardless of the method used, the team should also consider the quality criteria for each work item, such as the definition of done, the acceptance criteria, and the testing standards.
MosCow is also strengthened by adding value. It should also be recognized that Kanban is a pull system that allows a better flow of work. Management of WIP is critical to understand the proper flow of value.
I have developed my own method to prioritize by Risk and Value to the customer Risk in terms of technical debt, a vulnerability or break fix issues in production. Value to the Customer or an end- user. Once I create a table, I have two teams working, one on Prioritized Risks and second team on Prioritized Customer or End-User value
MoSCoW is good for building a roadmap, i.e. triage. Plan an iteration and determine what's included. Cost of Delay, or CoD, to be baked into MoSCoW because it's a natural calculus when labeling an item "must have", i.e. the item cannot be delayed because the cost of waiting is high. For example, a crucial bug fix or a highly requested feature has a high CoD. But CoD can be hard to quantity or qualify. A more intuitive method is Adam Nash's three buckets: metric movers (MM), customer delight (CD), and customer requests (CR). What are the project, or iteration, goals? Bug squash? New offering? How is success measured? Sample priority filter: Bug squash: high CR, high CD, low MM New offering: high CD, medium/low CR, high MM
Dependencies are situations where a work item depends on another work item to be completed or started. Dependencies can cause delays, bottlenecks, and waste in the Kanban system. To handle dependencies, the team should try to identify and eliminate them as much as possible, by breaking down large work items into smaller and independent ones, by aligning the work items with the customer value stream, and by collaborating with other teams or stakeholders. If dependencies cannot be avoided, the team should make them visible on the board, by using markers, colors, or links, and manage them proactively, by communicating, coordinating, and resolving them as soon as possible.
Dependencies are easy to manage if items are linked appropriately during decomposition. I find the key element to be relationships. Proper relationship selection can make prioritization or selection a breeze. Traditional PM relationships: - start to start, - finish to finish, - start to finish, & - finish to start (most common). Typical agile relationships: - blocked by - blocks - precedes - preceded by I disagree that a team should try to eliminate dependencies. That's like saying "eliminate risks." Not likely. Instead, like risks, minimization or mitigation are better strategies. The act of decomposing work creates items with dependencies. To eliminate dependencies go in the opposite direction and combine items.
Work in progress (WIP) is the amount of work items that are currently being worked on by the team. WIP is a key factor that affects the flow and the throughput of the Kanban system. Too much WIP can lead to multitasking, context switching, longer cycle times, lower quality, and higher stress. To manage WIP, the team should use WIP limits, which are rules that limit the number of work items that can be in each column of the board. WIP limits help the team to focus on finishing what they started, to reduce waste, and to improve flow. The team should also monitor and adjust their WIP limits based on their data and feedback.
I help Millennials and GenX job seekers in tech feel confident and get job offers
The thing to remember about WIP limits (WIPL) is that it's your mechanism for control of throughout and congestion. If you identify a bottleneck, you can use WIPL to alleviate the bottleneck. Imagine a congested highway, one solution is to increase the number of lanes, another is to reduce the number of cars on the road. WIPL reduces the number of items in a given state. Adding team members increases the capacity for items in a given state. One concern with kanban is when to adjust the WIPL. I recommend a weekly or biweekly review of flow & congestion. Use retrospectives to gather feedback from the team on issues with throughput.
Quality is the degree to which a work item meets the expectations and needs of the customer. Quality is essential for delivering value and building trust with the customer. To ensure quality in Kanban, the team should embed quality practices into their process, such as defining clear and measurable quality criteria for each work item, performing frequent and automated testing, conducting peer reviews and inspections, applying coding standards and best practices, and implementing continuous integration and delivery. The team should also measure and improve their quality metrics, such as defect rate, defect density, defect resolution time, and customer satisfaction.
Kanban was created for quality management at Toyota. The rule was no defective part would be delivered. If a defect was discovered, production halted and the issue was fixed immediately. With software we have several mechanisms to detect defects: - unit tests - code reviews - UAT - CI/CD - manual testing The key is to tie the output of those mechanisms to your kanban process and procedure. For example, a CI build fails, so an item cannot move to the next state. A useful convention for Kanban is test driven development (TDD). TDD ensues defects can be detected earlier in the SDLC. Note: You trade some development speed for quality with TDD. Also, it takes some experience to determine a good level of granularity for unit tests.