We took the opportunity to ask Bryan Finster, Value Stream Architect for an enterprise DevOps Dojo and member of the Dojo Consortium some questions on Value Stream Management.

What is a Value Stream?

A value stream includes all of the activities necessary to bring a product or service from conception to market, including research and development, manufacturing, marketing, and customer service.  I have a diagram I use to explain what continuous delivery means to me. It starts with an idea cloud, shows all of the key steps to deliver to the end user, and shows the feedback loop from the end user to inform the idea cloud. To me, that’s a software value stream. Value stream mapping is a tool used to visualize this process so that improvements can be made to shrink that loop. 

What are the key metrics for a Value Stream Architect?

For a VSA, the metrics are focused on waste in the system. Removing waste improves the ability to deliver value. Gary Gruver’s ‘Engineering the Digital Transformation’ is an excellent primer on this. Then it’s just a matter of generating valuable ideas. 

Also, the delivery outcomes: how frequently and successfully we are delivering, how long it takes to deliver a change and how long it takes to fix an incident.

Who’s accountable for gathering, inspecting and implementing these metrics in the team and when?

Automating observability is key and those metrics should not be gathered as an activity but should be continually tracked and kept visible. It should be baked into the delivery platform and used as the basis for every improvement experiment.

What does the Value Stream Architect role encompass? What are the goals?

Some background: there’s always been a need in organizations that wanted to deliver better for someone to help teams identify issues and optimize flows. The wrong way is to dictate practice. The right way is to engineer for reduced waste and improved flow across as much of the value stream as possible. Aimee Bechtle, then at CapitalOne, coined the role of ‘Delivery Systems Engineer’ as someone who engineers the entire system of delivery, not just build/deploy automation; a hands-on technical role for someone who understands CALMS, knows how to execute CI/CD (the processes, not the tools), and has the skills to identify the key constraints and the people skills to help everyone aligned to that value stream improve those constraints. 

Mik Kersten from TaskTop wrote a blog post introducing the role as ‘Value Stream Architect’ and Dominica DeGrandis presented it and other roles as emergent roles in the market during DevOps Enterprise Summit 2019.

What is the difference between a Value Stream Manager (VSM) and a Value Stream Architect (VSA)?

In my opinion, they are complementary roles with different focuses. Where the VSM is strategic, the VSA is much closer to the teams and the code. A VSA is:

• Helping leadership organize teams around communication lines and application architecture for speed of delivery
• Helping teams identify and clear team-level delivery constraints
• Informing the delivery platform on needed platform improvements
• Helping areas create secure, compliant, safe, and fast delivery automation while helping teams learn how to use that automation more effectively

How does a VSA help a team start thinking like a value stream?

It’s product focus. “Do we know what value we are delivering?” “How can we make it easier and safer to deliver that?” It’s important that teams see the impact of their work, good or bad. Teams want to deliver good things. Only in toxic environments do teams just not care. When teams see the value of their work, they want to make it better. So, by helping the teams overcome the hurdles to CD, they see the impact more frequently and see that they have the power to improve those outcomes quickly. Once they get over the hump, they will run.

How might a team automate metrics collection?

There are some open source tools available. CapitalOne’s Hygieia has been around for a while. Some of the CD platforms have some of the key metrics baked in but lack visibility to others. So far, Hygieia is the one I’ve seen that glues things together the best from multiple sources. When I was in an area that piloted CD, we used Grafana and instrumented our pipelines and production to keep those metrics visible. This is still something that needs improving in the industry. Much of the metrics tooling I’ve seen focuses on “developer productivity” and ignores that developers are only a part of the process and that developers pushing features faster doesn’t improve outcomes.

What’s a Dojo?

In general, a real Dojo will focus on immersive, hands-on learning to improve some aspects of the value stream for a team. Staffed with process and technical coaches, Dojos should use the team’s daily work to show them how to improve the flow of delivery. Dojos are not prescriptive. Instead, they should meet teams where they are, understand their context, and use a metrics-based approach and rapid Kaizen cycles to improve those metrics. Dojos should not be telling teams what to do. Dojos should be helping teams find better ways to deliver by using ever-shrinking cycle times to expose and remove waste. Dojos are intense. It’s quite common for Dojos to run 12 iterations in 6 weeks. They should also be fun because happy teams deliver value better.

How does a VSA operate within a dojo?

The downside of Dojos is that they do not scale. If you have a large enterprise, only a subset of teams could go through a Dojo process in any reasonable amount of time. This is where I see Value Stream Architects playing a pivotal role; federating the improvement using the same metrics-based approaches, but not the intensive process. VSA’s should help teams that cannot get into the Dojo and help teams that have been in a Dojo focus on continuing the improvement journey.

Does the (DevOps) market need more VSAs and, if so, how should we go about doing this?

We definitely need more. It’s hard to find people who understand more than a segment of the elephant. It’s also hard to find people who are flexible enough to not be prescriptive about how to solve a particular delivery process, but who can really apply principles to find the correct processes for a particular architecture, test maturity, and team structure to improve a delivery system. It takes experienced developers who like to help people. It’s not theoretical nonsense, but practical information on the step by step processes for analyzing and architecting better delivery.    

If someone wants to be a VSA, what are the steps that they should take to do this?

There are no shortcuts. You need to KNOW how to execute CD in multiple contexts and how to help other teams do it when you have no power to force them. Being a good pragmatic technical leader, not a dictator, is a great start. Then understanding how to look at the entire value stream as a system and how to find and improve the constraints of the system. It’s like any other senior engineering role.

What, if anything, can the existence of VSAs in an organization tell us about DevOps capability/fluency and organizational performance? 

To me, it says they actually want to improve performance because, just like in manufacturing, they have invested in process engineers focused on doing that. If we aren’t improving, we are losing to those who are.