The ultimate Value Stream resource page has just launched! Jump over to valuestream.link to find everything related to clarity, value, and flow you need to level up.

Eric Robertson shared a great presentation a while back on Value Stream Management adoption that I'm just now parsing myself, and I wanted to share my short paraphrase on the 5 main points:

1) The need for value stream thinking (and associated action) is clear, but misalignment hinders progress.

• What are the top techniques to boost alignment?
  • My approach to this is usually to produce a clear, visual resource that ties to a high level goal. Something easy to understand, and easy to agree to. A Value Stream Map is a perfect example!

2) Lacking collaboration continues to be a challenge and a roadblock to more holistic improvement

• What are the key actions to jumpstart collaboration?
  • Leveraging a resource (or a few) like the VSM I mentioned above is a great way to do this. A mapping session gets many people involved and collaborating. There are many other maps we can create as a diverse group as well to get everyone together and on the same page.

3) Very few have adopted Value Stream Management but those that have see a boost to visibility, collaboration, transformation progress and value

• How can we make adoption easier and more available?
  • Starting with mapping really sets the bar low and makes it easy to start and scale from a strong foundation. It takes only a few hours to create a very high quality map that delivers value.

4) Agile and DevOps are boosting Value Stream Management adoption, but without a product-centric work model, progress is hindered

• How can we increase product, customer and value stream thinking simultaneously to build upon Agile and DevOps momentum?
  • This is currently backwards!! So many organizations are trying to shoehorn Agile and DevOps into their environment. We need to start where we are and identify opportunities for new ways of working to address challenges, not the other way around. When you start from a clear problem or constraint, you can leverage whatever strategy fits best, and boost your odds of success!

5) Investment in a Value Stream Management platform improves satisfaction with associated tools

• How can we make it easy to get started with a platform, and how do we capture all the parts of the value stream that aren't visible in tooling?
  • We're not likely to have a perfect tool for Value Stream Management any time soon. The best we can do is leverage what we have (ideally what people are already using!) to improve visibility whether it's mapping, spreadsheets, dashboards or a Jira board. Once you're started and building domain expertise, finding and choosing a better solution will be easier.

I have many ideas about the questions above. I'd love to hear yours and bring them all together!

Perhaps the biggest point I always come back to is that in most cases organizations either have no clear definition of value to begin with, or they don't share that understanding across the organization. If you're going to improve and deliver value together, speaking the same language and aligning your efforts is definitely step 1!

I hope you check it out, it's interesting to note that any survey Eric or I or others in our ecosystem will share largely gets responses from early adopters and those already bought into value stream thinking. I think the broader industry stats would be far behind what we're seeing here, but quickly coming on board.

https://digital.ai/resources/blog/5-reasons-why-organizations-struggle-to-deliver-value-in-devops

You've heard a lot of opinions about 'the most critical' or the 'core' challenge of digital transformation, innovation and agility.

You'll hear a lot more in the coming years.

• Data.
• Automation.
• Culture.
• Security.
• Regulation.
• Code.
• Infrastructure.

They're all wrong.

They're all missing the real factor that drives change. They're missing the most important piece of the puzzle.

This is a system challenge. Your system, and the systems you collide with are always the challenge. Your system is the confluence of all those things and more.

Well, great. What do we do with that?

Shift your focus to process. The ways you do what you do are the levers you can pull. Process is the engine of your system.

What is the flow? Where is the friction?

What are the inputs and outputs? Incentives? Dependencies?

Everything else is a symptom or a byproduct.

Focus on symptoms and byproducts without acknowledging causes and systems is how we fail to build the puzzle. We'll wonder for ages why we can't complete the puzzle.

"Having a strategy suggests an ability to look up from the short term and the trivial to view the long term and the essential, to address causes rather than symptoms, to see woods rather than trees."

— Lawrence Freedman

You can build a better system by designing better processes, and the step to begin is a small one.

When was the last time you took a look at your process? Shouldn't it be something you invest in?

Why do I spend all my time on Value Streams instead of #DevOps in 2020?

I get this question often, especially since I've been closely involved in DevOps since 2011 (and before the term arose).

Don't get me wrong: DevOps isn't done, solved, or finished growing by any means!

The truth is: I have a bad habit of skating to where the puck will be, before the game has even started 😅

• From tech support in my teens
• To agile development
• To release engineering
• To infrastructure automation
• To DevOps
• and now, Value Streams

At each stage, the scope, complexity, and perspective has grown.

That's what I chase.

DevOps covers a broad range of complex, interesting, and valuable facets, and the community is unlike any I've ever found.

DevOps is a fraction of a business, Value Streams are the entire business. Value Streams are a fraction of the conversation, and I want to fix that.

I can't resist. 😬

I'm not leaving DevOps, but I aim to bring it further towards Value Stream thinking.

I want to raise the value, performance, and outcomes of our efforts. The big picture view provided by Value Stream thinking is where I'm putting all my chips.

For the first time in my career, I'm not looking for anything bigger.

Yet. 😅

I had the great privilege of joining a conversation yesterday about Value Stream Flow and wanted to share it here with a quick summary. We talk about Flow, Mapping and Management, as well as what's happening in the industry and coming soon

Some key highlights:

• You can start wherever you are, waiting for DevOps, agile, transformation goals to be complete first is just delaying those goals! Value Stream mapping and improvements make all of it clearer and easier
• Understanding VSM is easier by understanding what it's not:
  • A process is just a series of steps and activities (no measurement involved, no value captured)
  • Process mapping doesn't show you the most valuable next action
  • A value stream consists of several processes, but much more detail and value
  • A CI/CD pipeline is just one automated process inside a value stream
    • Since it's already highly automated, there's little opportunity for improvement compared to elsewhere
    • Your biggest problems and opportunities are probably upstream and downstream from your pipeline
• Flow is easy to understand if you think of a series of pipes. Pushing too much material through too small a pipe will slow it down. In a series of pipes, the tightest, most clogged or leaky ones are the problem. You have to find where the pipes are constrained in order to improve flow. You can:
  • widen pipes (eliminate constraints)
  • unclog them (remove blocks/approvals/delays)
  • fix leaks (distractions, handoffs, waste) in order to improve flow
  • among many other tactics!
• Value Stream Mapping is a periodic activity (once per quarter) and Value Stream Management is continuous. You always need both.
  • Mapping to quickly illustrate what's happening, share visibility, highlight quick wins and define a future strategy
  • Management to ensure progress towards goals
  • Mapping is a few hours and can be facilitated by a consultant
  • Management can take significant time to set up and needs to be managed once installed
  • Mapping without management is missing that continuous monitoring ability
  • Management without mapping is like collecting data without any goal or strategy in place, mapping is a much easier activity that informs management strategy and reveals issues that will affect management
  • Management can also lack detail in manual tasks since it relies on data integration and manual activities are not often tracked
• Value Stream Management in a nutshell: continuous flow optimization, allowing you to visualize, plan and respond to stream changes
• We don't really have value stream managers in many organizations, but flow and productivity responsibilities are often found in Product Owners and Scrum Masters
  • Because this isn't their focus, it's hard for them to do a great job
• Valuable metrics include:
  • Deployment Frequency (DF)
  • Mean Lead Time for changes (MLT)
  • Cycle Time: Time to complete a given step (CT)
  • Mean Time To Recover (MTTR)
  • Change Failure Rate (CFR)
  • Quality: % Complete and Accurate (%C/A)
  • Non-value Added Time (NVA)
• What's next? Awareness and adoption

Other thoughts: Most teams struggle with alignment, recruiting, coordination and retention of staff. Value stream thinking and improvement allows you to get more from less, while keeping everyone happy and productive. Most developers spend a small fraction of their time adding value, and can’t see how friction/complexity/improvement actually affects business metrics. The value stream brings you and your whole organization valuable context you can’t get anywhere else.

Check it out at https://www.brighttalk.com/webcast/18053/389599

Or: Keep CALMS but Carry On 😅

I believe there is a great reason Lean and Metrics (measurement) are the only two sections in the promising Dojo Consortium playbooks that have significant progress.

If you're starting, growing or correcting a transformation effort (dojo-led or otherwise), you need to use a lean, measurement-based approach to begin a successful effort. These two: L + M are often the least discussed and understood, though they provide a foundation for everything else in the transformation. Even worse; they're the easiest ones to understand and start with!

The interesting thing about CALMS is that beyond being a helpful acronym, each focus area actually builds on the previous, if you rearrange the order.

1. Start small, observe, experiment, learn and iterate (Lean)
2. Measure your baseline and progress (Measurement)
3. Share ideas, progress, work, learning and success (Sharing)
4. Develop behaviours, patterns, incentives and capabilities for improvement (Culture)
5. Implement and improve systems and operations (Automate)

LMSCA

By this order, each item in the list feeds the next directly and increases the odds of success.

This is incredibly valuable because it offers an opportunity for focus and direction in the effort, and provides a playbook itself. I'm giving you permission to ignore a lot of very important things. Ignore automation until you have behaviours worth automating. Collect data before you worry about what and how to improve sharing. Forget about culture until you have some behaviour and results you want to spread. Crawl, walk, run. We don't learn to crawl by agonizing over how we can go from lying around to suddenly crawling, walking and running. We iterate. Effective learning, growth and improvement is a lean practice.

The 2019 State of DevOps Report says it beautifully: "For organizations seeking guidance on how to improve, we point to the only real path forward: Start with foundations, and then adopt a continuous improvement mindset by identifying your unique constraint (or set of constraints). Once those constraints no longer hold you back, repeat the process."

Don't We Need the Right Culture to Do Anything?

I tend to define culture as 'how your organization behaves', not general values and beliefs (ethos). Believing in the change is truly the first requirement. Many organizational transformations occur despite a legacy culture. After all, we're trying to change culture as part of this effort. It's important to examine and leverage the organizational environment before embarking on this journey to ensure odds of success are maximized. If your organization is: 

• Hostile to change
• Not incentivized to change
• or otherwise hampered

Addressing and improving those conditions will take time. This is why we start small and iterate. We collect data to share success and build momentum. Even though it seems we're ignoring culture when it has such a major impact on our progress, to influence culture we need more than just ideas and plans. By starting with a lean approach and sharing measurement, we can build and direct culture intentionally through a sustainable practice.

LMSCA defines a clear path forward. The only problem is that it rolls off the tongue like bricks roll down a hill. So CALMS still has its use. 😁

If you'd like to talk further about this or otherwise maximizing your transformation efforts, I'd love to hear from you! Book a free chat with me here

Sign up here to get the latest content and offers as they launch

When I help companies improve their value streams, the target team and I start high and dig as deep as we need to in order to reveal their unique bottlenecks, risks and opportunities. That usually leads us to examining where dependencies lie, identifying handoffs, and how teams are structured. We start with dependencies and handoffs, as two of the worst offenders when it comes to team performance and happiness. Conducting a Value Stream Mapping exercise allows us to reveal problems. From there, one of the most impactful changes we can make towards improvement is in adopting a stream-aligned, flow-focused team structure.

What I’ll be writing about can be simplified in three main points, in case you love a good gist:

• Optimizing flow requires organizing work and teams to minimize friction
• Reorganizing your teams is expensive, if you’re going to change, you might as well do it as clearly, seldom and simply as possible
• There is a single model that can work for every team in your organization

In this series, I want to dig into various team structures with an aim towards illustrating how they provide value and flow. I’ll describe different team models, pros and cons, trends and pitfalls. To do this I will start by talking about Project-to-Product migration, a major trend that is driving these new team structures. Those structures are:  

• Product Teams
• DevOps Teams
• Platform Teams

Adopting these structures is a topic many companies are grappling with as we look to improve agility, resilience and performance. I’ll share some common pitfalls and advice to avoid common mistakes. I’ll conclude the series by looking at how to change and improve your team structure to facilitate sustained flow of value.

First, let’s look at why we’re doing this realignment towards products, and why projects are increasingly becoming obsolete in many value delivery contexts.

Project-to-Product Migration

There has been a steady shift in most organizations building software, away from project based development and towards product based development. A major turning point in common thinking was signaled by the release of The Lean Startup and it’s focus on minimal investment for maximum value and learning via continuous iteration. The topic was further analyzed in depth in Mik Kersten's book Project to Product from an enterprise perspective if you’re interested in that perspective. 

Here’s a quick recap of my learning on the subject to bring us up to speed:

• Projects focus on creating an outcome based on a prediction of value often far beyond our ability to forecast, and aim to deliver that outcome based on fixed costs, resources and time. This is incredibly challenging unless you have lots of prior experience with an identical effort

Projects aim to deliver their requirements, where products exist to satisfy their customers

• Customers are demanding value on a more continuous basis  (SaaS, subscription, cloud services, rental) rather than finite deliverables, something which iterative, sustained products are better suited to deliver
• Increasing complexity and demand has diminished returns of large-scale planning in favour of just-in-time, highly contextual planning as we learn
• Product development thrives in teams with high psychological safety
  • Psychological safety requires growth of trust, respect, comfort, domain expertise and confidence, and suffers with disruption
  • This is challenging in cross-functional teams as individuals come from separate disciplines and have varied incentives within the team

  Project teams

• Project teams are assembled and disassembled based on a single major deliverable [product/feature release, event etc]
• Project teams tend to organize around functional silos which are active based on the project's phase of completion [planning, testing]
• There is significant overhead and disruption incurred by assembling, changing and reassembling teams for each project (often involving the same product repeatedly)
  • Commonly known as Forming, Storming, Norming, and Performing

  Product teams

• Product teams are formed to develop and serve a product line (or distinct feature) continuously over the sustained life of the product beyond it's initial release and between milestones
• Product teams tend to be cross-functional and incorporate as many functions contributing to end-to-end value creation as possible (potentially including marketing, success, operations etc)
• Product teams can react to incoming customer demands more rapidly, collect learning and retain knowledge and experience within the team beyond any single delivery
• Product teams benefit from increased autonomy and capability by being cross-functional and requiring fewer external dependencies and handoffs

Modern approaches

• Modern software practices and environments create and foster sustained flow of value to customers and benefit from the sustained attention and support of product teams
• Rather than measuring output, we can now focus on outcomes
• Rather than presenting work to an assembled development team and pushing them to complete it based on an arbitrary date, a product team:
  • Develops customer knowledge
  • Product and competitive awareness
  • Assembles and develops capabilities
  • Creates and delivers value

            As quickly and often as is sustainable over the long term

• New thinking and practices are required to migrate from fixed price/time/staff to a focus on allocating sufficient resources to facilitate a sustained flow of value to customers indefinitely

There is of course much more to examine and explore there but hopefully that brings us to a problem of what we should aim for with product teams, how they should look and behave. More on that in a few days!

Sign up here to get the latest content and offers as they launch

How do we get from where we are to better with Value Stream Mapping?

I saw an example recently showing how using a Plan-Do-Check-Act (PDCA) cycle can drive improvement by iterating from a current state to a future state, but what I always find missing from PDCA when it's mentioned is useful strategies for actually implementing the process. 

Sure, we'd all like to Plan, Do, Check, Act as everyone recommends but tactically, what is involved? How do we plan? What's the right way to do? What should we check? How should we act to improve?

Value Stream thinking can provide a framework for putting this process on autopilot and consistently leveling us up.

Let's look at the example graph above in simpler terms to break down the process by looking at each iteration step-by-step.

Baseline

We start with a current state assessment in the form of a Value Stream Map (VSM). Starting with a current state assessment, we can see: 

• Our value stream performance baseline
• Risks and opportunities

From there we can form a future state value stream map (detail coming soon!) to set our vision and align on a future state target.

Compared to a typical roadmap, our future state target is directly based on our current state, and focused on what we can confidently achieve. As a result, our odds of success are extremely high.

Progress

As we make progress towards the future state, we can adjust tactics. Our priorities will change as we remove blockers and bottlenecks highlighted in our current state map. We stay on track by taking intermittent measurements and adjusting as we go. To further increase value, we show and share these measurements to track improvement.

Iteration

 After a quarter, the team has made so much progress, we have new constraints to address. We can quickly create a new Value Stream Map to find our current issues and opportunities. Since we're familiar with the process, it goes much quicker. We're focused more on finding our next opportunity than understanding what's happening.

Improvement as a Habit

We continue to see and share continuous improvement in the value stream, and see steady progress. If we see challenges, bottlenecks or friction arise, we know where to look based on our continual awareness of the value stream (we'll dig into that further in a later post!).

Our team grows more and more confident. Leadership and other teams can always see progress and understand the needs of the team. New members joining the team can always see where they are needed and where the team's focus and challenges lie. Team members moving on can share clear learning with other teams based on the measurable results seen in their value stream.

Life is good!

Stay tuned for a post about how Capability Mapping can highlight and address gaps in team skills that can dramatically improve performance along with your Value Stream Map.

What do you find most challenging about performance improvement? I'd love to hear more about your plans and challenges on a video call - grab some time with me at meet.visible.is and let's talk value streams! 

You may wonder when it's worthwhile to examine or improve a value stream if it hasn't become a regular (quarterly) practice in your organization. Should we just do it? How can we convince everyone involved to take the time? What value stream should we look at?

It helps to think of specific qualifiers that we can easily relate to in order to quickly get a sense for ROI, and where to start hunting for bottlenecks. One that was recently mentioned in 'the Unicorn Project' was the idea of a 'lunch factor'.

What's a lunch factor?

In short, a lunch factor is the result of asking: Who do I need to take to lunch to make this happen?

If you've had a long and storied career in business, this might resonate deeper with you than if you're new to the game, but the analogy carries to meetings, phone calls, emails, documents, slide decks, approvals etc. What hurdles stand between you and a desired outcome?

You might think this is tough to measure because, as with most things; it depends. It helps to examine specifics when doing this kind of thinking, so take each of these for a spin and see how you do:

• Deploying a change to production
• Adding a new test environment
• Doubling your platform resources
• Rotating credentials
• Abandoning daily standups

In an agile, cross-functional, empowered team these activities may not require any special approvals, they may either be self-service or require a quick slack message with some context. In larger, more complex environments with departmental silos, change management overhead, etc you may have to take a few people out to lunch just to find out who to take to lunch!

Rotating credentials

If we take #4 for example: If I don't have automation around my security credentials, and I want to change a database password for instance, I may be affecting many teams/products/services with that change. I may have to convince a lot of people that this needs to be done, and now, and at higher priority than everything they were planning to do before I dropped this on them. I may end up taking 3 product owners to lunch to catch up, find out what they're working on, and somehow squeeze in my request for the change. Then I have to convince them to accept it! Add to that the time to schedule lunch, and the follow-through, and you can see how this all adds up. Doing the mental exercise (or the actual measurement) helps reveal the friction in very real and tangible terms. We now have some data to identify the value we might see from credential automation. To more clearly measure the ROI, we can now map the value stream and find out in real terms where the challenges and waste are.

I hope this test helps quickly focus your thinking on some key opportunity or risk areas. It certainly helps me! Before I dive into a complex process I first try to visualize the path to anticipate challenges, friction or where I may find a shortcut. If it seems complicated, I often start with a rough value stream map just to record my understanding, and have something to share with others.

Cheap, Quick Measurements

What other measures can we reference to see what we might find in our value streams? Emails are another great, quick data point, as are meetings, and if you're using Jira (or a similar tool) it can allow you to trace a task, story or epic from start to finish.

With that, I'll leave you with a fun thought experiment for this week: Find out how much lunch one of your critical value streams costs.

You may just find a worthy bottleneck for your next dramatic improvement.

I wanted to share an illustration of how common challenges in business, tech and the business of tech map to positive outcomes via Value Stream Definition and Design.

For many people they may either be aware of Value Streams as a concept or how they fit into improvement efforts, and this provides a high level review. At some point I'll add the 'how' - but in the meantime check out my other posts for that information.

PDF link for more detail