Kanban is a popular framework used to implement agile software development. It requires real-time communication of capacity and full transparency of work. Work products are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time. The Kanban Method is a means to manage, design, and improve flow systems for knowledge work. The method also allows organizations to start with their existing workflow and drive betterment change. They can do this by visualizing their flow of work, limit work in progress and stop starting and start finishing. The Kanban Method gets its name from the use of kanban – visual signaling mechanisms to control work in progress for invisible work products.
Five conditions under which we found Kanban to be a better fit than Scrum.
1. Low Tolerance for Change
Many organizations that is brittle to change. They are comfortable with the way they do things even if they are not getting results. Their solution is not to rethink how they work, it is usually to make their teams work longer and harder—which is not a real solution. Scrum is a threat to breakable, change-adverse organizations primarily because of how quickly it transforms roles and meetings.
Kanban does not use transformative change it embraces evolutionary change. Kanban employs a start with what you do now mindset that introduces teams to the shallow end of the pool before taking them toward the deep end of maturity. Kanban does not require any changes to roles or meetings when first getting started.
2. Obvious at All Levels
The primary advantage Kanban has over Scrum is that it is immediately inborn to anyone. A Kanban board is an instant sense-making device. It requires zero explanation to understand. However, Kanban’s primary advantage is also its biggest defect. It’s easy to be fooled by Kanban’s hidden sophistication. Kanban is far more worldly-wise than a simple tool for visualization. Kanban is built for speed but most teams will never master the behaviors that produce those results because their commitment to learning Kanban stops at visualization.
3. Fluid Priorities
Scrum produces the best results when a team commits to a batch of work and is authorize to remain focused for the duration of their iteration. The success of Scrum requires informed and empathetic stakeholders who are bought-in to being agile. Kanban is able to survive conditions where agile culture doesn’t yet exist because it encourages benefit. A Kanban team prefers to not commit to work in groups and they don’t commit to work until they start it. This means a Kanban team can be maximally flexible to respond to emergencies or changing first concern without needing to arrange commitments.
4. Small Teams
The ideal size of a Scrum team is a two-pizza team. This makes sure that a team is small enough to be efficient and large enough where the time investment in meetings makes sense. If your team is smaller than a two-pizza team, Kanban can be the better option.
5. Complex Collaboration
- Scrum has changed the way the world thinks about work. My favorite assign of Scrum is the cross-functional team. The idea that a team is comprised of people from different departments and disciplines is a game changer. In the case of software development, it is not just engineers and testers anymore. Today, we have user experience, visual design, writing, editing and many other activities.
- If your team has a large number of activities, the strategies of sprinting ahead or using a scaling framework may introduce unnecessary delay and complexity. Kanban does not utilize time boxing to create calculability, it uses lead-time—so it is capable of sustainably supporting an unlimited number of activities and collaborations.
Given Kanban’s approach to start with your existing process and evolve it, there are no roles certain called for when adopting Kanban. Use the roles you currently have on your team.
There are two roles that have appeared in practice that serve particular purposes. It’s highly likely that these functions are filled by someone in an existing role as mentioned below.
Service Request Manager
Understands the needs and expectations of customers, and facilitates the selection and ordering of work products at the Replenishment Meeting. This function is often filled by a product manager, service manager, or product owner.
Service Delivery Manager
Responsible for the flow of work to deliver select products to customers. Facilitates the Kanban Meeting and Delivery Planning. Other names for this function include flow manager, delivery manager, or flow master.
We encourage you to resist the idea that Scrum and Kanban are competitors or enemies. Both are a means to help teams and their stakeholders achieve supportable success. Do not assume that whichever you best understand or most frequently use is superior. Adopt a true agile mindset and experiment with both!