Value Stream & Flow Q&A

Uncommon Questions, Uncommon Clarification :)

In this week’s newsletter, we’re diving into some of the most recent and thought-provoking questions we’ve received about Flow Engineering. From practical tips to strategic insights, this Q&A is all about helping you better understand and apply Flow principles in your work.
Topics:

• Value Streams compared to frameworks

• Flow Engineering and Value Stream Management

• Capabilities, JTBD, DDD, TOC, and Dependencies

• Risk Management

• OODA, PDCA, PDSA and Cybernetics
  

Let’s get into it:

Question 1: How are Value Streams categorized, and do they complement other methodologies or function as a standalone framework like ITIL?
A: Value Streams are just a model to describe the full flow of work that delivers value to customers or stakeholders. A model to visualize, measure, analyze, and optimize not just processes, but processes in the context of customers and the business. Unlike prescriptive frameworks like ITIL, Value Streams serve as a flexible lens to contextualize other methodologies. ITIL, SAFe, and many other frameworks have incorporated value streams as a model to put their guidance and practices in a meaningful context. Value Streams enable discussions about how changes impact work flow and value delivery, aligning technical and business perspectives. This makes them complementary, enhancing frameworks by providing a lens (flow in service of value) and a model (structure of representation and measurement) for what they’re meant to enable.

Question 2: What is Flow Engineering, and how does it relate to Value Stream Management?
A: Flow Engineering refers to practices that optimize work flow, which can be within the context of Value Stream Management (VSM), but it can also just be making life better at the team level. While VSM focuses on continuous improvement of value delivery at a macro level, Flow Engineering can involve periodic (e.g., every six months) or continuous efforts to refine specific streams at the mid and micro levels as well. Implementation of Flow Engineering improvements often incorporate methodologies like Kanban for team or intake-level improvements, creating a bridge between macro and micro flow performance.

Question 3: Is Value Stream Management or Flow Engineering a one-time process or part of ongoing lifecycle management?
A: Value Stream Management is a continuous process aimed at sustained improvement of flow and value delivery. Flow Engineering, depending on its scope, may involve periodic reassessments or ongoing refinements. Together, they support long-term lifecycle management, adapting to evolving business needs and process constraints.

Question 4: How do other methodologies, such as Design Thinking and Jobs to be Done, integrate with Flow Engineering?
A: Value Stream Management can incorporate principles from methodologies like Design Thinking, Jobs to Be Done, and Domain-Driven Design - depending on the needs of the value stream or value stream network. For example, Jobs to Be Done helps identify and define value streams, while techniques like User Needs Mapping or Value Stream Network Mapping create a holistic view of processes, enhancing stream design and optimization. Design Thinking is helpful in both the initial Outcome Mapping efforts in Flow Engineering, as well as Future State Value Stream Mapping and Flow Roadmapping, which are all creative efforts.

Question 5: Are business capabilities in Value Streams aligned with Domain-Driven Design?
A: Business capabilities in Value Stream Management share conceptual similarities with Domain-Driven Design (DDD), focusing on core business functions. While not identical, alignments with DDD and resources like BIZBOK are something I’m always interested in to try and connect Flow Engineering to other models and areas of practice.

Question 6: How does Dependency Mapping contribute to Value Stream Management?
A: Dependency Mapping identifies relationships and constraints within a value stream, offering a deeper view into what may be causing constraints or friction. It serves as a starting point for broader Value Stream Network Mapping, enabling organizations to address inefficiencies and optimize flow across interconnected value streams. In many practices, Dependency Mapping is a way of visualizing and managing dependencies, whereas in Flow Engineering our focus is on addressing them - by mitigation, avoidance, or elimination.

Question 7: Is the concept of bottlenecks in Value Streams aligned with the Theory of Constraints (TOC)?
A: The concept of bottlenecks in Value Streams closely aligns with the Theory of Constraints (TOC), emphasizing the identification and resolution of constraints to improve flow. While not strictly adhering to TOC, the principles are compatible, supporting a practical approach to process optimization. TOC is a very rich and mature ecosystem at this point, and in some cases it’s very strictly applied. As with most inspirations, we borrow what seems like the 20% that delivers 80% of the value.

Question 8: How is risk assessment addressed in Value Stream Management, particularly with dependencies?
A: Risk assessment in Value Stream Management often focuses on constraints, such as bottlenecks, where dependencies pose clear risks. By narrowing the scope to these constraints, organizations can prioritize risk mitigation. Emerging tools and methodologies, such as those in advanced risk management frameworks, provide deeper analysis for dependency-related risks. On the subject of risk, Doug Boyce has been producing an interesting series on Risk Management and Flow Engineering.

Question 9: Why not use OODA or PDSA/PDCA in Flow Engineering?
A: The issue I always find with these activity loops is a lack of vision and targeting. They each have an unstated (and too easily missed) dependency on a vision or target. OODA is dependent on clear mission objectives, training, and SOPs. PDCA began as quality control, but always relied on targets already in place.

This lack of defined vision or target makes it too easy to stay busy doing low value things or creating waste. Just doing actions efficiently and consistently doesn't necessarily create any value.

We could use OODA, PDSA, etc but I don't like either for what we’re aiming for in Flow Engineering: Effective Action. To me, the cybernetic model of target, assess, act, observe doesn’t require as much assumption or prerequisites. In short, you can use OODA PDSA PDCA if you already have a target outcome. Cybernetics includes it.

As with all things, if you don’t use the tool properly it won’t provide value. My argument is that OODA (etc) doesn’t tell you about the dependencies because they are assumed, and that invites misapplication. It’s not flawed, but it’s too easy to misapply.

Have a question?

Ask in the comments or send me a message -

A question for you:

Which topic would you like to hear more about?