Scrumban?? Is this one of those process gimmicks which are better suited for theory rather than actual business? These were my immediate thoughts on hearing the concept of Scrumban ! Why then, you ask, am I writing about it? Because I have felt its enormous impact and want to share the process with which I helped implement it, with you. Mind you, if you are a fence-sitter, I will convert you ! I will start by laying out the problem I faced in detail due to which I started looking at Scrumban as a solution.
The Layout
“The problems are solved, not by giving new information, but by arranging what we have known since long.”
―Ludwig Wittgenstein
As an organisation which develops products catering to both B2B and B2C, most of our products are under extended warranty (for up t3-7 years). This causes extensive maintenance operations where upgrades and fixes are made available for all product lines which are under warranty. This scenario is familiar to anyone handling operations for a product development organisation. While we utilised Waterfall model, the process followed for maintenance was as follows:
End user on facing any issue, would call up customer care. At this point cost starts in real dollar value for us in terms of $X/min of call.
If caller is satisfied during the call, no further activity is recorded.
If not, the caller can ask the issue to be corrected.
At this point cost gets escalated exponentially as issue is logged on to Customer care database.
Through profiling of call, issue is allocated to different teams. These allocations mostly were wrong and hence, the turnaround time (TAT) was large.
Till the issue is correctly solved, cost keeps getting increased.
The service manager bunches numerous issues together and releases them to end users as an upgrade. The timing of such a release is not fixed.
Above mechanism may sound familiar to some of you. Even if it doesn’t I guess you would have understood the picture by now.
The problem starts once transition to Agile from waterfall has been made (the details are available here). Simply put, if there are no departments, how do we now handle flow of maintenance issues?
Hence, we arrive at the requirement:
The Basics
“I cannot teach anybody anything. I can only make them think”
―Socrates
Before we start on the journey, we should get our basics defined. We need to identify what are the Agile processes we are discussing and their respective pros and cons. This will enable us to investigate what structures we can come up with to satisfy our goals stated in above section.
Scrum
Framework consists of 3 artifacts viz., Product Backlog, Sprint Backlogand Product Increment, using 5 events viz., Sprint planning, Sprint review, Sprint retrospective, Daily standup, Sprint. It has 3 roles associated with it viz., Product owner, Scrum Master and Scrum team.
Pros:
Teams use iterations to provide product level deliverable
Scope of iterations is defined by team
At the end of the iterations the deliverableare reviewed by all stakeholders
The priorities and backlog items can be changed during Sprint
The team can identify the rate of consumption of items (velocity) and can therefore, predict the release plan of all items
Cons:
Scrum process is not optimised for the case when constant, similar sized items create the backlog
Estimations may cause waste as different sized task are estimated randomly by team
Scrum allows items to be added/removed from backlog which might create a release not having all required items
Kanban
Framework is a set of processes which allow managing and improving workflow derived from the Japanese automobile industry. The 6 core practices of Kanban are:
Visualize the flow of work:the flow of work should be visible to all participants. This is done through a Kanban board (physical or electronic)
Limit WIP (Work in Progress):Kanban implements a 'Pull system’, wherein team members are required to first complete the task at hand before new work is pulled in.
Manage Flow: Flow of work is managed by highlighting work items and their status in each stage
Make Process Policies Explicit:Each stage has explicit policies and these policies should be highlighted so that all stakeholders can easily visualizethem
Implement Feedback Loops:Feedback loops are essential in Kanbanprocesses so that review of status, metrics and workflow can be done and feedback provided
Improve Collaboratively, Evolve Experimentally (using the scientific method):Kanban expects constant improvement through small changes, which helps the team to maximizeproductivity and achieve high performance.
Further,details on Kanban can be found in this article.
Pros:
Wastage is reduced using Kanban.
As only those items are picked which the team can work on, excess inventory is removed.
If jobs are entered at constant rate, a constant rate of release can be achieved.
Cons:
If jobs are of different sizes, this process leads to system lag
Since this process is related to day-to-day flexibility, multiple projects which require medium or long term planning cannot use this project optimally.
This process also has a requirement for a stable production environment where all dependent parties produce at the same constant rate. This may not be acceptable in all projects.
The Solution
“Do. Or do not. There is no try.”
-The Empire Strikes Back
Now that we have visited the basics, can we identify a process which mixes the virtues of both these frameworks to create a structure which will help us reach or goals? Lo and behold - you have reached the answer - its ....
How We Set It Up
Team- the team was a cross-functional team created from members in such a way that competency in all related fields were available. We setup a team of 9 members for each product line after consultation with all SME (Subject Matter Experts) and Product Owners. The team was encouraged to increase the 'T-profile’ in breadth so that every personnel could handle any incoming item and the competency of members did not become a bottleneck.
Roles-3 roles were identified in this framework. Scrum Master was tasked with handling the operational aspects and fine tuning the processes. Team handled the execution of day-to-day activities. Product Owner acted as Service Manager who would handle prioritization of incoming requests and release planning.
Framework-
Job Card
The very basis of Kanban is the job card which details the specification of the job to be done. This card is then ‘pulled’ by the team into the ‘FLOW’ which moves to various 'stages'. I initiated the Scrumban process by which, we kept the concept of the card by making slight modifications to our bug tracking system. The bugs entered into the system needed specific inputs based on which prioritisation could be done such as region of origin etc was included.
Workflow
The initial board created for Scrumban had a ‘Backlog' list into which all bugs (cards) would be entered. These cards would be pulled by the team into the ‘In Progress’ stage once the team was ready. The process of prioritisation within ‘Backlog’ was done using Big Data analysis. This topic will be dealt with in a future article.
The criteria for the ‘Pull’ was -
The job currently in ‘Working’ stage under a team member was shifted to ‘Done’ stage or
The job currently in ‘Working’ stage under a team member was shifted to ‘Waiting’ stage, waiting for inputs from other stakeholders (outside the scrumban team) and
No more cards than the total number of team members can be in ‘Waiting’ stage at any given time
The team owned the work in this structure. They gradually encouraged and coached each other in such a way that all members became competent across most competencies. No handoffs resulted in low lead time. The movement of card to ‘Done’ was only carried out once validation members undersigned the card as one which has passed the DoD (Definition of Done). As the same team was handling the cards, the lead time of each type of job was well defined after a short span of time. This allowed the team to predict accurately the rate of consumption of job cards. Extending this the Product Owner/Service Manager can plan for release at specified interval of time.
Improvement
The team started with a Sprint duration of 2 weeks. The backlog which was filled with job cards was checked and prioritised during each Sprint planning. Of this the prioritised job cards filtered based on lead time were estimated to be resolved by end of the Sprint. At the end of Sprint, a verified release was made available which could be updated to the end customer. However, it was found during iterations that prioritisation of items changed within the 2 week sprint. Hence, the Sprint duration was reduced to 1 week. However, it could not be reduced much further as a complete release package was needed to be generated when Sprint ended and this was possible only after 1 week.
Kanban also emphasises constant improvement of work flow and identification of bottlenecks. To do so, the stages were modified where ‘To do’ stage was identified which held the exact number of items identified for the Sprint after filtering from the 'Backlog'. This helped in identifying the exact WIP limit of the team. Another stage was identified as ‘In Validation’ which was the stage reached when card DoD was needed to be verified. This was required after the team found that some cards were kept in 'Waiting' stage even though no activity other than DoD verification was needed. This addition also showed the duration for which cards were getting blocked in ‘In Validation’ or ‘Waiting’ stages. At such points of time, members could pull extra cards. Hence, the total number of cards in ‘To do’ were changed from 1* Number of team members to 1.5* Number of team members. Additionally, the reason for blocked items were unearthed and resolved. The full board picture was as below:
Structure
The complete structure now looked as follows:
The customer calls the Call centre(CC) which would raise a bug defect in bug tracking system giving specific details as required. This becomes a job card which goes through the Scrumban process as mentioned earlier. It results in a software release which is provided as an Update at regular intervals (decided by the PO) to the end user.
Conclusion
The Scrumban teams were able to reduce the defect density from product lines under maintenance. As seen from above diagram the impact was huge and a reduction of field calls by 50% on a year-on-year basis was observed. This impact was purely due to the successful execution of the framework as mentioned above.
As can be seen, all goals mentioned in the first section were met. Hence, above steps can be utilized by any team who faces similar scenarios and want to achieve similar goals.
Update: The German translation of this article has been published in t2informatik and can be found here.
About Me : A passionate Agile leader having 16+ years of experience in software industry, I have handled Agile projects of various complexities. Having successfully handled Agile transition for multiple organizations, I write about my experiences, challenges and some solutions.