post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Based in London, I'm an Agile Coach with many years' experience of Scrum and Kanban development. I've worked in a variety of companies, some large and some small. My focus has always been on helping software development teams to deliver value to customers as fast as possible.

Susan Trapp

<h3>Introduction</h3>
<p>Last year, our team here at insightsoftware.com, makers of <a href="https://gohubble.com/">Hubble</a>, moved from Scrum to a Kanban software development approach. In my last <a href="https://www.mindtheproduct.com/transitioning-scrum-kanban/">Mind the Product article</a>, 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.</p>
<h3>Looking Back to 2017</h3>
<p>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.</p>
<p><img loading="lazy" decoding="async" class=" wp-image-12834 aligncenter" src="//wp-content/uploads/2018/02/ST-at-awayday3.jpg" alt="" width="435" height="435" srcset="/wp-content/uploads/2018/02/ST-at-awayday3.jpg 200w, /wp-content/uploads/2018/02/ST-at-awayday3-150x150.jpg 150w" sizes="(max-width: 435px) 100vw, 435px" /></p>
<p>&nbsp;</p>
<p>With our goal in mind, our priorities at the beginning of 2017 were:</p>
<ul>
<li>To have several cross-functional teams working on the same backlog of work, picking up the next most valuable items from the backlog.</li>
<li>To reduce the amount of time spent in regression testing.</li>
<li>To have occasional feature-planning sessions when the teams run out of work.</li>
</ul>
<h3>Where we are in 2018</h3>
<h4>Successes</h4>
<p>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.</p>
<ul>
<li><strong>Multiple team, one backlog.</strong> 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!</li>
<li><strong>Focused planning meetings.</strong> 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.</li>
<li><strong>Technical debt backlog.</strong> 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. (<em>Kanban Core Practice 1: “Visualize”</em>, <em>Mike Woods, Kanban from the Inside, Part I introduction</em>).</li>
</ul>
<p><img loading="lazy" decoding="async" class=" wp-image-12807 aligncenter" src="//wp-content/uploads/2018/03/kanban-2-300x200.jpg" alt="" width="593" height="395" srcset="/wp-content/uploads/2018/03/kanban-2-300x200.jpg 300w, /wp-content/uploads/2018/03/kanban-2-768x512.jpg 768w, /wp-content/uploads/2018/03/kanban-2-1024x683.jpg 1024w, /wp-content/uploads/2018/03/kanban-2.jpg 2048w" sizes="(max-width: 593px) 100vw, 593px" /></p>
<h4>Adaptations</h4>
<p>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 (<em>Kanban Foundational Principle 1: “Start with what you do now”</em>, <em>Mike Woods, Kanban from the Inside, Part I introduction</em>).</p>
<ul>
<li><strong>One team is doing “Scrumban”.</strong> 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.</li>
<li><strong>Team-based automation testing.</strong> 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.</li>
<li><strong>Detailed release planning.</strong> 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.</li>
</ul>
<h3>Next Steps</h3>
<p>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!</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

What We’ve Learned From Using Kanban

Susan Trapp

Comments

Read next