The development teams I am pleased to care about work either in Scrum or Kanban. All of them started working in Scrum, and some decided to move to Kanban instead (see also https://medium.com/@timhartnack/from-scrum-to-kanban-in-90-minutes-b3b6af4a7b0f).
Based on this experience I got asked which framework is the better to use for software development teams. The short answer: “It depends”. The rest of this article will give you some view on the insights I made.
Before I begin describing my experience in using either Scrum or Kanban, I like to point out that none of the frameworks is better than the other. Both should be used to face the problems and businesses needs you currently encounter.
At the very beginning of the business transformation to work with agile teams the teams have been told by management to use scrum to organize their daily work. As this top-down approach might not be the best, nobody in the company did have a deeper experience. Hence it was a good idea to undergo the first phase of change in this direction. The development teams did not really have a product to deliver but doing multiple unrelated customer driven changes to the existing product. Although this is not the ideal scenario for using scrum starting with a given framework worked out well. Also we had the possibility to train the way we work and using the “inspect and adapt” idea of scrum to questioning the way we work. This way we could learn about ups and downs of the framework in use.
After some teams moved to use Kanban instead of Scrum, we kept having a retrospective meeting every two weeks. This way the rear view of what happened for the bad and what happened for the good did stay within the DNA of the team.
Scrum did not fit all
While the scrum teams did not do product development by the book but customer changes instead, they struggle with the sprint goal in scrum a lot. The task that needed to be done were given at the sprint start and did not complete to a visible goal. Instead, the goal has mostly been to implement all task given the fastest way possible (but not without looking at quality). Additionally, the task to perform have been planned long ago already as the changes have been promised to the customers.
Delivery vs. discovery
As the teams face the problems described I got the first contact of a main difference between Scrum and Kanban.
Its the difference between discovery and delivery.
Scrum is a framework to discovery the most valuable change in a product. Of course, you need to know the challenges of your customers and which of them your business can solve. The solution to the customers problem instead needs to be discovered by any of your product teams. Scrum allows you to have short iterations to work on this solution in close coordination with any stakeholder. This way you thrive to implement valuable change to the product the customer can use.
Use Scrum to discover the next product change. You might not change the product the way the customer wants it but the way the customer needs it.
In the past I had the possibility to support the development teams in a big modernization project. The goal of this project has been to transform the functionality which has been highly accepted by the customer into a technological future. In such a scenario most software features are predetermined. This means that you know in advance what you should implement and in which order. This does not sound as you need to discover anything as you already know how the product should look like. This can be seen as some sort of iterative waterfall process. You did not plan the new project in any detail from the beginning, but you know the order of the high-level parts. As you refine the features in detail the development teams can already start developing. Kanban is a framework for delivery, as the team is working on the task with highest priority with expected high throughput.
Use Kanban to deliver the predetermined product changes. You get the already known features in a very fast manner.
The experience I’ve gained of the last years tells me that you should not stick to a given framework because someone told you to use it. As an alternative use the inspect and adapt idea working agile gives you to challenge the framework from time to time. Encourage your team to adopt to the given scenario and explain management the pros of using the right framework for the current scenario.