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:

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:

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.