Moneyball is a book (and movie - such a good soundtrack!) I come back to as a framework to approach knowledge work. In both cases, teams are facing incredible challenges with little resources, and the key to improvement is a systematic approach that delivers consistent results.

What does Moneyball have to do with Flow?

Moneyball is about engineering outcomes. The best way to improve flow is to engineer it through specific methods, models, and principles.

Key messages

• Moneyball emphasized the value of working backwards from outcomes:  runs win games, bases deliver runs, hits and walks deliver bases, capabilities deliver hits and walks.
  • Hint: Design the process, execute the process, trust the process.
    • Outcome mapping and value stream mapping were built for this
       
• To change culture, executives must make it clear you’re either on board or on your way out. On board means action, not lip service.
  • Outcome mapping can ensure your people are really on board and what that actually means
     
• To change culture, executives must be in it for the long term and be ready for challenges and learning. 
  • Hint: you can roadmap your workflow just like your products.
    • Flow Roadmaps were built for this
       
• Data can provide a check and balance against gut feeling and opinions. It also gives you a competitive advantage against companies that shoot from the hip.
  • Value stream mapping is great for this, and value stream management makes it continuous
     
• Beyond process, organizations must adopt continuous business experimentation, analysis, and adaptation.
  • Value stream management is great for this

Principles

• Work backwards from desired outcomes
• Identify undervalued assets and capabilities
• Challenge assumptions with data
• Study and learn from outliers

Find the right stats to track

In Moneyball it’s hits, players past home, and runs allowed

• For flow, this looks like lead time, value-added time, work profile, defect rate and a whole list of other metrics

Measure and improve key capabilities 

Across each category that matters to your team

• Architecture
• Design/UX
• Build
• Validation/Testing
• Feedback synthesis/Analysis

Hint: basing this on your value stream means you only have to focus on the ones linked to your biggest gaps and dependencies

• Capability mapping is built for this

I’m not the first to talk about this - check out this excellent talk from Jonathan Alexander in 2011 

https://www.youtube.com/watch?v=9OaQi27qQKg 

If you're interested in getting the most from your teams and organization - book a chat with me here - you can get started in a couple of hours

If you're interested in diving deeper into this idea, let me know here!

If Flow Engineering is new to you, check out the whole system here

From a recent community post:

Does anyone have any ideas or references for setting up the operating model (or team structure) when we are trying to move an organization from waterfall ways of working to a agile ways of working or from a project mind set to a product mind set?

Our leadership is trying to change the team structure to more focus on one or two products per team but I guess it has to be much more than that which basically means we need to look at the HR policies, the funding model and what we call as product because most of the time people just reliable the project as their product.Any recommendations on how can we set an operating model for agile transformation ?

There was some great guidance in response:

I'd be careful with focusing on products per team. We made the mistake of turning everything into a product and ended up with too many products, a lack of clarity on the products themselves and the organization didn't relate to the products defined by the teams. Teams don't need to own a product, teams need a mission and an interaction with other teams. They can work on a single product across many teams. Team topologies is a good place to start.  As a rule of thumb focusing on what either your customer thinks of as a product or your business / users, rather than the team is helpful.   What is often more useful is the identification of value and independent deployability for a team instead. A navigation menu or a search feature can be aligned to a team of the overall product is complicated but a user doesn't want a menu or a search feature by itself 

I weighed in with my 2 cents:

Good guidance here so far! Stream alignment is definitely valuable - working backwards from customer value, and clarity on core/supporting streams helps a lot. Define the dependencies and impacts of those dependencies across teams/streams. You don't need one team per product but single-threaded ownership is extremely valuable. One person needs to own sales, one person needs to own e-commerce, one person needs to own the shopping cart, all supported by teams. Each of those owners can own multiple products/features/streams, but that should be a calculated definition. If two people own something, who actually does?

This is an excellent guiding principle:
As a rule of thumb focusing on what either your customer thinks of as a product or your business / users

To put a finer point on that:

• If you want to make the people who pay for your service happy, work backwards from what makes them happy.
• If you want to make the people who use your service happy, work backwards from what makes them happy.
• The former is helpful in the short term, the latter is helpful in the long term.

One other point is that a major advantage of agile methods vs waterfall is just shorter cycles / faster feedback. Smaller and quicker iterations of what you're already doing help a lot, but that's often very hard under the same org/arch structure, so it's valuable to think about reorganizing in service of improving iterations.

What do you think?

How much of this looks familiar to you?

If you're working in a software or product delivery team,  you probably recognize quite a few of these symptoms, but what are the causes, and how do we get to better?

It starts from becoming clear on what today looks like, along with what better looks like. Everything could always be better, but what's going to make the most positive impact, with the least amount of effort? What's holding us back from getting there today?

To move towards flow and away from friction it takes focus. This is why the Theory of Constraints (TOC) is still the king of continuous improvement models. By mapping the value stream and identifying the most critical source of friction, we can focus on it and improve it. To do that, we have to be able to see, measure, target, and isolate the biggest impacts on flow. That starts by focusing on our goal, so we can make sure we're all seeing the same flow, and have a model for understanding what's between the current flow and our desired outcome.

Let's say we'd rather be here:

Everyone wants to get to automation, but like our symptoms of friction, automation is just a side effect of many other pieces falling into place. 

It all starts with clarity and alignment around a desired outcome, and flows from there through effective collaboration across the value stream.

To find out how to get moving in the right direction, check out my article on Outcome Mapping and the free Flow Engineering ebook and course series

Case: Ambitious Software Delivery Team

Let's look at the example of a team aiming to boost their performance:

Starting from: “We want to deliver software twice as fast without sacrificing quality” we first map that outcome to reveal top contributing factors.

We created an outcome map to clarify a team understanding of the goal, why it's valuable, what obstacles could impact success, key investigations to improve odds of success, and indicators that will reveal progress. The team discovered that out of 8 members, everyone had a different idea of what would contribute to the outcome.

Next we mapped the value stream to reveal the visual flow and collect data on how the work is performing currently, and how it could be improved. We revealed handoffs, delays, tool challenges, meeting impacts and more. The team discovered that 30% of the current process was waste that could be eliminated within the next 3 days. Their target state map was less than 1/3 the time of the current state.

We then mapped out dependencies beyond the team and value stream in question to highlight external factors affecting our desired outcome. Approvals, cross-team meetings, SLAs, and shared services interactions were all clearly revealed as measurable impacts on the team. As one example, the team revealed that there was a 3 business day SLA with shared services that affected the team almost every single sprint.

Finally, we mapped out team capabilities to see what internal factors could affect our progress to the outcome. The team could see how their key capabilities and gaps were affected by available resources and support, as well as ownership and cognitive load. Along with other insights, the team identified ownership gaps and missing backup roles that were needed to support automated testing.

All of this clarity and data fed into prioritization and a clear roadmap defining next steps. The team set off working with awareness, confidence, and alignment. With a few weeks of effort, the team was operating far beyond their target outcome and on to bigger and better things.

What's affecting us from inside the Value Stream?

In the example, you can see how feature delivery is being affected by your two primary bottlenecks which are dependent on validation and test automation, how they are connected to external tooling and infrastructure, and a gap in capabilities. By combining the 4 Key Maps, you can trace a clear path from desired outcome to actionable next steps. In fact, this method will work for any situation, not just identifying how to improve your performance for technical teams, but any process or outcome you want to address. 

"We can now see how contributions within the team are affecting our most critical constraints and our ability to address dependencies. If we can create a playbook to fix the simplest 80% of our build failures, we could resolve issues quickly within the team. We've identified a lead and backup to focus on building out test automation, and highlighted necessary support and training." 

Armed with these compasses and maps, the team has a clear direction, knowledge of the landscape between their position and destination, and supporting metrics to keep them on track. They can easily tackle a prioritized set of initiatives aligned to their true north. They have velocity and quality metrics to inform them when something is pulling them in the wrong direction. They can see the path to success, which they have confidently defined to avoid obstacles and mitigate challenges. They can clearly and constructively collaborate along the way with everyone involved or affected.

"We can now see a clear path to success, together. Everyone from individual contributors to leadership can share the same view and alignment. We went from 8 different ideas of where to focus to 2 clear, prioritized opportunities. We know exactly what to do next, and can act safely in the knowledge that our compasses and maps will keep us on track. We can craft data-driven hypotheses that drive rapid, measurable experiments. We can periodically measure against our baseline to see, share and celebrate progress."

You may have noticed by now that the focus of these efforts is not merely DevOps or software delivery performance, but value stream performance. Well beyond the boundaries of software development and delivery, value streams are the true engines of value in every organization. They encompass every role, department, function, capability, and purpose throughout your company. This means that the skills you develop to improve value stream performance can be leveraged in any scenario where performance is constrained, and targeted improvements can have massive impacts throughout your organization. Value Stream Thinking and these techniques can empower you to drive powerful change.

How do you get from a desired outcome to a target value stream?

If we take a desired outcome like: "Release 2x faster", it's easy to target the release value stream for the product in question. 

• Release what? We want to release our mobile app in half the time.
   
• Why do we want to release twice as often? This may be obvious to you but it's safe to assume it's not obvious to everyone you need involved. Do you want faster feedback from customers? Why else?
   
• What obstacles are in the way? Testing takes a long time, we need approvals from 3 different departments.
   
• What investigations can we do? We could send out a survey (which may raise alarm bells depending on the culture). We could approach our director to ask for support. We could try to map the existing value stream.

Bonus: If you have time or interest, you can enhance an Outcome Map with additional detail by digging deeper

• How will we measure progress? The first stream will be a big milestone. Having all the streams in a single portfolio is another (maybe aim for 10 a week). Assigning owners for each stream is huge. Having each team assigned to a stream is another big one. Creating a living visual reference would be great as well.
   
• What methods will we use to make progress? Should we collect survey data and document it in a wiki? Create a visual representation? Will it be maintained by the owners?

Having a well understood outcome helps us focus on a specific value stream, because there's a value stream involved in the delivery of that outcome. 

There's a value stream behind every outcome. 

Once we know the outcome, we can identify the customer involved, and work backwards to the start of the stream.

By starting with the clarity of the Outcome Map, the team is heading in one direction together. Having a map makes it easy to communicate within and beyond the team.

What do teams say after mapping?: "We're all on the same page and aware of what may lie ahead. We revealed that our regulatory requirements will demand a careful mitigation strategy, and our lack of test automation is a sore spot."

That's a lot more clarity than starting from scratch.

In our case, after setting the target of releasing 2x faster, and highlighting has pointed us to examine all of the requirements for releasing our software, and naturally the software development and delivery stream for that product. We can now map the value stream with a focus on improving velocity while keeping quality as a priority.

Outcome Mapping is

• Simple
• Clear
• Visible
• Inclusive
• Shareable
• Collaborative
• Flexible
• Fast

Let's talk about your next target outcome, or the one you're struggling with now

Book a free discovery call in 2 minutes here

Welcome, I'm so glad you're joining us!

It's the perfect time to learn more about Value Streams and how working with Flow can revolutionize your work.

It seems everyone in the Agile, DevOps and Tech scene are talking about Value Streams in 2021, and for good reason! Business and manufacturing folks have been focused on value streams for decades, but as maturity and capability evolve in tech, these areas are now combining and the best of each world is being applied everywhere.

Who am I?

I'm a tech veteran who's been through support, development, delivery, infrastructure, management, leadership, and now consulting for over 20 years. I live in Toronto, Canada, love running, biking, and frisbee, sci-fi, philosophy, history, and anything I can hear about in a podcast (lets share recommendations!).

I've focused on value streams and flow after seeing the common threads and patterns that have worked best across industries, and organizations of all sizes. I'm sharing Flow Engineering as the culmination of everything I've learned and used to get incredible results for teams.

Course Overview

This course will give you everything you need to start dramatically improving the flow of value across your organization. It's structured as 7 consecutive days (starting tomorrow!) like this:

• Day 1: How to Begin with the End in Mind - Outcome mapping
• Day 2: How to Map your Value Stream - Value Stream mapping
• Day 3: How to See what's Affecting Flow from Outside - Dependency mapping
• Day 4: How to See what's Affecting Flow from Inside - Capability mapping
• Day 5: How to Run the whole Process - An example case study
• Day 6: How to Get Results - Creating a Flow Roadmap
• Day 7: How to Get Help - More Resources and a Special Offer

Flow Engineering

Imagine the path of your workflow from idea to customer as a stream that currently winds throughout the landscape, off into the distance around you, from upstream to downstream. From where you stand, you can see part of the stream as it approaches you from upstream, and you can see a part downstream as it continues into the distance. If you wanted to improve the flow, you could widen the portion around you, or perhaps carve a more direct path from one curve to the next. You wouldn’t truly be able to see what effect your change had on the stream without a view of the entire flow, and the downstream outcome. The stream could be restricted far upstream beyond your view, or downstream. If you had a map of the stream’s path, and measurement of the flow within the stream, you could ensure it followed the most direct path to your destination, and improve the flow precisely where it would have the most positive effect.

This is the power of a mapping approach to improvement. By creating and leveraging maps of the flow of value in your organizations, you can create the optimal flow of value, by changing precisely what will have the greatest impact. 

4 Key Maps to Improve Flow

The 4 Key Maps provide a comprehensive view of the landscape that your value stream traverses. Using the maps to guide your focus, decisions, and efforts, you can scientifically approach your improvement efforts using a visual and easily understood medium.

Homework

• Write down a list of all the value streams that you are connected to in your job (hint: if there's a customer - internal or external - there's a value stream)

Resources

• What is a Value Stream?

Sign up to get the 7 day email course delivered to your inbox

Subscribe here

Want a guided tour of the course?

Book a free intro call

Thanks for reading, feel free to reply with any questions!

- Steve

Who participates in mapping?

It’s important to involve representation from at least the responsible and accountable parties within a given value stream. That means if design is a part of the stream, there should be someone from design present during mapping. That also means that leadership and those who are able to change the system, workflow, and team must be present and involved. Once you identify your key bottlenecks, you can narrow the involved parties to those who are critical to those areas, but until the number of people exceeds a manageable 12 (for a professional facilitator), it’s better to include as many voices and perspectives as possible.

In order to get the highest quality information about the stream, it helps to have 2 voices from each role in order to get a second opinion. If one engineer states it takes 20 minutes to code review, it could be because they're thinking of a section of the code they know very well, or simply being optimistic. Having a senior and junior perspective can be very valuable to paint a more accurate picture of the value stream.

In the case of a large, complex stream like a large, monolithic product, you may have legal reviews, marketing consultations, graphic design, etc. If they're in the stream, they should be on the map, but if including them brings you to an uncomfortable headcount it may be wise to request their data directly prior to the mapping session and then plugging it in. You can use the following format for a survey:

[Product X release process]

1. Which activities do you perform in the [Product X release process]?
2. For each activity, thinking of what has happened the last few occurrences, on average:
   1. What triggers the start of the activity? [e.g. Jira Ticket from Role Y, a meeting, a direct verbal request, etc]
   2. How long does the work sit before you can act on it? [e.g. in a queue, or inbox, etc]
   3. How long does the activity take from start to finish? [e.g. from the time you start looking at it to when you hand it off to the next activity or transition to another activity]
   4. How much of that time is time spent working on the task? [e.g. not waiting for things to load, looking up context, trial and error, etc]
   5. How often do you have to send the work back to a previous step because of an issue? [e.g. missing information, unclear instructions, etc]
   6. How long does the work sit completed before the next role picks it up? [If you know]
3. What do you feel is the biggest bottleneck in the process at the moment?
4. What do you feel is the largest contributor to that bottleneck?

As you can see, it can be a lot of information to collect and synthesize, but the biggest issue is not knowing it. If a survey seems like too much work or a hard sell, you can also complete the value stream mapping in phases with different stakeholders.

This scoping and participation challenge exists only when the value stream itself is too large and cumbersome, which is something we can address through mapping! By moving to smaller, more autonomous, stream-aligned teams, you can map faster, easier, and at higher quality.

Who guides this process?

It pays to have skilled, outside facilitation for this process for a few reasons: A perspective from outside the organization is far less likely to bring an agenda, bias, or political influence to the process, which will drive superior results. A skilled facilitator knows where to dig, and when to move on. They will know what questions to ask, and what seems like a strange measurement based on experience with other teams. All of that saves valuable time and maximizes value. Gathering a team can be expensive if you’re not getting value from the session, and it can impact morale and trust to waste time. A skilled facilitator can likely complete a session in half the time, while keeping the team engaged. You may find you have skilled facilitators right now as agile coaches, scrum facilitators, dojo trainers, community of practice leads, or teachers. It’s ok to pilot the process with a facilitator and team willing to try and learn!

The highest performing companies build alignment around three questions: Why are we doing this? What should we do? How do we implement the transformation?

Boston Consulting Group, 2020

The Outcome Map

Clarify the goal and contributing factors to explore your challenge/opportunity and align those involved. “We want to deliver changes every week” is a fine outcome to aim for, but your odds of success and ability to make key decisions depend on why that’s valuable, as well as what could get in the way.

Why? 

Begin with the end in mind. See and share factors between you and your goal. The Outcome Map allows team members to dig into a desired outcome and begin charting the path to achieving it with open eyes. Doing so will help the team define a clear roadmap towards better.

How do you build it? 

The team comes together to define their desired outcome, and then consider what could impact their ability to deliver it. Defining the Why(s) sets the foundation supporting the effort. Obstacles are the key challenges standing in the teams’ way. Investigation lists your immediate actions to address obstacles. Measures are TBD when you define the map at first, because until you create the following 3 maps, defining effective measures is impossible. You’ll loop back and fill them in. Optionally, you can dig even deeper to add Indicators, Impacts, Roles, and Methods. Indicators list how you will know you’re progressing. Impacts list factors that will affect your progress. Roles list the contributors to the process. Methods, like Measures, wait until you know more. Deciding what to do and how to measure it can’t be done effectively until you truly know where your risks and opportunities are.

How do you use it? 

The Outcome Map is an excellent way to create energetic communication, clarity, and alignment from the start. It also reminds you to stay on track as you progress, and how to know when we’re drifting from the path. By adding measurements and methods, you can describe where you want to go and how you plan to get there.

How do you get from a desired outcome to a target value stream?

If we take a desired outcome like: "Release twice as often", it's easy to target the release value stream for the product in question. 

• Release what? We want to release our mobile app twice as often.
• Why do we want to release twice as often? This may be obvious to you but it's safe to assume it's not obvious to everyone you need involved. Do you want faster feedback from customers? Why else?
• What obstacles are in the way? Testing takes a long time, we need approvals from 3 different departments.
• What investigations can we do? We could send out a survey (which may raise alarm bells). We could approach our director to ask for support.

The real secret to identifying value streams is here. Each value stream has a customer. If you find the customer, you find the stream. Some times the easiest way to map a mysterious value stream is to start from the customer and work backwards. Customer -> Customer Value (or need) -> What is delivering the value?

• How will we measure progress? The first stream will be a big milestone. Having all the streams in a single portfolio is another (maybe aim for 10 a week). Assigning owners for each stream is huge. Having each team assigned to a stream is another big one. Creating a living visual reference would be great as well.
• What methods will we use to make progress? Should we collect survey data and document it in a wiki? Create a visual representation? Will it be maintained by the owners?

Having a well understood outcome helps us focus on a specific value stream, because there's a value stream involved in the delivery of that outcome. There's a value stream behind every outcome. Once we know the outcome, we can identify the customer involved, and work backwards to the start of the stream.

Conclusion

By starting with the clarity of the Outcome Map, the team is heading in one direction together. Having a map makes it easy to communicate within and beyond the team.

"We're all on the same page and aware of what may lie ahead. We revealed that our regulatory requirements will demand a careful mitigation strategy, and our lack of test automation is a sore spot."

Other options

• Impact maps
• Fishbone diagrams
• Outcome orientation (check this out!)
• North Star Framework

The 4 Keys Maps in Context

Below you can see how each map addresses valuable questions, and flows from one to the next. As you progress through them, you add clarity, confidence, and context to support powerful decisions with maximum alignment.

In other words:

• Outcome: Define and clarify outcomes
• Value Stream: Identify and address constraints and waste
• Dependency: Visualize and address external needs and complexity
• Capability: Measure and address internal needs and opportunities

See all the details in the full Flow Engineering ebook @ https://flow.visible.is

I've been digging into and expanding my understanding of value flow in different contexts, and (as I do) visualizing it has been helpful to put it all into context. Have a look and if you're interested in further reading, check out the following for more detail:

Value Networks

Value Chains

Value Streams

Value Stream Mapping

How is Value Stream Mapping Different?

This is Your Organization on Value Streams