In most of my 15 years in Software Development, I’ve mainly been part of development teams which were practicing Scrum methodology. Although we have always aimed to do it right, somehow the organizational culture and operations methodology influences how Scrum was implemented in these teams. Recently, in my current team we decided to actually move from Scrum to Kanban. Here is how it turned out for us.

Why did we decided to switch?

I am very passionate about Software Development process. Without working process I believe it is not possible for a team to reach their output potential. Yet, I am not religious about methodology used. While one methodology in one environment may thrive, it may kill the productivity in one another. So, why did we decided to switch? Was Scrum not good enough for us?

Well, I would not say Scrum is not good. I’d rather say, in our organizational environment, it did not seem the most optimal methodology. There were certain details around Scrum that we were struggling to implement properly. While I believe that it’s OK if we id not implement it 100%, I also believe that if we are missing some core things, than something is not right.

What were we actually missing? Sprint goals! We were rarely actually meeting our Sprint goals and our burn down chart was rarely meeting the lower end. Why was this happening? Were we a lazy or a dysfunctional team? Actually completely the opposite. The team was and is very focused and very productive. It was just the environment that was not enabling us to achieve those goals.

In our department we embrace a DevOps culture. We don’t only develop solutions, we also run and maintain them. Also, in addition to modern cloud based solutions we have developed, we also have to support a legacy application which is old and with a lot of hidden details. Any time we were touching the legacy application, our estimation of tasks was completely deviating because of unknown surprises.

With all these constraints, it was often that while in the middle of the sprint, we had to change priorities because we needed to fix something in the legacy app or because we needed to attend to a customer incident. In such circumstances, we could not just tell our customers “wait until the next sprint because the current one is full”. Of course our customer centricity pushed us to react immediately and solve the problem of our customer, but often issues of this nature lead us missing the Sprint goals.

Another thing that was not working for us is estimations. Estimating software is difficult. Especially in Agile environments where you have to judge the “half specified” request and give a number. But then when you give the number, you have to live with the pressure to deliver on time. Plus, often we go ahead and plan for more than one Sprint because the backlog is always larger than one can deliver, and then you realize delays in one Sprint affect the others, but on the other side the business people expect the potential date you had given them. This was another major sign for us that Scrum is not the best methodology for our circumstances.

The transition to Kanban

We did the transition in small steps. First thing first, we had a joined workshop with the team and agreed on this transition and the steps. We also pictured how the new process will look like and how do we map existing process steps to the new one.

Of course, implementing Kanban by the book was difficult again for the same reasons. One has to adapt to the organizational requirements as well. We could for example transition to continuous deployment immediately. Technically we had all the mechanisms in place. Yet, we had to satisfy some organizational expectations. Our solution is used by customers around the world. Our account managers expect us to communicate the change to them so they can communicate to their corporate customers. We also get often their help in testing major changes, so just rolling updates without a schedule was not going to work well in our case.

What we decided was to apply Kanban and release to development and quality environments as continuously, but keep production releases on a regular schedule. So far, this is working quite well.

Initial Chaos

The first day or two when we transitioned the workflows things did not go perfect. We had some Jira ticket statuses mapped not exactly as we wanted, therefore our board got messed up. Fortunately, we were able to fix this in a day and things started to get back to normal. Also, during the first week, it happened that people were confused about the flow of the process but everyone got used to it quite fast

The joy of on-demand prioritization

One of the main benefits of Kanban is that we can re-prioritize the priority backlog as often as we need. Is there a new business requirement, a burning customer incident, or a support request, we can adjust the priority on demand without feeling the stress of missing sprint objectives. This has released especially the “friction” between the Product Manger (facing pressure from the customers) and the development lead (trying to maintain the sprint promise).

Feedback from the developers

Whenever I have to drive such a change, I like to constantly get the feedback of the team mates and adjust/pivot in necessary. So far, I’ve mainly received positive feedback from the team about Kanban.

Developers feel less under pressure when they do not see a waiting list of tickets for the sprint. While we have the same level of productivity, it now feels more like a flow rather than a milestone based sprint.

This change has also substituted ceremony meetings (prioritization, tech planning, retro and review) with on-demand fully focused meetings. This has created more productivity time for the team.

Conclusion

Again, going back to my initial statement, it’s not that Scrum is bad per se. It just was not the best methodology for our circumstances. Moving to Kanban was an opportunity for us to improve our process to something that fits our needs better. So far, it has been a very rewarding experience and we enjoy it. Of course, after some time we’ll have to revisit this as well and see if we need to move ahead to something else. Continuous improvement is what we enjoy!