How do you adapt your organization’s culture so it’s more responsive to customer needs and can compete with emerging alternatives without disrupting what’s working or adding unnecessary layers of complexity—all while undergoing a major paradigm-shifting merger? This was the challenge facing Latin America’s largest stock exchange, B3 S/A Brasil Bolsa Balcao (B3), back in 2019.
Recently, Marcio Tambelini, SPC and Lean Agile Transformation Coordinator at B3, sat down with us at the 2023 SAFe® Summit Nashville to discuss his organization’s journey with SAFe over the past few years. He talked candidly about the challenges that led to B3 considering Agile methodologies, what motivated them to adopt the Scaled Agile Framework®, and their results.
Challenges
Process
Results
Leaders at B3 gather in person to prioritize and align work for the PI as part of the Brazilian company’s multi-year SAFe initiative.
B3 Challenges
Every organization has its own operating culture and norms. In the case of a merger, the challenge becomes combining those norms and establishing a new, unified way of working.
This was the situation facing B3 in 2019. At that point, B3 was two years into a merger that had ushered in a new era of its history. BM&FBOVESPA, a leading regional exchange, had joined forces with CETIP, a merger securities clearinghouse, creating B3. The combination positioned B3 as a key player in Latin America’s financial landscape. But it also created a need for shared values and common goals.
“We had a distance between these areas, and every area had different problems,” said Tambelini.
A growing number of competitors were also emerging in the Brazilian market, putting additional pressure on B3 to deliver new features, capture new markets, and respond to challenges faster and more predictably.
When leaders started exploring options for improving their culture, they were drawn to Agile for its focus on speed and collaboration. They were also interested in SAFe to provide the necessary training for scaling Agile practices.
“We decided that Agile would bring us common objectives and common challenges,” said Tambelini. “This was very important for us because each area had personal problems and personal challenges. So we decided to work together, and Agile methodology was the best way to resolve this problem for us.”
Leaders at B3 gather in person to prioritize and align work for the PI as part of the Brazilian company’s multi-year SAFe initiative.
B3 Process
B3 started small with one Portfolio, using SAFe to guide the adoption of Agile principles at scale. In 2021, after proving the value of the Agile approach, they decided to upgrade to a SAFe Enterprise subscription. This would allow them to make training and resources available to the entire organization and better align the Agile adoption of separate teams.
By 2023, Agile practices had spread throughout B3. They had formed 32 value streams, with 121 Agile teams and more than 1,400 people working in those value streams. They had also begun expanding Agile values beyond development teams and into the operations side of the business.
“At B3, we’re working toward business agility, not just Agile … there are many initiatives in other areas like Human Resources, infrastructure, finance, and others,” said Tambelini.
He said the creation of value streams was particularly important to leaders because before, the various parts of B3 had functioned with different challenges and objectives, making it hard to track progress and align efforts. Value streams enabled them to see how each part of the organization played a critical role in delivering a product or service to the market.
Another way B3 brought teams together was by adopting shared metrics like Objectives and Key Results (OKRs) and key performance indicators (KPIs). They also shifted their mindset from “projects” to “products” to help teams better visualize the customer and focus on the end value delivered.
“This has given us the opportunity to enhance our customer-centric approach, delivering products and services that align more closely with their needs,” said Tambelini.
Leaders at B3 gather in person to prioritize and align work for the PI as part of the Brazilian company’s multi-year SAFe initiative.
B3 Results
Tambelini said the results have been overwhelmingly positive, helping to secure B3’s position as the leading stock exchange in Latin America.
“All the portfolios that we started in the last two or three years had many kinds of good results, especially when we’re talking about the clients,” he said.
One of the biggest benefits has been the ability to deliver value to clients in a much shorter time cycle. Before, delivering a new product or feature could take up to a year. Now, B3 developers can roll out new features for clients throughout the year, much faster than was previously possible.
Within B3’s largest portfolio, which represented 70 percent of their revenue, the challenge had become managing layers of complexity among clients, markets, and regulators. So before proposing any drastic changes, leaders started by mapping out the interdependencies among platforms and teams.
Their initial priority with this portfolio was to bring alignment and transparency to the work. They chose to adopt Lean Portfolio Management (LPM) because they believed that starting at the top and focusing on the financial aspect among leaders and stakeholders would bring much-needed clarity and direction to the rest of the process.
“Our understanding grew, and we identified points of contact and bottlenecks,” said Tambelini. “We proposed value streams that could bring productivity gains and increase deliveries to the clients.”
Instead of budgeting for projects, they began budgeting for products, enabling B3 to increase speed and become more responsive as an organization.
“This action has been instrumental in our evolution, leading to significant gains with both customers and regulators,” he said. “We’re able to respond to new challenges, become more efficient, increase customer experience, and capture new markets.”
“On the development side, they’ve seen shorter cycles, and, in one product release that I know of, they were able to get ten times the expected number of customers,” said Saldivar. “I think they realized the power of SAFe when building new solutions and new products and getting an attractive solution to market.”
B3 Conclusion
B3’s adoption of SAFe has proven highly successful, enabling leaders to overcome merger challenges and dynamic market pressures and begin to operate as one organization. Starting with one portfolio in 2019 and then expanding in the following years, they’ve been able to reduce delivery times and increase the value created. Their story proves the importance of approaching change intentionally, holistically, and with the customer at the center.
Wouldn’t it be great if transformations could go on autopilot?
Unfortunately, despite what we wish for, they can’t. They need strong and resilient teams driving transformations to success.
In this blog, you’ll learn how to set up your Lean-Agile Center of Excellence (LACE) for success. Everything in this blog is from our experiences in the field.
Our story begins at the very first LACE Summit, where we met for the first time. Heads of LACE teams from across the globe were brought together, where we were able to collaborate, exchange ideas, and benefit from each other’s experiences. This took place on October 6, 2022, when Amadeus welcomed Orange, Renault, Vodafone, and Scaled Agile, Inc. to the Amadeus headquarters in Sophia-Antipolis, France.
We left the LACE summit with practical examples of
LACE team setups
Challenges
Pitfalls
Best practices
Recommendations
The event was not only fun but a real eye-opener.
What to Consider When Setting up Your Lean-Agile Center of Excellence
We identified four focus areas when creating a Lean-Agile Center of Excellence:
It’s important to consider your progress in the transformation journey and transformation ambition.
Most LACE teams have a Hub-and-Spoke setup. This includes relays in the organizations they support (SAFe® champions). Most LACE teams include HR and Finance in their decision process and roadmap.
Based on input from other LACE teams, it’s not easy to map a LACE organization. The organization has plenty of connections and direct or dotted links with other groups.
You usually start with a small team of change agents representing different areas. They’re willing to drive the change, experiment, and learn fast. These team members may only dedicate a limited part of their capacity to the transformation at the beginning. But they’re willing to go the extra mile.
Skills in the LACE are global and include R&D, HR, Finance, Product Management, Design Thinking, and Communication. Use external consultants as you develop the skills of your internal change agents at the start of the journey. The goal of these external partners should be to enable your LACE team to drive transformation on their own.
As the scale of your transformation increases, you will also need to scale your team. You may need to create new transformation teams to support simultaneous transformations in different areas (portfolios).
At Amadeus and Vodafone, we use the Hub and Spoke model. This enables decentralized decision-making and concurrent transformation initiatives in different areas. It also brings alignment on important transformation topics with a strong Hub.
At Amadeus, we also have SAFe champions. We nominate these champions and train them on SAFe SPC curriculum. Once trained, they become strong change agents in the organization. They sustain the change in alignment with the LACE support.
The most critical success factor when you start is nominating a strong authentic leader. This leader understands the business and the challenges the company is facing. It should be someone eager to drive the change and with energy and resilience to resolve impediments and roadblocks along the way. Pairing two leaders—one from Business and one from IT—will increase alignment of the transformation from the get-go.
Reporting lines
Since most transformations start in IT, organizations create a Head of LACE position in IT. The role usually reports to the Chief Information Officer (CIO) or Chief Technology Officer (CTO). This underpins the importance of the transformation. It also creates a direct line of communication with executives within the organization.
But, in this case, the Business Executive Sponsor is crucial to the transformation. They enable acceptance of the transformation team in the Business organization. Otherwise, there is a risk that business engagement will lack. People will perceive the transformation as IT only.
At Amadeus, there is a double reporting line of Head of LACE both to the CTO and a dotted line reporting into HR. This double reporting enables the LACE to dig into engineering perspectives. It also gives them a transversal mandate to guide the people and culture evolution.
Agile Coaches usually report to one line organization led by the Head of LACE. This ensures
Alignment
Consistency of implementation approach
Fast upskilling
Knowledge-sharing
It’s important to note that a successful LACE is a collaboration, not a line organization. The LACE needs more cross-functional and cross-departmental capabilities. These capabilities anchor the change in the organization.
Diversity of capabilities
Depending on your transformation goals and environment, you’ll need different skills and capabilities. Your transformation will evolve. This means your required skills and capabilities will also evolve. New challenges and impediments will come up.
A typical LACE team can include the following skills and capabilities:
Agile Coaching and Training
Agile Methods and Tooling
Change Management and Communication
Design Thinking
DevOps
Representation of Finance, HR, line managers, and change agents
In a regulatory and compliance environment, include the following experts in your LACE team:
Tooling
Compliance
Process
Prioritization process
Transformation requires focus. Change agents and change champions have jobs that keep them busy. Other priorities get in the way. Transformations can feel like you’re changing tires on a highway at full speed.
To counterbalance conflicting priorities, try the following:
Upfront investment in alignment
Involving line managers of your change agents
Negotiating transformation goals as part of yearly performance goals
A small team of dedicated SPCs can speed up your transformation. When you start to scale on an enterprise level, the impediments will get bigger and harder to address.
At Amadeus, the LACE runs the transformation. They use SAFe Lean Portfolio Management (LPM) for prioritization. They use an Agile Release Train for the execution.
A Strategic Portfolio Review (SPR) drives the transformation LPM. The SPR includes executives from all business units. These executives share:
Priorities
Roadmap
Major achievements
Impediments where the LACE needs top management support
Amadeus holds the SPR quarterly.
They also organize bi-weekly Portfolio Sync meetings. These meetings include executive representatives. They address Epics and operational progress of the transformation train.
Some of the SPR members are also Business Owners of the transformation train. This generates better alignment and valuable discussions with the team members.
Prioritization at Amadeus
Lean-Agile Center of Excellence Challenges and Tips
The Lean-Agile Center of Excellence will face challenges throughout the transformation journey. The following two challenges are particularly critical to overcome.
Executive engagement
Transformation ownership
Challenge 1: Executive engagement
Transformation is not a sprint but a marathon. It’s not enough for executives to give their buy-in at the beginning of the transformation. They shouldn’t expect business results with minimal effort.
Many transformation teams struggle to get continuous executive engagement needed for sustainable change.
To keep executives engaged, always start with the WHY. Define the clear business outcomes you want to achieve. You don’t need to get engagement from all executives at once from the very beginning. Start with one. Build trust. Show quick incremental improvements, and let them become your biggest advocate.
Challenge 2: Transformation ownership
As the LACE team, avoid becoming a ‘Doctor’s office’. People should not come to you for quick pain relief and fast results with the least effort. With this method, if something is not working, it immediately becomes your fault.
Ownership of the transformation and business results should stay in the delivery organization. The LACE team is an enablement team. They partner with different business areas to
Become a catalyst of change
Drive continuous improvement culture
Help address roadblocks on the way to success
Tips for solving these challenges
Here are some tips for solving the two challenges mentioned in the previous section.
Engage your executives in your roadmap
Train executives. Coach them. Involve them in the planning through retrospectives, system demos, and other formats.
Why is this important?
You’ll need their support to get everyone on board. Then you’ll need their approval (and even more so, their sponsorship) to implement changes in the organization.
Don’t get out of breath
You are of no use if you run out of energy. Take time with your work. Make sure your teams have the right workload to avoid feeling like they’re gasping for air. Don’t be too wrapped up in meeting your own goals and forget to engage your team.
Changing for the sake of change won’t be enough for your teams
People need a compelling reason to change. Engage colleagues by building a vision and defining a burning platform. We’ve seen this work in many transformation journeys.
Change agents should work as a team and support each other
Organizational transformation is tedious work, and it is not a one-person job. Use PI (Planning Interval) planning to align priorities. Ensure the team works toward the same objectives.
Celebrate success together as a team and boost motivation
Short-term wins encourage team members to be more engaged and positive about the work.
Some people believe SAFe and agility are for technical people, like engineers. But this is not always true. Practicing Agile ways of working means planning work and delivering value based on the customer’s wishes. By this, all aspects of a company should be Agile.
So, your transformation team needs representation from everywhere. This includes business, HR, Finance, Procurement, and more. They will be your change agents in different areas of the business.
A Checklist to Keep Your LACE on Track
Setting up a LACE team can be overwhelming. Oftentimes, as an internal team, you may only have one chance to get it right.
Here’s a checklist based on experience from the trenches to help your LACE team get it right on the first try.
1. Design a purpose-driven transformation that ensures continuous executive engagement.
Secure a transformation sponsor at the executive level
Define common objectives (OKRs) with your sponsor
Connect to strategy and define transformation narrative
Involve executive leaders in prioritizing the LACE backlog of transformation initiatives
2. Define and evolve your LACE vision/mission, transformation scope, capabilities needed, and your operating model.
Host a LACE Kickoff to define your vision, mission, ways of working, initial scope, and metrics
Ensure nomination of HR and Finance representatives and establish a good mix of Business and Technology representatives in your LACE team
Co-create transparent rules of engagement between your LACE team and transformation the initiatives you’re supporting
Join forces and connect with the strategy team in your organization, Cultural Center of Excellence, or Digital Transformation office (when applicable) to support broader enterprise transformation and cultural change
Drive alignment on vision, mission, and why story when you scale across the organization and make your transformation inclusive to all transformation teams
3. Invest time in communication, focusing on different and sometimes unique needs of stakeholders. Remember, there is no successful transformation without successful communication.
Create an engaging communication strategy and communication plan for different target groups
Experiment; be bold and creative
Promote transformation stories, testimonials, and learnings in different formats (e.g. regular demos, newsletters, videos, podcasts, etc.)
Organize regular Agile events or internal Agile conferences to bring your transformation stories to life and connect change agents and enthusiasts in the organization
Don’t forget that executives represent a crucial communication target group; invest time in understanding their communication needs
4. Adapt to change, scale with alignment, and measure success.
Evolve your transformation scope over time and adjust your LACE capabilities depending on the current focus area of transformation
Scale transformation with SPC Champions in different areas and connect them via Community of Practice to drive excellence, community spirit, and pride in driving transformation together
Measure NPS of your LACE team for different transformation initiatives you are supporting
Additional LACE Resources
If you’re interested in setting up and driving a successful LACE, we would love to invite you to the next edition of the LACE Summit. It will be planned at Amadeus Sophia-Antipolis, France in October 2023. Join us to hear and share about your favorite topic. Stay tuned!
Sandra Bellong, Head of Lean-Agile Center of Excellence at Amadeus, is a senior people manager, project manager, and Agile/SAFe specialist with a strong background in business analysis and development design. She is a dynamic, engaged, and motivated actor in Agile transformations, process and methodology improvements, and always in the scope of high customer satisfaction.
Alena Keck, Head of Lean-Agile Center of Excellence at Vodafone, is passionate about helping large global companies reach the full potential of business agility and overcome challenges of Agile transformation at scale. Her mission is to be a strong change agent who creates strong transformation teams and growing Lean-Agile leaders. Her motto is “Transformation is a Team Sport.”
It’s incredible that the Scaled Agile Framework® (SAFe®) is now 10 years old, and the Agile Manifesto is now over 21 years old. What began in software development is now expanding to encompass the entire enterprise, changing how people work and how every aspect of business is run.
In the last few years, the COVID-19 pandemic has accelerated the need for and execution of digital transformation. Yet, many organizations are still struggling to get business results from their investments or haven’t made them at all.
To compete in this new era, these companies must look at agility as a core business competency. Many of these traditional organizations are looking for a playbook they can follow as they embark on their agility journeys. In my experience, organizations come from one of the following contexts:
The organization has done a successful pilot (typically with a small number of Agile teams) and now wants to scale to the rest of the business unit or line of business (which is NOT yet Agile)
An organization wants to implement SAFe to address its defined burning platform
A consultant has done an assessment and recommends initiating an Agile transformation
Some combination of the first three
Regardless of an organization’s starting point, it’s important to understand the current state of transformation and validate assumptions with due diligence before creating a path forward.
Before beginning, perform due diligence
For a transformation to succeed, it’s crucial that organizations articulate the “why” tipping point for their journey before they begin. In addition, it’s important for organizations to gather data points to validate any success patterns they have experienced using the SAFe Implementation Roadmap. Some of the questions to ask regarding this due diligence (in no particular sequence) include:
What change agent and team member training is completed and planned?
What is the current state of the foundational building block (Agile team)?
Which steps of the SAFe Implementation Roadmap have been completed?
Answers to these powerful questions bring organizations clarity about the purpose for their transformation and alignment through awareness of their true current state.
Kick-start the Transformation with This Approach
Various factors influence the decision to move forward with a SAFe implementation. For more traditional organizations with a waterfall or hybrid mindset, unaligned ways of working, and inconsistent terminology interpretation, the below transformation approach can help shape their paths.
Create and measure a maturity baseline
Having a simple maturity model without new terminology is crucial, and organizations should define one that works for their context. HCL Technologies, a next-generation global technology company, designed a maturity model (see Figure one) to set a baseline in a traditional organization, business unit, or line of business. This model, which can be tweaked given the client’s context, captures key characteristics of an organization on various dimensions.
Figure 1. Organization Maturity Model example
Keep in mind that in many situations, assessment “fatigue” is also real. So it’s critical to design and administer maturity measurements effectively with minimally invasive approaches, including the right combination of:
Interviews (one-on-one and/or in group settings)
Observations from attending various meetings
Simple assessments (eight to nine questions)
Putting it into practice: evidence from the field
HCL requested to lead the transformation for a client in the health industry using a hybrid SAFe methodology. The client organization had six ARTs and over 400 people involved in development, testing, and support. By conducting role interviews (Architect, RTE, Product Management, executive leadership, and so on) at various levels of the organization, HCL gathered the necessary data points to set a baseline for the client’s maturity level.
HCL also conducted 18 detailed, one-on-one interviews and observed several ongoing meetings and events for three weeks. They used a similar maturity model to Figure one, which helped establish alignment for priority and focus areas.
When another client organization in the pharmaceutical industry assessed the workforce enablement dimension of its current state, it found no or inconsistent use of tooling. Upon discovering this, leadership aligned and identified tooling as an opportunity and key enabler for the company’s digital strategy execution.
Script the critical moves
With relevant data points from baseline measurements, highlight the bright spots and rationalize target maturity level with relentless socialization for buy-in and alignment. Defining building blocks, or pieces of work, is the next key element in this approach, with categories like:
Organizational readiness
Content readiness
Logistics and planning event readiness
Enablers
Putting it into practice: evidence from the field
One of the crucial aspects of making this approach palatable for the health industry client was meeting the client where they were. Providing maturity model dimensions mapped to proven PI readiness success patterns helped accomplish that and reduced the cognitive load of transformation change because the client didn’t have to learn new terminology.
Data points from the maturity assessment findings helped the client prioritize specific readiness aspects before the first PI Planning event. Here are some examples of these readiness aspects:
Case for change and communication strategy (organization readiness)
Capacity allocation for various work types (organization readiness)
Capacity allocation of subject matter experts for enablers (content readiness)
Team topology at the ART and team levels (organization readiness)
The transformation team at the pharmaceutical client’s organization prioritized standardized tooling by implementing Jira Align at the enterprise level. This tool provided a central location for all work and enabled visibility of all work types.
Shrink and scale the change
After the building blocks are designed, the next key element is to “shrink the change” to reduce business disruption. Building blocks provide the opportunity to shrink change and make it more digestible. Initial success as small as one ART motivates the broader organization and provides a blueprint for replication.
Design building blocks in a way that provides the flexibility to shrink change first and scale from one ART to multiple ARTs or from Essential SAFe to Full SAFe later. Based on complexity, baseline maturity level, solution size, and development value stream(s) involved, the organization can establish either:
Eight to 12 weeks of runway preparedness (see 10 weeks translated into five iterations in Figure two) or
Eight to 12 weeks of executing a readiness plan before the first official planning event launch
Figure 2. Mapping Maturity Model Dimensions to Scalable Building Blocks for PI Readiness
Putting it into practice: evidence from the field
After prioritizing readiness building blocks for organization readiness, content readiness, and enablers, it took 10 weeks for the health industry client to create and socialize the readiness plan and align stakeholders. It took an additional 10 weeks to implement the plan. Once this client implemented backlogs and boards to visualize their work, they experienced improved coordination and dependency management and better visibility and transparency across ARTs.
Before implementing Jira Align at the pharmaceutical organization’s enterprise level, the organization’s transformation team developed an implementation roadmap, which included multiple rolling wave phases across the program and portfolio.
Experience Benefits without a New Language
While there is value in using SAFe toolkits and resources, those require an understanding of SAFe terminology. For traditional organizations that prefer to begin their transformation journey without learning a new language, the steps outlined above have generated desirable outcomes with reduced risk.
Putting it into practice: evidence from the field
As a result of this transformation approach, the healthcare client experienced the following positive business outcomes:
A single solution backlog across all ARTs of the solution train, a focus on enablers, and improved overall flow
Improved defect resolution lead time by 35 percent
Changes in value delivery and ways of working, specifically a QA shift left, resulting in quality improvements of 27 percent in lower environments
Crucial data points to strengthen the business case for traditional software development life cycle (SDLC) to move toward Agile SDLC through lean governance and process automation for better user experience
The pharmaceutical client experienced the following positive business outcomes from its enterprise-level Jira Align implementation:
Agile teams supported in capacity allocation, overall planning, and road mapping activities
Predictable delivery with fully aligned organizations across every level of scale
Aligned strategy through a federated, unified platform spanning program, product, portfolio, and development team layers (level of scale)
This transformation approach can be customized to fit other use cases with simple tweaks. Read my next post (coming soon) to learn more about other use cases.
About Bharat Shah
Bharat Shah is an SPCT candidate, certified architect, and trainer who has trained over 800 participants in Lean-Agile and DevOps transformation. He is passionate about digital business and driving enterprise-scale business agility journeys.
About Tracey Orphey
Tracey Orphey is a SAFe-certified Release Train Engineer and PROSCI-certified Change Practitioner with an extensive background in digital transformations and Agile programs. She is known for her authentic and forthright approach to cutting through the noise of transformation and has successfully managed change and training programs across various industries.
This post is the second in a series about success patterns for large solutions. Read the first post here.
Backlog refinement is integral to the Scrum process because it prevents surprises and maintains flow in iterative development. Regular backlog review ensures the backlog is ready for iteration planning. An Agile team understands how much they still need to refine the backlog items before the next iteration planning and beyond.
When applying SAFe®to large, complex, cyber-physical systems, you must expand backlog refinement to include more viewpoints. The complexity of a large solution is rarely fully comprehended by one or a few individuals, and the size of the large solution exacerbates the impact of risks that can escape into large solution planning.
So how do we find the balance between overpreparation, which limits ownership and innovation by the solution builders, and under-refinement, which can undermine the solution and the flow of value delivery?
To answer these questions, we adapted the following success patterns for large solution backlog refinement.
Use the Dispatcher Clause
The dispatcher principle guides large solution refinement by preventing the premature dispatch of requirements to Agile Release Trains (ARTs), solution areas, or Agile teams. Premature dispatching can cause risks like:
• Misalignment in the development of different solution components • Missed opportunities for economies of scale across organizational constructs • Sub-optimization of lower priority solution features
In contrast, making the right trade-off decisions at the right level drives holistic and innovative solutions.
Key stakeholder viewpoints that are often overlooked include marketing, compliance, customer support, and finance. Ensuring these voices are heard during refinement work can prevent issues that might remain undetected until late in the solution roadmap.
For complex solutions, we discovered that a planning conference is more effective than pre-and post-PI Planning events alone. This event mimics a PI Planning event and is intended to align upcoming PI work across ARTs and solution areas. To keep the conference focused and productive, it should only include representatives from the participating ARTs. We will cover specific planning conference details in a later blog post.
The goal of the planning conference is to provide a boundary for the large solution refinement work. Preparation for key decisions that can be made in the planning conference should be part of the refinement work. But making key decisions is part of the planning conference. However, key stakeholder inputs that cannot be reasonably gathered during the planning conference should be included in the refinement work.
For example, in Figure one, a review of the key behavior-driven development (BDD) demo and testing scenarios by a customer advisory board is valuable input in refinement. The customer advisory board will not attend the two-day planning conference, so their advance input provides guardrails on the backlog work that’s considered.
Agree on the Definition of Ready
The definition of the readiness (DoR) criteria for a large solution backlog is often multidimensional. Consider, for example, the architectural dimension of the solution. The architecture defines the high-level solution components and how they interact to provide value. The choice of components is relevant to system architects in the contributing ARTs and stakeholders in at least these areas:
• User experience • Compliance • Internal audit and standards • Corporate reuse • Finance
Advancing the backlog item—a Capability or an Epic—through the stages of readiness often requires review and refinement from the various stakeholders.
Figure one is an example Definition of Ready Maturity Model. It shows the solution dimensions that must be refined in preparation for the solution backlog. Levels zero to five show how readiness can advance within each dimension. The horizontal contour lines show that progression to the intermediate stages of readiness is often a combination of different levels in each dimension.
Figure 1. Definition of Ready Maturity Model example
This delineation is helpful when monitoring the progression of a backlog item to intermediate readiness stages on a Kanban board.
The key to balancing over-preparation and under-refinement is to distinguish between work that an ART or solution area can complete independently without a high risk of rework. For example, final costs could be prohibitively high without a Lean business case to scope the solution. Another common high-risk impact of under-refinement is unacceptable usability caused by the siloed implementation of Features by the ARTs.
The Priority BDD and Test Scenarios in Figure one represent how features are used harmoniously. These scenarios provide guardrails to help ARTs prioritize and demonstrate parts of the overall solution without significant rework of a PI.
Identifying the dimensions, levels, and progression of readiness is a powerful organizational skill for building a large solution.
Leverage Refinement Crews
Regular large solution refinement is necessary to ensure readiness. The complexity of a large solution warrants greater effort and participation than Solution Management can cover. And the number of key decisions grows in direct proportion to the size of a solution.
Our experience shows that roughly 10 percent of those who participate in large solution development should participate in a regular refinement cadence. If the total participation is 450 people, then 45 representatives from across ARTs or solution areas should set aside time for weekly refinement iterations.
Backlog refinement for a large solution requires more capacity than a typical backlog refinement session. The refinement crews determine a cadence of planning, executing, and demonstrating the refinement work. One-week iterations, for example, help drive focus on refinement to ensure readiness.
We also discovered that refinement crews of six to eight people should swarm refinement work within iterations. These groups are usually created based on individual skills and their representation within stakeholder groups. Alignment with crews and dimensions or skillsets is determined during the planning of refinement iterations. The goal is always to move the funnel item to the next refinement maturity level in the next iteration.
Our experience says that each refinement crew requires at least three to four core participants. The other crew members can come from stakeholder organizations outside the Solution Train.
Readiness progress must be reviewed on a regular cadence with solution train progress. Progress can be represented in the Solution Kanban between the Funnel and Backlog stages, as shown in Figure two. In our example, these stages replace the Analyzing state provided as a starting point in SAFe.
Figure 2. Refinement Stages in Solution Kanban
The organization must also allow each refinement step to vary over time, as it makes sense for the solution. For example, as the development of the solution progresses toward a releasable version, the architecture should stabilize. Therefore the readiness of the backlog item in the architecture dimension should progress very quickly, if not skip some readiness steps. As solutions approach a major release, the contributors’ capacity can shift from readiness to execution of the current release or readiness for the next release.
Because refinement happens in a regular cadence of iterations, weekly, for example, the refinement crews should be empowered to make these decisions in refinement iteration planning.
Employ Dynamic Agility
So is there a definitive template of dimensions with levels and a step-by-step process for determining the DoR? Not quite. And we don’t think that a prescriptive process is best for most organizations.
Instead, we advocate for using the organizational skill of dynamic agility.
As the size and complexity of a solution grow, so do the number and type of variables: compliance type, hardware types, skills required, size of the development organization, size of the enterprise/business, specialization of customer types, and so on. This complexity is augmented by company culture challenges, workforce turnover, and technology advancements in emerging industries.
Individuals’ motivation and innovation suffer when they get lost in the morass of complexity. When things don’t get done, more employees are added to help fix the problem. This workforce growth only magnifies the complexity again.
In contrast, the organizational skill of dynamic agility stimulates autonomy, mastery, and purpose for individuals within teams, teams-of-teams, and large solutions.
Consider the House of Dynamic Agility represented in Figure three.
Figure 3. House of Dynamic Agility
How can dynamic agility be applied to large solution refinement? DoR identification and maintenance of its dimensions and levels happen through a regular cadence of the right events. How often should these occur, for how long, and who should attend? What elements will represent and communicate the DoR? What roles are best suited to own and facilitate the management and use of DoR over time? How will collaboration across the organization happen most efficiently for maximum benefit? These questions are best determined in the context of the large solution.
Conclusion
Large solutions require a balance of preparation and execution to achieve an optimal flow of value. Conducting backlog refinement in preparation for a large solution planning conference and PI Planning lets decomposed work items be implemented without risk of rework. Avoiding over-specification in refinement allows ARTs to innovate and accomplish within the guardrails of refinement. Enabling large solutions to leverage dynamic agility builds ownership, collaboration, and efficiency in a large-scale endeavor.
Look for the next post in our series, coming soon.
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 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 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.
It was May of 2012, the year that the Mayan calendar said the “great cycle” shall come to an end. And with every cycle comes a new cycle. This new cycle was the beginning of an evolution of knowledge, sharing, and learning around how society builds the world’s largest systems.
For those of you who’ve followed the history of the Scaled Agile Framework® (SAFeⓇ), you’ll remember that the book Agile Software Requirements had just been published in 2011. And you’ll also recognize this book as the foundation and initial version of the Scaled Agile Framework. Just open the front cover and you’ll find Dean Leffingwell’s initial “Big Picture” rendition of the Framework. The book itself was fueled by Dean’s 2007 — 2008 blog series, where he published the initial articles and concepts within Scaling Software Agility and Agile Software Requirements, both books that helped move the market.
The book unfolds the “why” behind the Framework. Dean discerns that to scale agility, an aspect of Lean is requisite. He further goes on to state that Lean is required to scale agility because of its focus on value streams, principles, and tools that enhance value delivery to customers and its elimination of waste in the development process. You’ll also recognize the influence of Don Reinertsen’s Principles of Product Development Flow as some of the early concepts within the Framework. What you may not know is that the publication of Don’s book caused Dean to go back to the drawing board and rewrite his book.
And for those who know Dean personally, you know that respect for people and culture is a passion of his that continues to be prevalent in Lean as well as in SAFe.
Now, while writing and sharing the book was clearly an affection of Dean’s, taking the knowledge and research in the book and translating it into a learning experience was also a passion. Today marks the anniversary of the first Scaled Agile Framework Certification class!
#1 SAFe Program Consultant Certification, May 25, 2012
Roughly 30 curious agilists attended the first SAFe® Program Consultant (SPC) certification. The course was a bootstrapped effort, invite-only. I remember Dean personally reaching out to those who had leveraged the early concept of SAFe.
At the time, I was a product owner. I was honored when my Lean leader said “yes” to funding and allowed me the time and opportunity to learn and evolve my knowledge of my role and how to better scale and build systems that our customers needed.
Taught based on V0.94 of the Framework (isn’t that a work of art?), the course introduced the concepts of Lean and Agile, roles and responsibilities, and the practicalities of scale. The class format was similar to today’s, with the first two days about the mindset and principles and the second two days focused on implementation techniques such as identifying value streams and “finding the kidney,” which is a metaphor for identifying who within the organization contributes to value creation and designing Agile Release Trains (ARTs).
It was hosted at the f/k/a Rally Software headquarters in Boulder, Colorado. Instructors included Dean Leffingwell, Alex Yakyma, Drew Jemilo, and Colin O’Neil. Enterprise representatives included Nokia, McAfee, Mitchell International, EMC, Tendril (the case study in Agile Software Requirements), and Nordstrom. And of course, there were the consultants represented by IconATG, Rally Software, Blue Mercury, and Net Objectives.
In the true spirit of SAFe, the class was full of hands-on experiential exercises, teaming within the class, and knowledge that helped create the evolution and advancement of our traditional Agile mindsets to Lean-Agile mindsets.
There was even a proctored exam on the last day. If memory serves me, there were at least 30 essay questions and about 75 percent of the class graduated as the first SPCs!
I fondly remember chatting with Drew Jemilo, envisioning what SAFe could be in a decade. I can honestly say that the market has validated the need and exceeded all of our visions and expectations. It’s helped tens of thousands of organizations organize and deliver the highest-value products and solutions to their customers and created a powerful career market for lifelong learners, partners, and consultants.
Fast Forward 10 Years
The Framework has never stopped evolving and adapting to the field. Perhaps that’s what makes it unique: continuous value delivery to its customers. As humans, we thrive to evolve and learn, and this enables the sharing of knowledge from people like you.
Some of the latest enhancements include the addition of Principle #10: Organize around value (which was always present, just not as detailed and prevalent) and the seven core competencies of the Lean enterprise, which are crucial to achieving and sustaining your competitive edge.
Today, more than 1,000,000 practitioners and 20,000 enterprises worldwide in nearly every industry trust SAFe. Gartner names SAFe the #1 most considered and adopted framework for scaling Agile. If we were to apply Geoffrey Moore’s technology adoption curve from his book Crossing the Chasm to SAFe, it would most likely be in the early majority, and even in the tornado phase.
If there’s one thing for certain, customers are seeing results, and the Scaled Agile Framework has evolved its initial mission of “Better software and systems make the world a better place.” Today, Version 5 represents the most ambitious expansion of that mission in our history: to enable the business agility that is required for enterprises to compete and thrive in the digital age.
Sincere gratitude to my friend, Alex Yakyma, who helped maintain SAFe history with the visuals and helped refresh my memory of the event.
Learn more about the evolution of the Scaled Agile Framework, follow the SAFe blog, and join us at the 2022 SAFe Summit!
About Jennifer Fawcett
Jennifer is a semi-retired, empathetic Lean and Agile leader, practitioner, coach, speaker, and consultant. As a SAFe Fellow, she contributed to and helped develop SAFe content and courseware. Her passion and focus have been delivering value in the workplace by creating communities and culture through effective communication, product management, product ownership, executive portfolio coaching, and compassionate leadership. She has provided dedicated service in these areas to technology companies for over 35 years.
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.
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.
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.
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.
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.
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.
Note: This is the third post in the Practice Makes Permanent series. Read the first post here and the second post here. You can watch my webinar on PI Planning here.
Is your SAFe® implementation slowing? Has the energy and enthusiasm faded and it feels like just one more process change? Maybe you’re just not seeing the value you expected? That’s OK because PI Planning presents significant opportunities for your relentless improvement of the SAFe journey.
If you’ve read the previous posts in this series, you know that the right kind of SAFe practice doesn’t make perfect, it makes permanent. And you know that using creative tension will help you find the right outlook to discover new opportunities and foster relentless improvement. The reality is that many Agile Release Trains (ARTs) have a distorted view of PI Planning—they see it as a readout of the already created plan or a time to direct teams toward a plan rather than the discovery session it’s intended to be. This makes it a great place to get your implementation back on track. PI Planning is an opportunity to discover the plan for the next PI. Discovery is exciting, it’s engaging, and it’s about learning.
Through my years of teaching and implementing SAFe, I’ve identified key practices to help organizations successfully discover a plan for the upcoming PI. My goal in providing these tips and techniques is to give you practical ideas on how to revolutionize your PI Planning and improve the quality of your plans.
Consider these key practices to make PI Planning a discovery session:
Breadth vs. depth planning
Good objectives start early
Iteration plans from PI Planning are “what if?” scenarios
Raise the levels evenly
Preconceived is pre-committed—limit pre-PI Planning
Breadth vs. Depth Planning
During PI Planning, the Agile teams are instrumental in converting the ART vision and roadmap into team-committed objectives while discovering the risks, dependencies, and delivery goals for the PI.
The anti-pattern
A very common anti-pattern in PI Planning is when teams focus on one iteration at a time, attempting to create a solid plan for iteration one, followed by a deep dive in iteration two, and so on. This is dangerous because we’re not seeing the big picture of the whole PI. And often we get to the draft plan review, and the teams don’t have a high-level, end-to-end plan, which is critical for the management (adjustment) review and problem-solving activity.
Additionally, because teams have gone iteration by iteration, concentrating on creating and loading stories, they haven’t collaborated sufficiently on with other teams on dependencies. This can potentially lead to radical plan changes during team breakouts on day two.
Implement breadth vs. depth
This is where breadth vs depth comes in. Encourage your teams to think across the whole PI and create a very high-level plan within the first 60–90 minutes of the first breakout session. This will include initial starter objectives, the discovery of some initial dependencies on other teams, high-level goals for each iteration, and some initial stories (perhaps slotted into an iteration). These activities give teams a broad, overall approach.
Now, they can use the remaining time in the breakout to improve the depth by:
Discovering more stories
Identifying more dependencies
Refining objectives
Identifying and (perhaps) mitigating more risks
This breadth vs. depth strategy ensures that there’s always a draft plan to review and helps teams align on the approach and effort distribution.
Here’s a quick recap of the key principles of breadth vs. depth:
Start with a high-level, end-to-end plan that’s full of holes.
As time permits, go back and fill in those gaps.
Focus on “based on what we currently know, this is our plan. However, we know we have more to learn to fill in some gaps.”
Raise the water level evenly. Create some story placeholders, which will generate some objectives, which will raise some dependencies, which will identify more stories, which will update objectives, and so on.
Apply SAFe® Principle #3: Assume variability; preserve options. Start with minimal constraints and a high-level approach and add details as they emerge.
Good Objectives Start Early
Team objectives are one of the key outputs of the planning effort. Objectives are a team’s opportunity to say:
“Hey, ART leadership, we saw the vision, we saw the roadmap from the top x features. Here’s our contribution to the success of the ART for this PI.”
This is a powerful opportunity to engage SAFe Principle #8 and SAFe Principle #9 and is a critical component to ensuring alignment.
Many teams struggle with understanding objectives because they’re not used to being asked, “What can you contribute to our success?” Instead, they’re used to being told “this is what needs to be done.” I like to explain objectives with an analogy.
Team objectives
Imagine you’ve just read a really powerful, thought-changing book (such as Donald Reinertsen’s Principles of Product Development Flow). Most likely you’ve read the book chapter by chapter. You want to share the power of that book with your friend, and you’ll probably share highlights and key areas and concepts from your perspective. Now, another friend reads the same book and shares their key takeaways from their perspective. While there may be similarities in key concepts (for example, Economic Sequencing) each perspective may pick up on different areas and ideas that were key to them but that maybe didn’t stand out to you.
The chapters in the book are the features. All the teams read the features and come away with their key areas and contributions. These are the team objectives. Some teams may have shared contributions across the ART (Program Objectives), but many will have specific contributions unique to their own team (Team Objectives).
Start early, iterate often
So, how do you achieve these powerful objectives within PI Planning? That’s where the phrase “good objectives start early” comes in. Objectives should start as early thoughts and concepts and grow in clarity and alignment as the breakout continues.
These are the key principles to successfully writing objectives:
Start writing objectives early in the first breakout.
Don’t wait until you have ‘perfect’ objectives; perfect is the enemy of good.
As you learn more about the plan during the breakout conversations, potential objectives will emerge. Write these down, no matter how incomplete they are.
As you learn more about the objective through further planning-fueled learning, update the objectives.
Don’t try to start with SMART objectives, work toward them.
Iteration Plans from PI Planning Are What-If Scenarios
A common issue that limits the self-organization aspect of SAFe Agile teams is the mistaken belief that teams are creating iteration plans that must be locked in and committed to. This is a highly critical point: teams do not commit to iteration plans in PI Planning. They’re committing to the objectives they discover, and to the Program Board, which identifies when they believe they can deliver on the features and what dependencies are needed to deliver. When teams have the false belief that they’re going to be held accountable for plans for four iterations in sequence, they become nervous, realizing they can’t really know exactly what will be needed for each iteration. They believe they’re being held to a mini-waterfall approach. Actually, the opposite is true.
We ask teams to create iteration plans so that they can discover the objectives they want to commit to, discover the significant dependencies needed to deliver the features they pull in and discover the risks that may threaten the plan. The plan they create is one of many possible ways they can deliver, and many of the details of the actual plan will surface as they execute that plan. In my experience, the specific iteration plans the teams create are about 60-percent accurate. As long as we have the significant dependencies and risks identified, that level of accuracy is good enough to get started.
Key principles around the what-if scenario approach:
Teams do not commit to iteration plans. They commit to objectives and the Program Board’s dependencies and Feature deliveries.
Teams create iteration plans to unearth dependencies, discover objectives, and learn how to deliver to the business.
The iteration plans will almost certainly change as we iterate through the Program Increment. Understanding that we are only identifying one of many possible scenarios to deliver on these objectives helps the teams focus on what’s important.
Raise the Levels Evenly
Closely associated with the breadth vs. depth concept is ensuring you have a good balance of focus on each component of the Draft Plan Review. Following SAFe Principle #4, we want to shorten our Plan-Do-Check-Adjust (PDCA) cycles to increase the pace of learning. If you think of each key area of focus in the team breakout, we have:
Creating, sizing, prioritizing user stories and enabler stories
Identifying and improving team objectives
Identifying and attempting to mitigate risks
Discovering, discussing, and gaining commitment to cross-team dependencies
Updating the Program Board as we discover new feature delivery and dependency aspects in the emerging plan
Consider each of these areas as buckets to fill. We don’t want to fill one bucket to the top and then go to the next. Instead, we want to evenly bring up the level on all buckets together. That means we want the teams to generate some stories, which can lead to updated objectives, which can lead to new risks identified or mitigated, leading to new commitments with other teams, and leading to updates to the Program Board. This order is not rigid, there’s nothing wrong with discovering a dependency, adding some stories to cover this dependency, and then updating Program Board. The idea is to make sure that we are keeping the levels (amount of recorded information) approximately even across all the buckets.
These are the key principles to raising the levels evenly:
Don’t try to create a full iteration-by-iteration plan too early.
Use the energy and knowledge from adding to one bucket to add to the next bucket.
At regular intervals, step back and review the levels in each bucket. Are these relatively evenly filled? If not, do we need to revert to focus on a particular bucket?
At key points, review the entire plan we have created so far. Do we see major gaps? Dangerous assumptions? Note: a great time to do this is about five minutes before the next Scrum of Scrums team breakout. It provides a really clear view of the current progress that will help us identify any systemic issues in our planning process.
Preconceived Is Precommitted—Limit Pre-PI Planning
Before we start PI Planning, we need the right level of readiness. But too much can lose the discovery aspect of PI Planning. Finding that balance is a learning journey, but there are key elements to balance.
Too much pre-PI Planning:
Takes away from the current PI effort. The focus should be on this PI’s objectives, not pre-planning for the next.
Locks into a plan that is not well-informed. PI Planning is about learning, not perfecting. The best objectives come from shared learning during PI Planning.
Damages the team-of-teams culture in the ART.
Too little pre-PI Planning:
Leaves the teams anxious
Can waste time in PI Planning trying to answer foundational questions
The right balance of PI Planning:
Allows teams to ask intelligent questions during the morning briefings. The test I apply is to verify: are the questions probing and refining (good) or are they high level and more about initial alignment (not so good).
Ensures we have the right people in the room. For this PI’s features, we may need other shared services and assistance. Knowing this in advance helps us extend invites to the right people.
Sets the stage for PDCA-based learning cycles during PI Planning. When teams come into PI Planning thinking they already have the right plan, it leads to a fixed mindset for the next PI, which blocks the true discovery needed. We want the team of teams (ART) to iterate through these PDCA cycles together as they discover the plan.
I use a very simple approach—called the five-sticky rule—to help teams understand a good starting point for the level of pre-planning needed. Each team is encouraged to bring five sticky notes into PI Planning that represent potential stories. This requires the team to do enough discovery around the features, vision, and other elements needed in the next PI but keeps them from creating a deep-dive plan that loses the discovery aspect. Please note that the five-sticky rule is more of a guideline than a rule and can be adjusted as needed.
These are the key principles to finding a balance of pre-planning:
Prepare to create the plan, don’t pre-create the plan
Look for intelligent, informed questions during the briefings
Beware of a fixed mindset view of the plan coming into PI Planning
PI Planning is one of the Ten Critical Success Factors to achieve transformational progress with SAFe. By applying the above ideas, you can make it the dynamic, engaging, energetic event it’s intended to be. So, go make your PI Planning a discovery session!
Check back soon for the next post in the series.
About Dwayne Stroman
Dwayne is an Enterprise Transformation Coach and Trainer and SAFe® Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn.
How to use the gap between where you are and where you want to be
This post is part of the ongoing Practice Makes Permanent blog series. Read the first post here.
OK, so your Lean-Agile transformation is stalling. It’s not delivering the increased value and reduced delivery times you expected. Your teams are struggling and perhaps updating their resumes. You thought that implementing the Scaled Agile Framework® (SAFe®) would bring you these outcomes, but you’ve discovered you’re not using all Ten Critical Success Factors of SAFe. Perhaps you’ve discovered that you’re not actually implementing SAFe correctly as you intended, which means you’re probably not gaining the full value of what the Framework has to offer. The key to taking full advantage of this realization is to be encouraged rather than discouraged. We can’t improve until we see the improvements that are needed. The purpose of this article is to help you see that these discoveries should be cause for celebration, not concern.
One of my favorite books (and authors) is Peter Senge’s The Fifth Discipline. In his book, Peter describes the concept of creative tension as ”the tension between vision and reality.” It’s the concept of discovering the gap between where you are and where you want to be and using that gap as energy to make improvements. Think of it as a transformational snowball effect.
SAFe guidance depicts the perfect scenario where an organization exemplifies all seven core competencies, delivering high quality and accurate value to customers, and having the kind of culture and work environment that makes it a great place to work. Then we look at the current reality and realize we have a long way to go to reach this nirvana state of business agility.
Sometimes that gap seems insurmountable, unachievable, and perhaps just unrealistic. As we identify that first improvement opportunity and implement that first improvement effort, we start to see some excitement and engagement. We’re still a long way from that nirvana view, but we’re starting to make progress. And that creates more energy for the next effort. So, we take on the next improvement effort, and there seems to be just a bit more engagement and hope that we can move forward. And that’s where we start to see the snowball effect of relentless improvement.
The snowball effect.
For each improvement we make, we gain more energy, engagement, and willingness to change. And we start to go faster. And faster. And faster. And now, that relentless improvement pillar seems to make more sense, and in fact, becomes part of our DNA. As Peter Senge stated, “The most effective people are those who can ‘hold’ their vision while remaining committed to seeing current reality clearly.”
Positive change is contagious. It brings excitement and hope to the organization. That energy must start somewhere. So, as Taichi Ohno said, “If you are going to do Kaizen continuously … you’ve got to assume that things are a mess. Too many people just assume that things are all right the way they are … If you assume that things are all right the way they are, you can’t do Kaizen. So, change something!”
My point is to change something with a huge grin on your face because you can see the snowball effect of creative tension pulling you upward.
A team celebrating its small wins.
So, when you see that gap between your current reality and where you want to be, you should view it as an opportunity, not a negative situation. In other words, you should view every improvement opportunity with excitement and anticipation of where you can go next on the journey toward business agility.
As change agents, we’ve learned that empathy along the transformation journey is vital. We know how hard it is, so we fully understand why you skipped some of the steps. But now is the time to restart or renew that journey. In subsequent posts, we will talk about specific activities and components we can use the creative tension approach to jump-start a Lean-Agile transformation. The goal of this series is to help you find the next opportunity to accelerate that snowball effect in your transformation.
Check back soon for the next post in the series.
About Dwayne Stroman
Dwayne is an Enterprise Transformation Coach and Trainer and SAFe® Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn.
A big part of my personal life revolves around motorcycles, specifically road racing and coaching. When I’m working with new racers or track riders who want to improve their skills, the first thing I do is ask them to complete this sentence: “Practice makes _____.” Almost everyone says “perfect!” But usually, the opposite is true. When racers go out on the track and continue to repeat bad habits, such as not moving their eyes down-track or using poor body position, they simply cement the wrong technique, which is more difficult to correct later. I always teach riders to focus on learning the basics and build on these good techniques until they become permanent. We all start with the belief that practice makes perfect. However, if you practice the wrong things, the only thing you perfect is the wrong approach. (Note: I want to thank Nick Ienatsch from the Yamaha Champions Riding School (YCRS) for helping me see the importance of learning the right skills before starting to practice. Working with Nick and the crew at YCRS and ChampSchool taught me so much about the importance of getting the basics right.)
The author coaches the basics in an off-track drill.
Switching sports metaphors, a favorite phrase from football coaches (Marv Levy may have been the first to use this) is to “learn how to do it right and then practice it until you never get it wrong.” That’s how we bake in the right techniques, and where practice makes permanent is our ally.
When implementing SAFe®, it’s common to bring in old habits from your organization’s history. It’s hard to break free of these past practices but it’s even more difficult to change them once they’ve been brought into the transformation effort. There are many common anti-patterns that organizations practice and make permanent, including:
Multiple Program Backlogs (whether real or virtual) make it difficult for the teams or ART to focus on the most important thing to work on; this damages Lean flow due to context switching.
Leadership believing that their job is to direct work, which is in direct opposition to SAFe Principle 8 (unlock intrinsic motivation) and SAFe Principle 9 (decentralize decision-making).
Not using the IP iteration for its vital purpose to be a buffer for capacity and to support ongoing innovation, improvement, and synchronized planning.
Using PI planning as a readout of assigned plans, rather than allowing the teams to use team breakouts to discover the best plan to meet business needs.
Objectives given to the teams rather than teams creating their own objectives. When teams review the vision and roadmap and then create their own objectives, they gain engagement and alignment with business and Product Management to demonstrate they understand the value needed.
A common issue we see is organizations treating SAFe as a buffet where you can pick and choose what you implement and what you don’t. While SAFe is highly configurable and is not at all prescriptive, there are key elements that you must implement for real success. These 10 critical success factors are the basic components that you learn and practice until you never get them wrong.
This doesn’t mean that you must be perfect to start. Learning to implement SAFe correctly is just like learning to ride both fast and safe. You learn the proper techniques and continue to inspect and adapt until you get it right, then practice these techniques until they become instinctive. That’s when the speed comes. The same concept applies to your SAFe implementation—learn the 10 critical success factors and practice them until they become instinctive. You will make mistakes along the way because getting these factors right takes time and effort. But if you continue to focus on these basics, they become part of the culture and the norm for your organization. That’s when you experience the true value of a SAFe implementation.
Practice Makes Permanent Blog Series
In this blog series, I aim to share my experiences from the field in helping organizations master and apply good, basic, Lean-Agile and SAFe practices to promote successful SAFe implementation.
Upcoming topics I plan to cover include PI planning, the Program Backlog, and SAFe roles. My hope is that as part of this effort, you will be able to achieve business agility through the Lean-Agile mindset.
Dwayne is an Enterprise Transformation Coach and Trainer and SAFe Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn.
Globalization is an important growth strategy for Scaled Agile. Localization of SAFe content enables our customers worldwide to participate and learn in their own native language. And it helps drive the adoption of SAFe across international markets.
We need several key ingredients to create a great global product. One of them is people. Since I started working at Scaled Agile, one of the most rewarding experiences was building a global SAFe In-country Review (ICR) team comprised of SAF SAFe experts —known as SPCs and SPCTs—from around the globe. All of them are highly experienced Agile coaches and transformation leaders who are changing the way people work in their respective countries. I’ve had the utmost pleasure of working closely with this team and I can tell you that they are fantastic people!
At Scaled Agile, translation quality, including that of our glossary, is critical. We don’t simply translate a term. We make sure every term has been discussed and thoroughly vetted by our passionate ICR team. Does the term or concept exist in the target language? If the concept can be translated in multiple ways, which one is most appropriate given the context? Do we use the traditional translation of the term or the anglicized version? Does the transliteration make sense instead? These are just a few examples of the questions that our ICR team addresses on a regular basis.
After all, the glossary is an integral part of the learning experience. And we need to ensure that SAFe content is well-translated and of high quality. Thanks to our ICR team’s effort, the SAFe glossary is now available in 13 languages.
The holiday season is a perfect time for reflection. I’d like to take a moment to recognize the contribution of the ICR team and properly thank everyone who contributed. The list below includes past and current ICR team members (listed in alphabetical order by the first name). These individuals went above and beyond to contribute to the SAFe community by sharing their knowledge and devoting their time. They’re helping to make SAFe more accessible to learners worldwide.
I’d like to say a heartfelt thank you to our special ICR team because we couldn’t have done it without you! I look forward to working with everyone in the new year as we will continue to update the SAFe glossary and focus on courseware translations.
Wherever you are, whatever you are celebrating, I wish everyone a healthy, happy holiday season!
Interested in becoming an ICR? Please ›click here to learn more.
About Yuka Kurihara
Yuka is Director of Globalization Services at Scaled Agile, Inc. She has 20+ years of experience building corporate globalization strategies and leading localization technology and operations in enterprises of all sizes. Connect with Yuka on LinkedIn.