(picture by Vermin Inc)
Once again context has slapped me in the face.
When trying to figure out a better way to deliver software in a company, I can’t deny that I always start with what I know. In a current assignment, we decided to switch from Scrum to Kanban in the belief that it would better serve our needs. We had high expectations about the new approach, so we decided to go all the way and apply Kanban to all projects and services. I know, that’s already a 1st mistake. “One process to rule them all”.
Thanks to the critical minds of my colleagues, it didn’t take long for us to reflect about reality. What did we notice?
We started to deliver a new product with Kanban, no questions asked. It was the way to go at the time, for all teams. But we noticed that people lost focus. We didn’t have that major focus we used to have when working in sprints. Instead, we measured flow, limited Work In Progress and pulled work from a prioritized list. Maybe it was an illusion that people could remain focused thanks to their own discipline and coaching. Reality showed us different. Focus was low and features took longer than expected to flow through the pipeline. Maybe we needed more senior people on the team? Maybe coaching was insufficient?…
I believe there’s another, more important cause to these symptoms.
We were in the stage of creating an entirely new product. A new technology, a new business problem, new architecture and new products. The learning curve was very high. In these types of projects, focus is very important. Focus on the lightest solution possible, building a first release fast and with high quality.
This is where I believe the focus of a planned iteration has high added value. Planning a time boxed delivery cycle with a clear goal. “At the end of the iteration we want to be able to… so that we learn about … and can improve our predictability and reduce variation.”
That’s why we’re thinking about reducing our ‘Kanban all the way’ vision. We will still use Kanban for most of our work, with one exception: The first release of a NEW product gets delivered by applying the Scrum framework. Highly focused iterations that are planned and evaluated in order to get past that first steep learning curve. Once things get stable, we will switch to a pull system. History has shown us that this can already be done after the first release. And since we try to keep this release as thin as possible, the switch can happen quite early.
Why don’t we stick to Scrum after the first release? Well, because we truly value the Kanban concepts such as limited WIP, pull and reducing variability. They make it easier for us and the stakeholders to plan and adapt. It allows us to agree on SLA’s with different product stakeholders so that we don’t overload the teams, which only leads to frustration and mistrust.
Will this approach better fit our needs? I don’t know, but we have no other option to look further and try to improve. Every suggestion or thought is welcome!