Solution Areas: A More Dynamic Form of Agility – Agility Transformation

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.

Solution Areas: A More Dynamic Form of Agility
Figure 1: event synchronization 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.

Solution Areas: A More Dynamic Form of Agility
Figure 2: House of Dynamic Agility

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.

Solution Areas: A More Dynamic Form of Agility
Figure 3: solution area board

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.

Solution Areas: A More Dynamic Form of Agility
Figure 4: domains, problem spaces, and solution areas

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.

Chief Scrum Master, and Agile Head Coach in various Agile environments

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.

Cindy VanEpps -  SAFeยฎ Program Consultant Trainer (SPCT)

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.

U.S. Airforce and Northrop Grumman – Using SAFe and DevSecOps for Agile Transformation

Lean-Agile Mindset & DevSecOps in a Multi-billion Dollar Defense System

Share:

How do you achieve unprecedented communication between contractor, government, and stakeholders in a large acquisition?

Northrop Grumman and US Air Force agile transformation leads describe how they have worked together to leverage SAFe and DevSecOps to scale Agile practices to refine requirements, enable customer and stakeholder collaboration, and facilitate technical planning for the Ground-Based Strategic Deterrent (GBSD) intercontinental ballistic missile (ICBM) modernization program. The development occurs under a multi-billion dollar contract involving hundreds of companies and over 10,000 people across the US.

GBSDโ€™s 50-year mission is vital to our nationโ€™s security and adoption of a Lean-Agile mindset is essential to meeting GBSDโ€™s schedule and capability requirements.

Presented at the 2021 Global SAFe Summit, October 2021 by:

  • David Gellen, Agile Transformation Lead for GBSD /Northrop Grumman
  • Micheal Burkhart, Lead for Agile Transformation of the Ground-Based Strategic Deterrent program /U.S. Air Force

Back to: Customer Stories

Next: Kaiser Permanente Customer Story

Telia Finland – SAFe Transformation Journey

โ€œSAFe seemed like a 1-to-1 match for us. Someone had already come up with a model to address our needs, which brought better requirements management, prioritization, governance, and a common language for the entire organization.โ€

โ€”Risto Reinikainen, Head of Lean Agile Center of Excellence, Telia Finland

Challenge:

In the competitive, fast-moving telecom market, Telia Finland sought to deliver more capabilities to customers, but that longstanding waterfall methods kept it from moving forward.

Industry:

Telecommunications

Solution:

SAFeยฎ

Results:

  • 39 percent more capabilities than before
  • 34 percent less cost
  • 94 percent accuracy delivering on commitments for a major rebranding
  • Teams deliver incrementally and more often
  • People are more engaged in and satisfied with their work

Best Practices:

  • Donโ€™t skip training โ€“ Telia trained as many people as possible on Leading SAFe and Implementing SAFe, with many earning SAFeยฎ Agilist (SA) and SAFeยฎ Program Consultant (SPC) certifications. When they hit the critical mass, everything began running more and more smoothly.
  • Get help, especially in the beginning โ€“ Telia engaged partners for training and guidance for the first one to two years to speed up implementation
  • Prepare suppliers โ€“ The company provided way of working documentation (WoW) and training for suppliers
  • Plan ahead โ€“ Do your homework on epics and features, and prepare carefully for ceremonies, especially for PI Planning

The partner that made it happen:


Introduction

Telia is a leading telecom operator in the Nordic and Baltic regions with 21,000 employees and 84.2 billion SEK ($9.46 billion USD) in net sales. Telia Finland is a major player in the Finnish market with operations on mobile, broadband, fixed line, and TV.

Within the country, multiple companies compete for a share of the telecom market. To stay ahead of the competition, in 2011 Telia Finland began a transformation initiative to deliver innovations to customers faster. At the time, the company struggled with infrequent and often delayed releasesโ€”about every nine to 12 monthsโ€”and quality issues, with various groups placing the blame on others.

telecom and SAFe

โ€œThe market, especially in the mobile business, is constantly changing,โ€ said Risto Reinikainen, Head of Lean Agile Center of Excellence at Telia Finland. โ€œTo compete, we have to be very proactive and agile in bringing out cutting-edge offerings.โ€

To that end, individual teams and projects spent several years applying more or less homegrown practices to achieve goals, including improving communication, putting more emphasis on statements of work, better requirements management, and close follow-up of activities. Yet none of these disparate activities produced the results they sought and most projects continued in waterfall.

SAFeยฎ: A Perfect Fit

Driven by an urgent need to change, Telia researched Agile methodologies. When they came across SAFe, it seemed like a perfect fit for their objectives.

โ€œSAFe seemed like a 1-to-1 match for us,โ€ Reinikainen said. โ€œSomeone had already come up with a model to address most of our needs, which brought better requirements management, prioritization, governance, and a common language for the entire organization.โ€

To begin the journey of adopting SAFe, Telia engaged partners such as Scaled Agile Partner CGI for training and coaching. Partners initially trained approximately 100 people on Leading SAFeยฎ. The next natural step was to train Teliaโ€™s own people on Implementing SAFeยฎ. During the fall of 2016, four people earned SAFeยฎ Program Consultant (SPC) certification and began leading training as well..

The company kicked off its first Program Increment (PI) in 2015. Since many within the company had worked with loose Agile concepts previously, most individuals were ready and willing to embrace a more mature framework. Yet, the first few PIs did not go as smoothly as hoped as people were still getting accustomed to the new terminology and method. The structure, however, kept people engaged and with a clearer vision about their roles.

โ€œThe First Planning sessions were more or less chaotic,โ€ Reinikainen said. โ€Epics and features were far too big and not mature enough; routines and tools were missing; some teams were still waterfalling their sprints; and areas such as test automation and configuration management were not ready for Agile operations.โ€

The company applied that experience and devised various steps to prepare people for PIs. They trained as many people as possible on Leading SAFeยฎ with many earning SAFeยฎ Agilist (SA) certifications. To that, they added their own โ€war storiesโ€ to educate team members and give them more insight throughout the training.

To prepare suppliers to join Agile Release Trains (ARTs), Telia created a guidelines document on working with Telia and applying SAFe, and a workshop to reinforce the concepts. Every few weeks, coaches followed up with suppliers to ensure they were working in the new model. The common language of SAFe effectively unified the internal and external team members across locations.

Once Telia reached around 200-250 people trained, Reinikainen noticed a new synergy; people were using the same terminology and applying the concepts more cohesively and naturally. Today, the company has trained more than 400 people. They promote continuous improvement and best practices with Communities of Practice.

An Answer for Complexity: Large Solution Level SAFe

Initially, Telia began with Program-level SAFe, but then moved to Portfolio-level SAFe. More recently, they moved to Full SAFe, including SAFeโ€™s Large Solution level, to accommodate complexity, which includes more than 200 systems, many dependencies, and numerous external suppliers. Particularly, the Large Solution level offers the roles, artifacts, and processes for larger, multi-year projects such as those at Telia.

From Teliaโ€™s perspective, Full SAFe and SAFeโ€™s Large Solution level brought much-needed additions:

telecom and SAFe
  • More transparency to all development activities and resourcing
  • Coordination and synchronization between waterfall projects and Agile Release Trains (ARTs)
  • Control, visibility, and transparency to connect all trains, suppliers, and programs
  • Greater value creation with one prioritized portfolio backlog

โ€œLarge Solution SAFe brought a systematic approach to our complex environment that we definitely needed in order to coordinate our work,โ€ said Nina Pakkanen, a Solution Train Engineer (STE) at Telia.

In Inspect & Adapt sessions at the close of PIs, comments from team members confirmed that the Large Solution level had achieved what Telia anticipated:

  • โ€œLarge Solution Level makes epics more concrete prior to actual implementation.โ€
  • โ€œCapability and feature-level analysis are much clearer now.โ€
  • โ€œTransparency and collaboration with the business has improved a lot.โ€

Additionally, Telia consolidated from seven development portfolios into a single operational one that includes all B2B, B2C, B2O, and channel solutionsโ€”resulting in better visibility into resources, activities, and priorities. Before, the various portfolios competed for the same resources and projects.

Pulling Off a Rebrandโ€”On Time

In 2017, when the company rebranded under the name Telia Finland, SAFe provided essential structure to coordinate the many pieces. Overnight, everything had to be branded with the Telia Finland name, from the website to napkins.

With everyone committed to the goal, they delivered smoothly by the target date. Whatโ€™s more, they did so with 94 percent accuracy on their commitments.

โ€œAt night it was the old name, and in the morning everything was under the new name,โ€ Pakkanen said. โ€œIt was truly a success that we carried out such a big initiative on time.โ€

Delivering More, and More Often

Telia currently runs two Agile Release Trains and two Large Solution Trains with around 350 people. Since moving to SAFe, the company has noted quantitative and qualitative results to show its progress:

  • More capabilities โ€“ The development organization delivers approximately 39 percent more capabilities than before
  • Greater predictability โ€“ Telia has much-improved insight into whatโ€™s coming in the next one to two years
  • Cost reduction โ€“ Telia reduced the price per developed capability by around 34 percent
  • More frequent delivery โ€“ Teams deliver incrementally and more often
  • Higher engagement โ€“ Leaders note that people are more engaged in and satisfied with their work

Such results have helped earn middle management buy-in for the transformation; their commitment has increased in step with results.

โ€œPeople know the old way doesnโ€™t work, and they are now seeing that SAFe is a better approach,โ€ Pakkanen said. โ€œWeโ€™ve demonstrated that, even on the largest projects, this creates more communication, more transparency, and more progress.โ€

Back to: All Case Studies

Suggested Case Study: Swisscom