QA/BA Specialist at XSolve, interested in user experience. Natalia supports communication and shared understanding between development and product teams. Persistently asks 'why?'.
I hope you enjoyed the first article in this series where the background for a transition from Scrum to Kanban was described. If not, please go back to part one to better understand the process.
This time we would like to describe how the transition was actually conducted: what were the assumptions, what steps we took to accomplish the mission and what issues we faced.
The team’s attempt to switch from Scrum to Kanban was the first within the company’s history. Initially, we designed it as an experiment, to be reviewed after a 6-week period, but really the team hasn’t even seriously considered going back to Scrum for this particular project.
What did we want to achieve?
The team aimed for a smoother development process accompanied by clear visualisation. As a result, constant information about progress should be available to the Product Owner and his team, the developers, and all other interested parties. We hoped to enhance communication and maintain a high level of mutual understanding but at the same time spend less time on unproductive meetings.
To accomplish that goal, the team decided to prepare two boards, so that each person involved in the process could focus on the part that interested her/him in particular.
Moreover, to cope with changing priorities or excess workload, the team set limits on work in progress issues.
To provide transparent insight into the timeline, we decided to keep track of the cycle time.
Also, our goal was to precisely define when a story or task was ready for development so that we would not be in any doubt when starting a new feature.
Day one of Scrum to Kanban transition
The team’s adventure with Kanban started with a short workshop where we mapped the current development process into the new statuses. We discussed the new workflow, including how to keep it unequivocally understandable and that resulted in a great discussion. The crucial topics we highlighted were:
Limits – it took quite some time to agree whether we should apply them from the very beginning and to what extent.
Push/pull model? – they say Kanban is definitely a pull model but we observed that in some stages of our process, ‘push’ was more accurate. As a result, we combined the two approaches.
Too many statuses – an ‘in progress’ and ‘done’ column for each status seemed to be a lot. In the end, we kept two columns only for some actions: development, testing (Internal and User Acceptance Testing – UAT for short) and resigned for others (e.g. requirement gathering phase).
Kanban Product Board
When the team had mapped the process, two Kanban boards emerged: a product board and a development team board.
The product board was an overview focused on user stories and features, not on specific tasks, to give the client a general overview of progress:
flow started when tasks/stories were moved from backlog to ‘selected for refinement’;
less detailed columns were: selected for refinement, refinement, refinement done, in development, development done, deployed to UAT, in UAT, blocked, UAT done, then scheduled deploy to production;
stories ready for development automatically appeared on the development team board.
Kanban Development Team Board
The development team board was definitely more focused on the implementation phase and no details concerning refinement were mentioned:
More detailed statuses allowed us to observe progress from refinement to production and deploy;
We started with ‘selected for development’, followed by ‘technical analysis’ (to deepen the business analysis if necessary), then ‘development’ including ‘code review’, and internal and user acceptance testing (UAT) activities;
At the end of the flow, a candidate for release was specified;
Defects were pushed automatically to the ‘selected for development’ column, omitting the refinement phase.
Limit on Work In Progress
For both boards, limits were set on items within some statuses. We tried to keep the number of such items low in order to have more control at the beginning of the transition. However, considering the size of the team (ca. 14 people) the decision on the relevant number of tasks had to take into consideration the need to provide work for all team members. Basically, restrictions were established at the beginning of the flow:
selected for refinement – 12 items;
refinement – 6 items;
selected for development – 14 items.
Limits were also set for the ‘code review’ (10) column in order to move developed functionalities forward.
Unfortunately, we did not prepare any restrictions or ‘punishments’ for not keeping the limits in order. As a result, we still had too many issues in refinement or both in development and code review, meaning there was not enough pressure to prepare a completely clear board before we started development, resulting in a slight slow-down at the beginning of the process.
During the first days of the transition, the team faced a few issues with mapping the Scrum board to Kanban. In ‘selected for development’ as well as in ‘development’ there were some outdated tasks and defects that should have been either in ‘won’t’ do status or in backlog.
Also, we had to figure out how to deal with tasks that did not end with production release, such as design tasks, exploratory test, meeting, business analysis. It was decided to keep them in backlog, and not include them in the current board overview.
Cycle time turned out to be one of team’s biggest struggles. Every time we asked when a feature/task/story would be ready for UAT, the team had to discuss the case from scratch and our recommendations were never based on cycle time. Of course, it is possible that it was too early in the process to have the perfect measurements in place, but we definitely could have paid a bit more attention to that aspect of the transition.
Eventually, the team worked in Kanban flow for about three months before it was downsized. At that point, we wanted to check how the experiment had gone – was it a success or a disaster? The team was surveyed about the transition from Scrum to Kanban, and…
You will discover the results in the last part of the series, which will be published next week.
Inspired by this article? Find out more by reading: