First, understand your value stream

My past six years of consulting for and working with product teams have taught me a lot.

Start with the end in mind, fail fast, fail safe, iterate, what problem are you solving? do you have product-market fit?

These are the things we often hear and take away when building a product.

Despite all this great advice, I think Carl Sagan has put it best…

If you wish to make an apple pie from scratch, you must first invent the universe.

As technologists we often jump to the fun, exciting tools that everyone is chatting about.

Yeah, we’ve containerized our microservices, scheduling them with K8s and using Consul for discovery but now we’re looking to go totally serverless with Lambda.

These are the whipped topping or ice cream that goes with your pie as you’re eating it. But you will never get to ship great software unless you first, understand and master your value stream.

The tendency to jump to the fun stuff is especially apparent at scale. Imagine a scenario where Product Owners, UI/UX Designers, Architects, Developers, Testers, SREs, Managers and Leads, all working across 2-15 different products that share the same priority (#1). Each individual group I just mentioned plays a critical role in shipping good software. But when there is too much work in process, each group will tend to self-optimize with the latest and greatest tools, expecting it to increase velocity and quality. It may be obvious when objectively reading this to say it comes as no surprise that this expectation falls flat. But time and time again when building products at scale the habits of optimizing individual silos prevails.

The theory of constraints will tell you that optimizing anywhere in the system other than the constraint will potentially cause system wide degradation.

Logically, this makes perfect sense. If your product owner has the tools to fire off amazingly perfect user stories at an unbelievable rate, but your development team is blocked every other day by build issues, the stress applied from a growing product backlog will likely make them move even slower.

There are a set of questions you can ask yourself, or any member of the team, that will help identify the lack of understanding of your value stream.

• Do you understand all the steps involved to take an idea and ship it to the customer? Can you describe each step with some level of detail?
• Do you know the highest level initatives that your Product group has identified to support the overallvision? Do you know how many are being worked on currently and the progress on each?
• Are you made aware of, in a timely manner, of downstream teams being blocked by a need from your team? Are your needs from other teams readily known and addressed in a timely manner?

If you can’t begin to answer these questions, working on implementing the next hot tool is premature. Thinking about these types of questions help guide you on the way to understanding The Three Ways as described by Gene Kim in his novel, The Phoenix Project

Not being able to answer these questions means you fundamentally do not understand your value stream and your place in it or supporting it. Your team of teams is likely not communicating and providing the necessary feedback loops through the value stream.

This leads to:

My development teams can’t deliver fast enough. -Product Owner

We don’t have clear enough requirements and my ops team struggles to deploy my flawless code -Developer

Oh yeah… that’s expected behavior -Test Engineer

This s^&t doesn’t even build -Ops Engineer

I am overloaded with customer tickets because we ship broken features -Support Engineer

Where to from here?

Stop thinking about the latest and greatest tool or method that you read about on HN. Do not try to force your team to be exactly like the other teams you read about. Understand what your value stream is. What are the work centers from idea to impact on your customer? How do you measure the velocity and quality of those work centers? (Hint: lead time, %C/A) How can you gain awareness of blockers quickly and enable teams to swarm issues?

If you can focus on visualizing the work you have to do in support of your vision, and where each piece of work is in the system, you are on your way to mastering flow. The next step is amplifying feedback that ultimately will create a culture of learning. These should all be thought of first, or at least at the same time as your teams explore sexy tooling and progressive development methods. Otherwise, you’ll be destined to wonder why all your spend on buzzwords isn’t returning any value.