Smooth Transitioning From Scrum To Kanban

Years ago, when I started to work as a QA engineer, Waterfall methodology was in its popular times (it might still be popular for some people nowadays) and I had barely heard by that time that there are some other ways of conducting your work.

Then I changed my job and I got introduced to Scrum.

For many years I found Scrum methodology to be close to perfection. It is very powerful in helping you structuring your work, giving a good visibility on what needs to be done in a fixed amount of time, in planning your activities for that certain amount of time.

But then people start making changes. Usually, this happens when something starts to work differently than expected or when people get disappointed of frustrated by something. Fortunately, none of these were the trigger for us to move from Scrum to Kanban, but the need to have a more flexible approach. Don’t get me wrong, Scrum is enough flexible, but as usual, depends on the context and on the team needs.

Welcome to #noplanning and #noestimations land!

Things that changed:

• the number of meetings

Spring planning? Nope. Poker panning? No, thanks. Tasks breakdown meetings? Nope. Sprint review? Nope.

We took with us into the Kanban era the daily stand-ups, in this way ensuring that people talk to each other and have a good understanding of the work in progress. Another meeting is the grooming, scheduled usually at every 2–3 weeks, where the Business Analyst (in our case) shows the team the work which is going to be taken in the nearest future and the team has the chance to ask for clarifications if needed. And the third meeting inherited from Scrum is the retrospective meeting, but being a quite mature team, we tend to solve any issues on the way.

• no commitments

Here comes the moment of truth. This was the main reason we made the transition from Scrum to Kanban. The product we are working on is going to pass through a transition phase, when we are re-writing the APIs that our application is using on one side, and on the other side we are introducing React on the UI. With all these changes, it became quite hard to predict which and how many user stories are we going to deliver on a sprint base. By removing the deadlines imposed by commitments, we could adapt our process of delivering continuously as an as-needed basis.

• not afraid anymore by change requests

Changes are not causing us anxiety as it did before, because we did not commit to anything so there isn’t something that needs to be done in a dedicated period of time (i.e sprint in Scrum). While changes during a sprint are strongly discouraged in Scrum, Kanban allows changes mid-stream for a continuous improvement of the product, making this methodology a more adaptable one.

• #noestimates

In the Scrum era we used to consider the estimations a very important step of our delivery process. Knowing how many story points each user story has assigned, have given us the perspective on what is going to be delivered in the dedicated period of time I mentioned above. From what I have seen during time, people tend to overestimate an user story in most of the cases, giving them the confidence that they can finish the work in a reasonable amount of time. There were also situations when the work for an user story was underestimated and this caused issues and forced us to carry over the next sprint unfinished work from the current sprint, causing overload for the team. Our main goal became to complete the work for an user story as fast as possible with a maximum of quality.

• roles

We have a mixed team composed by Java developers, UI developers and testers, automation and manual. All the team members are strongly encouraged to step in and give some help in any area is needed or anytime a person becomes overwhelmed, but based on the individuals specialisation and preference.

• limiting work in progress

By limiting the work in progress we keep the focus on a fixed number of tasks that need to be completed with a high quality, discouraging multitasking, context switching and time wasting. Also, by having a limit on the work in progress on the Kanban board, it gives a more predictable perspective of what can be delivered. Usually the limit of the work in progress is set based on the size of the team.

• continuous delivery

The transition to Kanban had a big impact on the testing side, because we introduced the automated functional testing as part of the definition of done of an user story. We are now able to take any work in progress code from a specific feature branch using Docker, build it and deploy it on our local machines and be able to start writing the automated scripts earlier in the process. Since there is no rush to make it to the deadline, we are not tempted anymore to cut corners and and make compromises on the quality side.

And what is the most important thing:

• team morale

I can say for sure that the team morale increased and it increased a lot. In the Scrum era, we used to start each sprint with lots of meetings, usually a day and a half were dedicated for planning the activities in the sprint and only after all these the work used to start. Less time in meetings, discussing, the happier we became!We feel no pressure now on completing a certain task in a given amount of time, being ready to be delivered at the end of the sprint. Also, reduced the frustration of carrying incomplete work from a sprint to the next one and reduced the amount of stress we used to have before the sprint review.

As a conclusion — Kanban works well for our team. It might be good for us, but it might not be right for everyone in every situation. As I like to say, it is context dependant. As circumspect as we were when we got in front of the decision of transitioning from Scrum to Kanban, as happy we are now, with a good productivity and less overhead.

Photo by Bram Naus on Unsplash.