Choosing Scrum over Kanban – Why we Switched

As we set out on the Agile journey, picking Kanban seemed like a no-brainer. It is visual, easy to use, and a perfect fit for the PM tool we have been developing. However, after a short few months, we realized Scrum was indeed a better fit and switched.

Here is our story, hopefully, it will give you some insights.

Why did we choose Kanban?

As a small engineering team with a new product (we develop a project management tool called Teamhood) we had no strict timeliness or process to follow. Thus, Kanban seemed like a perfect fit. It allowed us to visualize what is happening, prioritize the most important items and track their progress.

The team would meet for a daily standup to discuss progress and monthly retrospectives would be held to see what could be improved. All of this was great up until the product beta went live and the focus of the engineering team had to shift.

Advertisement
[widget id=”custom_html-68″]

Why did it not work?

With the launch of our beta version, we got the first paying customers. Yay! But with that came customer expectation management and a need to provide reliable forecasts for the new features.

With the engineering team working in Kanban, the sales and marketing teams had issues in knowing when to expect new features. In result of that, they were not able to plan timely marketing and sales actions to promote the new features that were coming out.

Moreover, the clients needed to know when specific features would be live, and the engineering team was not able to provide those answers. As such, we knew it was time to change.

How Scrum improved our process

Thus, instead of Kanban, we switched over to Scrum and introduced new practices to improve the process.

First, we have chosen 2-week iterations to ease estimation and feature predictability. Now we had to think about which features can be delivered in two weeks’ time and commit to them. This was especially useful for the sales and marketing teams that were communicating with existing and potential customers.

We have also divided the work into several boards to better separate different processes. Design, Roadmap planning, Backlog, UI/UK, and Development are all done on different boards, thus better categorizing all of the work items.

We have introduced various new ceremonies to make sure all the processes are under control. Roadmap planning and prioritizations, Backlog review, Backlog planning, Backlog refinement, Backlog planning, and others were added to make sure we are delivering value to our customers and working on the most important features.

Lastly, we have started using T-shirt sizes to estimate the features. This helps us ensure each feature we commit to can be delivered during one iteration. Otherwise, we rework the feature to make sure it can fit the iteration or push it back to the drawing board.

What’s next?

We have successfully moved away from Kanban and into Scrum territory. However, this Scrum application is far from the textbook. In fact, some could argue that it is far more resembling Scrumban. I don’t disagree.

Will we move towards full Scrum in the future? No one knows. However, we will not do it just for the name. Instead of applying any of the practices blindly, we tend to look and see what works best for the process and our needs now.

Have you changed Agile practices with your team? I would love to hear your comments.