Tuck your team members in around the areas where they quickly achieve flow—those are typically where they are particularly primed to contribute value.

—Brené Brown, Dare to Lead

Team Flow

Definition: Team Flow describes a state in which Agile teams deliver a continuous flow of value to the customer.

The SAFe Team and Technical Agility competency guides the creation of effective cross-functional Agile Teams and Agile Release Trains (ARTs). It encourages teams to apply specific quality practices and work with extended stakeholders to deliver valuable products and services to their customers. This competency has proven to be highly effective in improving business outcomes. But many individuals and teams have not worked in an Agile way before, and impediments abound. Moreover, there is no limit to a team’s effectiveness, and there are always opportunities to improve the flow of value to the customer.

---

Note: About the Flow Article Series
SAFe is a flow-based system. As such, any interruptions to flow must be identified and addressed systematically to enable continuous value delivery. While flow-based guidance is embedded throughout SAFe, a special collection of eight articles directly addresses impediments to flow. These are Value Stream Management, Principle #6- Make value flow without interruptions, Team Flow, ART Flow, Solution Train Flow, Portfolio Flow, the extended Guidance articles Accelerating Flow with SAFe, and Coaching Flow.

---

Details

Agile Teams do much of the vital work of defining, building, validating, deploying, and supporting some of the world’s most important systems. The small, cross-functional nature of Agile teams, the increased level of empowerment, the connection to the customer, and proven Agile practices all contribute to creating a work environment that delivers faster value, is far more productive and is simply more fun.

However, the work itself is complex, and while that is a big part of what brings knowledge workers to the endeavor, it also complicates the effort. SAFe addresses this challenge by providing guidance and practices for the roles and activities of each Agile Team. When implemented correctly, work will flow to the customer as smoothly as the process allows. Much of this guidance is provided in Principle 6 – Make value flow without interruptions, which highlights eight properties of a system of value flow. Each of the eight properties offers an opportunity for inspection and analysis to determine what interruptions to flow are likely to occur. While the properties and accelerators are common to all flow systems, the application is specific to each level of SAFe. The sections below describe how to apply the accelerators to ‘Team Flow.’

---

#1 Visualize and Limit WIP

Why it matters

Excessive Work in Process (WIP) decreases team productivity and impedes the flow of value to the customer (Figure 1). It confuses individual and team priorities, causes frequent context switching, and increases waste, overhead, and frustration. Like a highway at rush hour, there is simply no upside to having more work in a system than the system can handle.

What to do about it

• Make the current WIP visible. The first step is to make all the different types of work visible, including new functionality, maintenance, architecture, infrastructure, and technical debt reduction. Often, this simple visualization is a much-needed ‘wake-up call’ that causes practitioners to start addressing the systemic problems of too much work and too little flow.
• Balance WIP against available capacity. The next step is to set WIP limits that balance demand against the available development capacity. No new work is started when any workflow state reaches its WIP limit, helping match demand and capacity and increasing flow.

#2 Address Bottlenecks

Why it matters

A team’s productivity is constrained by various bottlenecks – where skill, capacity, resources, and other elements of the process or system cannot meet the demand. Improving team flow requires addressing bottlenecks continuously.

What to do about it

The first important task is to identify bottlenecks. Common examples include:

• An insufficient number of people with a given expertise
• Overspecialization
• Excessive technical debt
• Lack of availability of a shared service
• Lack of customer feedback

Many bottlenecks occur when work passes from one workflow step to another. A large amount of work piling up in front of a state in the Team Kanban may indicate a bottleneck (Figure 2).

However, when bottlenecks are caused by a capacity or skill shortage, identifying them is not always obvious and may require root cause analysis.

Once discovered, there are generally two ways to deal with a team bottleneck.

1. Increase capacity at the bottleneck. In many cases, adding people is an appropriate response. But there are other ways as well. SAFe’s Built-in-quality and other Agile practices provide many helpful techniques for increasing capacity at the bottleneck, including:

• Collective ownership. Collective ownership implies that anyone on the team can fix a defect, update a work product or resolve a problem. However, to help ensure that there are no unintended consequences, such changes are subject to the necessary competence and local governance of the work product.
• Developing T-shaped skills. Agile Teams develop people with T-shaped skills. This metaphor describes people with deep skills in a specialty area and broad—but not necessarily deep—skills in other areas. T-skills increase the range of issues and opportunities a team member can address.
• Pairing. Pair work doubles the capacity to address the issue and provides better insights into a specific problem that may be blocking progress. It also helps in developing ‘T skills.’
• Swarming. With ‘swarming,’ multiple team members collaborate to accomplish work that a team member may have difficulty completing on their own.

2. Bypass the bottleneck. Bottlenecks are not always easy to resolve immediately at the source. Fortunately, teams likely have other valuable stories in their backlog that other non-constrained people can work on. Selective replanning can increase flow while the bottleneck is being addressed.

It’s also important to note that some root causes of team bottlenecks may be beyond the team’s span of control. In this case, the Inspect & Adapt event is an excellent opportunity to elevate the problem.

#3 Minimize Handoffs and Dependencies

Why it matters

‘Handoffs’ occur when work transitions from one process step to the next. ‘Dependencies’ occur when specific input is needed from another person or a team. While some dependencies and handoffs are inevitable, excessive and unnecessary dependencies and handoffs disrupt team flow, create delays, and increase context-switching and overhead.

What to do about it

• Organize around value. SAFe Principle 10 – Organize around value, provides the primary constructs for minimizing handoffs and dependencies. Effective team topologies help by reducing the cognitive load placed on the team.
• Make handoffs and dependencies visible. Teams must understand what they are, the pattern in which they occur, and the impact they create.
• Take corrective action. Corrective action may be evident from the context of the dependency. Such action often requires changes to the process, the design of the system under construction, the individual work product, or the organization or skills of the teams themselves.

#4 Get Faster Feedback

Why it matters

Solution development is critically dependent on the feedback needed to guide the team’s work. When feedback is missing or delayed, misunderstandings accumulate quickly, leading to rework, slow delivery, and unsatisfied customers. Generally, two types of feedback are required, ‘building the right thing’ and ‘building it right’ as illustrated in Figure 3.

What to do about it?

• Determine what types of feedback are missing or inadequate. Different forms of feedback provide distinct answers to various questions. Are the priorities right? Will the architecture support the functionality? Will the customer be able to use the product?
• Shift reviews left. All work products should be peer-reviewed as early in the cycle as possible. However, there can be a natural tendency for individuals to want to get their work to a state of completion before showing it to others. But this can create over-investment in unproven designs and a defensive posture by the author. Apply transparency. Shift reviews for all WIP left.
• Demonstrate working systems. SAFe has events for getting fast feedback. The most basic example is the System Demo that occurs every two weeks. It creates a discipline for validating core assumptions.
• Frequently integrate and engage with the customer. Frequent integration provides critical feedback concerning the current implementation approach. Also, providing customer access to the current product increment in a staging environment can provide early important feedback.

#5 Work in Smaller Batches

Why it matters

Working in large batches of stories, tasks, and other activities leads to delayed feedback, significant rework, and high variability. Teams have many different types of batches in their flow system:

• Integration batch (how much functionality can the team develop without integrating with others?)
• Testing batch (how much functionality can the team create without systematic testing?)
• Architectural batch (how much architectural enablement can be created without validating user-facing features?)
• Customer feedback batch (how much functionality can be implemented without customer feedback?)
• Deployment batch (how much functionality can be implemented without deploying and testing it in the production environment?)

What to do about it

• Use recommended cadence and team size. SAFe structural guidance helps keep batch sizes small. Adhering to short PI and iteration lengths makes batch sizes smaller. In addition, the optimum size of ARTs and teams automatically imposes a limitation on how much work can be processed at a time.
• Adjust the process to support smaller batches. If a specific batch remains too large, reducing it may require adjustments to planning and execution. It may also require context-specific changes to reduce the effort in processing the batch.
• Ensure proper enablement. Reducing batch size often creates a higher number of smaller transactions. Optimizing and reducing the batch size usually entails planning and executing enablers to refactor architecture and infrastructure

#6 Reduce Queue Lengths

Why it matters

Queues occur when there is a committed backlog awaiting implementation. The longer the queue, the longer the wait time for the new functionality.

What to do about it

Teams generally have some direct control over the length of each queue. They can make queues shorter with various mechanisms:

• Flow measures like velocity and load (see below) help the team commit to only their available capacity. PI objectives help teams limit commitments beyond that scope, ensuring that the queue for new work is not much longer than a PI
• Short iteration time boxes and concise iteration objectives also bring focus to near-term work
• Informal or formal requests for additional work should be directed into the backlog to keep queues shorter

#7 Optimize Time ‘In the Zone’

Why it matters

Solution development relies heavily on creativity, focus, and the intellectual effort of team members. For example, implementing a new software feature requires a developer to navigate hundreds of intricate dependencies between different parts of the code in a way that is uniquely related to the component under development. The ‘zone’ is a highly productive mental state that takes time to enter and sustain.

It may take up to 15-20 minutes for a person to fully immerse themselves in the context of their work, and a simple external factor may instantly interrupt it.

What to do about it

Several factors make it difficult for individuals and teams to reach and sustain an optimal time in the zone. These include excessive WIP, excessive meetings, frequent context switching, interruptions, inadequate development tools, and CD Pipeline infrastructure.

Ensuring that these factors are resolved is an essential task for every leader and coach. The following can help to increase time in the zone:

• Optimize meetings and events. Teams should evaluate the efficiency of all work sessions. A team may discover, for example, that it remains more productive when the team members interact with each other informally throughout the day vs. a cadenced-based event (for example, the daily standup). Others find scheduling regular synchronization meetings add cadence to communication and minimizes interruptions. Teams should periodically review all their meetings to understand the necessary ones and the required attendance.
• Limit work-in-process further. Context switching is often a result of too much WIP. Less active items at any given time mean fewer interruptions of work.
• Use innovative collaboration patterns. Being in the zone does not imply working in isolation from others. Practices like pair work and mob programming can increase in-depth immersion and focus.
• Improve work product health. Teams need to maintain a healthy code and asset base; otherwise, it takes more work to evolve and maintain the system efficiently.

#8 Remediate Legacy Policies and Practices

Why it matters

It’s appropriate for those leading a transformation to want to leverage what’s new. Far too often, however, leaders often wish to keep what’s old. Some of these new and old practices are incompatible (design evolves vs. design upfront) and put teams in a difficult predicament. Either pretend to conform to mutually conflicting policies and reduce transparency or fight the system while development is in process, slowing progress and creating internal friction. In any case, they inhibit flow through the system and put the entire enterprise in half-Agile mode.

What to watch out for

The first thing is for leaders and change agents to recognize that legacy policies and practices are likely to persist—even with top leadership support for the Lean-Agile transformation. Some examples follow:

• Traditional project and program management (for example, Earned Value Management, Work Break Down Schedule, Integrated Master Schedule, and project cost accounting) on top of Agile team practices
• Keeping management status reporting in place when the system has moved to transparency and objective evidence
• Having developers maintain their old timesheet and recording work in their Agile Lifecycle Management (ALM) tooling results in duplicate reporting
• Requiring, for example, documenting design specifications, mandating traceability of non-critical code, and other practices not required by regulation because ‘we’ve always done it that way.’
• Forcing root cause analysis and documentation on every defect, as opposed to finding, fixing, and forgetting
• Separating developers and testers and V&V teams for ‘separation of quality concerns’ when not mandated
• Subjecting teams to legacy phase gate reviews
• Required managerial review of artifacts and tasking micro-management
• Compensation and performance policies that reward the wrong kind of behavior
• Collecting and using metrics across teams as performance measures

What do about it

Unfortunately, this is nowhere near an exhaustive list. Leaders, Scrum Master, coaches, and SPCs should constantly look for these and other impediments to flow. The LACE should deal with known issues as part of the transformation roadmap. Newly discovered legacy practices and policies that cause impediments or extra work should be taken care of immediately.

Measuring Team Flow

It is hard to improve what isn’t measured. SAFe’s Measure and Grow guidance provides three measurement categories—Competency, Flow, and Outcomes—that can assess and improve an enterprise’s ability to deliver innovative business solutions quickly. This guidance includes six measures specific to flow: flow distribution, velocity, time, load, efficiency, and predictability. Flow velocity and distribution are particularly relevant to team flow and are highlighted below.

Flow Velocity

Figure 4 illustrates an example of a team’s flow velocity. In this example, the newly formed team has unstable velocity early on but sees some higher throughput. However, they later discovered that those stories didn’t integrate well into the broader system or perhaps did not meet all the NFRs. In other words, they weren’t indeed done.

The appropriate response is to tighten the Definition of Done (DoD) to a higher quality level. Doing so triggers lower delivered velocity, but each story has higher quality. Over time, teams sort it out and move to a more stable, higher quality, and higher-performing state. As noted earlier, quantitative data should be combined with qualitative data to interpret the information correctly.

For example, a velocity change can indicate an actual increase or decrease in a team’s underlying productivity, and it usually is. But it could also reflect a move to a new business domain or technology stack or an effort to shift to smaller work items to improve flow.

Equally importantly, these measures cannot be used to compare Agile teams. Each team’s local context can be different. Any attempt to set specific targets or use velocity as a performance measure will fail to cause improvement and may even have the opposite effect.

Flow Distribution

Figure 5 illustrates an example of a team’s flow distribution, showing the various types of work items present in the system, as measured at each PI boundary.

Generally, the balance of work items is indicative of team and system health. In this case, it looks like a significant investment in architecture (enablers) was required to eliminate some tech debt or support some upcoming new kinds of functionality. However, these measures can also vary dramatically from team to team, based on each team’s context and responsibilities. For example, some teams will have high maintenance responsibilities for current systems; others may be doing all new development.

In addition to velocity and distribution, the additional SAFe flow measures of flow time, load, efficiency, and predictability are equally valuable to the teams. As noted earlier, quantitative measures should be combined with other qualitative insights. Judgment is always required.

Last updated: 9 December 2022