skip to main content

Blog | About me

Three notes on Value Streams

These are some scattered notes from a DevOps Toronto meetup earlier this year. These are highlights from a presentation by Steve Pereira on value stream mapping. I’ve been finding making value streams explicit, whether formal or not, a key part of my role evolving from testing to DevOps more generally. One of the basic strategic things that I think testers can do is make explicit what each step of the process to getting an idea out to production actually is, why it is there, what differentiates it from other steps, and what value it adds to the process.

1. On structuring value streams

At a granular level, when laying out a stream from Step 1 to Step 2 to Step 3, take note of how long each step takes and how long of a gap is between steps. Both a long step and a long wait time are opportunities for streamlining.

When one step fails, what step do you have to go back to, and what’s the likelihood of that happening? It might be that you’re repeating a costly step more often than you need to be.

At a higher level, value streams should be like Google Maps; You should be able to look at continents, but also to zoom down into countries, cities, and neighbourhoods. In my work right now I’m focusing on the steps to get a commit into production through the CI/CD pipeline, but that’s only one piece of a broader picture. The product owner might zoom out and look at the steps to take an idea to a ticket, to production, to user adoption. Good testers know that testing activities happen throughout the software lifecycle, but we might focus in on one broad step to improve whatever internal steps are going on—the release process one week, the grooming and design of tickets the next. Those are all just different views of one value stream.

2. On hard measurements

Unless something is your primary bottleneck, being precise isn’t important. Given two steps that take 20 hours and 1 hour, it doesn’t really matter if they’re actually 18 hours and 2 hours, or 23 hours and 40 minutes. As long as you’re not off by orders of magnitude, it’s still clear which one of those two steps you should focus on improving.

Beware of volatility, though. Let’s say two steps take the same amount of time on average, but one varies wildly and one is always reliably the same time. All else being equal, you are likely better off stabilizing the volatile step before trying to optimize either of them. If it’s a consistent bottleneck, even if it’s painful, at least you know what you’re getting. It’s worth highlighting those volatile steps in the value stream as such.

3. On what value means

As testers we know that quality can be defined as value for some person, but it can be useful to use that to think of different kinds of value: value for customers, value for the business, and value for employees. I don’t think these are independent, but for different activities one will be more front of mind. When I improve developer experience, that’s adding value for employees directly, but indirectly makes the business more productive.

When you boil it all down, though, I still think it all comes down to customer value. It was possibly off the cuff, but in one comment Steve said he recognizes something isn’t of value if “your customers aren’t going to pay you more to do more of it.”

The goal here is optimizing away those pieces of the value stream that aren’t adding as much value. This usually means optimizing the pieces that don’t need to be creative, so that we have more time to be creative. This should be familiar to testers. After all, we automate tests not to make testers unnecessary, but to give testers more time to do the kinds of testing that can’t be automated. This kind of thinking can also highlight where some testing steps don’t actually add anything new, maybe because they’re repeated needlessly or because the same thing is tested elsewhere. This is why I think it’s so important for testers who work mainly in the UI space to still be aware of what unit tests are being written. To be most effective, we need to consider intentionally where each test should live among many possible levels.

So, what steps are in your value stream and where are you adding value as a tester?

About this article

Leave a Reply