Is Scrumban just adding a Kanban board with a few other ornamental changes, or are there deeper issues that need to be addressed? What advantages do you expect to achieve by infusing your current practices with Lean Kanban?
Hybrids are problematic at best. Without principles guiding your actions, they create indecision about in which direction changes should occur. The result may be the implementation of the worst possible set of features. The foundational principles of Scrum and Lean Kanban are pretty clear. Will you violate them because it was convenient? Are you being flexible or just being ruled by the expediency of the moment?
My suggestion is to pick one and incorporate the features of the other. I mostly work with Scrum teams, but I always try to infuse a “little bit of Kanban in my life.” With that in mind, let’s assume you are already Scrum and are adding a shot of Lean Kanban to go with it.
Maybe you are experiencing a few of the following problems?
- User Stories are bogging down the board
- You have to continuously reset the sprint length due to changing release dates
- Work has to stop three days before a Sprint ends to finish testing
- Team members are always working on multiple User Stories simultaneously
Are monster User Stories eating your Scrum board? The issues raised above are all queuing problems. Maybe if you lean the Kanban way you can help your team stay focused?
Just Go with the Flow, Baby
There are quite a few advantages for going Lean. What Scrum and Lean Kanban have in common is that they are philosophies, not just methodologies. Maybe it’s time to think “Progressively” and follow the Flow.
Scrum teams can be prone to less than optimal habits that Lean Kanban can help to re-adjust. Let’s think about what a few of these might be.
- User Stories grow into unwieldy requirements, not small efficient work packages
- Teams fixate on ceremonies and not process efficiencies
- Sprint become schedules, not a rhythm of work helping to accomplish Sprint goals
- Release dates dominate the Sprint cadence
- The Retrospective becomes an ineffective change feedback loop
The solution to these issues may be resolved using a Scrum approach, but it goes deeper than that. These are behavioral issues. After doing Scrum for a few years, teams sometimes lose their way and become comfortable with less than optimal behaviors. Does a Lean Kanban philosophy offer advantages? Let’s explore what it means to be Lean Kanban.
A Lean, Mean Kanban Machine
Lean Kanban is not Agile or Scrum. It’s based on Just-In-Time (JIT), Lean manufacturing concepts, and Kaizen. By definition, it’s not methodology specific. The unit of work is a work package, which doesn’t have a predefined definition.
It’s not a scheduling system or based on a fixed schedule length. It’s a visualization of the work-flow. It’s not a Push system. Work is not pushed forward after a task is completed. It’s a Pull system. Work is pulled from a previous part of the process.
The focus is on managing work as it flows through the queue. Product built-up waiting to be worked upon is considered waste. It’s all about the efficient flow of work through a queue.
Why don’t Scrum teams become more Lean naturally? Building small, independent User Stories seems to be a fairly obvious practice. It reduces complexity, dependencies, wait time, and uses resources more efficiently. Project Management theory teaches us to manage schedules, effort hours, and sizing. Scrum does something similar: it focuses us on Sprint length, effort hours, and story points. Lean Kanban doesn’t. It’s a question of focus.
What should you consider when blending Scrum and Lean Kanban? Recommendations are provided to help facilitate the blending. I’ve organized this with a set of generic principles that captures the essence of both frameworks.
Process Controls – Managed Workflows
When infusing Lean Kanban into Scrum, the first step is to replace the Scrum board with a Kanban board. Configure it with columns for To-Do, Work-In-Progress (WIP), and Done. I hear you cry: “but the tool forces us to do that. We don’t have a choice.” Well, now that you have come this far you need to go a bit farther.
Add WIP limits to the Kanban board. This helps regulate the flow of work through the queue by placing maximum limits on the amount of work in each column. Initially, base them on your team’s capacity. Modify the WIP limits to help control the accumulation of work in any one column. This will slow down the work in columns experiencing inventory build-up. In Kanban, it’s considered waste. This will force the work to flow smoother. It will modify the behavior of taking on too much work simultaneously. This is also a form of waste.
Kanban Board with WIP Limits
Next, create a Pull system. Individual columns under WIP should also have a Done column. Once work is finished, it’s moved to its Done column. That signals work is available to be pulled to the next column. This creates a “true” Kanban board. Kanban means “message card that triggers a replenishment.”
Focus on Team Dynamics – Self-Organizing and Collaborative
This is basic to both approaches. Lean Kanban starts with the team and moves outward throughout the organization. Scrum is highly focused on the team, encouraging self-organizing teams and a collaborative approach. A variety of techniques that foster this are described in other sources. It’s all good.
Next Steps
The recommendations above will take you a long way to becoming Scrumban. They don’t violate the foundational principles of either Scrum or Lean Kanban. But have they gone far enough? Maybe it’s time to Lean a bit further.
Focus on Useful Work – Customer Focused, Value-Based, and Prioritized
Sprint Planning is used to plan for high-priority User Stories. If your Sprint Planning session is more of a User Story refinement session, it needs to shift back towards its original intent.
Before Sprint Planning even starts, conduct a Risk Review meeting. I like to do a RAID session where the team identifies Risks, Assumptions, Issues, and Dependencies.
Conduct User Story Estimation as a separate session from Sprint Planning. It helps keep your Sprint Planning session on track by eliminating distractions. A Sprint Planning session should only consider previously pointed, prioritized User Stories that can fulfill Sprint capacity. Everything else is a waste of your team’s time.
Embrace a Philosophy of Continuous Improvements
In Scrum, incremental changes typically occur after Sprint completes. The Scrum Master or Agile Coach may engage the team in a variety of ways to encourage change, but fundamentally it comes from within the team and in increments of the Sprint. The Retrospective, in practice, becomes a primary vehicle for change. The minimal unit of work is the User Story, and the minimum time frame is the Sprint. The best time to assess lessons learned is after the work has finished. This is similar to why Postmortems are done after a project concludes.
Consider implementing a Kaizen approach with additional feedback loops, Quality circles, experimentation, and continuous learning opportunities. During your Retrospectives, consider how to reduce the seven wastes of Lean Manufacturing. I have mostly been discussing inventory wastes but consider waste due to defects, waiting, and over-processing.
Implement monthly or quarterly meetings to consider how well the client was served by the team’s output, how operations can be improved overall, and what factors put the work delivery at risk.
Make All Policies Explicit
This is central to both Scrum and Kanban. Team Agreements, the Kanban Board, and metrics all need to be visual, publicly posted, and transparent.
Minimalism
Queuing theory favors small work packages as being more efficient flowing through a queue. Scrum ceremonies and meetings should be time-boxed with specific agendas. Small increments of work with deliverable results are more efficient than large ones. If you are Scrum or Lean Kanban and not doing this, then why not?
Shippable Products
How does your team view the concept of a Shippable work product? In Scrum, this is work that can be shipped but doesn’t have to be released to production immediately. Has this morphed into inventory batched into Release packages and shipped at the end of the Sprint? That may lead to dependencies between User Stories, inefficiencies in the Sprint, and waste due to excessive inventory build-up. One of the design constraints of a good User Story should be that it can be shipped independently.
Metrics
The Scrum Master’s job will need to change slightly from focusing on removing impediments to also managing the workflow. They need to monitor inefficiencies in inventory as it flows through the work queue.
Consider what metrics you need to help your team. In Scrum Velocity and Burn-down/Burn-up, charts are aggregate measures of throughput. While in Lean Kanban, Lead time and cycle time are specific to the behavior of individual User Stories. You need to do both.
“If you’ve come this far, maybe you’re willing to come a little further”
Let’s revisit a few of these guiding principles for the next step on your journey. Is it time to go full JIT Monty?
Process Controls
You have a Kanban board to regulate the flow of work for Work-In-Progress, but what about the requirements queue? Scrum typically has a Product backlog and a Sprint backlog. How does your team’s Product Owner manage requirements? Is there a mad rush to fill the Sprint Backlog with User Stories before Sprint Planning?
Create a second board for User Story Elicitation, Elaboration, Validation, and Acceptance. Your goal is to only have enough requirements inventory to satisfy the needs of your developers. As they pull the next requirement, another one needs to be added to the To-Do column. Reduce the pressure on your PO to suddenly produce a lot of hastily written User Stories just before Sprint Planning. It’s all about the flow, baby!
Focus on Useful Work
If the “To-Do” column only has enough User Stories to satisfy the next pull of the developers, do you need to do Sprint Planning? Well, not per se. What you need is a Replenishment meeting. It’s sorta like Sprint Planning.
Conduct a Replenishment meeting in conjunction with Sprint Planning:
- Decide work items to be pulled next and delivered to the customer
- Identify and discuss dependencies and risks
- Decide if any work items need to be deferred till the next Replenishment meeting
Put in place a Service Delivery Review to determine how well the client is being served by the team’s output. This determines how well the client is being served by the team’s output.
If you are using a Scaled Scrum framework, consider adding a Strategy Review (Quarterly). This evaluates the big picture: the market landscape, technology changes, strategic goals, and the direction of the Kanban road map.
Shippable Products
Have you considered building a Continuous Delivery/Continuous Integration (CD/CI) pipeline and releasing User Stories once they are completed? This will encourage behaviors to keep User Stories small, independent, and completed within a 4 to 8-hour time frame.
Closing Thoughts
The approach here is to start with Scrum and move closer to Lean Kanban. I glossed over many concepts. I suggest you investigate them further. As always, I suggest you go back to foundational principles.
When merging Scrum and Lean Kanban, one is attempting to blend two different philosophies. This is not impossible. They are very complementary. If you create a hybrid, then you need to stay true to the foundational philosophy for both frameworks. If you desire to create Scrumban, then consider including the items listed above.
The implications of a continuous flow, focusing on the efficiencies through an unbounded work queue vs. a calendar-based, ceremony-bound iteration will force you to favor one approach over the other. I don’t recommend building a hybrid. After all, the whole alien-human hybrid thing never really works out well.
References
Scrum The Art of Doing Twice the Work in Half the Time by Jeff Sutherland and J.J. Sutherland, 2014
The Toyota Way Management Principles from the World’s greatest Manufacturing by Jeffrey K. Liker, January 7, 2004
6 Main Principles in the Scrum Framework from blog.scrumstudy.com/
What is Scrum from Scrum.org
KainNexus blog
The Four Principles of Kanban, Planet Together
The Kanban Method, The Kanban University, David J Anderson
The Rhythm of Success: Kanban Meetings, Sonya Siderova, Nave
The Seven Wastes in Manufacturing by David McBride, August 29, 2003
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
