Case Study: In the Pocket

The theory and principles of Kanban are one thing. Applying it in an actual software development context, with real-life challenges and difficulties, is something completely different. Especially in large projects, finding the precise levers to pull can be a daunting task. And that was exactly the case for In The Pocket, a European Digital Product Studio, when they undertook the challenge of crafting a cloud platform for one of their bigger clients.

Growing Complexity

As the project grew over the years, so did the complexity of the challenge and the context surrounding it. To effectively manage this growing complexity, the team adopted an implementation of Scrum. However, as development progressed, they found themselves struggling with unexpected changes and unknown unknowns. It felt like a constant rush from one task to another, relentlessly pushing their boundaries. Not exactly the most healthy way of working.

The root cause of all of this? Many assumptions were made, such as "there isn't enough time for the product manager to better refine tickets," "the solution architects' refinement isn't sufficient," and "there's no room to improve technical debt due to focusing on new features." As it often goes, the process from identifying the problem to finding a solution was messy. There's no silver bullet solution that works for every team, as every context is unique and, more importantly, unpredictable.

Visualising the Workflow

After a few months, the team started realising that they had a strong view of their operational activities but lacked a clear perspective on a higher, more strategic level. Consequently, they started visualising all overarching epics using Miro. This platform afforded them the flexibility to experiment with what they wanted to visualise and what worked best for them.

By representing all ongoing work visually, the team spotted that they were working on five different features at the same time. To regain better control over their workflow, they made the decision to restrict the WIP for features to a maximum of two.

Operating the Workflow

Thanks to the transparent relationship with the client, they agreed on our proposed changes - knowing that the impact wouldn't show immediately. But eventually, after 4 months, the team truly began to see the positive impact of the changes we made.

The team consists of 14 people. To avoid dependencies, they decided to not split the team into subteams, but rather keep working as one big team on one big backlog. The features that were selected to be worked on were assigned to a ‘feature lead’, often one of the more senior engineers. Those feature leads are responsible for fleshing out what needs to happen, assembling the necessary people, and pulling the feature through the value flow.

Improving the Workflow

To ensure the team had accurate insights into how they were doing, they began utilising flow metrics such as cycle time, throughput, and work item age to track their progress. Four months later, the positive results of closely monitoring these flow metrics and adjusting our strategies based on the data insights became evident. By closely monitoring work item age and limiting WIP at both the story and feature levels, cycle time and throughput naturally improved. Moreover, also the pressure on the team declined and the spirit within the team drastically improved. Finally, to make sure we keep a balance between short-term focus and long-term plans, we reintroduced our sprints.

The Data Tells the Story

The beauty of using historical data is that, as you can see in the images below, trends are visible and you can really see the changes having an impact. The red area tells us about a high WIP with a lot of outliers in cycle time. Our WIP was consistently increasing during the first half of the data shown below. The Daily WIP shown in the second chart shows that our WIP increased steadily till the end of 2022. 

The result of this change is visible in the Cycle Time Scatterplot where we have multiple outliers over 40 days. One even takes as long as 78 days. As we got our WIP under control, the outliers started to disappear.  The second half of the graph (starting midway through the orange area) does not have a single item that took more than 40 days. We became a lot more consistent in our cycle times for individual epics. By limiting WIP and focusing on fewer epics at the same time, we got the team through the orange area towards the green area with lower WIP, fewer outliers in cycle time, and better controllable circumstances.

As we described above, our client understood the way we wanted to work and, even to this day, the team uses flow metrics in steering comités with them. We offer the client insights into the team's performance and potential course adjustments. Most important was the direct applicability of these metrics, without the need for a full understanding of the underlying theory. While theory is important, it is so much more important to have the right tools under your belt for the context you are working in. Our team, with all of its experts, just do their thing. We visualise their work and the data speaks for itself without having too many extensive rules or processes to stay in control. That is how we like it!  

Author - Thijs Morlion