Why The Kanban Flow Review Makes The Perfect Retrospective

Metrics tell a powerful story and indicate critical areas for improvement.

If you work on a Kanban team and conduct regular Flow Reviews, you may discover the valuable interplay between how metric analysis leads to beneficial retrospective outcomes.

What Is A Flow Review?

First, let me start by saying the Flow Review is not an official designated cadence endorse by Kanban University or the latest Kanban Maturity Model. However, on the lower end of the maturity scale, the action can be described as a “practice,” what the Maturity Level 0–2 refers to as:

regular activities, observable patterns of interactions, measures and metrics, decision frameworks, and routines, habits, or rituals. Practices are “how we do things around here.

At this moment in time, the team I work with conducts a bi-weekly Flow Review of our Kanban metrics to collaboratively discuss and perform root cause analysis of our product features and user story outliers. We want to know why specific work packages take longer than others and investigate the deeper reasons why blockers become present in our Kanban system.

The analysis conducted in our bi-weekly Flow Review creates immediate actions to course correct and instill positive change. And this process is a powerful example of a type of retrospective driven by metrics.

Three Retrospective Improvements

Let’s examine how a recent Flow Review revealed three retrospective improvement opportunities.

1. Projects Are Not Product Features

Features are distinct pieces of functionality with a definitive beginning and end. Examples of specific scope are:

• The ability to add a user.
• Cancel an order.
• Stop payment processing.

Features are not never-ending catch-all’s. Therefore when a feature is created based on a phase of a project, the entire concept is no longer being used as intended. Herein lies the problem of potential scope creep and the prolonged life of a feature within the Kanban system.

During the Flow Review, the team noticed one feature had a life span of 97 days from when the work entered into the system to production release. We noted how the feature was an outlier amongst our other work and realized our mistake in creating the work based on the project's first phase.

Our major takeaway is to immediately stop creating features based on projects and focus on establishing the practice of feature mapping at the onset of any initiative.

2. A Feature Is A Feature Is A Feature

Historically the team used to create minor features based on small client requests that in theory should take a week or two to release and can be picked up on the fly when there are gaps in the workflow. These little features are called JDI’s (Just Do It’s).

Over time the concept bastardized, and any feature that is a month or less worth of work also became known as a JDI, possessing their own roadmap separate from the other client-approved work.

Since November 1, 2020, our data shows 22 completed features, regardless of size, with an average system lead time of 43 days.

A few challenges present themselves with the JDI scenario followed by corrective action:

• Features segregate by size in two separate roadmaps. All work, regardless of size, must be reviewed and prioritized holistically.
• The company permits one release per month; therefore, there will never be a scenario where a feature has a life span of fewer than 30 days old. Our average system lead time of 43 days is, in fact, a decent metric.
• Team focus must be placed on ensuring all features are created as discrete pieces of functionality, and by default, will be contained.

Our central takeaway is to migrate away from the use of segregated JDI’s and prioritize work in one holistic roadmap.

3. Unaccounted Post Production Bugs

During the Kanban Flow Review, the team noticed an interesting data point — since November 1, 2020, only one post-production bug has been logged in JIRA. Either we are the best team on the planet, or something more mysterious happens behind the scenes.

The data point enabled the team to have a healthy discussion allowing us to unearth the root cause of our challenge. We determined that post-production bugs are being logged separately in another application called Service Now and are not tracked in JIRA. A few issues present themselves with this scenario:

• Post-production bug work is being conducted outside the Kanban workflow and is not transparent to the overall team.
• Unclear how much time it takes for post-production bugs to enter and flow through the Kanban system.
• How are post-production bugs impacting prioritized work? We have no clear answer.

Our team concluded that the best way to mitigate the missing data issue is to create a post-production bug in JIRA, citing the Service Now (SN) identification number in the JIRA issue type subject heading line, including the SN link in the description for transparency. While not ideal, we will track the bug instance in two locations as opposed to isolating work.

To Conclude

The Kanban Flow review, while not a recognized official Kanban ceremony, adds massive value to our team as a type of retrospective. Here, we openly discuss our data and look for outliers identifying behaviors to course correct them.

All data tells a story. Sometimes the drama unfolds by describing what is present in the system, such as the example of a feature whose life cycle lasted 96 days. And sometimes, the tragedy is told by reading between the lines of what is not overtly present, as in the example of only having one post-production bug.

While I do not advocate removing the standard Retrospective from your Kanban cadence, I believe data analysis pinpoints essential truths one cannot ignore.

The original story was published on Medium 06-01-2021

Lisa Bradburn is transitioning into an Agile Coach and is a Gestalt Psychotherapist-In-Training. She writes about the intersection of technology and the human condition. Follow Lisa on Medium.