Our Journey into Scrumban

Here at Arrk Group we have adopted Scrumban methodologies over Scrum and other alternative development methodologies. Let’s take a look why we did, what we did and importantly what have been the benefits.

Scrum and Kanban

Since Agile was first conceived, many development methodologies have evolved; Scrum, XP, DSDM, RUP, Kanban, Lean to name a few, all bringing many valuable elements worth considering from time to time. Two of the most common flavours of agile today are Scrum and Kanban. At Arrk Group we believe that it is always about being Agile rather than being methodology-manic.

Before delving into the Scrumban methodology, let’s take a look at some of the elements taken from Scrum and Kanban:

Scrum

Kanban

A prescriptive tool for Agile development

A flexible approach suited to change management, rather than fully-fledged development projects

Work done by small cross-functional, self-organising teams

Teams are self-organising and sometimes cross-functional

Work split into small, concrete deliverables and prioritised into a backlog

A visual workflow with columns is used to track small-sized work items. There are limits to the number of items that can be taken up

Potentially shippable code is delivered at frequent intervals. The team estimates and commits to the work that will be done in each iteration before it starts.

Iterations or commitments are not prescribed. Release contains shippable code as needed but short intervals

A release plan is prepared in collaboration with the customer

The release plan is flexible

Once the iteration has started, changes in the form of new items are not normally premitted

New items can be added, provided the capacity allows for it

Team comprises of Product Owner, Scrum Master and Development team

No roles are prescribed

Follows the Push Model (i.e. tasks are assigned to team members)

Follows the Pull Model (i.e. a team member picks a task from the backlog)

Retrospectives held after each iteration to improve the process and share learning

Continuous improvements are a key element of Kanban

Velocity is a default metric

Lead time is the default metric

Up front preparedness/training and setup time is needed

Non-prescriptive, can start immediately

Suited to development projects

Suited to production and support projects

Why Scrumban?

We started with Scrum with much fervour and focus. Our project was development oriented to begin with, the product backlog was ready, the 25-30 strong team was properly trained and in a single location, with the customer and product owner in another.

We followed Scrum methodology practices like planning, estimation, story development, scrum ceremonies with proper implementation cycles. As we began to progress with growing team sizes and maintenance/production support kicking in, the limitations of the Scrum methodology, complemented by some of the idiosyncrasies of the specific project began to set us back.

These were:

Non-availability of complete user-stories within the product backlog for release planning.

The need to meet urgent business demands during implementation.

Poor utilisation of “idle” resources when work finishes early within the iteration.

Busy customer unable to actively collaborate or attend ceremonies.

Lack of a fully-fledged cross-functional team.

We started searching for a methodology which would suit our context, to help build timely and quality backed solutions. At Arrk Group, we strongly believe that being agile means speed and flexibility to respond to and deliver solutions which cater to the customer’s needs.

Therefore, we decided to explore the use of core Kanban framework, but Kanban, being an assembly line and manufacturing methodology, focuses on the execution process more than the planning aspects. We concluded that following a Kanban-only methodology would not work taking its limitations to handle fully-fledged product development; comprising development, production support and ongoing maintenance with multiple teams.

What was required was a methodology which would provide optimal project planning and reporting similar to Scrum, combined with an execution process that optimized the change handling and resource utilization found with Kanban.

The Scrumban Methodology solution

Scrumban methodology combines the best features of both Scrum and Kandan and can be used for development and maintenance projects. Scrumban allows augmenting of Scrum with Kanban practices to progress towards a more recognisably lean workflow.

Therefore, we continue to utilise Scrum-like iteration planning and iterations process, but we know complement this by incorporating Kanban pull features for production issues. These issues could be bug-fixes or enhancements whose characteristics are as below.

They needed to be turned around quickly since these were found in production.

The changes are relatively small compared to building new application features.

These changes are independent of each other.

This led to us having a dedicated backlog for Production issues alongside those for the iteration and the release. This also meant creating a release for such changes on a weekly basis. The capacity planning was tweaked to ensure we were satisfying the customers priorities, be they for Production issues or new features. Subsequently as the application size grew, so also did the demand from production (end) users, we created a dedicated team to cater for this demand.

As the project progressed we fine-tuned our approach, borrowing from the Kanban process-can as needed. We also introduced agile practices driven by the cadence of the project context.

Our Scrumban methodology has evolved over time but now looks like this:

Feature

Taken from

Impact when using Scrumban

Product Owner + Scrum Master + Team

Scrum

No changes required

Cross-functional team

Scrum

Not fully cross-functional but specialists contribute to the projet success

Prioritised Backlog

Scrum

Project/multiple release work is good to have but Scrumban allows flexibility of working with minimum available user stories

Work In Progress

Kanban

Team member picks up new item from the backlog only after satisfactory completion, assuming obstacles don’t exist or are resolved. The WIP limit ensures focus and prevents dysfunctional heroics. (This is also equivalent of a work-agreement of sorts)

Boards/Tools

All

Rally and defect management tools continued to be used

Release planning

Scrum

This is important and carries on as usual, driven by business expectations

Backlog grooming

Agile

This is great practice we believe in to sharpen user stories, foster early thinking, judge cycle time and estimate t-shirt sizes

Planning meeting

Scrum

No change. This is to pull and discuss a set of user stories, prioritised for delivery

Velocity

Scrum

We stopped maintaining this, since the story priority is liable to change for accommodating items pulled from the ‘Production backlog’. Also its removal meant death of the metric that can in some circumstances cause lower quality at the end of a Sprint as it pushes the team to scramble to finish every last story they committed to.

Estimation of stories

Scrum

Required to judge the relativity of work compared to release end date in story point form.

Time-boxed iteration

Scrum

We stopped this to accommodate continuous flow of work, working towards a (development) release timeline while being flexible to admit and deliver (production/maintenance) high priority items.

Upfront assignment of stories with Pull system

Scrum & Kanban

The assignment of stories during Iteration Planning was stopped to ensure that whoever finishes the story first can pick up next. Remember minimum required work shall always available in backlog

Granular stories/tasks

Agile

A Story is broken into as many tasks practicable for increased efficiency. A smaller task, given its quicker completion, also helps motivation and feeds progress.

Daily Stand-ups with Continuous improvement

Scrum & Kanban

Besides the usual 3 questions, the team focuses on Release Goals, utilizing idle time, if any, and dealing with suggestions to resolve impediments and improve the process.

Definition of Done

As per organisation/project need

Regular feature demo/review

Scrum

There isn’t any fixed date as work is flow-based however demos happen to ensure visibility and feedback provision from PO/customer.

Retrospectives with Continuous improvement

Scrum & Kanban

Timed Retrospectives are stopped in favour of this being an ongoing process

Metrics

Lead Time: a period of time, measured from the moment a request is made until the tasks are completed. It is what the customer sees and relevant from a business perspective.

Cycle Time: the time an item spends on the board, from Ready to Done measured in elapsed days. It is a mechanical measure of process capability and influenced by the team, its capability and work-process.

How Arrk Group benefits from using Scrumban Methodology

We began piloting and developing our flavour of Scrumban out of necessity on a large, distributed development project where the team was finding that just following Scrum-based practices was beginning to hinder theprogress the team felt they could be making.

They felt by making changes they could drive better productivity and efficiency and optimise resources. Here are the benefits the team experienced by moving to a Scrumban methodology:

Different backlogs for Release/Product, Iterations and Production Issues ensure team focus and optimum work allocation. Resources are therefore optimally utilised.

Since the pull system is utilised, team swarms to achieve goals whether they are specific technical tasks or customer imposed priority tasks, resulting in better teaming and team productivity.

The team is a mix of cross-functional and specialist resources thus allowing us to harmonise the best of both.

Our experience suggests that quality considerations are addressed better than they would have been if we had not followed Scrumban.

Just-in-time decisions and implementation of decisions is greatly facilitated since tasks needing immediate attention can be taken up.

Customer impromptu requests are taken care of so the customer gets higher priority requests dealt with earlier and with a sense of real urgency.

Since the continuous improvement is on-the-go, the monotony of retrospectives has given way to team members voicing concerns about impediments as and when with resolutions brainstormed soon after.

Minimizing waste (cutting out everything that is not adding value to the customer).

When to consider Scrumban

Since Scrumban methodology features the best of Scrum and Kanban, the situations in which it can be used are many and varied. It can and should of course be tailored to suit your own particular requirements. The following projects/types of situations can all benefit with its adoption in our view:

Development Projects

Maintenance Projects / Production Support Projects

Where frequent, intermittent changes are needed

If Scrum is challenged by workflow issues, resources and processes

Conclusion

Scrumban methodology at its core does not have any fixed framework similar to Scrum, however it becomes strong and Agile with the best practices from Scrum and Kanban. As a team we decided which practices fit best and we used them to reap many benefits which have been outlined in this post.

In our case, Scrumban helped developers by limiting work in progress and removing overburden, the Project Manager in optimising resource utilisation for increased efficiency, and above all allowed the customer to get real value for money from them investment. Scrumban mixes the prescriptive Scrum with culture-rich Kanban to deliver a set of practices which allows achievement of objectives and multiple teams with different focal points to deliver successfully.

Authors

Interested? Get in touch

Name:

Telephone:

Email:

Message:

Digital Maturity Assessment

Complete our five minute survey and you will be sent a detailed report on how you compare to your peers across five dimensions. The report will also contain best practices in each of these dimensions to guide your digital transformation.

We have a profound commitment to collaboration, executing engagements ranging from high value consultancy to whole-of-life ownership of complex digital platforms and infrastructures across a broad spectrum of industry sectors, from start-ups to multi-national enterprises.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.