Agile DevOps – Part 1 – A Guide to Scrumban

Introduction

Welcome to the world of Agile DevOps! In this first blog of the series, we will have a detailed discussion on what Scrumban is and how it can be used to successfully execute a project.

To be precise, Scrumban is an agile framework describing hybrids of Scrum and Kanban. It was originally designed as a way to transition from Scrum to Kanban and combines selective best practices of both Scrum and Kanban. It uses the inherent nature of Scrum to be agile for development work along with encouraging teams for following the lean philosophy of Kanban to eliminate wastes and provide what customer needs. Scrumban supports continuous improvement.

Scrumban has proven to be a good exposure to teams for getting adapted to lean thinking before they start moving to Kanban frameworks. This is especially helpful to teams that are new to agile and want to start with some lighter frameworks in agile.

Leveraging Srumban – Few Scenarios

Scrumban has been quite popular among organizations who desire to adopt a full-fledged agile methodology. It shapes themindset of teams in getting adapted to agile methodologies and allows organizations to follow a systematic approach in getting their teams agile-ready. Following are some of the common scenarios where Scrumban can be handy in successful project execution:

• Frequent and unexpected changes to user stories and priorities
• Involvement of event-driven work (for example, work initiated from Helpdesk support)
• Focus on adding new features and supporting existing product
• Needs fluidity in model v/s adopting any structured model. before instance, a team is working on L1, L2 and L3 tickets. L3 work is a new development whereas L1 and L2 have the same workflow. Here, L1 and L2 forms the majority of the work and L3 is eventual
• Team is transitioning to Kanban but needs some changes to limit disruption

How is a Project Executed in Scrumban?

• We need a Kanban board to visualize work and manage backlog. Scrum board is not used, as sprints are not mandated. Work is more of continuous flow, and deployments and releases would be done at the team’s discretion as per readiness. However, it need not be a fixed cadence if we have to opt for Scrumban.
• We would need to impose WIP Limits so that we know how many tasks a team can handle at any given time. We can have more columns than just ‘To-Do’, ‘In-progress’ and, ‘Done’. For example, ‘Development and Testing’ can replace ‘In-Progress’. Work-in-Progress is controlled by workflow states.
• It is a best practice to have a DOR and DOD as you may still want to know when to start development and when to claim the work as Done. This can be supported by two columns on board having ‘Ready’ after ‘To-Do’ and, ‘Done’ as the last column.
• Scrumban does not impose need for cross-functional teams and members can be specialized in skills. Hence, there can be roles as needed. Though there is no restriction as such on total number of members in a team. It is recommended that team size should be manageable.
• There is no estimation of backlog items as it does not add value when work is done in a continuous flow. We are more focused on eliminating waste. Thus, estimation is eliminated as it does not add value.
• As we do not have estimations, work priorities are handled by arranging the flow of work in a way that enhances business value.
• Implementation of high-value changes is instantaneous as they can be show-stoppers. Prioritized work is handled one after another when resources are available.
• Not having sprints in Scrumban doesn’t mean planning it not required. On-demand planning is highly encouraged along with reviews and retrospectives as and when required by the team to ensure continuous improvement.
• Daily scrum with a time-box is mandated. This helps to track day-to-day progress and gather team feedback.
• Impediments are avoided by on-demand planning and application of explicit policies. For example, the project manager can terminate less important features or do freeze feature(s) when the deadline approaches.
• Team performance with respect to productivity on Scrumban can be measured using cycle-time metrics. Lead-time and throughput metrics will support the information required on the overall work done by the team.

Conclusion

Scrumban has proven to be a very helpful framework to carry out the support and development work together. This model has become popular where teams are new to Agile and when teams are transitioning to Agile.

The next blog on Agile will be soon published. Stay tuned.

About the Author:

Sr. Consultant, SUHAS HANUMANTRAO MALI – PMP, CSM, CSPO, SAFe Agilist – has 19 years of IT experience out of which majority of experience is in Project Management and Agile Coaching. Author has coached 1000+ Consultants in Hexaware and at Client locations, experienced in leading Enterprise Agile Transformations and Technology Migrations, experienced in coaching Business Teams, Product Owners, Scrum Masters and Development teams in Lean and Agile Frameworks.