Agile Scrumban – Built on the Fabric of Scrum and Kanban

Scrumban, a hybrid of Scrum and Kanban flavors of Agile, offers the best of both worlds. Scrumban ensures that a highly versatile workflow management is achieved by integrating the flexibility and visualization of Kanban into the structure of Scrum. Scrumban thus offers a middle ground to the Scrum’s structure overhaul, and Kanban’s unstructured approach – making it useful for both development and maintenance projects.

To fully understand Scrumban, let us first understand the main individual characteristics of Scrum and Kanban.

Scrum

  • Small, cross-functional self-organizing teams
  • Work is split into a list of small deliverables, sorted by priority
  • Prescribed roles- Scrum Master, Product Owner, Development Team
  • Short fixed length iterations with potentially shippable code demonstrated after each iteration
  • Approach is to inspect and optimize the release plan, and update priorities
  • Retrospectives occur after each iteration

In Scrum, the work to be done for the next sprint is chosen beforehand, and the sprint is then locked till the work is done. And at the end of the sprint duration, the queue is empty.

Kanban

  • Workflow Visualization through Kanban Board
  • No prescribed roles
  • Limits WIP – limits the items in process at any given time
  • Measures lead time and optimize the process to improve the lead time

In Kanban, the work keeps flowing, and although the size of the queue is limited, the items in the queue can be changed at any time.

Scrum and Kanban: The Divide

Both these approaches have their own pros and cons and work on different ideologies. Whereas Scrum has a set of prescribed roles, Kanban has none. Meetings are an integral part of Scrum, while Kanban has no such requirements. Besides, unlike Scrum, Kanban does not have a fixed time limit for development.

Let us observe how Scrumban fixes this divide and coalesces an ingenious approach absorbing the best of both.

Scrumban

Introduced by Corey Ladas, Scrumban was initially developed as a method of transitioning a development team from Scrum to Kanban. However, it has evolved as a methodology on its own, combining the finest elements of both Scrum and Kanban.

Scrumban Methodology: Filling the Void

  • Scrumban makes iterations short and optional while imbibing Kanban’s approach of a continuous workflow. Items are worked upon as and when they appear, with no prioritized and committed product backlog items. Prioritization on demand technique is normally used.
  • Scrumban has a definite team, but only requires roles as needed. There is no definite number, and roles are more specialized and less cross-functional than in Scrum teams. Team members are free to choose the task they like using the pull system.
  • Scrumban boards are used like Kanban for workflow visibility with the columns – ToDo, Doing, and Done. The board is persistent – only the tasks and priorities change.
  • Like Scrum, Scrumban involves daily meetings, however, embraces on-demand planning at regular intervals, rather than sticking to release-planning meeting or retrospectives at the end of the sprint like Scrum.
  • Like Kanban, Scrumban does not have a specific time constraint. Through the use of WIP limits on columns within their task board, the team limits itself. In Scrumban, a WIP limit is normally equal to the number of people in the team but can be expanded based on work specifications.
  • Like Kanban, Scrumban relies on measuring the lead time and cycle time as the key metric to estimate the average time of completion of a specific task.
  • Feature Freeze is used in Scrumban when the project deadline is near, which implies that the features the team already has for development can only be worked on, and no additional features can be added.
  • Finally, triage is critical as Scrumban does not embrace estimating. Scrumban triage enables termination of less significant features in order to complete essential features on time.

Scrumban definitely brings in the best of both worlds, however, application of Scrumban is not conducive to every environment and culture. Scrumban is apt for fast-paced processes or projects that require continuous product manufacturing with dynamic environments. Let us understand the applicability criterion for Scrumban.

Suitability of Scrumban

To sum up, Scrumban is ideally suited for:

  • Projects that involve a great deal of unexpected change to user stories and priority reworking. For example- maintenance projects like event driven work or help-desk/support.
  • Teams focused on new product development or continuous management improvement.
  • Projects where Scrum is constrained by workflow issues, resources, and processes.
  • Teams that require both structure of Scrum and flexibility of Kanban.
  • Transitioning to Kanban, where minor methodology changes are required to limit disruption.

Indubitably, when used aptly, Scrumban leads to better quality, reduced lead time, application of Kaizen and JIT principles along with waste minimization and process improvement. A word of caution is that before applying any methodology, it is imperative to understand the basic principles of all the agile methodologies currently in practice to determine the befitting approach for the project specific needs. The company and team readiness to adopt that approach also matter.

With skilled resources and expertise to understand the intricacies of various agile approaches, we at Astegic have developed a Scrumban Framework – SBDEFT (Scrumban Driven Engagement Framework for Testing). SBDEFT is developed with an aim to deliver the benefits of both the approaches, Scrum and Kanban, in a pioneering way in an outsourced context. Our experts are adept at understanding and implementing the approach that best suits your project, whether it is Scrum, Kanban or Scrumban. Moreover, our TRAF (Testing Requirement Analysis Framework) ensures validating QA /Testing requirements in the early stages of development to serve you with the best approach.

Leave a Comment

Your email address will not be published. Required fields are marked *