Are We Really Moving Faster 2021 Update

Roman Pickl speaking at a conference

Roman Pickl

January 15, 2022

This is a short and final update to Are we really moving faster? How visualizing flow changed the way we work.

As described in the last blog post, we were in the middle of the analysis and able to soften the pain, but there is still an important question to answer: Are we really moving faster?

We found that we had limited system focus and needed buy-in to influence the processes up- and downstream. That’s why we engaged in a detailed Value Stream Mapping exercise.

Insights from Value Stream Mapping

In the last blog post I described two of my epiphanies:

  1. We were creating too much inventory
  2. We will never be able to run fast enough

Our Value Stream Mapping exercise really let to another one:

We need to change the way we work

The biggest benefit of documenting the current state as well as thinking about the future state and identifying the improvements necessary to achieve it, was visibility. I have the feeling that, while most of the problems were already known and in our heads, it really helped to visualize and discuss them with a larger audience.

It was obvious that we could not do all the necessary changes ourselves. Dr. John Kotter’s 8-Step Process for Leading Change was really helpful to guide our thinking.

  1. Create a sense of urgency
  2. Build a guiding coalition
  3. Form a strategic vision and initiatives
  4. Enlist a volunteer army
  5. Enable action by removing barriers
  6. Generate short-term wins
  7. Sustain acceleration
  8. Institute change

As part of the Transformation Program we already had established a sense of urgency. We had a guiding coalition and a strategic vision and related initiatives. It was time to enlist a volunteer army.

Socializing the Value Stream Maps

Karen Martin and Mike Osterling note in their book Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation, that creating maps but not taking action is a common failing with Value Stream Maps. According to them, the best way to socialize the map is not distributing a digital version of it or posting on a wall, but rather talking about and discussing it. This is not only necessary to reduce resistance to change, but also a powerful learning opportunity for everyone involved as it helps to instill holistic thinking.

Following this advice, we came up with the following idea to socialize the value stream maps in the teams:

The two scales used for implementation effort (don't know / five point scale from low to high) and anticipated benefit (don't know / five point scale from low to high)

Survey item scale

The feedback from these rounds was very helpful and positive. Making the pain points visible also helped to channel some of the energy which came from these frustrations to change something and “enlist a volunteer army”.

Alignment with PACE Priorization

With the help of the benefit and effort assessments we created a PACE (P​riority, ​A​ction, ​C​onsider, ​E​liminate) matrix. Using the findings from the value stream analysis as the one-list to rule them all allowed us to pull in the same direction and as this was done as part of the the transformation it “enabled action by removing barriers” as it also had management support.

A two dimensional matrix putting every potential improvement on the scales implementation effort (high / low) and anticipated benefit (low / high)

PACE matrix


What we already knew is that having two to three major releases each year and providing monthly patches did not provide the quick feedback necessary from the market. This also showed in the numbers, when we looked at Flow Time of the items that were released in the last 6 month before February.

Histogram of the Flow Time

Flow Time of items released in the 6 month before February in days

We actually see our deployment schedule here, with a fastlane for patches (fixes) and another peak for our two to three releases per year

Thanks to our further improvements we were able to move towards monthly release cadence starting from March and create the release branch at the latest possible date from master, just in time for the release (as proposed by trunk based development)

When we did the same analysis of the flow time in June (again for the previous 6 month)

Histogram of the Flow Time

Flow Time of items released in the 6 month before June in days

We now see that there is a peak around the 30 day bucket; Note that we also got rid of the Task category and moved them to a different one

Note that these charts also show that it is not a good idea to look at averages alone. While using medians might improve the situation, Jonathan Smart argues in his book Safer Sooner Happier that lead time typically follows a Weibull distribution, which resembles a normal distribution with a long tail and skewed to the left. He recommends using the 85th percentile and its change over time as a measure. While my nerd brain loves that, I think it is quite hard to explain to everyone involved.

We were now able to answer the fundamental question that I raised a year earlier: Are we really moving faster, to get faster feedback, learn quicker, reduce risk, monetize earlier and maximize outcomes?

Yes, we finally are!

Further references and information

If you want to know more, you should really read these books, follow these links or watch the talks of the authors:

Summary and Outlook

During the last two years I had three epiphanies at my job:

These made us move faster.

The hardest thing though might still be outstanding. It is the final step in Dr. John Kotter’s 8-Step Process for Leading Change : “Institute change”. We did some really great progress last year though with doing book clubs and discussing Project to Product from Mik Kersten and the The Unicorn Project from Gene Kim.

If you have any questions, recommendations, hints, or just want to say thanks, feel free to contact me. You can reach me on twitter @rompic or via mail at

Thanks for reading this article.