top of page

How to make value flow without interruptions in SAFe

Writer's picture: Roland FlemmRoland Flemm

Updated: Dec 22, 2024

Introduction


In 2022, Andrew Sales (Chief Methodologist and SAFe Fellow at Scaled Agile, Inc.) spoke at Tecnifor SAFe Day about “accelerating the flow of customer value.” You can watch his talk here. In this post, I will reflect on his ideas and share additional approaches to improving the flow of customer value systemically within SAFe.


While Andrew highlights key areas that can dramatically improve SAFe’s delivery capacity, I invite you to think beyond the immediate solutions and consider how organizational design principles—such as those found in Org Topologies™—can address the broader, root-level constraints that often limit our ability to achieve true business agility.


Andrew begins by posing a critical question:

“The question arises: if the (SAFe) framework has flow built-in and the teams and the ARTs are cross-functional, why do we sometimes struggle so much to deliver value seamlessly to our customers?”

He then proposes eight “flow fundamentals” that will, in his view, significantly change how SAFe is practiced. Let’s examine each one, discussing potential remedies, deeper considerations, and how they align with Org Topologies thinking.


1. Visualize and Limit WIP


Andrew’s Summary

  • The value-delivery capability of a team drops as Work in Progress increases.

  • Proposed Actions: Make WIP visible and set strict WIP limits.


Expanded Reflection and Analysis

Visualizing WIP is a valuable first step that raises awareness. It helps teams see how many tasks they are juggling and appreciate the inefficiencies in context-switching. Strict WIP limits often lead to immediate improvements in the team’s throughput.

  • Short-Term Relief: Limiting WIP on a single team can increase its output and reduce stress.

  • Potential Pitfalls: If only one team or a handful of teams impose strict WIP limits, work might accumulate upstream or downstream, creating bottlenecks elsewhere. This local optimization can inadvertently slow down overall flow across the ART, Solution, or Portfolio.

  • Systemic Perspective:

    • ART-Level WIP: Consider implementing WIP limits at the ART backlog level. This broader scope forces the entire release train to confront systemic constraints (e.g., insufficient capacity, unclear priorities) that only become visible when we stop overloading teams.

    • Organizational Design: If teams cannot handle certain types of work, it may indicate a deeper capability gap rather than merely a “too much WIP” issue. Sometimes, “limiting WIP” becomes a temporary band-aid unless you also address cross-functional skills, system architecture, and organizational structures.


By integrating an Org Topologies perspective, you can decide whether to move teams “up” (broaden their scope) or “right” (expand their capabilities), ensuring that WIP constraints are part of a larger design strategy rather than an isolated fix.


2. Address Bottlenecks


Andrew’s Summary

  • Bottlenecks commonly emerge from limited shared knowledge, poor collaboration, missing discipline, or external dependencies (including delayed customer feedback).

  • Proposed Actions: Increase capacity at the bottleneck or replan work.


Expanded Reflection and Analysis

Identifying and addressing bottlenecks is a continuous challenge:

  • Increasing Capacity

    • Quick Win: Add specialists to the team. Although it helps clear the immediate bottleneck, it may not be sufficient if the newly introduced skill remains concentrated in a single person.

    • Long-Term Investment: Use pairing or mobbing to distribute specialized knowledge across multiple teams. This approach takes more time but creates a more resilient system in the long run.

  • Replanning Work

    • Risk: Simply rescheduling tasks defers the underlying bottleneck problem. For truly valuable features, you might still need that scarce skill tomorrow.

    • Systemic Approach: If certain types of work always require a specialized skill, consider reorganizing to embed that capability in multiple teams or reduce the scope of specialized tasks so that it becomes more feasible for additional team members to learn and take on the remaining specialized work.


Moving “Right” on the Org Topologies Map

  • Increasing a team’s capabilities (e.g., adding new skill sets) can reduce bottlenecks. However, you must also consider the frequency of using those skills. If the skill is needed often across multiple teams, a system-level reorganization might be more beneficial.

3. Minimize Handoffs and Dependencies


Andrew’s Summary

  • Handoffs and dependencies arise when one team (or individual) must wait for another’s output.

  • Proposed Actions: Visualize dependencies, reorganize around value, and redesign teams or systems to reduce overhead.


Expanded Reflection and Analysis

Dependencies are not inherently bad. Synchronous dependencies can spur beneficial collaboration; the real issues often arise with asynchronous dependencies or deep, specialized silos:

  • Reorganization Paths

    • Left/Down Move (Team Topologies): Create streamlined groups specialized in certain components, with clear communication pathways. This can control dependencies by isolating complex components to dedicated teams.

    • Up/Right Move (Org Topologies): Form “team-of-teams” constructs within an ART, focusing on broader chunks of customer value. Allow them to pull work directly from the ART backlog to reduce cross-team handoffs.

  • Balancing Complexity

    • System Architecture: Sometimes the product architecture is the root source of these dependencies. Without architectural improvements (like decoupling components), simply rearranging teams has limited impact.

    • Collaboration Practices: Techniques such as mobbing across teams for shared tasks can reduce repeated handoffs, but they require a culture that encourages collaboration and shared ownership.


By examining dependencies through an organizational design lens, you can systematically reconfigure teams or the entire ART to ensure that integration and delivery happen at the level where true customer value emerges.

4. Get Fast Feedback


Andrew’s Summary

  • Technical feedback (e.g., ensuring the product is built correctly) and customer feedback (e.g., ensuring we build the right product) are both crucial. Broken feedback loops lead to rework, technical debt, and dissatisfaction.

  • Proposed Actions: Investigate which type of feedback is missing, shift left for technical feedback, and practice CI/CD.


Expanded Reflection and Analysis

  • Technical Feedback

    • Emphasize code reviews, pairing, mobbing, and continuous integration to detect problems early.

    • Adopt automation tools, including AI-assisted testing, to speed up cycles.

  • Customer Feedback

    • SAFe typically provides a big feedback window every Program Increment (PI) (often every 10-12 weeks). This might be insufficient for highly dynamic markets or fast-evolving products.

    • Encourage more frequent integration and demonstration at the ART level or higher, rather than strictly by individual teams.

  • Systemic Dimension

    • If multiple teams are required to deliver a customer-facing increment, ensure they can frequently integrate their work.

    • Shrinking feedback loops often requires changing organizational structures that slow decision-making or add bureaucratic gating steps.


In Org Topologies terms, moving “up” can mean giving teams a broader scope so they can test and demo an entire feature or sub-product to the customer in real-time rather than waiting for a separate integration phase.


5. Work in Small Batches


Andrew’s Summary

  • Large batches create long feedback delays and increase the risk of rework and unpredictability.

  • Proposed Actions: Align story size to iteration, feature size to PI, and consider smaller release, integration, or customer batches. Prioritize enabler work to improve automation.


Expanded Reflection and Analysis

Most practitioners agree on the efficiency gains from smaller batches:

  • Practical Constraints

    • Some organizational policies or regulatory environments may enforce “big batch” releases, slowing feedback. Challenge these policies if possible or design intermediate validations to emulate smaller batch feedback.

  • System Design

    • Splitting work into tiny pieces is only helpful if teams can actually deliver those pieces end-to-end. If siloed functions (e.g., QA, security) come in late, you still end up with a large integration batch.

    • Consider a vertical “up” move: enabling teams to own features at the business-problem level. They can slice user journeys or epics in small increments that are still meaningful to the customer.


When small batches become the norm, flow accelerates. But do not forget that it often requires not just rethinking iteration planning, but also evolving the architecture and team compositions so that integration is continuous and frictionless.


6. Manage Queue Lengths


Andrew’s Summary

  • Queues represent committed work. Long queues mean long wait times for customers and diminished agility.

  • Proposed Actions: Avoid overcommitting to future PIs, reduce informal (untracked) work, and focus on what’s promised.


Expanded Reflection and Analysis

  • SAFe Context

    • Enterprises implementing SAFe often value predictability, which sometimes conflicts with the unpredictable nature of software development. Balancing “enough predictability” with the need for agility is a tricky but necessary conversation.

  • Systemic Insight

    • Managing queues effectively might mean reducing the number of backlogs altogether. Many organizations have separate product, team, and portfolio backlogs, each adding overhead and friction.

    • If teams within an ART can collaborate on a single ART backlog, they can rapidly respond to emergent, high-value requests without the inertia of multiple queue handoffs.


By removing or combining backlogs, you reduce the communication overhead. This is a significant organizational design shift that can pay dividends in responsiveness and alignment.


7. Optimize Time in the Zone


Andrew’s Summary

  • “Being in the zone” refers to focused, deep work essential for complex tasks. Excessive meetings, events, and context-switching undermine productivity.

  • Proposed Actions: Question the necessity of certain meetings, keep WIP low, and leverage pairing/mobbing to reduce handoffs.


Expanded Reflection and Analysis

  • Meeting Culture

    • Identify which meetings are truly indispensable for alignment or decision-making and streamline or eliminate the rest.

    • Consider a “meeting-free day” policy or carefully structured meeting blocks to give teams uninterrupted blocks of time.

  • Beyond WIP Limits

    • If a team’s backlog is a mix of unrelated tasks, limiting WIP will help to some extent. However, the deeper cure is to provide teams with a cohesive scope (e.g., a full feature or business capability).

  • Pairing and Mobbing

    • These can rapidly spread knowledge, reduce dependencies, and create shared ownership. They also cut down on the need for status meetings since the team is aligned in real time.


Viewing these improvements through Org Topologies might lead to restructuring roles or merging backlogs so teams spend more time innovating and less time “managing the process.”


8. Remediate Legacy Policies and Practices


Andrew’s Summary

  • Old habits can sabotage a modern SAFe implementation by reintroducing silos or extra layers of bureaucracy.

  • Proposed Actions: Identify and address these obsolete patterns.


Expanded Reflection and Analysis

  • Identifying Legacy Issues

    • Legacy often hides in approval chains, governance rules, and organizational hierarchies that are ill-suited to agile flow.

    • Tools like value-stream mapping in combination with the Org Topologies map can reveal how outdated practices obstruct effective collaboration.

  • Changing Mindsets

    • This is often the hardest part. People who grew accustomed to certain processes or organizational structures may feel uneasy abandoning them.

    • Emphasize system-level outcomes, focusing on how an outdated policy slows flow or increases waste.

  • Educational and Cultural Shifts

    • Offer training or workshops on systems thinking and Org Topologies so that teams, managers, and executives understand how local decisions affect overall flow.

    • Encourage experimentation with new practices, such as cross-functional “team-of-teams” or short, frequent planning cycles, to replace rigid, outdated methods.


Conclusion


Andrew Sales’ eight flow fundamentals offer a solid starting point for enhancing SAFe’s effectiveness. However, improving flow at scale requires a holistic approach that looks beyond the immediate fixes—like limiting WIP or planning around specific bottlenecks—to address deeper organizational structures and cultural norms.

  • Systemic Thinking: Embrace Russell L. Ackoff’s insight: “the performance of a system depends not on how the parts perform taken separately, but on how they perform together as a whole.” Focus on end-to-end flow (ART, Solution, Portfolio) rather than on isolated improvements within individual teams.

  • Organizational Design: Consider how you can “move” across and up the Org Topologies map to expand teams’ capabilities or give them more business scope. Aligning on a single backlog at the ART level, merging teams into a “team of teams,” or embedding specialized skills across multiple squads can all be powerful levers to achieve sustainable flow.


This article is an invitation to re-examine how your organization delivers value and to unify teams around shared goals. By integrating Andrew Sales’ flow fundamentals with a systemic organizational design perspective, you can create lasting improvements in your SAFe implementation—without losing the framework’s structural benefits.


139 views

Recent Posts

See All
otp.png

Thank you for subscribing!

bottom of page