Have you or your customers or business partners ever made these complaints?
- My change requests or features are usually urgent and cannot wait for the next sprint to start.
- My business scenario is quite volatile, and I might change my direction in one to two weeks’ time; I need flexibility to accommodate the change immediately.
- I have a high-profile, critical application whereby people report several problems that need to be solved and deployed quickly, and the time I reserve in a sprint is not sufficient to address most of them.
- My platform supports several groups of stakeholders who have their own cadence and working habits and provide requests at varying priority and urgency. Fitting everything into a sprint sometimes is not feasible.
- I have a high number of changes coming my way at any point in time, and I must meet a strict service level agreement (SLA) to service them.
If you have heard any of these complaints or can relate to any of them, read on!
Although in several enterprise scenarios you can work with your customers to educate and guide them through the Scrum development process, not all customers can do this owing to their business environment. Force-fitting Scrum into these kinds of scenarios drives one toward a general perception that Scrum doesn’t work, when the truth is that Scrum was not designed to work in such scenarios.
For all the complaints mentioned, the team needs to broadly meet the following two objectives:
- Business expectation of a quicker turnaround time for high-priority user stories and bugs for an existing product/platform in the market.
- Develop a faster go-to-market process for small changes.
- Resolve bugs/issues within a defined SLA.
- Support ad-hoc urgent requests coming in during a sprint.
- Support multiple businesses and stakeholders, each having their own cadence.
- Add a significant feature set to the existing product/platform or develop the next version of your product/platform while you support an existing one, both of which require significant commitment from the team, a sense of purpose, and a timeline.
Why Scrum and Kanban will not work
Scrum prescribes no changes to scope while the sprint is underway. As a result, the team defers the implementation of any new changes and ad hoc requests that require quick turnaround to subsequent sprints. This leads to customer dissatisfaction.
While Kanban can solve the problem of reacting to frequent changes and bugs, substantial delays can exist for new or existing product development, as the team usually loses sight of specific targets and milestones. The loss of focus is attributable to the lack of timeboxing against which the team usually works, which Scrum provides.
Scrumban as the solution
Scrum lends itself very well to incorporate nuggets from other Agile and Lean methods, which is where Scrumban originates as a method. Scrumban is a management framework that leverages Scrum as a preferred way of working and uses Kanban to continuously improve on how the team works and delivers. Scrumban as a process takes the best of both Agile (Scrum) and Lean (Kanban) methods and becomes the middle ground between Scrum and Kanban approaches.
Some of the teams I have worked with adopted one of the flavors of Scrumban by 1) combining the boundaries of the sprint from Scrum to enable the standard product development work to proceed as planned, and 2) by applying the work-in-progress resource limits of Kanban to handle frequent changes, and high-priority work items and bugs. This allowed the teams to take on ad hoc, unplanned, frequent work without having to adjust for sprint boundaries.
The team composition that was adopted was 60–40 for Scrum and Kanban work respectively, and had weekly planned releases when any completed/signed-off work items from either the Scrum or Kanban track were deployed. The team further matured to be flexible on the composition as well as the release on a need-only basis outside of the weekly production cadence.
This capability to deploy at will was achieved through an excellent, rigorous engineering process and adopting best practices, such as continuous improvement, automated regression, and automated deployment.
The Scrum aspect of Scrumban provides the following benefits:
- Use of Scrum to complete all new product development work
- High-quality product development and delivery
- Engineering excellence and best practices, leading to product stability
- Continuous improvement through retrospectives and sprint reviews
- Continuous sustainable pace for the team to churn out work
The "ban" aspect of Scrumban provides the following benefits:
- Quicker feedback loops, leading to customer satisfaction
- Waste minimization
- Lead-time reduction and accelerated go-to-market by improving efficiency
- Greater flexibility for picking up ad-hoc work items
When to apply Scrumban
Below are some of the scenarios when you would apply Scrumban:
- A project has many unexpected ad hoc changes that are time sensitive and usually urgent.
- Priorities are constantly changing.
- The work is event-driven, such as help desk support, whereby priorities shift constantly.
- The team is focused on building a new product from the ground up while also supporting an existing product.
- Some of the rigidness of Scrum is limiting your team’s ability to adapt to change.
- You want to limit large-scale disruption to your ways of working, so you require an intermediate step to your transition to Kanban.
- You have a heavy in-flow of support or production tickets with an expectation of quick turnaround time along with the usual heavy new feature building.
Comparison of Scrum vs. Kanban vs. Scrumban
||All Scrum ceremonies
||Stand-up, on-demand planning
||Required (story points)
||Welcomed, next sprint
||Instantaneous based on resource availability
||Instantaneous based on resource availability
||Constrained & descriptive
||Least constrained & least descriptive
||Moderately constrained & moderately descriptive
||Fast-paced projects, multiple stakeholders and expectations.