What is Scrumban?

Background

Scrumban originated from the ideas of Corey Ladas, who unveiled this concept in his 2009 publication, “Scrumban: Essays on Kanban Systems for Lean Software Development.” Ladas's goal was to mitigate Scrum's limitations by incorporating specific Kanban principles. Initially, Scrumban was designed as a transitional tool for teams shifting from Scrum to Kanban. However, many found the hybrid state an ideal operational point, leading to varied implementations of Scrumban among different organizations.

Since its inception, Scrumban has developed into three primary forms:

1.A method to introduce Scrum within a team or organization;

2.A strategy for extending Scrum throughout a larger enterprise; and

3.A means to modify Scrum for better addressing and resolving persistent organizational challenges that are resistant to quick or straightforward solutions.

What is Scrum and Kanban?

As Scrumban combines elements of both Scrum and Kanban, it's beneficial to initially understand what each of these methods entails. These frameworks are part of the broader Agile framework spectrum, designed to be adaptable in the face of change and uncertainty. Among Agile's various forms, Scrum is the most structured. It features cross-functional teams operating in defined periods called sprints, usually lasting between one to four weeks, often two. Each sprint is centered around a specific goal, and new tasks cannot be added once a sprint has started. In contrast, Kanban emphasizes visualization and a continuous flow of work rather than structured sprints. Tasks are visually represented on cards and tracked on a Kanban board, which typically has columns like 'to-do,' 'in progress,' and 'done.' This approach not only helps in monitoring progress but also in controlling the number of concurrent tasks, ensuring team members are not overwhelmed. With an overview of both Scrum and Kanban, we can now delve into understanding Scrumban.

Exploring the Essence of Scrumban

To gain a better understanding of Scrumban and its contributions to product development, let's examine some of its fundamental traits.

Focus on Ongoing Improvement While the structured nature of Scrum might not suit all teams, especially due to its periodic starts and stops, Kanban’s principle of kaizen, or continuous improvement, is central to Scrumban. This philosophy is seamlessly blended with Scrum’s structural elements in Scrumban.

Visualization is Key in Scrumban The Scrumban board, a pivotal tool, visually maps out the team's workflow. This board, which can be either physical or digital, displays tasks that are pending, in progress, and completed. Unlike a Scrum board that resets after each iteration, the Scrumban board remains consistent throughout the project, fostering transparency, accountability, efficiency, and teamwork.

Flexibility in Team Composition and Roles Unlike Scrum, which prescribes specific team sizes and roles as per Ken Schwaber and Jeff Sutherland's guidelines, Scrumban does not mandate fixed roles or team structures. This allows for more flexibility in how teams are organized and operate.

Planning is Demand-Driven in Scrumban Planning sessions in Scrumban are not scheduled at regular intervals as in Scrum but are triggered when the backlog reaches a certain threshold. This approach helps maintain workflow continuity and avoid disruptions.

Effective Workload Management Each Agile methodology has a mechanism to manage workload. Scrum delineates this with fixed sprint durations and task limits. In contrast, Kanban and Scrumban use WIP (work-in-progress) limits to control the number of tasks undertaken simultaneously, reflected on the Scrumban board.

Semi-Structured Meetings Scrumban adopts a balanced approach to meetings. Daily standups are brief and consistent, while other meetings like retrospectives are held as needed, differing from Scrum’s more regimented meeting structure and Kanban’s absence of such standards.

Prioritization Over Points In Scrumban, unlike Scrum where story points dictate sprint planning, task prioritization is key. Team members pull the highest priority item into the work-in-progress column as capacity allows, shifting the focus from timeboxed efforts to priority-based task execution.

Adaptability of Scrumban Scrumban's versatility is twofold: it's applicable in various contexts beyond software development and has evolved significantly since its inception, with teams customizing it to fit their unique needs.

Cycle Time as a Core Metric Scrumban primarily utilizes cycle time, the duration from task initiation to completion, as a measure of success. This is distinct from lead time, which is the time from task request to delivery. Consider the coffee shop analogy: lead time is from ordering to receiving your drink, whereas cycle time begins when the barista starts making it.

Scrumban's Values

1.Empiricism: Empirical approaches are always favored over theories, as are verifiable results over dogma.

2.Humility: Systems are constantly changing, and we are constantly learning. We must always be ready to challenge our understanding. Improved understandings and approaches can come from any source.

3.Constructive interaction: Scrumban emphasizes constructive debate that improves understanding of the strengths and limitations of each framework over blind acceptance that any one framework represents the “only” or “best” way of achieving a particular outcome.

Scrumban's Goals

1. Scrumban maximizes the potential of Scrum with Lean and Kanban principles.

2. Sustainable improvement

3. Effective business results

4. Faster, cheaper - Leaner

5. Dependable and predictable delivery

Four Principles

1.Start with what you do now.

2.Respect the current process, roles, responsibilities, and titles.

3.Agree to pursue incremental, evolutionary change as opportunities are discovered.

4.Encourage acts of leadership at all levels of the organization.

Six Practices

1.Visualize.

2.Limit WIP.

3.Manage flow.

4.Make policies explicit.

5.Develop feedback mechanisms at the workflow,  inter-workflow, and organizational levels.

6.Improve collaboratively using model-driven experiments.