Tag: scaling agile

This post is the first in a series about success patterns for large solutions.

When applying the Scaled Agile Framework® (SAFe®) to large, complex, cyber-physical systems, we have discovered a pattern called solution areas to manage the complexity. A solution area is made up of two to four Agile teams that collaborate daily to solve problems together. A solution area is neither a fixed organizational structure with given roles, events, and artefacts, nor another scaling level between Agile teams and Agile Release Trains (ARTs). Instead, it dynamically adapts to the given work. This solution area pattern is an example of a paradigm shift toward a much more dynamic form of agility. And this shift requires development of organizational skills, as we will explain in this blog series.

Revive the Feature Team Idea

In Agile development, we often speak about feature teams as an important pillar in Agile organization design. The idea of a feature team usually means that a single Agile team has all the skills and tools necessary to produce meaningful end-customer value on its own. This is often hard to achieve when hundreds of engineers must work together to create a complex cyber-physical system.

In such an environment, Agile teams have so many dependencies between them that a single team can hardly produce end-customer value alone. When producing only a portion of an end-customer value, it becomes hard for single Agile teams to pursue meaningful objectives on their own. Changes to their team goals can therefore only be made with the consent of other teams because these changes could potentially impact the other teams’ work.

As a result, a key motivator of why we introduced agility in the first place is lost. We are no longer able to react quickly to learnings and changing requirements, as the effort to recreate alignment between the teams can be considerable. In such an environment the communication efforts are eating up a non-negligible part of the team’s capacity, the result of which is a loss of focus on value and the pivots necessary to achieve it. A typical pattern that arises under these circumstances is ‘spoon-feeding teams.’ For example, in the backlog refinement meetings before Program Increment (PI) Planning, work items are prepared to fit the skill sets of certain teams. The result is that only a specific team can handle a specific work item, thus locking teams into big up-front design.

Solution areas can often solve this problem. Two to four teams collaborating daily, in many cases, can have all the skills and tools necessary to pursue meaningful objectives and produce real end-customer value together. On the one hand, they’re often big enough to take on responsibility for substantial changes to the system, and on the other hand, they are small enough to react quickly to learnings and changing requirements. With the right communication and collaboration structure, solution areas can revive the feature team idea one level higher in the form of feature solution areas.

Self-Organize around the Flow of Value

One of the most important design criteria of a solution area is that the communication and collaboration structure is dynamic and tailored to the objectives of the teams. By introducing solution areas, we don’t want to establish an additional scaling level between Agile teams and ARTs with a set of fixed events, roles, and artefacts. A solution area is like a collection of boundary conditions within which the teams can organize themselves around the flow of value according to their needs. To give you an example, we take a closer look at the synchronization of the events.

Suppose we have four Agile teams in a solution area with the same iteration cadence of two weeks. Every team has an iteration planning at the start of each iteration, daily stand-ups on each working day, and an iteration review and retrospective at the end of the two weeks. A first step in establishing a solution area would be to synchronize each of these team events among all the teams, as illustrated in a 3×3 matrix.

Using this matrix, the teams try to find the leanest synchronization mechanism that fulfills the communication and collaboration needs of the four teams. Let’s take iteration planning as an example. One option could be that the product owners are meeting for 30 minutes in the pre-event of the iteration planning to make sure they all understand the solution area’s iteration goals. After that, each product owner goes back to its respective team for the main event where each team plans its upcoming iteration in the next two hours. After that, all teams meet in a big-room event to align and adjust their iteration plans with all the other teams in the solution area. This post-event could be scheduled for another 90 minutes.

Another option could look completely different regarding the sequence of the sub-events and the timing. For instance, the teams may create a first draft of an iteration plan for themselves within a one-hour time box in the pre-event. Then for the main event, all teams meet for three hours to collaboratively create an iteration plan for the solution area. In the post-event, the scrum masters of the four teams come together to talk about resolving impediments and managing any risks that came up.

After creating an aligned understanding of the communication and collaboration needs of all the teams within the solution area, the ART needs to find a constellation that matches these needs with the least amount of meeting overhead possible. Once found, these synchronization mechanisms are not carved in stone. They can change dynamically according to the objectives of the solution area for a given timebox, like a PI. At first, we usually revisit synchronization mechanisms every PI. Over time, the solution area can change its synchronization within a PI if necessary.

Like the events, we can also synchronize roles, artefacts, and collaborations. For each pillar in the House of Dynamic Agility (see Figure 2), we can use similar matrices to create an aligned understanding of what the specific needs are, and which composition best matches those needs.

For example, the definition of done could be changed or refined to represent the type of work (hardware, software, modeling) or the maturity in the progression toward delivery (regulatory compliance items and reviews).

The House of Dynamic Agility helps leadership master this grammar of transformative co-creation while faced with profound disruption. Moving from an output efficiency-centric focus to an outcome customer-centric operating system requires leadership transformation mastery.

Example system

The solution area for spacecraft navigation systems consists of four Agile teams: LiDAR, RADAR, GPS, and Navigation Control. In the PIs or iterations where the individual types of navigation are focused on hardware upgrades, software algorithm improvements, and other items that are encapsulated within those navigation sub-components, these teams will each send a representative to a post-iteration planning event as their only iteration planning coordination. However, in a PI where they are implementing an anomaly detection feature, they will hold pre-iteration planning coordination with a team representative, and each team will hold an individual iteration planning and one big-room post-iteration event to educate all the participants in the navigation solution area.

The test case and results artefacts they create in earlier iterations are draft artefacts as far as the compliance team is concerned. The integration tests conducted in early iterations use models and are focused on navigation only. As they approach formal verification and validation (V&V), the teams in the solution area will closely collaborate and communicate with the compliance teams and formal V&V testers.

Encapsulate Complexity

Another benefit of solution areas is the encapsulation of certain areas of complexity within a large system. Consider a typical cross-functional Agile team. When a software programmer, a database architect, and a tester work together on the same user story, nobody outside this Agile team cares about the dependencies between these team members. In other words, this Agile team encapsulates a part of the complexity of the system.

The same is true for solution areas. As all teams within a solution area are closely synchronized, they also encapsulate a certain part of the complexity, usually a larger part compared to an Agile team, which is aligned to a complex component of the large system. The dependencies between the teams and team members within the solution area are a concern within the solution area only.

Looking at a solution area board, only the dependencies below the thick blue line are of interest to other solution areas, ARTs, solution trains, or suppliers. The dependencies above the thick blue line are managed by the teams within the solution area itself.

This also leads to an important design principle: there should be more dependencies between teams within a solution area than dependencies between the solution area and the outside world. The stronger the collaboration within a solution area, the more cross-functional teams become, which then creates better decision-making.

Maybe the most important aspect of encapsulating complexity is the switch from linear or orderly value streams to unordered or “messy” value streams. Our characterization of “messy” value streams as an enabler for creativity is inspired by Tim Harford’s book: Messy: How to Be Creative and Resilient in a Tidy-Minded World. Within a single Agile team, we usually don’t have clearly ordered value streams. People collaborate with whomever on whatever makes the most sense at that point in time. It could be something planned or completely unforeseen. It could contribute to an iteration goal or a PI objective. Or it could be something that deviates from any planned work, such as investigating a new path or following a new learning.

Especially when creating something new, this creative freedom of a messy value stream can lead to better, high-quality products. With the right synchronization mechanisms tailored to the needs of individual solution areas, the ability to react to unforeseen changes in development can be fast enough to support messy value streams. This establishes a creative environment like a single Agile team at one level higher. 

React Quickly to Changing Value Stream Networks

Forming solution areas around architectural domains helps create better solutions, faster. But what about cross-domain problems? For many large system problems, several domains must work together to come up with satisfying results. These problem spaces often show up like bubbles on top of the architectural layer, meandering around for a while whilst people are working on certain aspects before they are completely solved and vanish. Sometimes problem spaces can be planned for; sometimes they show up completely unforeseen.

With solution areas already in place around architectural domains, a next step could be forming new, cross-domain solution areas which exist only if necessary to address the problem space. These new cross-domain solution areas bring together people or complete Agile teams from different solution areas. They are only temporary, existing from one iteration to several PIs.

Ramping up cross-domain solution areas can be seen as an additional organizational skill on top of the organizational skill of synchronizing Agile teams within a domain-aligned solution area. Management should not decide the structure of new solution areas; the people closest to the problem should. Management only sets the boundary conditions for the self-organization of the people doing the work.  

The goal is to enable an organization to ramp up new organizational structures quickly when needed and ramp them down the moment a problem is solved so that organizational structures can flow around architectural needs.

Find the Sweet Spot for Organizational Learning

Organizational skills that facilitate dynamic agility require training in the form of a focused effort to help parts of the organization identify options, build new structures, and abandon them as soon as the problems are solved.

Like with a professional sports team, this approach needs qualified coaches and an aligned vision of how to play this Agile game. The vision needs to be broken down into moves that team members can master, one move at a time.

A successful approach relies on finding the right level for this training. Single Agile teams are often too small to react on their own in a significant way to changes in the complex value stream networks in which they participate. Yet, ARTs are often too large to change their structures frequently and fast enough. Solution areas have the right size and focus to react quickly and change structures around the flow of value in a meaningful way. The solution area construct is often the sweet spot for organizational learning, replacing organizational structures with organizational skills.

Solution areas are given the language and technology to facilitate the inter-relationship of the system elements (for example, leadership, employees, and customers) as part of the whole ecosystem to which they belong.

Find the Minimum Viable Structure

When striving to build large systems in an Agile way, adding scaling levels on top of each other isn’t helpful. From our experience, the core proposition of the organizational architecture of large systems must be dynamic and tailored to the needs. Stated another way, we must descale before we scale up. We want to have the minimum viable organizational architecture— the bare minimum to satisfy the cognitive, communication, and collaboration demands of the teams involved.

This efficiency goal is not achievable by following a set of fixed roles, events, and artefacts, but only by enabling the teams to dynamically and frequently change their communication and collaboration structures according to the objectives on which they focus. This dynamic agility approach can reduce the impediments to the flow of value, leaving room for innovation and learning when scaling up to large, complex system delivery.

Read the second post in our series here.

About Wolfgang Brandhuber, Project & Team, Inc.

Dr. Wolfgang Brandhuber has been a Scrum Developer, Product Owner, Scrum Master, Chief Scrum Master, and Agile Head Coach in various Agile environments. His passion is large solutions. Since the advent of the large solution level in the Scaled Agile Framework in 2016, he has set up and helped solution trains improve their complex systems. During his 18 years as a professional consultant, he worked over 16 of those in the Agile world and more than nine years with SAFe. Among other certifications, he is a certified SAFe® Program Consultant Trainer (SPCT), a Kanban University Trainer (AKT), and an Agility Health Trainer (AHT).

About Cindy VanEpps, Project & Team, Inc.

From crafting space shuttle flight design and mission control software at Johnson Space Center to roles including software developer, technical lead, development manager, consultant, and solution developer, Cindy has an extensive repertoire of skills and experience. As a SAFe® Program Consultant Trainer (SPCT) and Model-based Systems Engineering (MBSE) expert, her thought leadership, teaching, and consulting rely on pragmatism in the application of Agile practices.

About Malte Kumlehn, Project & Team, Inc.

Malte helps deliver complex ecosystems, people, Cloud, AI, and data-powered digital transformations toward business agility. He pioneers intelligent operating models for portfolios with large solutions as a SAFe® Fellow, advisory board member, and executive advisor in this field. He guides executives in developing the most challenging competencies that allow them to deliver breakthrough results through Lean-Agile at scale. His experience has been published by Accenture, Gartner, and the Swiss Association for Quality over the last ten years.

Learn more about Project & Team.