Scrumban is a hybrid Agile project management methodology that combines elements from both Scrum and Kanban. It was initially designed as a way to transition from Scrum to Kanban, but has since evolved into a standalone framework that takes advantage of the strengths of both systems.
Here’s a brief overview of each, to provide context:
- Scrum: This is an iterative and incremental agile software development framework. Work is divided into sprints (usually 2-4 weeks), where a set of features are developed and delivered. Key roles in Scrum include the Product Owner (who defines the product in detail), the Scrum Master (who facilitates the process), and the Development Team.
- Kanban: This system emphasizes real-time communication and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time. The workflow is continuous and isn’t divided into sprints. A key aspect of Kanban is limiting the amount of work in progress (WIP) to prevent overcapacity and ensure smooth flow. The key focus of Kanban is flow and efficiency.
What are some general benefits of scrumban?
- Flexibility: Scrumban uses the structure of Scrum and the flexibility of Kanban. Unlike Scrum, which is time-boxed, Scrumban focuses on completing the highest-priority tasks and then pulling in the next ones from the backlog as capacity allows. This makes it highly adaptable to changes.
- Focus on Efficiency: Scrumban uses the pull-based system of Kanban, meaning team members pull new tasks when they have completed their current task, rather than having tasks pushed to them. This helps eliminate multitasking and allows for increased focus and efficiency.
- Continuous Improvement: Scrumban also embraces the continuous improvement philosophy of Kanban, encouraging teams to constantly evaluate their own performance and look for ways to improve.
- Visual Management: Like Kanban, Scrumban uses a visual board to track progress and workflow. This provides a transparent view of the project’s status to everyone involved.
- Roles: Similar to Scrum, Scrumban recognizes roles such as the Product Owner and Scrum Master, but they are not as strictly defined. Teams have the flexibility to adapt roles based on their needs.
- WIP Limits: By setting a maximum number of tasks that can be in progress at any given time, Scrumban can help manage workflow and prevent team members from being overwhelmed.
- Planning on Demand: Instead of planning work for the entire sprint upfront as in Scrum, Scrumban introduces planning on demand, which means planning is triggered when the number of backlog items falls below a certain level. This approach ensures a continuous flow of work and is better suited for projects where priorities may change frequently.
- Limiting Waste: Let’s plan / refine only what’s necessary in scrumban. Lean is best.
Does Scrumban use Velocity or Cycle & Lead Time?
In Scrumban, key performance metrics from both Scrum and Kanban are used, with more emphasis on Kanban’s flow-based metrics like Cycle Time and Lead Time rather than Scrum’s Velocity.
- Cycle Time: This is a key metric in Kanban and Scrumban, representing the amount of time it takes for a work item to move from the start to the end of the process. It helps teams understand their system’s capacity and provides a basis for forecasting future performance.
- Lead Time: This is the total time from the customer request to the delivery. It includes the wait time before work begins plus the cycle time. By monitoring and looking for ways to reduce lead time, teams can improve their responsiveness to customers.
Unlike in Scrum, where velocity (the amount of work completed in a sprint) is a key metric, Scrumban places less emphasis on velocity. This is because Scrumban is more flow-based, with work items being pulled in as capacity becomes available, rather than being planned in iterations as in Scrum. That being said, some teams may still choose to track velocity as a secondary measure or use it for longer-term forecasting. For a quick guide on estimating in agile please check out that article! The specific metrics used can vary based on the team’s needs and the nature of their work. As with any Agile methodology, the key is to use these metrics to drive improvement and enhance the team’s ability to deliver value to the customer. Don’t get stuck on the process only. Remember customer value and quick iterations!
Does Scrumban still have refinement & planning meetings?
In Scrumban, the concept of backlog refinement or planning, which is common in Scrum, still exists. However, it can be more fluid and continuous compared to Scrum. In Scrum, backlog refinement / planning is usually a dedicated meeting occurring during the sprint, where the Product Owner and the team review and update the items in the product backlog.
In Scrumban, this activity is often referred to as “Ready to Pull” or “Replenishment” or “Refill” meetings. Instead of refining the backlog for the next sprint, the purpose of these meetings in Scrumban is to ensure that there are always enough well-defined tasks ready to be pulled into the workflow as the team has capacity.
The timing of these meetings is usually determined by the depletion of the ready column (or ready queue) in the Kanban board. When the number of tasks in this column drops below a certain level, it triggers the Replenishment meeting. This way, instead of having a regularly scheduled meeting as in Scrum, the need for refinement in Scrumban is determined based on the actual flow of work. This allows the approach to be more flexible and adaptive to changes in priorities and the team’s capacity.
Does Scrumban still have demos and retrospectives?
In Scrumban, similar to Scrum, the concept of retrospectives and demonstrations (or demos) is preserved, although they might not be held as regularly scheduled events tied to the end of a sprint, as in Scrum.
- Retrospectives: These are opportunities for the team to reflect on their performance and identify opportunities for improvement. In Scrumban, retrospectives are typically held continuously and informally, or at regular intervals that make sense for the team. The main goal remains to uncover and address issues that may be impeding the team’s performance.
- Demos: Also referred to as reviews, these are held to showcase the completed work to stakeholders. In Scrumban, they can be scheduled regularly (for example, every two weeks) or could be held on a just-in-time basis when a certain number of features are ready to be shown. This could be particularly useful in environments where work items vary greatly in size or complexity and trying to fit them into a regular schedule would be artificial.
As with all aspects of Scrumban, the exact practices can be adapted based on the needs of the team and the nature of their work. It’s all about delivering value to the customer effectively and efficiently, and fostering a culture of continuous improvement. The ceremonies of Scrum such as retrospectives and demos serve these goals and therefore find a place in Scrumban, albeit with modifications to suit the flow-based nature of the work.
What are some potential cons of scrumban?
- Lack of Strict Structure: Scrumban is more flexible than Scrum, but this can also be a disadvantage for teams that need more structure and discipline. Without the structure of sprints, teams might struggle to organize their work and maintain productivity.
- Requires Discipline: The flexibility and adaptability of Scrumban require a high level of discipline from team members to limit their work in progress and ensure that tasks are pulled through the system efficiently. Without this discipline, teams can easily become overwhelmed.
- WIP Understanding: Limiting work isn’t intuitive to some. Why would limiting work reduce cycle time? I can take on as much as I can do increase that velocity right? WIP takes time to implement and really get going with some teams.
- Complexity: For teams new to Agile methodologies, Scrumban can be complex to understand and implement because it combines elements from two different frameworks. It also requires a solid understanding of both Scrum and Kanban to be implemented effectively.
- Resistance to Change: Like any change in methodology, transitioning to Scrumban may face resistance from team members who are comfortable with their existing processes. This can be particularly challenging if team members are deeply rooted in traditional Scrum or Kanban practices.
- Dependency Management: In situations where there are high inter-dependencies between tasks, managing these dependencies can become more challenging compared to Scrum, where the work for a sprint is planned up front. Classes of service must be visited (I’ll talk about this later) which is a foreign concept to those newer to Kanban
Conclusion
Getting used to Scrum and Kanban can be hard. Combining the two can get tricky as well. Some team members may resist and say “I only do Kanban” or I only do “Scrum”. One of the most important values is to not get lost in the process and to remember customer feedback loops, time to market and efficiency are some of the top things to focus on in this environment. If you have any questions on combining scrum and kanban or working with either, just let me know.