Teams often ask me if they should use Kanban or Scrum. Here are the questions I ask to determine which flow to recommend.
Scrum/Sprints:
— It’s a great transition from very long cycles (aka waterfall) to shorter cycles.
— When your business partners are not willing to give you ad-hoc feedback, the sprint ceremonies help set expectations on their time.
— Great for helping teams learn and practice discipline.
— Committing to work and then showing it at the end of a sprint helps build trust between business and Delivery teams.
— Sprints work great for project based teams, particularly in software. Teams where waiting to show work at the end of a sprint makes sense.
Kanban:
— Generally I find that operational teams are best served through Kanban. Most of the business teams I have worked with lend themselves to a Kanban model. Software teams that are operations, maintenance, or enhancement teams also tend to work well in this model.
— The team’s work is a continuous flow of work, and their objective measured “by piece” i.e. Mean time to repair, time to market, # new contracts signed.
— You have a great trust relationship with your business partner already
— You have very small pieces of value that you can, and should, release immediately. For example, help desk or report writing teams fit the description.
— There’s nothing to demo. I find this a lot with non-software teams. They have nothing to demo, no users. There’s nothing to plan. They generally just execute.
— The work doesn’t require much collaboration. In other words, people can grab a ticket and work it. They only need to collaborate when something is blocked.
— The team doesn’t want to change it’s way of working. Yup you heard me. If the team doesn’t want to change the way it works, you can overlay a Kanban board on their current process. This is minimally disruptive to the team but it illuminates bottlenecks and weaknesses in the workflow.
Either way you should sync up daily, spend some time aligning on goals, and do retrospectives. Either way you should also limit the number of items in the ‘doing’ column(s).
Your turn…try applying Kanban to a process that you weren’t intending to change. Did you get any new insights?
