It is well known that Scrum is very popular with Development teams while Operations teams prefer Kanban as it suits their nature of work best. That is because development teams deliver an incremental product over iterations and they have to plan and deliver a product as a team. Normally the scope does not change within an iteration for the committed work. For all this Scrum is ideal as it has planning, daily stand-up, review and retrospectives. Support work on the other hand is unpredictable even on a daily basis. So support teams pick the next priority item in the queue and keep completing them one by one. Mostly each work item is treated separately and completed. So Kanban suits such teams well.
However, nowadays Operations teams are facing new challenges in organizations. Most organizations are giving importance to group initiatives at various levels. These initiatives can be for improving collaboration across teams, bring in the culture of innovation, drive automation in a big way and so on and every team in the organization will need to participate in these initiatives. They are typically planned activities and it is not difficult for Scrum teams to include them in their backlog. But support teams using Kanban find it difficult to fit into their existing backlog as the current backlog is very dynamic for them. So they are faced with the challenge of closing the support requests as and when they come and at the same time, planning on delivering initiatives over a period of time. That is to say they need to adopt Scrum for initiatives while continuing to use Kanban for operations. It is popularly known as Scrumban in the industry though it could as well be BanScrum! or even KanScrum. The reason why I say this is that whatever it is called, most teams cannot change the way support work is done as they are primarily driven by SLAs. Let us examine some of the possibilities for such teams:
- Use Scrum for both development and support work. Here it is assumed that development forms major part of teams’ load.
Modus operandi:
- Deliver support work also in iterations. If that is not possible due to SLAs, support work can be delivered as and when done since Scrum is not against it.
- Review would be done at the end of iteration including any work delivered during the iteration.
- Planning will focus on stories for development and allocating a chunk of time for support work based on data collected from previous iterations.
- Allow incomplete support work to be carried over across iterations.
Challenges in this approach:
- Cycle time measurement for support work alone would be difficult.
- Setting WIP limits for work states will not be possible.
- Lead time might increase based on priorities assigned.
- Identifying delays in-between work states would be difficult for support work.
- Estimating amount of time to be budgeted for support work.
- Use Kanban for both development and support work. Here it is assumed that support work forms major part of teams’ load.
Modus operandi:
- Stories are sliced to less than cycle time size. If that is difficult, tasks are created with size less than cycle time.
- Team allocates a certain capacity in terms of number of stories/tasks for development stories/tasks based on throughput.
- A separate swim lane would be created for development stories.
- Planning would focus on picking certain number of development stories/tasks based on capacity allocated and priority assigned.
- Team members pick stories along with other work based on mutual priorities (SLA tickets get higher priority).
- Development stories/tasks are allowed to be carried over across iterations.
- Since team will be completing very small part of development work in iterations, integration testing might not be done in the same iteration.
Challenges in this approach:
- Difficulty in defining development stories with good granularity.
- Cycle time needs to be maintained very well for proper planning. That means old tickets should be cleared and backlog should be well groomed.
- Difficulty in predicting support work. There could be ups and downs and team needs to be observing variations carefully during daily stand ups.
- Difficulty in delivering meaningful functionality for development work in iterations.
I have just listed here some aspects only of such variations in scrum and Kanban implementations. These are aspects which teams have tried out during my coaching. Some teams have found benefits in these and some continue to face challenges. That is because there is nothing like ‘one size fits all’. A new team could start with some of these guidelines in absence of anything else and since Agile is all about thinking differently, one could modify them as needed to bring in newer practices and ways of working.
As usual, I look forward to your valuable feedback and suggestions.
