Scrumban ‒ Being Differently Agile

Executive summary:

Anyone who has worked for quite some time in the Agile environment would not have walked out without tasting the spices of Scrum and Kanban as part of their day-to-day activities. Scrum is best suited to products and development projects, whereas Kanban is best known for its role during production support. We can clearly see that both these ingredients of Agile have their own flavors and work style. Having said that, the characteristics of both these models have helped Agile experts take the decision to combine the best features/possibilities of both and thereby come up with a new technique/model, namely the “Scrumban”. In the recent past this has served as the best choice for service industries, where we have both development and maintenance projects. Before we jot down the pros and cons of adopting Scrumban, let us understand Scrum and Kanban better.

Unveiling Scrum in a nutshell:

Step 1: Split your organization into small, cross-functional, self-organizing teams.
Step 2: Split your work into a list of small, concrete deliverables. (Sort the list based on priority and estimate the relative effort of each item.)
Step 3: Split the timeline into short fixed-length iterations (usually 1–4 weeks), with potentially shippable code demonstrated after each iteration.
Step 4: Based on insights gained through inspection after the release of each iteration, optimize the release plan and update the priorities of the work item with the buy-in of your customer.
Step 5: Optimize the process by having a retrospection after each iteration.

Unveiling Kanban in a nutshell:

Step 1: Visualize the workflow
Step 2: Split the work into pieces, put each item on a card and stick it up on the wall.
Step 3: Use named columns to illustrate where each item is in the workflow.
Step 4: Limit work in progress (WIP); assign explicit limits to how many items should be in progress at each workflow state.
Step 5: Measure the lead time (average time to complete one item, often called the “cycle time”), and optimize the process to make lead time as small and predictable as possible.

In Scrum you select the work you will be doing for the next sprint in advance. You then lock the sprint, do all the work, and after a couple of weeks ‒ the usual sprint duration ‒ your queue is empty. (See Figure 1.1)

image001

Fig 1.1

In Kanban, the only limitation is the size of the queues, called the WIP limit. This means that you can change the items in the queues at any time, and that there is no „sprint end“. The work just keeps flowing. (See Figure 1.2)

Fig 1.2

Fig 1.2

Scrumban is a pull-based system where the team, in addition to planning out the work that was committed to during the initiation, continually grooms the backlog. The same Scrum meetings which include that of Planning, Review, and Retrospection can and should still take place, but with the pace of such meetings being more context-driven. The real key for opting for Scrumban is to ensure that work in progress (WIP) is still limited.

Work-in-progress limits, not Sprints:

With Scrum, the amount of work that is ongoing is limited by the Sprint time commitment. But in Scrumban, with no specific time commitment, the team must limit itself through the use of WIP limits on columns within their task board. The goal is always to move tickets in a flow from left to right on the board. If too many issues are in progress, the team is at risk of not finishing anything with high quality standards. Since the team now pulls work into a small, ready queue before pulling it into WIP, the team’s perspective of the iteration backlog’s utility is that it always contains something that is worth doing next. Therefore, we should use the least wasteful mechanism that will satisfy that simple condition. In order to fix this, there should be a maximum number of tickets allowed per column and if the number of tickets in that column ever exceeds the maximum, the entire team should swarm onto that column and help move tickets on. This should happen no matter what functional role a team member has.

Planning meetings: These should take place as often as they are needed. When the team is unable to regularly pull stories off the top of the backlog at their normal pace, a planning meeting is necessary.

Review meetings: Reviewing the work with clients and customers is the only way that development teams can get the feedback necessary to properly adapt what they are working on. Clients tend to prefer that these are held at a regular cadence.

Retrospective meetings: These can vary as to when they are held, but a general rule of thumb is to hold a retrospective meeting after every review. This is the most useful part of the Agile process and should be given its deserved position in the schedule.

Standup meetings: Standup meetings in the Scrum world follow a simple pattern. The team takes 15 minutes and each person says:

  1. what he/she did yesterday,
  2. what he/she is working on today, and
  3. what is blocking any of that work.

In practice, this boils down to redundant statuses that recount information available on the team’s task board. For Scrumban, a more effective method is to refocus on the flow of tickets on the board. That same pattern of yesterday/today/blocked can be transferred to the tickets themselves — the group moves through each column and briefly discusses each ticket and what is necessary to move that ticket to the right on the board. This provides far more context to the team and informs every one of any major architectural or design decisions.

Metrics: Metrics can certainly be useful, but they are often abused by managers and business stakeholders who want to unnaturally simplify a complex process into a one-dimensional number. Velocity, the amount of story points a Scrum team completes in a single Sprint, is such a metric that incentivizes lower quality at the end of a Sprint as a team scrambles to finish every last story they committed to. When the number fluctuates, as is common with a newer team, the stakeholders begin to question the outputs of the team, and even the effectiveness of Agile itself.

Instead of velocity, a useful Scrumban metric is cycle time. This is the length of time a ticket takes to complete, measured from when it was first initiated. Over time, a statistical analysis of all tickets in the project can yield a mean cycle time and standard deviation. This can be a useful planning tool at the macro level, providing better clarity and tracking of the tickets onboard and during the Retrospection.

When should you go for Scrumban?

  • If it is a Maintenance project
  • If your work is going to be event-driven. Something like:
    • Help desk/support
    • Hardening/packaging phases
    • Sprint teams focused on new product development
  • If it is going to be a Project with frequent and unexpected user stories or programming errors
  • If it is going to be a project with Sprint teams focusing on new product development:
    • Work preceding sprint development (backlog, R&D)
    • Work following sprint development (system testing, packaging and deployment)
  • If Scrum is challenged by workflow issues, resources and processes
  • To manage improvement communities during/after Scrum roll-out

Kanban vs. Scrumban

Kanban Scrumban
Roles No prescribed roles Team + required roles
Daily Scrum Meeting No Meetings We do have meetings to make sure of continuous work on requirements and reduce the idle time of team members
Review & Retrospective Meeting Not prescribed Can be set up as required to work on process improvements and to share the learnings across the team
Work Flow Continuous Similar to Kanban except for the existence of the ‚limit of slots‘, so the pull system lets team members work seamlessly, making it even more comfortable.

Scrum vs. Scrumban

 Scrum  Scrumban
 Board/Artifacts  Board, Backlogs, Burn-downs  Board only
 Ceremonies  Daily Scrum, Sprint planning, Sprint review, Sprint retrospective  Daily Scrum (Planning, Review and Retrospection as required)
 Iterations  Yes (Sprints)  No (continuous flow)
 Estimation  Yes  No rigid estimates during initiation. Instead will be put up dynamically as per outputs from the Daily Scrum.
 Teams  Must be cross-functional  Can be specialized
 Roles  Product owner, Scrum Master, Team  Team + required roles
 Teamwork  Collaborative as needed by the task  Swarming to achieve goals
 Work in Progress (WIP)  Controlled by sprint content  Controlled by workflow state
 Changes  Should wait for the next sprint  Added as needed on the board (to do)
 Product Backlog  List of prioritized and estimated stories  Just-in-time cards
 Impediments  Dealt with immediately  Avoided

References:

  • Combining Scrum with Kanban for support and enhancement teams, from Innovel
  • So what is ScrumBan?, by Yuval Yeret
  • Scrumban: Using Kanban to take Scrum outside its comfort zone, from the Israeli Scrum User Group

Arunkumar Thangaraj

Arunkumar Thangaraj works as a Senior Test Analyst at Cognizant Technology Solutions. He has excellent experience in the field of quality assurance & engineering and is an Insurance domain expert, having worked across all the phases throughout the STLC. He...
Read more about Arunkumar Thangaraj