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 realised 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 developed 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 visualise what was happening, prioritise the most necessary 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 until the product beta went live, and the engineering team’s focus had to shift. 

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. As a result, they could not plan timely marketing and sales actions to promote the new features coming out.  

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

How Scrum improved our process 

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

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

Also Read: How can you build a living, thriving community around your SaaS product?

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 categorising all work items.

We have introduced various new ceremonies to ensure all the processes are under control. Roadmap planning and prioritisations, backlog review, backlog planning, backlog refinement, backlog planning, and others were added to ensure we deliver value to our customers and work 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, the Scrum application is far from the textbook. 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 practises 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. 

–

Editor’s note: e27 aims to foster thought leadership by publishing views from the community. Share your opinion by submitting an article, video, podcast, or infographic

Join our e27 Telegram group, FB community, or like the e27 Facebook page

Image Credit: nicoelnino

The post Going from Kanban to Scrum: Why we chose this path? appeared first on e27.

content first appear on e27