What We’ve Learned From Using Kanban [Mind the Product]

Introduction

Last year, our team here at insightsoftware.com, makers of Hubble, moved from Scrum to a Kanban software development approach. In my last Mind the Product article, I shared my insights on our transition as we were right in the thick of it. In this follow-up post, I want to share some more developed thoughts and findings from myself and our development team.

Looking Back to 2017

Being able to develop continuously but release periodically has always been the goal of our team. Like most development teams, we know how challenging this goal can be. Prior to moving to Kanban, we made a list of priorities that we wanted to focus on over the course of the year. Each of these priorities supports our main goal.

With our goal in mind, our priorities at the beginning of 2017 were:

• To have several cross-functional teams working on the same backlog of work, picking up the next most valuable items from the backlog.
• To reduce the amount of time spent in regression testing.
• To have occasional feature-planning sessions when the teams run out of work.

Where we are in 2018

Successes

Generally Kanban is helping us to manage our workflow, it’s particularly helpful with combining work from many sources into a work stream scaled across many teams.

• Multiple team, one backlog. We have four product teams working on the same backlog of work, including fixing defects and high priority items as they come through. One product manager handles the backlog and sets priorities. The Scrum Masters help allocate the work between teams based on team availability. All teams are considered equal!
• Focused planning meetings. We only run planning meetings when a new feature is ready to be introduced. This could be once a month or more frequently if a new urgent feature is identified. Otherwise the teams work off the shared backlog picking up the top priority items.
• Technical debt backlog. Over the last year, we’ve built up a long list of technical debt – fixes to the framework that will save time, but don’t deliver obvious business value. We’ve agreed that the teams will spend 10% of their time working on these issues and to make this visible we’ve created a new workstream on our Kanban board, so we can see if it’s empty. (Kanban Core Practice 1: “Visualize”, Mike Woods, Kanban from the Inside, Part I introduction).

Adaptations

While sticking to the Kanban principles, we have had to make some adaptations. The beauty of this approach is that it is really easy to do this incrementally (Kanban Foundational Principle 1: “Start with what you do now”, Mike Woods, Kanban from the Inside, Part I introduction).

• One team is doing “Scrumban”. One team has been working on a new product, which has required an amount of research and investigation to define the stories. They have found it easier to reintroduce working in Sprints so they can set a tighter scope for a Sprint, rather than working off a never-ending and variable backlog.
• Team-based automation testing. We used to have a separate team responsible for writing automation tests. Although this allowed the specialist automation testers to share the work from all teams, it prevented our product teams from being fully cross-functional. Stories were not really done when the teams had finished with them, so we found bugs during the writing and running of automation tests. This has frequently extended our pre-release regression tests. We’ve now redistributed that team across the product teams, so each can own the delivery of the fully tested story.
• Detailed release planning. Our business colleagues find it hard to sell new features when they don’t know when they’ll be delivered. Last year we were releasing every two or three weeks in order build up the quality and stability of the product, but could never predict which release a new feature would appear in. Now we’re preparing a quarterly release schedule which includes a major release with all the new and exciting stuff and more frequent minor releases to sweep up the bug fixes.

Next Steps

Our teams will need lots of support with the transition to the new structures. We’d like to spread the automation testing skills, so anyone can pick it up, although this may meet some resistance as some team members would prefer to stick to their core skills. We’ll keep a close eye on our ability to meet our delivery plans. I want to show the commercial team that Kanban works, but we need to deliver the goods consistently before we can win them over. In summary, we’ve learned a lot, have found success and can see the potential in continuing with Kanban as it is helping us reach our end goal. I look forward to sharing more updates around specific product releases as time goes on and welcome any comments or questions!

The post What We’ve Learned From Using Kanban appeared first on Mind the Product.

Source: Mind the Product https://www.mindtheproduct.com/2018/02/weve-learned-using-kanban/