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 optimizes 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 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 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 for 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 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 matters.

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.

What is Scrum, and Why You Should Adopt It

Hirotaka Takeuchi and Ikujiro Nonaka introduced the term ‘Scrum’ in the context of product development in their article, ‘The New New Product Development Game’. By definition, Scrum is a project development framework that highlights teamwork, collective accountability, transparency and iterative progress towards a defined goal.

In the contemporary competitive environment, stakeholders are vying for speed to market, excellent product quality, and a quicker ROI. In addition, frequently changing business requirements need to be addressed continuously. This is where Scrum fits in. In Scrum, tasks are divided into shorter fixed timeframes of release cycles with adjustable scope to address frequently changing development needs. Scrum is unlike the traditional Waterfall Model that follows a step by step process to get a full featured product– a major drawback to which is that any changes added later in the SDLC would involve revisiting the earlier phases, and redoing the changes. Scrum saves this effort.

The Scrum approach is open to changes and welcomes change as long as they enhance customer experience. The Scrum dev team starts working with the product owner from early on to determine the minimum viable product or MVP, from which point on the incremental development proceeds till the full set of requirements is delivered. Scrum teams normally consist of five to seven members, and work is done in ‘Sprints’ with predefined timelines, resulting in a fully tested product with additional functionality.

The three key roles in any Scrum Team are:

Product Owner: The key stakeholder who is actively engaged with the Scrum team, and is business savvy with a clear understanding of what the product functionality should be. The product owner ensures that the expectations for the end product have been communicated and agreed upon, and can prioritize user stories for the product as required, along with making sure that any new requirements are not assigned during the Sprint.

The Scrum Master: The Champion of the Scrum ensuring that the Scrum team is productive and progressive. They may take up any role in the team to finish the task required to move the Sprint forward, and in case of any obstructions, Scrum Master follows up and resolves the issue. They also organize sprint planning and stand-up meetings, reviews, retrospectives to keep the sprint moving.

Developer/Tester:  Sprint teams consists of a mix of competencies working together, and the roles may rotate Sprint by Sprint. Testers, Developers, Database people, Support- all work in close collaboration to develop and implement the defined features and there are no set rules or defined job descriptions, rather it depends on what the team agrees upon. Overall, it’s a ‘whole-team’ responsibility to deliver the working software at the end of the sprint.

Let’s understand the entire Scrum Process in brief along with where the above roles come into picture.

The Scrum Process

  • The Product Owner creates a Product Backlog.
  • Sprint Planning takes place and based on the priority, the team imports items from the Product Backlog to the Sprint Backlog, and brainstorms on how to implement it.
  • Daily Scrum meetings are conducted to assess the progress and share the impediments.
  • At the end of each Sprint, delivery teams ensure the work is in a potentially shippable state.
  • Scrum Master ensures that Sprint is moving forward, tasks are being completed in time, and impediments removed.
  • Sprint ends with a Sprint Review, and a Sprint Retrospective to identify what went wrong and what went right.
  • For the next Sprint, the team pulls another prioritized chunk from the Product Backlog, and begins working.

The cycle is iterative and whenever the projects ends, Scrum ensures that the most significant work has been completed. So you get a viable product at a lower cost in a short time span.

Let us check the benefits that Scrum offers to businesses.

Benefits of Scrum

Overall, the Scrum Framework offers the following benefits:

Quick Deliverables: The involvement of the Product Owner to progressively elaborate the requirements and to set priorities along with providing real time clarification reduces the time to market. ‘High value and risk’ requirements can be delivered before the ‘low value and risk’ requirements, with every Sprint resulting in a working product that is potentially shippable.
Increased ROI: Daily meetings, regular monitoring, continuously imbibing market changes, and shorter predefined release cycles- all lead to increased ROI. Regular stakeholder feedback enables early corrections sparing a lot of time and money. Additionally, automation and up-front testing results in lower wastage and faster deployment, and thus a better ROI. Finally, if the product has to fail, it fails faster.
Superior Quality: Regular inspection of the working product, with daily testing and Product Owner feedback in the development process, allows for early visibility of the quality issues and necessary adjustments. Sprint reviews and retrospectives allows for continuous improvement and thus a superior end product..
Increased Collaboration and Ownership:The complete team works together on the entire project, and decisions are made in consensus. Sprint Planning meetings helps self-organizing cross-functional teams to set their pace and organize their work around the given business priorities, and further, daily Scrum meetings, Sprint reviews and retrospectives enhances team spirit and collaboration.
Enhanced Customer Satisfaction: Scrum enables organizations to change the project and the deliverables at any point in time, resulting in the most apt release. Scrum thus embraces changing customer requirements leading to increased customer satisfaction.
Better Project Control:  Regular feedback, the ability to address changing market demands, Sprint reviews and daily meetings offer ample opportunities to keep the project under control, and make timely amends.
Transparency: Expectations are effectively met with Scrum as the key stakeholders are actively involved throughout the project. Continuous inspection and adaptation, and total transparency are the real benefits of Scrum.

Given these benefits, it would not be an overstatement to say that if an organization adopts Scrum in its true sense, everyone involved will be able to discover the real benefits Scrum brings along.

At Astegic, we have developed a Scrum framework specifically crafted for QA and Testing stages of product development- SDEFT (Scrum Driven Engagement Framework for Testing). SDEFT introduces a set of best practices that create a flexible framework allowing consistent and predictable result delivery, resolving the critical client concerns of quality, agility, cost effectiveness, quicker ROI and speed to market.