post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Creating metrics that matter

A case study: Launching a product process in a project-based company

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! 🎉

How much are product managers getting paid in 2024?

Leading product ops at Delivery Hero with Koen Dubelaar

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

“You’re not as competent as you think” 5 lessons from Ken Chin on navigating a product career (CPO, Spark Networks)

Everything wrong with the product management job market. And how to fix it

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

We here at insightsoftware.com, creators of <a href="https://gohubble.com/">Hubble</a>, have recently moved from a Scrum to a Kanban software development approach. The driver behind the move was to improve the speed of business delivery and quality of the delivered product. The process seemed to go smoothly, even though the teams are distributed and have varying skill levels. In this short initial retrospective on the transition, I look at some of the factors that have helped and the potential for further improvements.
<h2>Starting Point</h2>
Our teams were already experienced in Agile development and were working in two week sprints, with a regression test and proposed release at the end of each sprint, but the business stakeholders were still concerned about the speed of delivery. They saw a development team working hard, but not delivering the features and quality improvements needed by our customers. 80% of our proposed releases did not make it to customers, because they contained unacceptable defects. We decided to move to a Kanban approach, so that we could focus on improving the flow (Kanban Core Practice 3: “Manage Flow”, Mike Burrows, Kanban from the Inside, Part I introduction), making it easier to identify and resolve the unacceptable defects quickly and not hold up the releases. We also took the opportunity to move from TFS to Jira as our lifecycle management tool.
<h2>Goals</h2>
We have several cross functional teams working on the same backlog of work, but they have different areas of expertise. Ultimately, we’d like them all to pick up the next most valuable items from the backlog, but this will require some skills transfer. We’d like to reduce the amount of time spent in regression testing, but we’ll also need more of our testing automated. We’d also like to have feature planning sessions when the teams run out of work but, for now, managing the bug backlog means that we have to discuss and adjust priorities more frequently. These are our longer-term goals, but the steps we’ve put in place mean we are heading in that direction already.
<figure style="width: 1200px" class="wp-caption alignnone"><img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2017/06/433c6896-b1da-4908-9902-1eb505002d99_kv4eAzUPPDGUUpSrKPtEFRYQqoZ1TasNOwGCb1zhvNHrt-WnqSlex5DNmxJS7THWbz7sLdoUuDnKLNcMiypIZ1x2GrQs2048.jpg" alt="Kanban Training" width="1200" height="1600" /><figcaption class="wp-caption-text">A team going through training on Kanban principles</figcaption></figure>
<h2>Approach</h2>
Several key decisions have made our path to Kanban quite smooth:
<ul>
<li>Commitment from the top of the organisation. The move from Scrum to Kanban is supported right up and across the organisation. The business stakeholders are patient and supportive.</li>
<li>All teams trained on Kanban. Everyone was professionally trained over a period of a few weeks, so we all had the same message and understanding.</li>
<li>Used one team as guinea pig. We experimented with our first Kanban board by moving one self-contained team. Then used what we had learned to smooth the process for the remaining teams who all shared the same backlog.</li>
<li>All 4 teams moved within 5 weeks. After the first team migrated, we moved one team a week so all four were using Kanban. This minimized the period when we had two different systems.</li>
<li>Visible Kanban boards. The teams look at their Kanban boards during their daily stand ups and they are displayed on big screens in the office. (Kanban Core Practice 1: “Visualize”, Mike Burrows, Kanban from the Inside, Part I introduction)</li>
<li>Switch from TFS to Jira. By changing our lifecycle management platform at the same time, we had a clean break and a new workflow designed from scratch. However this was still based on our established flow. (Kanban Foundational Principle 1: “Start with what you do now”, Mike Burrows, Kanban from the Inside, Part I introduction)</li>
<li>Continued to use sprints for planning and releases initially. To smooth the transition from Scrum, we started with two-weekly sprints for planning and reviewing. Although we still have the two-weekly releases, the teams are naturally now working from the backlog and the flow continues.</li>
<li>“Hierarchy of business value” and release blockers. Backlog items are prioritised by business value, so the teams can just take the next item from the top. Key issues that must be fixed in a customer release are identified with a special priority and are picked up by the next free person.</li>
</ul>
<figure style="width: 1600px" class="wp-caption alignnone"><img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2017/06/a0ca2550-0981-4a25-9e09-5fa805581c68_aw-VVo-HiR2QGhzvGqkSu8m-Jjp__8wldaPzRzbXjOBDGK7aO9B_4NfOEpix6HY8hHs2z7A_x-xO7-cza636FatAImIs2048.jpg" alt="Kanban board" width="1600" height="1200" /><figcaption class="wp-caption-text">A newly-minted Kanban board, as a team starts to make the transition away from Scrum.</figcaption></figure>
<h2>Challenges</h2>
The transition has gone well, but there are some challenges. We need to focus more on keeping Kanban board clear – finishing rather than starting items. (Kanban Core Practice 2: “Limit Work-in-Progress”, Mike Burrows, Kanban from the Inside, Part I introduction). This means that developers will often have to pick up testing activities as the Testing queue builds, which requires a change in thinking from “developer” to “team member”.
<figure style="width: 1600px" class="wp-caption alignnone"><img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2017/06/2b189d6b-e0a6-40df-a197-97da8dda89a6_uQGvp0XUpCUaXNPn8W-mKRvbu5PmdpzeVdeUSR3pHDF0X3dCS9NGN2KtK3vbCYmh7iiyX1BDXq373pk0cL0o5vbyeZ4s2048.jpg" alt="Kanban on monitor" width="1600" height="1200" /><figcaption class="wp-caption-text">As teams become more comfortable with Kanban, the boards are formalised and converted into dynamic, digital dashboards.</figcaption></figure>
With emphasis on flow, all team members have the same responsibility to keep things moving (Kanban Foundational Principle 4: “Encourage acts of leadership at all levels in your organisation… “, Mike Burrows, Kanban from the Inside, Part I introduction). Everyone in the team needs to be encouraged to step up and contribute to the success of the team.
Planning a sprint to capacity and then seeing how many story points are delivered makes measuring a team’s velocity straightforward. However, now that the teams are working on items which can be of varying sizes, the velocity will not be reliable until we have been working this way for some months.
I have been involved in transitions of this kind before, but this has been particularly smooth. In six months, I’ll look back again and see how far we have progressed to our ultimate goals.

Transitioning from Scrum to Kanban

Susan Trapp

Read more

Comments