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.
