The Complete Guide to Measuring Team and Technical Agility

 

Before writing this article, we were curious to know more about how often teams are measuring their agility (if ever). We ran an informal poll on LinkedIn, and the results were fascinating.

Assessing your team’s agility is a crucial step toward continuous improvement. After all, you can’t get where you want to go if you don’t know where you are.

But you probably have questions: How do you measure a team’s agility? Who should do it and when? What happens with the data you collect, and what should you do afterwards?

We’re here to answer these questions. Use the following sections to guide you:

  • What is Team and Technical Agility?
  • What is the team and technical agility assessment?
  • Assessment tips, including before, during, and after you assess
  • Team and technical agility assessment resources

These sections include a video showing where to find the team and technical agility assessment in SAFe® Studio and what the assessment looks like.

What Is Team and Technical Agility?

Agile Teams, Built-In Quality, and Teams of Agile Teams graphic from Framework article
The three dimensions of team and technical agility

Before jumping into the assessment, it’s important to understand team and technical agility. This will help determine if you want to run the assessment and which areas may be most beneficial for your team. 

Team and technical agility is a team’s ability to deliver solutions that meet customers’ needs. It’s one of the seven business agility core competencies. 

Team and technical agility contains three parts:

  • Agile teams
  • Teams of Agile teams
  • Built-in Quality

Agile teams

As the basic building block of an Agile Release Train (ART), the Agile team is responsible for 

  • Connecting with the customer
  • Planning the work
  • Delivering value
  • Getting feedback
  • Improving relentlessly

They’re the ones on the ground bringing the product roadmap to life. They must also plan, commit, and improve together to execute in unison. 

Teams of Agile teams

An ART is where Agile teams work together to deliver solutions. The ART has the same responsibilities as the Agile team but on a larger scale. The ART also plans, commits, executes, and improves together. 

Built-in quality

Since Agile teams and ARTs are responsible for building products and delivering value, they must follow built-in quality practices. These practices apply during development and the review process. 

As we state in the Framework article: “Built-in quality is even more critical for large solutions, as the cumulative effect of even minor defects and wrong assumptions may create unacceptable consequences.”

It’s important to consider all three areas when assessing your team’s agility.

What Is the Team and Technical Agility Assessment?

Team and Technical Agility Assessment results screenshot

The team and technical agility assessment is a review tool that measures your team’s agility through a comprehensive survey and set of recommendations. 

However, there’s more to it than that. We’ll review the information you need to fully understand what you learn from this assessment and how to access it.

Each question in the assessment asks team members to rate statements about their teams on the following scale:

  1. True
  2. More True than False
  3. Neither False nor True
  4. More False than True
  5. False
  6. Not Applicable
The assessment answer options

What information can I get from the team and technical agility assessment?

Team and technical agility assessment helps teams identify areas for improvement, highlight strengths worth celebrating, and benchmark performance against future progress. It asks questions like the following about how your team operates:

  • Do team members have cross-functional skills? 
  • Do you have a dedicated Product Owner (PO)
  • How are teams of teams organized in your ARTs? 
  • Do you use technical practices like test-driven development and peer review? 
  • How does your team tackle technical debt?

For facilitators, including Scrum Masters/Team Coaches (SM/TC), the team and technical agility assessment is a great way to create space for team reflection beyond a typical retrospective. It can also increase engagement and buy-in for the team to take on actionable improvement items.

Once the assessment is complete, the team receives the results broken down by each category of team and technical agility.

Team and Technical Agility Assessment results (aggregate view)

When you click on a category, the results break into three sub-categories to drill down even further into the responses.

Team and Technical Agility results (drilled down view of Agile Teams category)

In addition to the responses, you receive key strengths. The answers with the highest average scores and the lowest deviations between team members are key strengths.

Assessment results showing statements with the highest scores and highest amount of agreement

Inversely, you also get key opportunities. The answers with the lowest average scores and highest deviations between team members highlight areas where more focus is needed.

Screenshot of areas of improvement in assessment results

The assessment will include growth recommendations based on your team’s results. These are suggested next steps for your team to improve the statements and areas where it scored lowest.

Screenshot of a growth recommendation example from the TTA assessment

How do I access the team and technical agility assessment?

You can access the team and technical agility assessment in SAFe® Studio. Use the following steps:

  1. Log into SAFe® Studio.
  2. Navigate to the My SAFe Assessments page under “Practice” in the main navigation bar on the left side of the homepage. 
  3. Click the Learn More button under Comparative Agility, our Measure and Grow Partner. The team and technical agility assessment runs through their platform. 
  4. Click on the Click Here to Get Started button.
  5. From there, you’ll land on the Comparative Agility website. If you want to create an account to save your progress and assessment data, you may do so. If you’d like to skip to the assessment, click on Start Survey in the bottom right of the screen. 
  6. Select Team and Technical Agility Assessment.
  7. Click Continue in the pop-up that appears. 
  8. The assessment will then start in a new tab. 

See each of these steps in action in this video.

Team and Technical Agility Assessment Best Practices

To ensure you get the best results from the team and technical agility assessment, we’ve compiled recommended actions before, during, and after the assessment.

Assessment Best Practices

Before facilitating the team and technical agility assessment

Being intentional about how you set up the assessment with your team will give you results you can work with after the assessment.

Who should run the assessment

Running assessments can be tricky for a few reasons. 

  • Teams might feel defensive about being “measured” 
  • Self-reported data isn’t always objective or accurate 
  • Emotions and framing can impact the results 

That’s why SAFe recommends a SM/TC or other trained facilitator run the assessment. A SM/TC, SPC, or Agile coach can help ensure teams understand their performance and know where to focus their improvement efforts.

When to run the assessment

It’s never too early or too late to know where you stand. Running the assessment for your team when starting with an Agile transformation will help you target the areas where you most need to improve, but you can assess team performance anytime. 

As for how frequently you should run it, it’s probably more valuable to do it on a cadence—either once a PI or once a year, depending on the team’s goals and interests. There’s a lot of motivation in seeing how you grow and progress as a team, and it’s easier to celebrate wins demonstrated through documented change over time.

How to prepare to run the assessment

Before you start the team and technical agility assessment, define your team’s shared purpose. This will help you generate buy-in and excitement. If the team feels like they’re just completing the assessment because the SM/TC said so, it won’t be successful. They must see value in it for them as individuals and as a team. 

Some questions we like to ask to set this purpose include: 

  • What do we want it to feel like to be part of this team two PIs from now?
  • How will our work lives be improved when we check in one year from now?

We like to kick off the assessment with a meeting invitation with a draft agenda if you’re completing the assessment as a team. Sending this ahead of time gives everyone a chance to prepare. You can keep the agenda loose, so you have the flexibility to spend more or less time discussing particular areas, depending on how your team chooses to engage with each question.

If you’re completing the assessment asynchronously, send out a deadline of when team members must complete the assessment by. Then send a meeting invitation for reviewing the results as a team.

Facilitating the team and technical agility assessment

Now it’s time to complete the assessment. These are a couple of tips to consider when facilitating the assessment for your team.

Running the assessment

Ways to run the assessment graphic

There are two ways you can approach running this assessment. Each has a different value. Choose the option based on your team’s culture. 

Option one is to have team members take the assessment individually and then discuss the results as a group. You can do this one of two ways: team members complete the assessment asynchronously by a certain date so you can review results as a team later or set a time for teammates to take the assessment at the same time and discuss results immediately afterwards.   

Option two is to discuss the assessment questions as a team and agree on the group’s answers.

When we ran this assessment, we had team members do it individually so we could focus our time together on reviews and actions. If you run it asynchronously, be available to team members if they have questions before you review your answers.

Keeping the assessment anonymous

Keeping the answers anonymous is helpful if you want more accurate results. We like to be clear upfront that the assessment will be anonymous so that team members can feel confident about being honest in their answers. 

For example, with our teams, we not only explained the confidentiality of individuals’ answers but also demonstrated in real time how the tool works so that the process would feel open and transparent. We also clarified that we would not be using the data to compare teams to each other or for any purpose other than to gain a shared understanding of where we are selecting improvement items based on the team’s stated goals.

However, if you choose to complete the assessment as a team and decide on each answer together, answering anonymously isn’t possible. Choose the option you think works best for your team’s culture.

After facilitating the team and technical agility assessment

The main point of running the team and technical agility assessment is to get the information it provides. What you do with this information determines its impact on your team.

What to do with the assessment results

Once you’ve completed the assessment using one of the two approaches,

  • Review sections individually
  • Show aggregate results
  • Allow team to notice top strengths and areas for improvement
  • Don’t tell the team what you think as facilitator

We learned in the assessment how much we disagreed on some items. For example, even with a statement as simple as “Teams execute standard iteration events,” some team members scored us a five (out of five) while others scored us a one. 

We treated every score as valid and sought to understand why some team members scored high and others low, just like we do when estimating the size of a user story. 

This discussion lead to:

  • Knowing where to improve
  • Uncovering different perspectives
  • Showing how we were doing as a team
  • Prompting rich conversations
  • Encouraging meaningful progress

We know it can be challenging to give and receive feedback, especially when the feedback focuses on improving. Here are a few ways to make conversations about the assessment results productive with your team.

How to review assessment results graphic

Using the assessment to improve

With your assessment results in hand, it’s time to take actions that help you improve. 

For each dimension of the team and technical agility assessment, SAFe provides growth recommendations to help teams focus on the areas that matter most and prioritize their next steps. 

Growth recommendations are helpful because they’re bite-sized actions to break down the overall area of improvement. They’re easy to fit into the PI without overloading capacity. 

Examples of growth recommendations:

Example 1:

  • As a SM/TC, watch the How to Run an Effective Backlog Refinement Workshop video with the team.
  • Discuss the importance of refining the backlog to ensure upcoming work is well-defined and there is no work outside the backlog. 
  • Schedule backlog refinement on a cadence.

Example 2: 

  • As a team, use the Identifying Key Stakeholders Collaborate template and answer the following questions:
    • Who is the customer of our work? (This could be internal or external customers.)
    • Who is affected by our work?
    • Who provides key inputs or influences the goals of our work?
    • Whose feedback do we need to progress the work?
  • Maintain a list of key stakeholders.

Example 3:

  • As a team, collect metrics to understand the current situation. Include the total number of tests, the frequency each test is run, test coverage, the time required to build the Solution and execute the tests, the percentage of automated tests, and the number of defects. Additionally, quantify the manual testing effort each Iteration and during a significant new release.
  • Present and discuss these metrics with the key stakeholders, highlighting how the lack of automation impacts quality and time to market.
  • Create a plan for increasing the amount of test automation.

Here are some actions you should take once you’ve completed the assessment: 

  • Review the team growth recommendations together to generate ideas
  • Select your preferred actions (you can use dot voting or WSJF calculations for this; SAFe® Studio has ready-made templates you can use)
  • Capture your team’s next steps in writing: “Our team decided to do X, Y, and Z.” 
  • Follow through on your actions so that you’re connecting them to the desired outcome
  • Review your progress at the beginning of iteration retrospectives

Finally, you’ll want to use these actions to set a focus for the team throughout the PI. Then check in with Business Owners at PI planning on how these improvements have helped the organization progress toward its goals.

Tip: Simultaneously addressing all focus areas may be tempting, but you want to limit your WIP. 

To do this, pick one focus area based on the results. You can add the remaining focus areas to the backlog to begin working on once you’ve addressed the first one.

Ways to prioritize action items: WSJF, Team vote, Timeliness, Ease, Team capacity

Feeling overwhelmed by the action items for your team? Try breaking them down into bite-size tasks to make it easier on capacity while still making progress.

These are some examples.

Bite-size action item examples

Team and Technical Agility Assessment Resources

Here are some additional resources to consider when assessing your team’s agility. 

About the authors

Lieschen is a product owner and former scrum master at Scaled Agile.

Lieschen Gargano is a Release Train Engineer and conflict guru, thanks in part to her master’s degree in conflict resolution. As the RTE for the development value stream at Scaled Agile, Inc., Lieschen loves cultivating new ideas and approaches to Agile to keep things fresh and engaging. She also has a passion for developing practices for happy teams of teams across the full business value stream.

Sam is a certified SAFe® 6 Practice Consultant (SPC) and serves as the SM/TC for several teams at Scaled Agile. His recent career highlights include entertaining the crowd as the co-host of the 2019, 2020, and 2021 Global SAFe® Summits. A native of Columbia, South Carolina, Sam lives in Kailua, Hawaii, where he enjoys CrossFit and Olympic weightlifting.

How to Upgrade to SAFe 6.0 in Five Steps

Last month, we introduced SAFe® 6.0, a new version of SAFe. 

What does this mean for your SAFe certifications

It’s simple. You can upgrade your SAFe certifications in five easy steps (including showing off your new certification badge). In this blog, we’ll help you understand the following:

  • What is the SAFe 6.0 upgrade?
  • Why should you complete the SAFe 6.0 upgrade?
  • How to complete the SAFe 6.0 upgrade

What Is the SAFe® 6.0 Upgrade?

The SAFe 6.0 upgrade is a self-paced online learning series that transitions your certifications from SAFe 5 to SAFe 6.0. In the upgrade, you’ll cover five modules highlighting the critical information you need to work effectively in a SAFe 6.0 environment.

These five modules include:

  • The SAFe 6.0 Big Picture and Terminology 
  • Lean-Agile Mindset, Core Values, and Principles
  • Accelerating Value Flow
  • Empowering Teams and Clarifying Responsibilities
  • SAFe® Studio

It takes about an hour and a half to complete the upgrade.

If you’re a SAFe® Practice Consultant (SPC), you’re required to take the following three additional modules and pass a 20-question quiz:

  • The SPC Role in 6.0
  • The Implementation Roadmap
  • Measure and Grow

This SPC expert upgrade takes about two hours to complete.

Each module comprises videos, reading material, and activities to help you understand what’s new in SAFe 6.0 and how it impacts your daily work. 

You’ll also find links to relevant updated Framework articles and other important material at the end of each module. These are found in the “Next Steps” section.

You can select which language you’d like to complete the upgrade in. Currently, we have English and Japanese available, with more language options coming soon.

Why Should You Complete the SAFe 6.0 Upgrade?

In addition to a shiny new badge (or badges, since all your badges get upgraded at once), the SAFe 6.0 upgrade gives you the knowledge to apply SAFe 6.0 concepts to your organization, teach SAFe 6.0 courses, and thrive in a digital age that includes new concepts like AI, Big Data, and Cloud.

Coach your teams and ARTs on how to apply new role guidance and new concepts like flow, all while working differently in a SAFe 6.0 environment. 

With SAFe 6.0 guidance and the resources to learn, practice, and manage your transformation within SAFe® Studio, you can achieve the business agility and resiliency needed to win in the digital age.

Also, did we mention the upgrade is free for all members?

Need more convincing? Hear why I think you should complete the SAFe 6.0 upgrade.

How to Complete the SAFe 6.0 Upgrade

Screenshot of SAFe 6.0 upgrade homepage in SAFe® Studio
The SAFe 6.0 upgrade homepage in SAFe® Studio

This section will walk you through the SAFe 6.0 upgrade steps. Prefer a video format? See the steps in action in this video.

Step 1 | Log into SAFe® Studio

To start, you need to log into SAFe® Studio. Once logged in, you’ll see a SAFe 6.0 upgrade banner at the top of the page. Click on the banner or you can follow this direct link to the upgrade page. 

Step 2 | Add the upgrade to your learning plan

Once you click “Get Started” on the SAFe 6.0 upgrade page, it will take you to My Learning. Completing this step means you’ve successfully added the SAFe 6.0 upgrade to your learning plan. You can now come back to it at any time and pick up where you left off. 

Update: you can now select a language for your upgrade. If you’d like a different language than English, scroll to the section titled “SAFe 6.0 Upgrade Options.” You can then choose your preferred language by clicking on the corresponding button for the upgrade.

Step 3 | Start the SAFe 6.0 upgrade online learning series

The certified member upgrade learning series takes about one hour and 45 minutes to complete. The expert upgrade for SPCs takes about two hours. Each module takes about 10 – 15 minutes to complete and is a combination of written material, videos, and required activities. 

The online learning series is self-paced, meaning you can start and stop on your own time. If you prefer to break it up and complete one module per day, you’ll be done in a week (a little less than two if you’re an SPC). You have the flexibility to adjust the upgrade timeline to your schedule.

Once you’re ready to begin, click “Launch” to the right of the first module name (Welcome to the SAFe 6.0 Upgrade). The online learning series will then launch within the same window. 

Step 4 | Update your certifications and digital badges

Once you’ve completed all the modules, your active SAFe 5 certifications will automatically update to SAFe 6.0.

If you opt in for digital badges, you’ll receive SAFe 6.0 digital badges that you can share on digital platforms. Learn how to opt in to receive digital badges here.

Join in the SAFe 6.0 upgrade fun on LinkedIn

Step 5 | Share your achievement on social media

Don’t forget to share your new digital badge on your LinkedIn, Twitter, or any other social media profiles! Share your achievement with the online SAFe community using the hashtag #SAFe6Upgrade.

SAFe 6.0 Upgrade FAQs

Can I upgrade from a SAFe 4 certification to SAFe 6.0?

Yes. First, you must complete the SAFe 5.0 upgrade to upgrade your version 4 certification(s) to version 5.0. After that, you must complete the SAFe 6.0 upgrade (or expert upgrade if you have an SPC certification) to upgrade to 6.0.

You can find the SAFe Version 5.0 upgrade here.

If your certification is Version 3 or older, you will need to take a SAFe 6.0 course and pass the associated exam.

Is there a cost associated with upgrading to SAFe 6.0?

The SAFe 6.0 Upgrade is included, at no additional cost, with every SAFe membership. 

If your membership needs renewal, you can follow the instructions here.

If I upgrade to SAFe 6.0, do I still get to keep my SAFe 5 certifications?

Yes. Your SAFe 5 certifications will remain valid and in good standing, and the upgrade will award you brand-new SAFe 6 Certifications.

As an SPCT or SPC, does upgrading to SAFe 6.0 upgrade all of my active certifications?

Yes. Completing the SAFe 6.0 expert upgrade learning plan and quiz will upgrade your SPC(T) and all other certifications you hold.

Have more questions? Check out our SAFe 6.0 Upgrade FAQs.

There you have it—five easy steps for upgrading to SAFe 6.0. As Beyonce says (or should have said), let us upgrade you to SAFe 6.0.

Beyonce meme: Let me upgrade you to SAFe 6.0
Start your SAFe 6.0 upgrade today

Get the Upgrade

About Tamara Nation

Tamara Nation - product management at Scaled Agile

As VP of the Professionals Business Segment at Scaled Agile, Inc., Tamara is a results-driven servant leader with a proven track record of motivating high-performing teams to deliver positive outcomes in complex environments. She collaborates with her team of senior product managers and other stakeholders to identify and define customer needs and understand customer and market dynamics to develop product vision, roadmap, and features to bring to market. Find Tamara on LinkedIn.

What Is a SAFe Practice Consultant-T (SPCT) and How Can You Become One?

SAFe Program Consultant Trainer

“I am so glad I did it. It is unreservedly the single most important thing I have done in my career. If you are a seasoned professional with a commitment to lifelong learning and are wondering what your next career move might be, I highly recommend you take a look at the SPCT program.”

 Michael Casey, SPCT, Agile Big Picture

As more organizations engage with SAFe®, it’s even more critical that we have knowledgeable, experienced SAFe leaders to help transform large enterprises and continue to shape the way SAFe is being implemented. If you have deep SAFe knowledge, are a lifelong learner, are SAFe Practice Consultant (SPC)-certified, and excel in training and coaching, I invite you to consider becoming a SAFe Practice Consultant-T (SPCT).

“As is the case with any certification, you should carefully evaluate SAFe instructors and consultants, and make sure that they have demonstrated experience that is relevant to the role you are asking them to take on. Do not rely on certifications alone as a measure of the skills of a consultant or prospective employee. A notable exception to this is the SAFe Program Consultant Trainer (SPCT) certification [now SAFe® Practice Consultant-T], which does require demonstrated experience with Agile, software development or product management, training and consulting. If you’re hiring someone who has [an] SPCT certification, you can be confident that they do have experience in these areas, as well as experience with SAFe implementation at multiple organizations. However, SPCTs are in short supply. As of February 2020, there are fewer than 100 people worldwide holding this certification.”

Gartner, “A Technical Professional’s Guide to Successful Adoption of the Scaled Agile Framework (SAFe),” Kevin Matheny, Bill Holz, 13 April 2020

SPCTs are among the most highly regarded SAFe experts in the world. They are also the most sought-after SAFe Trainers, SAFe Trusted Advisors, and SAFe Transformation Architects among enterprises seeking to improve their methods of working and pursue business agility.

As transformation catalysts, SPCTs share their vast industry expertise and skills through teaching, coaching, and handling the most challenging SAFe implementations. And they are experts at communicating, consulting, and creating SAFe knowledge.

SPCT is the most advanced certification you can achieve with SAFe and can be career-changing through job advancement and new opportunities.

SPCT credentials bring the highest level of credibility, which opens doors for you and generates confidence within the organization that you’re helping to create the highest-quality SAFe implementation.

That said, you should know that our selection process has very high standards, and not everyone will get in. To be accepted into the program, you must not only meet the skills and experience prerequisites but have presence and gravitas. The requirements and expectations are slightly different for partners and enterprise employees.

Nominees must either be sponsored by a Gold Partner or an enterprise customer with a SAFe® Enterprise Subscription. However, both must be full-time employees of their respective organizations and are expected to have several years of experience in the tech industry, with five years of Lean-Agile experience and five years of software/systems/product experience.

Here’s how the process works:

  1. Get nominated: If you or someone you know would make a good candidate, request access to the SPCT portal by sending an email to spct@scaledagile.com. Through the portal, you can submit your documented accomplishments as you achieve them.
  2. Have an interview: After your nomination requirements have been reviewed and accepted, you’ll have two screening interviews with SPCT guides. Our team will then determine whether you’d be a good fit for the program.
  3. Attend Immersion Week: If you’re accepted, you’ll be invited to attend SPCT Immersion Week (currently, we hold three to four classes per year) where nominees showcase their knowledge, skills, and abilities in training and consulting with SAFe. You’ll also learn how to teach an Implementing SAFe® class and may even work on a class project that contributes to SAFe’s intellectual property.
  4. Complete field experience: After Immersion Week, you’ll need to complete additional certification requirements that include teaching SAFe classes, completing SAFe implementations, and finishing the required readings.
  5. Co-teach an Implementing SAFe® class: Lastly, you’ll participate in a pairing test by co-teaching an Implementing SAFe® class with one of our guides. During this class, we’ll evaluate your presentation, training, and coaching skills.

I believe becoming an SPCT is a valuable and rewarding career goal to aspire to—but I’m not the only one. Here’s what some of our SPCTs have to say:

“SPCTs are differentiated in the marketplace. The SPCT certification is rare and the knowledge and expertise it represents is valuable and much in demand.” 

—Simon Chesney, iSPCT, Western Digital Corporation

“Becoming an SPCT takes hard work, but it will pay you back many times over what you put into it in personal growth and career advancement. Get on board the SPCT program and you won’t look back!” 

—Michael Casey, SPCT, Agile Big Picture

I encourage you to explore what it takes to become an SPCT to see if this would be a good fit for you or someone you know.

Learn more by contacting spct@scaledagile.com.

About Adam Mattis

Adam Mattis is a SAFe® Fellow and SAFe® Practice Consultant-Trainer (SPCT) at Scaled Agile with many years of experience overseeing SAFe implementations across various industries. He’s also an experienced transformation architect, engaging speaker, energetic trainer, and a regular contributor to the broader Lean-Agile and educational communities. Learn more about Adam at adammattis.com.

View all posts by Adam Mattis

Share:

Back to: All Blog Posts

Next: Scrum Master Stories: Resolving Conflict

How to Start and Grow Your Lean-Agile Center of Excellence

Transformations don’t happen in a vacuum. They need momentum, stewardship, and what John P. Kotter calls “a guiding coalition that operates as an effective team.” In the Scaled Agile Framework® (SAFe®), this coalition is the lean-agile center of excellence (LACE). The LACE is a cornerstone of successful transformations because it 

  • Encourages continuity and manages expectations
  • Sustains the change by sharing success patterns
  • Reduces the “time to transformation” by focusing on execution and progress 

LACEs aren’t a new concept, and you can find a helpful overview of how they work in the current Framework article. But this piece will expand on that article by introducing new findings from 2022 field research. We observed organizations with a well-established LACE practicing the following advancements:

  • Leading the transition to Lean Portfolio Management (LPM)
  • Facilitating effective events, like Value Stream Identification, to organize around value
  • Nurturing the employee development and job architecture needed to thrive in a SAFe environment

A LACE will grow and evolve as much as the entire organization during the change process. We’ll explore each stage of this evolution through key highlights from our research, which include:

You won’t see this new networked model or some of the additional insights in the Framework article; it’s an emerging pattern discovered as part of our research into SAFe implementations. Our research uncovered other key themes shared among LACEs as they start and develop. These additional themes are:

We’ll show how these themes apply as you start and grow your LACE. Understanding your LACE journey will support transformation success from the beginning and help you avoid burnout, common mistakes, and blocks to improving business agility.

Building an Effective LACE

SAFe Implementation Roadmap
SAFe Implementation Roadmap

When should you start your first LACE? The SAFe Implementation Roadmap suggests that LACE creation should coincide with the beginning of a transformation. While things won’t be perfect in the first stages, starting a LACE early on will help you build momentum, steer critical decisions, and equip new teams. 

Restating the same question differently: When should you form a LACE with members who are fully dedicated to leading the transformation? This question is particularly relevant to LACE groups that are part-time or voluntary. While external expert coaches might work at first, over time you need to build internal coaching capabilities and dedicate people to extend and sustain the SAFe transformation.

What are the first steps toward organizing an effective, impactful coalition? Below we outline six essential steps for successfully setting up and running your first LACE.

Step 1 | Identify sponsorship and the right members

Early on in your implementation, you should consider who you want in your LACE. This task usually falls to change leaders and drivers of the transformation.

Find multiple roles

Include coaches, internal people who feel or live the problems, champions who emerge based on their behaviors, and leadership. This diversity makes it easier to get buy-in or a voice in decision-making. 

Tip: Find leaders who consistently highlight pain points and the need for transformation.

Finding people for these roles is one thing; getting them to commit is another. How do you convince them this isn’t just another “volunteer” role? They need to understand what’s in it for them and the organization. 

On a personal level, showing transformation leadership is proof that you have what it takes to turn initiatives into reality. This is a key incentive for many potential LACE members. As a member, you’ll gain valuable skills to develop your career and pave the way for future leadership roles. 

On an organizational level, helping to lead the change puts you in a position to determine what the change will look like. It gives you a stake and vested interest in the outcome.

Cross business lines

Getting the right executive sponsorship is critical early on. Traditionally, LACEs were part of the CIO’s organization, but we recently observed a shift to business-led transformations with LACEs reporting to the CFO, COO, and Head of Sales.

Digital transformations are emerging as collaborative initiatives across Business and Technology organizations. As an Effective LACE evolves, it starts to mirror this same pattern by incorporating active membership and sponsorship from both Business and Technology. 

If your LACE initially started under the CIO organization, look for ways to include representation from other business areas; especially ones involved in the digital transformation. This diversity builds credibility and richer transformation solutions to achieve desired business outcomes.

Think cross-functionally

LACEs should be a cross-functional team. You need senior coaches and SPCs to coach and train ARTs, but those aren’t the only skills you need. 

Your LACE also needs skills in communications and change management to help the impacted groups navigate change. As an example, we’ve seen some LACEs engaging with experts in organizational design. The LACE can also engage a Project Management Office (PMO) or financial management, especially when starting a Lean Portfolio Management implementation. These skills may be full-time for a larger LACE or added as an extended team.

Aim small

Instead of transitioning the entire organization to SAFe ceremonies all at once, begin small by practicing SAFe ceremonies within the LACE team. Use them to plan any work related to the transformation or training. 

Some examples of these team-level ceremonies include:

As the transformation expands and grows, multiple teams will start running SAFe ceremonies simultaneously. 

You can then incorporate more program-level ceremonies into the organization to help with the larger transformation vision. These can include:

Step 2 | Create a mission statement

Sample LACE Mission Statement

The LACE must align on a common mission statement. The mission statement gives the LACE a measuring point to help determine transformation scope and success. 

You can use the recommended structure provided in the Framework article (shown in the preceding graphic) when writing your mission statement.

Step 3 | Set preliminary goals

To frame your goals, you must understand the state you’re trying to reach. What are you trying to accomplish with business agility? To answer this question, it’s important to understand where other business areas are experiencing challenges. Talk to sales, compliance, operations, and other areas supporting solution delivery to learn their aspirational outcomes. 

This allows you to design goals based on the organization’s needs. 

A recent pattern gaining momentum is to set transformation OKRs for the SAFe implementation. The following sections include a few examples.

Short-term objectives:

  • Shorten the delivery cycle by addressing silo-related handoffs and friction
  • Introduce customer-centricity and a product discipline

Longer-term objectives:

  • Enable business agility and sense and respond to change
  • Foster employee engagement and respect for people
  • Shape disruption

You might first use metrics like the number of ARTs launched and people trained. But these metrics are based on adoption rather than outcomes. It is recommended to pivot once you can demonstrate and articulate the aforementioned goals.

Make goals visible so everyone understands where the transformation is headed at all times.

Step 4 | Build relationships and get buy-in

When leaders are vulnerable and share both good and bad experiences, it normalizes that transformations can feel uncomfortable at times, but that’s not a reason to stop or slow down. This relationship-building can happen informally through peer connections or formally through Communities of Practice.

Do the roadshow. Make the long trek down the hall (or organize some Zoom meetings) to build relationships and understand what others are seeing. Implementation of mindset and principles will help resolve the challenges people are sharing with you. Share how this new way of working can help their specific business unit. This builds trust, supports a shared understanding, and fosters empathy.

Step 5 | Conduct empathy interviews

How do people speak about Agile? What are their opinions? What do they view as the challenges to them and their organization from Agile?

Tip: Use empathy interviews to find potential partners through sponsorship and vocalized support or participation.

Once you’ve accomplished these beginning steps, it’s time to consider the formation of your LACE. We’ve found that the formation of the LACE often correlates to the following factors:

  • Executive sponsorship and willingness to dedicate people and fund the LACE
  • Agile maturity level
  • Number of ARTs
  • Number of LACE members 

The following sections will detail each of the most common LACE formations, and we’ll specifically focus on the following areas:

  • When to mature your LACE formation
  • What changes as your LACE evolves through different formations
  • Success patterns for managing the change
  • Personal insights from experienced change leaders
Lean-Agile Center of Excellence Evolution Research Observations

Centralized

Now that you can answer the question, “What is a lean-agile center of excellence?,” you’re ready to formalize and structure your LACE. We start with the centralized LACE because that’s where organizations often begin.

Forming one centralized team is the most logical step when creating your first LACE. Think of the first LACE as an incubator. Your goal is to find out what works, what doesn’t, and how to keep success patterns going. It may be a small team of two to three people or a slightly larger team of five to six people. Ideally, these members should have a foundational knowledge of SAFe (Leading SAFe®) and how to apply it (Implementing SAFe®).

Here are three steps to set and communicate your first priorities.

Measure the impact

One way to establish an organizational baseline and prioritize transformation work on your LACE roadmap is by facilitating an assessment. The Measure and Grow assessments on the SAFe Community Platform uncover strengths and areas for improvement. They also offer growth recommendations, which are specific tips tailored to your organization’s growth areas.

Visit the SAFe Community Platform to start assessing your transformation today.

You can then use this data to determine your LACE’s priorities. To understand the organization as a whole, it’s best to survey as many teams as possible. 

Tip: You should aim to start strong in the areas that will have the biggest impact. Your assessment data will show these areas.

Understand your responsibilities

With your data and priorities gathered, you should start the transformation strong by training and equipping members, especially leadership, with the resources they need for success. 

The Framework article offers a large list of responsibilities for LACEs. While these responsibilities all add significant value, they tend to shift in importance over time. And we typically see the responsibilities increase in number and sophistication as a LACE matures. 

The key focus areas for an early-stage centralized LACE include the following: 

  • Communicating the business need, urgency, and vision for change 
  • Developing the implementation plan and managing the transformation backlog 
  • Establishing the metrics 
  • Conducting or sourcing training for executives, managers and leaders, Agile teams, and specialty roles such as Product Owner, Product Manager, Scrum Master, and Release Train Engineer
  • Facilitating Value Stream Identification Workshops (using supporting toolkit) and helping define and launch new Agile Release Trains (ARTs)
  • Starting the LPM implementation journey

Tip: We recommend starting Value Stream Identification early in the transformation journey to organize around value and LPM. We understand that this may not be possible in your transformation. Introduce them as soon as there’s a need and continue to revisit them over time.

Communicate early and often

Transparency is an important tenet of a successful transformation. Communication is one way to encourage transparency. Communicate the LACE structure, members, mission, priorities, and goals out to the whole enterprise (or at least the ART). You can even share some of your early wins or lessons. 

Metrics can help establish a routine communication avenue. Sharing progress through metrics in a way the whole enterprise can understand will increase buy-in for the transformation.

Challenges for a Centralized LACE

Here are some of the challenges that can occur when transitioning to a centralized LACE.

Prevent regression

As the LACE extends the transformation and moves on to launch the next team, ART, Value Stream, or Portfolio, the LACE needs measures in place to continue the support for previously-launched groups. 

The LACE must provide the previously launched groups with continuous learning opportunities, on-demand assets, and tools to be able to do their day-to-day job in a SAFe environment. 
One way to avoid this regression is through SAFe Enterprise and the SAFe Community Platform. These solutions enable “beyond classroom” role growth within your organization.

Avoid burnout

The LACE has to extend and sustain the transformation. This is almost too much. Creating a plan to balance capacity is a good way to ensure this challenge does not affect the centralized LACE. Consider augmenting your capacity with external partner experts.

Assessment Success Patterns

Create a working agreement and coach leadership that the assessments are not about judgment but to foster continuous improvement. You can use the following statements to help communicate the value of assessment:

  • Be realistic; otherwise, there’s nothing to learn. 
  • We can always get better together. 
  • The more you do it, the more we can improve. 

Create a safe space for assessment; feeling threatened will create more reservations in engagement. Build camaraderie as a team. 

Bonus tips:

  • Encourage participants to take their time on the assessment, especially if it’s the first time they’re experiencing a particular assessment. 
  • Discuss the meaning of the questions to ensure the responses are informed. 
  • Set the foundation that assessments will be taken every PI. Help participants understand what’s in it for them and how you will use the assessment to help them. 

For more assessment success patterns, watch this webinar.

Webinar: Common Daily Challenges of a LACE

Decentralized

Locally-funded LACEs sometimes emerge in different business units. These LACEs are typically responding to a local need to adopt Lean-Agile in that particular group.

Siloeing is a common challenge for decentralized LACEs. Without consistent communication and collaboration, LACEs can lose cross-functional benefits and miss out on economies of scale with tooling and training acquisition.

One way to solve this challenge is through inter-LACE collaboration, which is one of the themes we found in our research. Ideas for collaboration include:

  • Coach collaboration on success patterns, materials, and tooling 
  • Global LACE Communities of Practice that meet regularly (once a PI) to discuss knowledge, PI Plans, and success patterns
  • Monthly LACE syncs

Read the Network/Meshed section to learn more about how to incorporate these collaboration opportunities.

Hub and Spoke

The Hub and Spoke structure fosters more LACE collaboration and mutual reinforcement of transformation goals. The same pressures and changes that prompt a shift from a centralized to decentralized LACE still apply to the Hub and Spoke formation. Specifically, the Hub and Spoke formation is designed to drive uniformity in messaging, practices, and overarching goals throughout an enterprise.

Hub vs. Spoke Roles

To keep the transformation consistent but not too prescriptive, the “hub” and “spoke” LACEs have different roles:

  • The central hub creates overall messaging, language, overarching goals, and foundational practices for the transformation. It also develops success patterns to share with the various “spoke” centers. These success patterns form a foundation for any smaller LACE that’s formed to support new transformation areas and business units. The central hub also houses funding for personnel and common tooling used by all LACEs.  
  • The Hub can provide the value of standardization where it matters to the other LACEs. This can include the following examples:
    • Offer enterprise-wide classes to help employee advancement and role-based learning needs for new hires
    • Common toolsets for Agile work tracking
    • Standards for Epic to story work taxonomy
    • Job architectures and career paths for Agile roles
    • An Enterprise subscription to SAFe
    • Enterprise-level Lean Portfolio management solutions
  • The individual, smaller spoke LACEs use goals from the central LACE and contextualize them to their team’s function and capabilities. The primary focus of the local LACE is still to achieve business outcomes for their local business unit or group. 

The LACEs that support individual business units have the authority to adapt the transformation to their needs, including funding. This structure allows the LACEs to maintain the right balance of consistency and necessary adaptation.

Smaller LACEs can also rely on the hub for support or capacity.

Responsibilities

Some of the new responsibilities at this stage include

  • Fostering SAFe Communities of Practice (CoPs)
  • Offer enterprise-wide classes and training
  • Common toolsets for Agile work tracking
  • Standards for Epic to story work taxonomy
  • Job architectures and career paths for Agile roles
  • An Enterprise subscription to SAFe
  • Introducing Lean Portfolio management solutions
  • Implementing Lean-Agile focus days with guest speakers and presenting internal case studies

Challenges

Although spoke LACEs communicate with the Hub, they don’t necessarily communicate with each other. Most communication routes through the Hub, which could create bottlenecks and information gaps.

Along with new challenges come new opportunities. This LACE structure allows for cleanup of “organically launched” ARTs without sufficient training and coaching that may need to reevaluate their structures and practices. It also allows the transformation to spread to new areas of the business with a common language and method.

Tips

  • Create an implementation roadmap and adapt it over time 
  • Capture and highlight quick wins by delivering what you committed to
  • Manage the transformation flow and visibility through a Kanban

Networked/Meshed

We are excited about the emergence of this new pattern, which is not currently included in the Framework article as it was only recently uncovered in our research. This Networked/Meshed formation comprises a collaborative, connected network of LACEs that work together to accomplish the transformation.

LACEs in this formation are several years into their transformation and morph into a more collaborative dynamic instead of competitive against each other. Network/Meshed model LACEs now help each other when capacity allows and leverage the hub LACE for standards and items that provide economies of scale. They share success patterns, findings, and common challenges.

The main priority of the Network/Meshed model is to sustain the transformation while growing it to new business units. The initially-trained business units must retain their effectiveness and commitment to Agile work while the LACE focuses on new business units. Those groups must be self-sustaining to ensure a successful transformation long term.

Some of the new LACE responsibilities at this stage include:

  • Promoting continuing Lean-Agile education 
  • Extending Lean-Agile practices to other areas of the company, including Lean Budgets, Lean Portfolio Management, contracts, and human resources 
  • Helping to establish relentless improvement (see Accelerate in the Implementation Roadmap)

Some of the major challenges include:

  • Sustaining the transformation
  • Managing complexity
  • Finding people to support Enterprise transformation

We’ll cover these challenges more in a later section.

New opportunities for this model:

  • Coaches can collaborate to support others when capacity and knowledge allow across the enterprise
  • Global LACE CoPs allow experts to gather at a regular cadence to share knowledge, PI Plans, and what they’ve found in practices and patterns
  • Monthly LACE sync with LACE members or leaders

Common LACE Challenges

Some of the LACE challenges we’ve uncovered apply to all formations. Many of these challenges are rooted in the same question: how do we sustain our transformation? We asked LACE members to identify their top concerns, and the following graphic outlines their poll responses.

LACE Top Concerns

Challenge 1: Understaffed

Example: Demands are growing; especially from non-IT business areas that want to learn more about the Lean-Agile approach.

An understaffed LACE is a common problem, and it’s most prevalent when there is a need to accelerate the transformation to show a bigger impact. One way to overcome this challenge is to borrow expertise from other LACEs. Another option is to augment capacity with external partner experts.

Challenge 2: Budgeting for the LACE

Example: We don’t have the funding to do needed training. To start the LACE, members need a basic level of SAFe knowledge. Specific roles also need to understand their part in the LACE and transformation. Lack of funding to adequately train these roles creates a block for the LACE. 

In addition, there are other costs related to external coaching, SAFe events, standardized tooling, and attending conferences to name a few.  Here are examples of what the participating LACEs indicated they budget for every year:

LACE Budget Items

One possible solution is SAFe Enterprise

We learned in our research that the SAFe Enterprise subscription was useful in these surprising ways:

  • One LACE found it easier than asking for class funding from each group they need to train, which can discourage departments from sending their people to training.
  • Another LACE had the clever approach of offering Enterprise level SAFe classes and self-funding the subscription through classes. In other words, subscription funding is centralized and back-charged.

Challenge 3: Sustaining the transformation

Example: How do we make sure the groups we invested in are still on track now that we’ve moved to other areas?

We recommend a few approaches to solve this issue.

  • First, build resilience to weather leadership changes. Leadership needs to do more than support the transformation. They must participate in and accelerate the change through coaching, establishing relationships, and helping people succeed and do the right things for customers. 
  • Second, provide support after class with tools, resources, and additional learnings to help support a new way of working. SAFe Enterprise is a powerful enabler because it gives anyone using SAFe access to the full system, including training, on-demand learning, business agility assessments, and executive workshops. 
  • Third, tune-up organically formed ARTs. You may want to revisit some of the first ARTs you launched to apply new learnings or practices you’ve honed throughout the transformation process.

Challenge 4: How do I make my impact as a LACE visible?

Example: How do we show our progress and return on investment as a LACE? 

Establishing your baseline metrics is critical for showing impact. You can use these metrics to share successes along the journey through the implementation roadmap you’ve created. And you can start with whichever metrics make sense at the time, knowing they will evolve. 

Share your progress and impact widely. Use Intranet pages, employee town halls and meetings, physical boards in high-traffic areas in your office, or a cadence of LACE debriefs with a Q&A made available to the organization.  

Your responsibility as a LACE includes active and continuous communication with the organization about what you do and the impact it’s having. Not only will it fuel the transformation, but it will also help your LACE sustain the funding they need to continue to deliver value.

Early measurements at the team level

From the beginning, you can measure flow metrics like Flow Time. How long does it take to bring value to customers in various areas? The Team and Technical Agility assessment is also a great source to help the team identify the next opportunity for improvement. 

Mature measurements at the ART level

At the ART level, you can understand how ARTs release features. Start with predictability since it’s captured every PI. Flow metrics at the ART level are equally important.

On a portfolio level, it’s important to understand how long it takes to bring an idea to customers. This time can be broken into decision and implementation. Once you have this baseline, you can show how the time it takes to make decisions and implement them shrinks over time. 

Aside from time, measure whether the right investments are prioritized through tracking OKRs for the Strategic Themes. Look for indications of “agility” within the LPM decision-makers, either through anecdotal examples or measures of stopped or discarded initiatives due to a change in value compared to other investments.

Ways to make transformation metrics visible

Depending on if your organization is remote or in-person, there are a variety of ways to make transformation metrics visible. Choose one or some combination based on what works best in your organization. 

  • Create a dashboard with descriptions of the metrics, how to interpret them, and coaching guidance (if you want to do X, here’s what to think about) 
  • Use a visual management tool like iObeya for remote teams or business units
  • Create flipcharts and make them clearly visible to everyone in an office setting

And don’t consider any wins too small to share. You want leadership to see what you’re accomplishing, even if they’re small wins that will lead to larger initiatives in the future.

FAQs and More Learning

Should the LACE operate like an Agile team?

Yes, the LACE needs to operate like an Agile team. This helps members of the LACE model the Agile behaviors and mindsets they’re coaching others to emulate. 

To do this, start with the basic Agile team structure, like Scrum or Kanban, and then ART-level ceremonies and artifacts, like PI planning and a roadmap.

Should we include external contractors in our LACE?

If external contractors are on-site partnering with you for a transformation, you can use their knowledge to evolve the LACE and to coach and mentor your coaches or develop internal SPC or coach skills.

What role does the LACE play in LPM?

The LACE brings expertise and knowledge to implement LPM. They often teach the LPM course to the PMO and portfolio management groups. They also enable the groups that will own LPM operations in the long run through mentoring and co-facilitating the early LPM events.

Typically, in the long run, LPM facilitation/operation transitions to the portfolio operations group.

More Learning Resources

A SAFe Fellow, Deema Dajani helps large institutions create the environment to shape disruption like a startup with business agility and Lean Portfolio Management (LPM). Deema currently serves as a Scaled Agile Product Management Director focused on enabling sustainable SAFe transformations at scale. Co-founder of Women in Agile, a non-profit organization focused on breaking barriers and inclusivity in the Agile community. Connect with Deema on LinkedIn.

My Release Train Engineer Career Path: Transition from RTE to Enterprise Agile Coach

Enterprise Agile Coach

Recently I’ve transitioned from working as a Release Train Engineer (RTE) to an Enterprise Agile Coach. While the RTE career path isn’t always well defined, this has been a rewarding journey personally for my professional development and collectively for growing our organizational capabilities. 

In this blog post, I discuss:

  • Enterprise Agile Coach as a potential development path for RTEs
  • My personal experience nine months into the role and what an Enterprise Agile Coach does in a SAFe® context
  • Learning paths for RTEs and several key insights

Pointing the Release Train Engineer Career Path toward Enterprise Agile Coach

If you look at the SAFe Big Picture (in any configuration), you can quickly identify Agile coaching roles at the team (Scrum Master) and program level (Release Train Engineer). But beyond these roles, the development path isn’t always clear. 

Release Train Engineer

What are the opportunities for Release Train Engineers?

To start, current Release Train Engineers could look at either a Solutions Train Engineer (STE) or a SAFe® Program Consultant (SPC) role. STE is a good progression, but the role only exists in very large enterprises (typically comprising thousands of people) building large solutions (for example, cyber-physical) that require multiple ARTs for development. SPC is a much more common role because it is required at organizations of any size. SPCs play a critical part in implementing SAFe.

But, because SAFe leverages the concept of a dual-operating system (proposed by John Kotter), SPC is often more a set of responsibilities than a specific position. So although many RTEs become certified SPCs to deepen their knowledge of SAFe and increase their own SAFe transformation capabilities, SPC is their next credential but not their next job title.

Enterprise Agile Coach is a common job title for someone who operates at an organizational level and works across organizational boundaries to coach Agile transformations and enable business agility.

These functions make Enterprise Agile Coach an excellent progression for an RTE whose scope has expanded beyond an ART to a broader role in their organization.

Release Train Engineer

What Does an Enterprise Agile Coach Do? My Experience After Nine Months

After working in my current organization for six months, it became clear the role had grown significantly beyond Release Train Engineer. I found myself increasingly leading a SAFe implementation rather than facilitating an ART. I was also managing an Agile delivery function/department with Scrum Masters working on projects operating outside of SAFe. I was promoted to Enterprise Agile Coach to recognize these responsibilities and to make my role clearer across the organization. 

Some of my new Enterprise Agile Coach responsibilities, which are described in SAFe, include:

  • Delivering and provisioning SAFe training across the business
  • Establishing a Lean-Agile Center of Excellence (LACE)
  • Value Stream identification and onboarding new teams onto our ARTs
  • Extending practices to the portfolio level
  • Leading Communities of Practice

RTEs or Scrum Masters may occasionally do (or directly support) some of this work, but there is an essential distinction between leading and contributing to these activities. Additionally, RTEs and Scrum Masters have program and team-level responsibilities that they need the capacity to focus on.

My new role also encompasses leading an Agile delivery function/department, which has a wider scope than our current SAFe implementation. Some of our delivery teams work outside our SAFe ARTs on independent projects with fixed durations. Taking a more complete and integrated view of how we deliver our value streams and projects has allowed us to gain a broader range of perspectives and insights, share knowledge, and apply standard practices across teams when beneficial. 

In my experience, the biggest shift from RTE to Enterprise Agile Coach has been learning to influence across organizational boundaries and starting to more fully apply systems thinking (SAFe Principle #2). This includes partnering with departments beyond Product and Technology (like HR) to examine the impact of policies, consider the working environment, and remove systemic impediments. I’ve also gained a better understanding of how value flows across the organization rather than just focusing on optimizing development activities.

One of the challenges that I had not anticipated was the amount of work needed to develop my own personal leadership capabilities. Here are a few of the practices I’ve found beneficial for building a new skill set:

  • Regular professional coaching
  • Developmental practices such as meditation and journaling
  • Leadership self-assessments
  • Enterprise Coaching Mastercamp

Additionally, I’ve continued reading widely to expand my knowledge in some of the disciplines listed in the next section.

Going Beyond Release Train Engineer Skills: My Key Learnings

Enterprise Agile Coaching is shaped by a wide range of disciplines. If you’re interested in moving to Enterprise Agile Coach, some of the areas you might start exploring include:

  • Systems thinking and complexity theory
  • Organizational design
  • Organizational change process
  • Developmental theory
  • Leadership development
  • SPC certification (for advanced knowledge of SAFe)
Release Train Engineer

Some of the ideas and concepts that immediately resonated with my own experience are:

  • Holons – The concept that something is simultaneously a whole in and of itself but also a part of a larger whole (see Arthur Koestler, Ken Wilber, and Michael K. Spayd). This is a useful way to consider individuals, teams, ARTs, and the enterprise. 
  • Fractals – Patterns reoccur at various scales, and this occurs throughout the organization (Mandelbrot).
  • Developmental stage models – Understanding how organizations can be centered in a developmental stage and how their worldviews and values affect the system and culture (see Clare Graves, Don Beck, Ken Wilber, and Frederic Laloux).

Defining Your Release Train Engineer Career Path: More Resources

Enterprise coaching can be very challenging but is also incredibly rewarding. Working more holistically as an Enterprise Agile Coach across the organization has broadened my perspective and understanding of how systems work. 

My previous work as an RTE gave me access to program-level perspectives and insights invaluable to my current role. For any RTE that wants to move into Enterprise Agile Coaching, I recommend seeking out mentors and peers to help support you in your learning journey, adopting a strong growth mindset, and investing in your own development as a leader. 

From Our Team

Defining your RTE career path can start now with a few small steps. Below are more resources you can use to improve your daily practice as an RTE and clarify your professional development path:

About Tom Boswell

Tom Boswell is an Enterprise Agile Coach

Tom Boswell is an Enterprise Agile Coach and certified SPC and RTE. He has worked at multiple organizations using SAFe, coaching at the team, program, and enterprise levels. He is passionate about lifelong learning, helping others grow, empowering teams, and co-creating more meaningful workplaces. Connect with Tom on LinkedIn or at www.tomboswell.com.

Kick-starting the SAFe Journey at a Traditional Organization – Implementing SAFe

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?
  • Which SAFe configuration are you using and why?

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.

SAFe implementation
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:

  1. Case for change and communication strategy (organization readiness)
  2. Capacity allocation for various work types (organization readiness)
  3. Capacity allocation of subject matter experts for enablers (content readiness)
  4. Team topology at the ART and team levels (organization readiness)
  5. Training and workshops, including SAFe® for Teams, before PI Planning (enabler)

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
SAFe implementation
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

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

racey Orphey is a SAFe-certified Release Train Engineer

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.

Large Solution Refinement: Paving the Super-Highway of Value Delivery

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.

Applying SAFe for Agility
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.

Applying SAFe for Agility
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.

Applying SAFe for Agility
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.

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 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 Malte Kumlehn, Project & Team, Inc.

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.

True Agile Teams and Trains – SAFe Implementation

This is the fourth post in the Practice Makes Permanent series. You can get caught up by reading the first, second, and third posts. 

Any SAFe® implementation relies heavily on one of the 10 Critical Success Factors: Real Agile Teams and Trains. Let’s break this conversation down to make it easier (small batches, right?) and talk about the “Real Agile Teams” part (the next blog in this series will address the “and Trains” part). The “Agile Teams” article does a great job of describing cross-functional, high-performing teams.  

What is a real Agile team? In this post, I hope to avoid the standard message about “what is a team?” and instead share some thought-provoking ideas about what a true

is. 

True Agile Teams

I came to a discovery a few years ago: there is no such thing as an Agile team.

Think about it. The Agile Manifesto Principle 12 states, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” To me, this means that a team never arrives at true agility, but is constantly striving toward agility. Sure, you can call your team Agile. But, as soon as your team believes they have “arrived,” they have begun to stagnate. True agility is only found when we’re eager to learn what’s next to improve, and when we realize how much room for improvement still exists.

If you’ve ever rowed a boat upstream then you know what happens when you stop rowing—you go back downstream.  There is no steady state. If you’re not moving forward, you’re moving backward. This is the reality of relentless improvement and of the spirit of Agile Manifesto Principle 12. Your team(s) may have made incredible progress towards agility, but until you realize it’s a never-ending journey, your path forward will always be in jeopardy.

Agile Teams

Empowered Teams

Leaders often tell me that they want to empower their teams because they believe that empowered teams can deliver more value. That’s a valid belief, but leadership often doesn’t understand that our natural state is empowered. In his book Turn the Ship Around Captain David Marquet stated:

“We’re taught the solution is empowerment. The problem with empowerment programs is that they contain an inherent contradiction between the message and the method. While the message is ‘empowerment,’ the method—it takes me to empower you—fundamentally disempowers employees. That drowns out the message.”

In other words, to empower teams (and team members), we must first acknowledge that we have disempowered them through the systemic constraints we have created. If you want true Agile teams to constantly strive toward agility, the secret is to get out of their way. Create an environment with complete clarity on what needs to be done, then trust the competency of the people you have hired to do the right thing.  As Marquet stated, “We realize that we don’t have the power to give these talents to others, or ‘empower’ them to use them, only the power to prevent them from coming out.”

So how do you empower teams?

Remove Constraints around Team Members

In Team of Teams: New Rules of Engagement for a Complex World, General Stanley McChrystal observed, “For people who perceived themselves as skilled workers, being recast as mindless cogs in a larger machine was degrading.” Businesses hire the best and the brightest they can possibly find, but in many cases, these skilled people are used as the “mindless cogs” in a machine. They’re asked to do small, separated components of work without being allowed to see or add value to the system overall. In many cases, this is due to a lack of clarity. The teams are given only enough information to solve the task at hand, but not enough to apply their shared intelligence to solve the overall problem in the best way possible.

To begin correcting this, apply SAFe Principle #9: Decentralize decision-making by providing clarity of mission. Here is an easy way to get started:

  • Select a decision that typically requires sign-off or approval by management or leadership. Deploying to production is a common example.
  • Ask the person that approves this decision what they are using as criteria to make the approval decision. 
  • Work with the teams to create a framework that will give the approver the confidence that the decision is being reviewed correctly.
  • Provide the information that the approver has to the team so that they can make the decision by combining what they know (local context) with the approver’s vantage point. 

Let the team make the decision but allow the approver to see and hear the decision as it’s being made. I like using  Marquet’s approach to this practice by having the team state something like: “We intend to deploy this package to production. All functional, security, and compliance tests are passing. All code has been checked into version control.  Appropriate code reviews have been completed. The rollback process is in place and has been tested.” Using this statement of intent is a great way to allow teams to make the decision while keeping the approver in the loop. Over time, the approver will gain confidence in the team’s ability to correctly determine this decision.

Now you can move on to the next decision.  And the next, and the next…

Change the Culture

Apply SAFe Principle #8: Unlock the intrinsic motivation of knowledge workers by building a culture of psychological flow. 

Psychological flow is a concept stemming from a 1975 study by Mihály Csíkszentmihályi who measured test subjects’ happiness metrics at random times throughout their days. Csíkszentmihályi discovered that people are at their happiest when they are in an environment of:

  • Intense and focused concentration on the present moment
  • Merging of action and awareness
  • A loss of reflective self-consciousness
  • A sense of personal control or agency over the situation or activity
  • A distortion of temporal experience, as one’s subjective experience of time, is altered
  • Experience of the activity as intrinsically rewarding also referred to as autotelic experience

Boiling this down, people are most happy when faced with a clear challenge that’s not too difficult to achieve and is intrinsically rewarding. 

If you read my previous blogs, then you know that I’m also a motorcycle road racer and instructor. I have experienced psychological flow many times when in a really good battle with fellow competitors. We all know the finish line, we all know the risks (some better than others), and we are hyper-focused on achieving our goals. This is my happy place. And one of the best parts of this flow is the ability to talk with my fellow racers, who previously wanted to beat me to the finish line but now want to share the experience, after the race. 

There are many ways to improve team culture, but incorporating psychological flow is a critical component.  We all hear about “self-organizing teams” in Agile, but this doesn’t mean the teams self-form. It means they are formed with a purpose and given specific challenges to overcome with minimal guidelines. Leadership’s motivation is to remove impediments from their team’s path even if the leaders are the key impediment. 

If you want to have real teams striving toward agility, one of your first steps is to ensure they are properly challenged. Don’t bring them long lists of requirements. Instead, bring them a problem to solve or an opportunity to embrace. Then step back and watch the engagement begin. Culture changes every day. Take purposeful steps to create the culture needed for real Agile teams.

Crave Fast Feedback

We’ve all heard the need to “fail fast.” At this point, it’s almost cliché. But does it mean we set the teams up so that they will fail quickly? That sounds very demotivating. What fail fast really means is to create an environment where it’s safe to fail. We set out on paths that seem valid, but we continue to look for qualified data that helps with the pivot-or-persevere moments. 

Two things need to happen when we hit those pivot decisions. One, celebrate that we were able to truncate an invalid path before pursuing it too far. Two, incorporate the learning from this pivot so that we’re better prepared to find more successful paths and narrow in on the right specifications. For more on this topic, review SAFe Principle #3: Assume variability; preserve options.

Real Agile teams crave feedback that’s accurate, timely, and useful. Teams need fast feedback to quickly fail and invalidate paths; otherwise, they begin to lose focus and validated direction. Do you want to see your teams striving towards agility?  Create an environment where feedback continuously flows to the teams.

“Team Leader” Is an Antipattern

Well, at least in the conventional sense.  Team leads typically have one or more of these traits:

  • They’re the person who has exhibited the most skill
  • They’ve been with the company the longest
  • They have the most application or product knowledge

But are those the right reasons to look to this person for leadership? 

All of us have worked with the “rockstars” of product development. They always have the answer, they can solve just about any problem, and they seem to know how everything works. But why don’t the rockstars create a rock band? Shouldn’t those with that much skill, experience, and knowledge try to bring others up to their level rather than continuing to stand out from the crowd? Solos are great, but we all want to hear music from the whole band. 

safe for teams

Let’s look at a much more successful team lead approach, the Kaizen leader. In my experience, the whole team thrives when its leader is focused on continual, relentless improvement. Since leadership should be a role that is held as needed (rather than a title), team leadership can switch from one person to another as new improvement opportunities arise. Create a team environment where this is part of the culture and becomes part of the team DNA.

Getting Started

When talking about enterprise transformation with internal change agents, I often hear “that won’t work here” or “our culture just doesn’t work that way.” You know what? They’re right. Not with the current culture or reality.

However, remember that culture changes every day. Our job is to implement some of these team approaches to create a culture where transformation can really thrive. Teach, learn, and focus on the fifth lean principle of Pursue Perfection: “Perfection is like infinity. Trying to envision it (and to get there) is actually impossible, but the effort to do so provides inspiration and direction essential to making progress along the path.” To pursue perfection in a team is to be more excited about the journey than the destination. Teach your teams to view the pursuit of perfection as a worthwhile but never-ending journey of improvement.

I hope this post helps you to look at things through a different lens. Look for the next post coming soon that will add some of the same thought-provoking concepts applied to the ART.

About Dwayne Stroman

Dwayne is an Enterprise Transformation Coach and Trainer and SAFe Program

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 Decade in SAFe Adaptation: The Scaled Agile Framework, 10 Years Later

A little SAFe history …

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.

SAFe Adaptation

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.

SAFe Adaptation

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.

SAFe Adaptation

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.

SAFe Adaptation

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 retired, empathetic Lean and Agile leader, practitioner

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.

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.