Honest Assessments Achieve Real Insights

In this post, I share my experience of running a series of Measure and Grow assessments at a government agency in the UK I’m working with—including the experiments that we decided to run and our learnings during the SAFe transformation process.

The last year has been a voyage of discovery for all of us at Radtac. First, we had to figure out how to deliver training online and still make it an immersive learning experience. Then, we needed to figure out how to do PI Planning online with completely dispersed teams. Once that was sorted, we entered a whole new world of ongoing, remote consulting that included how to run effective Measure and Grow assessments.

In this post, I share my experience of running a series of Measure and Grow assessments at a government agency in the UK I’m working with—including the experiments that we decided to run and our learnings. The agency has already established and runs 15 Agile Release Trains (ARTs). We agreed that we wouldn’t run assessments for 15 ARTs because we wanted to start small and test the process first. Therefore, we picked four ARTs to pilot the assessments and only undertake the Team and Technical Agility and Agile Product Delivery assessments.

Pre-assessment Details

What was really important was that each ART we had selected had an agility assessment pre-briefing where we set the context with the following key messages:

  1. This is NOT a competition between the ARTs to see who had the best assessment.
  2. The assessments will support the LACE in identifying the strengths and development areas across the ARTs.
  3. The results will be presented to leadership in an aggregated form. Each ART will see only their results; no individual ART results will be shared with other ARTs.
  4. The results will identify where leadership can remove impediments that the teams face.
  5. We need an honest assessment to achieve real insight into where leadership and the LACE can help the teams.

In addition, prior to the assessments, we asked the ARTs to:

  1. Briefly review the assessment questions.
  2. Prioritise attendance with core team members with a cross-section of their team.

Conducting the Assessment

The assessment was facilitated by external consultants to provide some challenges to the responses. We allotted 120 minutes for both the Technical and Team Agility and Agile Product Delivery assessments, but most ARTs completed them within 90 minutes. We used Microsoft Teams as our communication tool and Menimeter.com (Menti) to poll the responses.

Each Menti page had five to six questions that the team members were asked to score on a scale of 1 to 5–with 1 being false, 3 being neither false nor true, and 5 is true. To avoid groupthink, we didn’t show the results until all questions and all members had been scored. Because Menti shows a distribution of scores, where there was a range in the scoring, we explored the extremes and asked team members to explain why they thought it was a 1 while others thought it was a 5. On the rare occasion that there was any misunderstanding, we ran the poll again for that set of questions.

Scaled Agile Partners
Some results from the Team and Technical Agility poll.

What we found after the first assessment was that there was still a lot of SAFe® terminologies that people didn’t understand. (Based on this and similar feedback, Scaled Agile recently updated its Business Agility assessment with simpler, clearer terminology. This is helpful for organizations that want to use it before everyone has been trained or even before they’ve decided to adopt SAFe.) So, for the next assessment, we created a glossary of definitions, and for each set of questions before they scored, we reminded them of some of the key terminology definitions.

The other learning was that for some of the questions, team members didn’t have a particular experience, and therefore scored a 1 (false) which distorted the assessment. Going forward, we asked team members to skip the question if they had no experience. We also took a short break between the assessments. And of course, no workshop would be complete without a feedback session at the end, which helped us improve each time we completed the assessments.

Here is a quote from one of the ARTs:

“As a group, we found the Agile Assessment a really useful exercise to take part in. Ultimately, it’s given our supporting team areas to focus on and allowed us to pinpoint areas where we can drive improvements. The distributed scores for each question are where we saw a great deal of value and highlighted differences in opinion between roles. This was made more impactful by having a split of engineers and supporting team roles in the session. The main challenge we had about the session was how we interpreted the questions differently. To overcome this, we had a discussion about each question before starting the scoring, and although this made the process a little longer, it was valuable in ensuring we all had the same understanding.”

Post-assessment Findings

We shared the individual ART results with its team members so that they could consider what they as an ART could improve themselves. As a LACE, we aggregated the results and looked for trends across the four ARTs. Here’s what we presented to the leadership team:

  1. Observations—what did we see across the ARTs?
  2. Insights—what are the consequences of these observations?
  3. Proposed actions—what do we need to do as a LACE and leadership team? We used the Growth Recommendations to provide some inspiration for the actions.

We then made a commitment to the teams that we would provide feedback from the leadership presentations.

Next Steps

We need to run the assessments across the other 11 ARTs and then repeat the assessments every two to three Program Increments.

You can get started with Measure and Grow, including the updated Business Agility assessment and tools on the SAFe® Community Platform.

About Darren

Darren is a director at Radtac, a global agile consulting business

Darren is a director at Radtac, a global agile consulting business based in London that was recently acquired by Cprime. As an SPCT and SAFe® Fellow, Darren is an active agile practitioner and consultant who frequently delivers certified SAFe courses. Darren also serves as treasurer of BCS Kent Branch and co-authored the BCS book, Agile Foundations—Principles, Practices and Frameworks.


Back to: All Blog Posts

Next: Creating Your PI Backlog Content

Creating Your PI Backlog Content – Agility Planning

Glenn Smith and Darren Wilmshurst with Radtac, a Scaled Agile Partner, co-wrote this blog post. 

At the conclusion of Program Increment (PI) Planning, we’re always reminded of something one of our colleagues always says. There’s much to celebrate because we’ve created a set of committed plans. But we first have to complete a retrospective of the PI Planning event (cue groans from everyone in the room) and we “start preparing tomorrow” for the next PI (more groans).

Moreover, the critical path for any PI Planning is the creation of the content, suitably refined and prioritized. Without this, we can’t do any planning! But what does this look like in practice? 

This blog post is aimed at coaches who need to think about the content preparation for the next PI. By that we mean SAFe® Program Consultants (SPCs) supporting the Agile Release Train (ART) and Release Train Engineers (RTEs). But more importantly, Product Management (PM) and System Architects (SA) need to create, refine, prioritize, and socialize the content supported by Product Owners (POs) and Business Owners (BOs). We will explore each of these roles in turn during the course of this post. 

The traditional siloed hierarchy of organizations can engender a ‘this isn’t my job’ attitude. Yet many people and roles need to work together to create a compelling backlog that delivers economic benefits and satisfies your customers.

The visual model below is a high-level view of the intensity of the preparation activity for each of these roles. It isn’t meant to represent the number of hours. That is, high intensity does not mean 100 percent of your time, we just expect more time spent on preparation while recognizing that there will be other things to be done.

PI Backlog Content
Preparation intensity for specific roles.

You will also notice that there is a significant spike in preparation during the Innovation and Planning (IP) Sprint for PM, BOs, POs, and the Teams. This is when PI Planning happens.

Product Management and System Architect

PM and the SA will follow a similar pattern to each other, as their roles are two sides of the same coin—one focused on the outward market and the other technically oriented. They are going to be collaborating and working closely to make sure their respected needs are met and the right balance of the work is correctly scheduled.

Crafting backlog items for an ART, whether they are Business Features or Enabler Features, follow a pattern of Creating, Refining, Prioritising, and Socialising. While overly simplistic, each step could follow the first four iterations of a PI. In the first half of the PI, expect PM and the SA to be looking to the future. This will include looking at upcoming Epics, decomposing existing Epics, and the ART roadmap and associated Architecture Runway.

A common pattern is to see poorly defined Features with weak benefit hypothesis statements and acceptance criteria. It shouldn’t be overlooked how much effort this takes to do well. This is because the work involved isn’t just writing them down in your Agile Lifecycle Management tooling, but working with BOs, talking to a wider stakeholder cohort, including customers, and reviewing market trends. Improving their own understanding of the value proposition and scope enables people on the ART to more easily deliver against it. Through the PI, their effort tapers as other cohorts take the backlog content and prepare for PI Planning.

Business Owners

BOs are key stakeholders and critical friends of the ART. As such, they gradually experience an increasing demand on their time to support creating backlog content throughout the PI—with the most involvement happening during PI Planning. As a cohort, BOs are available when needed by the likes of PM, and actively participate in the System Demos every iteration. Here, they not only get to see the progress of delivery but give feedback to help PM and the POs inspect and adapt the backlog.

We recommend that prioritization be a ‘little and often’ affair. And as it is a team sport, BOs must attend these sessions (these are the little spikes on the BO line in the model).

Product Owners

In a scaled environment, POs serve both the team and the train. In the initial periods of the PI, as you might expect, the PO has both a team execution focus and needs to support PM with Feature creation and refinement. As the content starts to get in better shape for the upcoming PI Planning, PO involvement increases, but with a shift in focus to Feature elaboration and decomposition into drafting user stories to later socialize with the team.

The Team

Through most of the PI, the team is execution-focused, although on hand for those ad hoc, short whiteboard sessions with PM, SAs, and POs. Larger demands on the team’s time should be scheduled like any other demand on their time—after all, work is work! This will be done through the use of exploration enablers in a future PI, or spikes and innovation activities that occur during the IP iteration. Either way, the outcome is gaining knowledge that reduces the uncertainty of future work.

The team’s involvement, however, peaks during the IP iteration when the POs socialize the upcoming backlog of work—the Features and the draft stories they have created. It is during the preparation for PI Planning that the team takes time to understand what is needed and answer questions that need “I’ll look in the code” to find out.

Release Train Engineer and Scrum Master

Hey wait, you didn’t forget about the RTE and Scrum Master (SM), did you? Surely they are just facilitators, we hear you say, what do they have to do with backlog items? But let’s think about this. As facilitators at the train or team level, they are key advocates for the improvement of flow and value delivery. Therefore, it is not unreasonable to expect them to create improvement items that require effort from the teams during the PI. And we know that anything that requires effort from the teams should be planned accordingly.

The items that the RTE and SM will bring to the table for inclusion will likely come from team retrospectives, the Inspect and Adapt problem-solving workshop, or from insight gained from activities like the SAFe® DevOps course.

Creating Content During PI Planning

During each PI Planning session, PM presents the vision, which highlights the proposed features of the solution, along with any relevant upcoming Milestones. While some may feel that at this point in the proceedings the content creation is over for PM, there is actually still work to do. During the planning, there will likely be scope negotiations and prioritization calls needed as the teams get deeper into understanding and scheduling in their breakout sessions.

Similarly, the BOs have a role in adaptive content creation too. Beyond providing the business context in the briefings, they will work with the team to discuss the needed outcomes from the work. And they’ll support PM and the SAs in adapting the scope from what was originally crafted—because tradeoffs need to be made during planning. Discussions with the teams during the assignment of Business Value could influence what gets produced in the upcoming PI too.

While the POs and the Teams need to sequence and plan their stories to maximize economic results, there will almost certainly be variability of scope that will need to be accommodated as new information emerges. This will involve further elaboration, negotiation, planning, and reworking of the content during PI Planning.

In addition, the model shouldn’t be followed religiously, but used to identify who, when, and by how much focus the different roles on the train need to spend to make this happen. While putting an emphasis on the quality of the backlog items is going to help your ART, it alone won’t fix your delivery problems but will act as a key enabler in doing so. 

It is important to give a government health warning at this stage: context is king! While we have given our view on the preparation activities and the intensity, your context will provide a different reflection. In fact, when creating this post, we both had a slightly different approach for prioritization based on our respective experiences. Neither is right or wrong but a reflection on the clients that we have worked with. So please treat the model we have created as a ‘mental model’ and something you can use with your trains to frame a discussion. 

The pattern, while broadly accurate, will change in some situations, particularly if you are preparing for a training launch and this is your first PI. Here, the cadence may be condensed and more focused, but this will be guided by the quality of the backlog content you already have.

A final thought and back to our colleague who says that “PI Planning starts tomorrow.” So does PI Execution. There’s no point in making a team committed to the plans that you have created and then not executing on them. Otherwise, what was the point of PI Planning in the first place?

If we’ve piqued your interest, check out this post about changing a feature in the middle of the PI. It’s a question we always get asked when we teach the Implementing SAFe® class.

About Glenn

Glenn Smith is SAFe program Consultant Trainer (SPCT)

Glenn Smith is SAFe Program Consultant Trainer (SPCT), SPC, and RTE working for Radtac as a consultant and trainer out of the UK. He is a techie at heart, now with a people and process focus supporting organizations globally to improve how they operate in a Lean-Agile way. You will find him regularly talking at conferences and writing about his experiences to share his knowledge.


Back to: All Blog Posts

Next: We’re Giving More Than a Donation for Pride Month

Three Steps to Prepare for a Successful Value Stream Workshop – SAFe Transformation

Value Stream Workshop

The Value Stream and Agile Release Train (ART) identification workshop are some of the most critical steps to generate meaningful results from your SAFe transformation. That’s because it enables you to respond faster to customer needs by organizing around value. This workshop can also be the hardest step. It’s complex and politically charged, so organizations often skip or mismanage it.

A savvy change agent would invest in the organizational and cultural readiness to improve the chances of its success. Attempting to shortcut or breeze through change readiness would be the same as putting your foot on the brake at the same time you’re trying to accelerate. Get this workshop right, and you’ll be well on your way to a successful SAFe implementation.

Why Is It So Difficult? 

Aside from the complex mechanics of identifying your value streams, there is also a people component that adds to the challenge. Leaders are often misaligned about the implications of the workshop, and it can be tough to get the right participants to attend.  For example, a people leader could soon realize that ARTs may be organized in a way that crosses multiple reporting relationships, raising the concern of their direct reports joining ARTs that don’t report to them. 

In reflecting on my battle scars from the field, I’ve distilled my advice to three steps to prepare the organization for a successful workshop.

Step 1: Engage the right participants

The Value Stream and ART identification workshop can only be effective and valuable if the right audience is present and engaged. This is the first step to ensure the outcome of the workshop solves for the whole system and breaks through organizational silos.

“… and If you can’t come, send no one.” —W. Edwards Deming

The required attendees will fall into four broad categories:

  • Executives and leaders with the authority required to form ARTs that cut across silos.
  • Business owners and stakeholders who can speak to the operational activities of the business, including ones with security and compliance concerns.
  • Technical design authorities and development managers who can identify impacted systems and are responsible for the people who are working on them.
  • Lean-Agile Center of Excellence and change agents supporting the SAFe implementation and facilitating the workshop.

Use some guiding questions to identify the right audience for the workshop within your organization. Are the participants empowered to make organizational decisions? Do the participants represent the whole value stream? Is the number of attendees within a reasonable range to make effective decisions?

Step 2: Build leadership support and pre-align expectations

To support engagement and address potential resistance, I recommend performing a series of interactions with leaders in advance of the workshop. In such interactions, the change agent would socialize a crisp and compelling case for change in the organization, supporting the “why” behind running the workshop.

The change agent needs to be prepared to address leader trepidation about the possibility of having their reporting-line personnel on ARTs that they don’t fully own.  Most compelling is a data-based case made by performing value-stream mapping with real project data to expose the delays in value delivery due to organizational handoffs. 

Interaction opportunities can include one-on-one empathy interviews, attending staff meetings, internal focus groups, and overview sessions open to all workshop participants. 

I highly advise setting expectations with leaders in advance of the workshop. This will help them understand the workshop implications, help identify potential misalignment or resistance, and coach them in how to signal support for the workshop purpose.  

The following are useful expectations to set with the participants in advance to help shape how they view the upcoming workshop:

Value Stream Workshop
  • Allow the designs to emerge during the session. This is meant as a collaborative workshop.
  • Expect to be active and on your feet during the session, actively contributing to the designs.
  • Be present and free up your schedule for the duration of the workshop as key organizational decisions are being made.
  • Alleviate the anxiety of broad, big-bang change by clarifying that they get to influence the implementation plan and timing to launch the ARTs.
  • Address the misconception about organizational change by explaining that ARTs are “virtual” organizations, and that reporting lines need not be disrupted.

Step 3: Prepare the workshop facilitators

A successful Value Stream and ART identification workshop will have the main facilitator, ideally someone with experience running this workshop. Additionally, you’ll need a facilitator, typically an SPC, per every group of six to eight attendees. Prior to the workshop date, schedule several facilitator meetings to prepare and align them on the game plan. This will go a long way in helping your facilitators project competence and confidence during the workshop. Discuss the inherent challenges and potential resistance, and how the facilitators can best facilitate such moments. Share insights on change readiness based on the leadership interactions and empathy interviews. Finally, prepare a shared communication backchannel for facilitators, and build in sync points during the event to ensure alignment across the groups.

While these simple steps and readiness recommendations don’t necessarily guarantee a successful workshop, they’re a great starting point. You’ll still need to understand the mechanics of identifying value streams. This is what Adam will cover in the next post in our value stream series. Look for it next week.

In the meantime, check out the new Organize Around Value page on the SAFe Community Platform.

About Deema Dajani

Deema Dajani is a Certified SAFe® Program Consultant Trainer (SPCT).

Deema Dajani is a Certified SAFe® Program Consultant Trainer (SPCT).
Drawing on her successful startup background and an MBA from Kellogg Northwestern University, Deema helps large enterprises thrive through successful Agile transformations. Deema is passionate about organizing Agile communities for good, and helped co-found the Women in Agile nonprofit. She’s also a frequent speaker at Agile conferences and most recently contributed to a book on business agility.

View all posts by Deema Dajani


Back to: All Blog Posts

Next: Leading the SAFe® Conversation to Win Over Your Peers

Aligning Global Teams Through Agile Program Management: A Case Study – Agile Transformation

Agile Program Management

Like many organizations, Planview operates globally, with headquarters in Austin, Texas, and offices in Stockholm and Bangalore. About two years ago, we launched a company-wide initiative to rewire our organization and embrace Agile ways of working—not just in product and R&D, but across every department and team, starting with marketing. We developed three go-to-market (GTM) teams, whose goals and objectives centered around building marketing campaigns to create a pipeline for sales. Each team aligned to a different buyer group, with members from the product, marketing, and sales.

The challenge: integrating international teams in our Agile transformation

Like many organizations, we struggled to align and execute our marketing programs across our international teams, defaulting to “North-America-first efforts” that other regions were then left to replicate. As we built out these new groups, we considered how to best include our five-person team of regionally aligned field and demand marketers in Europe, the Middle East, and Africa (EMEA).

At the beginning of our Agile transformation, the EMEA marketers were often misaligned and disconnected from big-picture plans. The EMEA teams were running different campaigns from those in North America. Before forming cross-functional GTM teams, the EMEA team had to individually meet with the different functions in marketing, product marketing, and other departments. The extra complications of time zones and cultures also made it difficult to get things done and stay on strategy.

With team members feeling disconnected, at Planview we suffered lower-impact campaigns and less-than-ideal demand generation. To succeed in our Agile transformation journey, it was critical to properly align the international team through an integrated Agile program management strategy.

The approach: forming and integrating the EMEA team into Agile program management

While the three GTM teams had dedicated cross-functional members representing demand generation, content strategy, and product marketing, it was clear that assigning an EMEA team member to each of these teams wouldn’t solve the problem. Each EMEA marketer is organized by region and language, not by GTM Agile Release Train (ART), so we needed to develop our own EMEA Agile program that would meet the challenges and achieve the needed international alignment.

Agile Program Management

Working with our Chief Marketing Officer and other stakeholders, we determined that we would continue to align our EMEA team by region/language. Now that the GTM teams were formed (with each team having all the necessary people to deliver end-to-end value), the EMEA team could meet with each team in the context of the prioritized strategic initiatives. Drawing on our local expertise, we could weigh the campaigns from the three GTM teams against each other to determine which would drive the most pipeline and impact in each region. This structure enabled EMEA marketers to opt into GTM campaigns that were regionally impactful, instead of creating standalone campaigns. This approach has been a success. At our last PI planning event, EMEA progressed from just replicating campaigns into co-planning and co-creating the campaigns that were of local interest and fit.

By including the distributed teams in Agile program management, we achieved better alignment as a global marketing team; gave our EMEA marketers the opportunity to leverage fully supported, regionally impactful campaigns; and ultimately, achieved better results for our demand generation campaigns.

Learning 1: When starting the process of shifting to an Agile approach, there is an advantage in letting the GTM team form, storm, and norm before involving the EMEA team. That delay allows for the EMEA team to finish up previously committed (sales-agreed-upon) deliverables. It gives the team and the sales stakeholders time to observe and see the benefits of Agile GTM teams without feeling that they are not getting the support they were expecting.

The practice: virtual, inclusive PI planning

Our model continues to evolve in a positive way. We’ve now been through five PI planning events and have transitioned from a “one EMEA representative” approach to including our full marketing team in a truly global planning event.

What does a global planning event look like in practice?

When our EMEA team started to participate in PI planning, we had one representative join to understand the process and feed the critical milestones into the team’s plans. We then matured to the full team joining remotely, which meant that we needed to create a system that would enable inclusive planning across continents.

We created a process of “continuous planning.” First, our global team would plan “together,” from Austin and virtually via web conferencing for EMEA. Our EMEA teams would log off during the evenings in their time zones, and the US team would continue to plan with recorded readouts. The next morning, while the US teams were offline, the EMEA teams would listen to the readouts, adapt plans accordingly, and provide their own readouts on changes made once the team was back together during mutual business hours. While tricky at first, this process ensured that everyone was engaged and that all teams’ contributions were heard and considered. Most recently, we’ve conducted fully virtual planning in mutual time zones.

Learning 2: The gradual inclusion in PI planning meant the GTM teams were already well-established and well-versed in the process. The maturity of the teams and the process helped a lot in the inclusion of the international team.

The results: greater alignment, faster time-to-market, better campaigns

Agile Program Management

The impact of our EMEA Agile program can be broken down into three main categories: alignment, time, and utilization.

The collaboration between the EMEA and GTM teams has created significantly stronger connection and alignment, evidenced by both the improvement in campaign quality and our working practices. Our teams have increased visibility into shared and separate work and developed a better understanding of how decisions impact overarching shared goals.

Our Agile ceremonies, combined with the use of Planview LeanKit, have served as a catalyst and a framework to bring us closer together. Communication is easier, more frequent, and more productive, as everyone is aligned to the same goals and plans and has visibility into each other’s progress, needs, and capacity. The greater team can now make conscious trade-offs based on mutual priorities, which enables the EMEA team to focus on the right things and deemphasize asks that are not aligned to the goals. EMEA marketers feel more involved and have an important seat at the table. That is both motivating and effective.

Learning 3: Ceremonies and visual planning tools are absolutely necessary, but only really benefit teams with the right enablement and coaching. To this day we still meet weekly with our Agile coach to refine our LeanKit board and discuss WIP limits, sizing, retros, etc.

From a time-to-market perspective, we’ve seen substantial improvements. Before aligning EMEA to the GTM teams, there were delays in deploying campaigns because EMEA would “find out” about campaigns rather than being part of them from the beginning. Now, the team can give early input and feedback on how a campaign could be adapted to provide the most impact for EMEA, then roll it out more quickly. As a concrete example, we have reduced the time for campaign tactics to go live from three months to three weeks.

The volume and quality of campaigns and campaign materials has increased significantly as well. In the past, the EMEA team often made do with the materials (especially translated materials) that were available, not the assets that were ideal. There were campaign ideas that we could not realize due to a lack of localized material. Without dedicated resources for EMEA, the team had to share creative and translation services with North American providers, who often needed to prioritize programs led by corporate/North America.

Now that EMEA has full visibility into the North American programs, they know what kind of material is in development.

Scaled Agile

They give input on what is needed to execute campaigns in global markets and when delivery will happen. That means EMEA campaigns can begin at almost the same time as the North American ones, and their marketers can prepare for when translated assets and other materials will be available.

Overall, by transforming our EMEA Agile program, the region went from running one or two campaigns each PI to running five campaigns per PI. EMEA marketing went from approximately four to six new localized assets/materials per year to 18 – 20. We added three translated, campaign-specific landing pages per language. And, most importantly, we’re beginning to see direct indication of pipeline improvements.

Agile program management can be challenging with international, distributed teams. By integrating our global team members into our planning processes from the beginning of our Agile transformation, we’ve been able to achieve measurable benefits across the marketing organization.

About Verena Bergfors

Verena is the Marketing Director for Planview’s EMEA markets

Verena is the Marketing Director for Planview’s EMEA markets. She’s from Germany but moved to Sweden around 10 years ago and has been with Planview for over four years. Prior to living in Sweden, she worked in Shanghai for seven years where she held positions in marketing and sales. Verena’s true passion is languages and she enjoys working on diverse international teams.

View all posts by Verena Bergfors


Back to: All Blog Posts

Next: Use WSJF to Inspire a Successful SAFe Adoption

Use WSJF to Inspire a Successful SAFe® Adoption – Agile for Business

SAFe® Adoption

By definition, Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs to produce maximum economic benefit. Utilizing WSJF relies on the Cost of Delay and job size to determine its weight in priority. Think of the Cost of Delay as the price you pay for not delivering a feature to the end-user in a timely manner. For instance, if you know a competitor is also working on a similar initiative to yours, you can acknowledge the risk of losing customers if the experience you deliver pales in comparison.

I like to refer to WSJF as a tool that helps you take the emotion and politics out of a decision and rely on facts instead. WSJF allows us to take an economic view and not be swayed by the loudest complainer (aka squeaky wheel) or the person with the longest title in the room.

I’m sure we can all relate to being in a prioritization meeting either before, during, or after your SAFe® adoption where people demand that their feature be the top priority. But what they can’t clearly explain is why they want it, why that feature is important to the business, end-user, or buyer, and how it aligns with the organization’s purpose. After the WSJF exercise, participants often assume that the biggest, most needed items will find their way to the top of the priority list and are surprised by what features actually get selected. Remember, in Agile, we like to show value quickly. So, WSJF also helps participants identify features that could be too large to ever get to the top, forcing them to break down the work into more manageable batches.

Here’s an example from a retail company I worked with. The company’s top priority at the time was a single-sign-on (SSO) integration feature that was considered critical to improving the user experience. SSO was all everyone was talking about. So, after going through the WSJF exercise, a marketing executive was surprised that aspects of their SSO integration weren’t at the top of the list. The conversation surrounding this—which, by the way, involved the squeaky wheel and the person with the longest tile—enabled participants to break the work down into smaller batches. Everyone involved in the discussion got the context they needed to see that by changing the scope of the work, teams could provide incremental value to customers more quickly. We then went back through the WSJF exercise with the smaller batches of work, some of which moved to the top of the priority list and others moved further down.

Going through this exercise gave participants the context and information to explain:

  • Why and when items were being delivered
  • How customers would be delighted with ongoing improvements versus one large release in the future

Having those key stakeholders in the room allowed us to work through the tough conversations and gain alignment more quickly. That’s not to say the conversations were any easier. But showing how the larger batches of work could be broken down into small batches provided proper context based on end-user value and faster delivery.

In the end, WSJF doesn’t only help an organization deliver the most value in the shortest amount of time, it also fosters decentralized decision-making. This requires your RTE or Product Managers to be steadfast in their approach to ensure trust and belief in the process. When members of the team see leadership supporting this new approach, even when that leader’s feature doesn’t land at the top, it goes a long way in building the trust and culture to inspire a successful SAFe adoption.

About Elizabeth Wilson

Elizabeth Wilson

For more than a decade, Elizabeth has successfully led technology projects, and her recent experiences have focused on connected products. As an SPC, she’s highly versed in Agile methodology practices, including SAFe, and leverages that expertise to help companies gain more visibility, achieve faster development cycles, and improve predictability. With a wealth of practical, hands-on experience, Elizabeth brings a unique perspective and contextual stories to guide organizations through their Agile journey.

View all posts by Elizabeth Wilson


Back to: All Blog Posts

Next: The SAFe Coach

Agility Fuel – Powering Agile Teams

Agility Fuel

One of my favorite analogies for agile teams is to compare them to an F-1 race car. These race cars are the result of some of the most precise, high-performance engineering on the planet, and they have quite a bit in common with high-functioning agile teams. Much like F-1 cars, agile teams require the best people, practices, and support that you can deliver in order to get the best performance out of them.

And just like supercar racing machines, agile teams need fuel in order to run. That fuel is what this post is about. In the agile world, the fuel of choice is feedback. I would like to introduce a new ‘lens’ or way of looking at feedback. I’ll leverage some learning from the art of systems thinking to provide a better understanding of what various metrics are and how they impact our systems every day.

Most often, this feedback is directly from the customer, but there are other types as well. We have feedback regarding our processes and feedback from our machinery itself. In broad terms, the feedback in an agile world falls into three different categories:

  1. Process: Feedback on how the team is performing its agility.
  2. DevOps: This is feedback on the machinery of our development efforts.
  3. Product: The so-called ‘Gemba metrics.’ This segment of feedback is where we learn from actual customer interaction with our product.

Thinking in Feedback

Every agile framework embraces systems thinking as a core principle. In this exercise, we are going to use systems thinking to change how we see, interact with, and make predictions from our feedback. If you want to go deeper into systems, please pick up “Thinking in Systems,” by Donella Meadows or “The Fifth Discipline,” by Peter Senge. Either one of these books is a great introduction to systems thinking, but the first one focuses solely on this topic.

For the purposes of this post, we will be thinking about our feedback in the following format:


This is the actual metric, or feedback, that we are going to be collecting and monitoring.


Every feedback loop will be a process-, operational-, or product-focused loop.


Each feedback metric will be impacting some stock within your organization. In each case, we will be talking about how the stock and the feedback are connected to each other.


Balancing: Think of the thermostat in a room; it drives the temperature of the room (the stock) to a specific range and then holds it there. These are balancing feedback loops.

Reinforcing: Because a savings account interest is based on how much is in the account, whenever you add that interest back in, there is more stock (amount in the account) and more interest will be deposited next time. This is a reinforcing feedback loop.


Feedback always reports on what has already happened. We must understand the minimum delay that each system has built into it, otherwise system behavior will oscillate as we react to the way things used to be.


We will talk about the limits for each stock/feedback pair so that you can understand them, and know when a system is operating correctly, but has just hit a limit.

A Few Examples

Let’s look at one example metric from each category so that you can see how to look at metrics with this lens.

ART Velocity

Agility Fuel


ART velocity impacts two stocks: Program Backlog and Features Shipped, both of which are metrics themselves. In both cases, ART Velocity is a balancing loop since it is attempting to drive those metrics in particular directions. It drives Program Backlog to zero and Features Shipped steadily upward. In neither case will the stock add back into itself like an interest-bearing savings account.

The upper limit is the release train’s sustainability. So, things like DevOps culture, work-life balance, employee satisfaction, and other such concerns will all come into play in dictating the upper limit of how fast your release train can possibly go. The lower limit here is zero, but of course, coaches and leadership will intervene before that happens.

Percent Unit Test Coverage

Agility Fuel


Percent Unit Test Coverage is a simple metric that encapsulates the likelihood of your deployments going smoothly. The closer this metric is to 100 percent, the less troublesome your product deployments will be. The interesting point here is that the delay is strictly limited by your developers’ integration frequency, or how often they check in code. Your release train can improve the cadence of the metric by simply architecting for a faster check-in cadence.

Top Exit Pages

Agility Fuel


This list of pages will illuminate which ones are the last pages your customers see before going elsewhere. This is very enlightening because any page other than proper logouts, or thank-you-for-your-purchase pages, is possibly problematic. Product teams should be constantly aware of top exit pages that exist anywhere within the customer journey before the value is delivered.

This metric directly impacts your product backlog but is less concerned with how much of anything is in that backlog and more of what is in there. This metric should be initiating conversations about how to remedy any potential problem that the Top Exit pages might be a symptom of.


Yes, agility fuel is in fact metrics. Actual, meaningful metrics about how things are running in your development shop. But here is the thing about metrics … I have never met a metric that I could not beat, and your developers are no different. So, how do we embrace metrics as a control measure without the agile teams working the metric to optimize their reward at the cost of effective delivery?

The answer is simple: values. In order for anything in this blog post to work, you need to be building a culture that takes care of its people, corrects errors without punitive punishment, and where trust is pervasive in all human interactions. If the leadership cannot trust the team or the team cannot trust its leadership, then these metrics can do much more harm than good. Please proceed with this cautionary note in mind.


This blog post has been a quick intro to a new way of looking at metrics: as agility fuel. In order to make sense of how your high-performance machine is operating you must understand the feedback loops and stocks that those loops impact. If this work interests you, please pay attention to our deep-dive blog posts over on AllisonAgile.com. Soon, we’ll be posting much more in-depth analysis of metrics and how they impact decisions that agile leaders must make.

About Allison Agile

Lee Allison is a SAFe 5.0 Program Consultant

Lee Allison is a SAFe 5.0 Program Consultant who implements Scaled Agile across the country. He fell in love with Agile over a decade ago when he saw how positively it can impact people’s work lives. He is the CEO of Allison Agile, LLC, which is central and south Texas’ original Scaled Agile Partner.

View all posts by Allison Agile


Back to: All Blog Posts

Next: Tips to Pass Your SAFe Exam and Get Certified

Tips to Pass Your SAFe Exam and Get Certified

SAFe Exam and Get Certified

I’ve always been a good test-taker. I was a model student with great grades in K – 12 schooling and beyond. I also spent almost two years full-time teaching students how to raise their scores on standardized tests like the ACT, SAT, PSAT, and HSPT. I know tests and test-taking! Still, I put off my SPC exam until I only had a few days remaining. I can clearly remember crossing my fingers, holding my breath, and clicking the submit button, eyes intent on the screen … “You passed!” Commence happy dance. 

Yet my journey to being Certified SAFe® started long before that happy day. To get there, I applied the same guidelines that I used with my former students. 

Know your exam

You first must know what it is that you must conquer. You need to know the style of the exam, the number of questions, how much time you have to complete the whole exam, the average time per question, the passing score, and the rules of the exam. You can find all of the information you need on our certification webpages

Know the exam content

To be Certified SAFe means you have “the skills, knowledge, and experience required to successfully perform the job in a SAFe working environment.” This means that if you pass the Product Owner/Product Manager exam, you’re showing that you can successfully perform the role of a SAFe Product Owner on the job. hat’s a high bar, and it’s powerful! It’s no wonder that simply attending the course doesn’t cut it. That’s right, attending the class does not equal an exam pass at Scaled Agile. Here are a few ways to get to know exam content outside of being an engaged and willing participant during your course.

safe certification

Step 1: Study SAFe materials.

Review the course slides and your notes after the class. Crack open your Learning Plan, download the study guide provided, and read through it. There you’ll find some suggested reading, the majority of which can be found on the Scaled Agile Framework website. Start with topics that you intuitively know you don’t understand very well. For me, I automatically knew I was not as strong in topics dealing with the portfolio level because I don’t participate in portfolio events, so I read the Lean Portfolio Management and Value Streams articles.

Step 2: Target your weaknesses.

To make the best use of your time, you need to target not only your perceived weaknesses but your objective weaknesses. One of the best ways to do that is by taking the practice test in the same conditions that you’ll take the certification exam. For SAFe 5.0 exams, you can see exactly which questions you got wrong. I know a few people who like to take the practice test again and again and again until they get above a 90 percent. I recommend using the practice test as an assessment tool, not as something to memorize, because your real exam won’t have the same questions. Focus instead on concepts. Make sure that you’ve clarified all the terms and content that you felt shaky on in the practice test.

Step 3: Engage creatively with the content.

So now you need to try to learn the material you’re weakest in; reading the articles over and over again isn’t going to cut it. These were my favorite ways to study:

  • Explain the SAFe Big Picture to someone. If you’re familiar with all of the icons on the Big Picture and can explain it well, you’re in good shape.
  • Build a case study. Use a real company, your company, or a fictitious company and try to apply some of the abstract concepts that you’re struggling with. When I was studying for the SPC exam, I made up a fake company called Lib’s Lemonade. I outlined its strategic themes and objectives and key results (OKRs). I made a Lean business case for a proposed product. I attempted to map the company’s value streams. Bonus points if you share it with someone else who is knowledgeable in SAFe and who can check for correctness.
  • Look at your work through the SAFe lens. What matches with the Framework? What doesn’t? Does your team write stories using user-story voice? Do you really use the IP iteration for innovation and planning? Does your team have WIP limits on its Kanban board? Do you have a scrum master? What would it be like if your company did things differently? Have a conversation with a coworker about these discrepancies. Better yet, if you have some influence, make some of these changes. Or shadow and learn from someone else in your company who works in the same role for which you took the course.

Take the exam

The only thing left to do is bite the bullet and take the exam. Make sure to take your exam within the deadline and ensure you have the time, space, internet connection, and quiet to focus on the test. The countdown clock at the top of the screen will help you keep track of the time. Make sure to read each question carefully and review your answers before submitting. Only change your answer when you know with certainty that your other answer was a mistake. Changing your answer based on a whim is a bad idea. Here are some of my other favorite tips:

Pass the exam

SAFe Exam and Get Certified

The only thing left to do is bite the bullet and take the exam. Make sure to take your exam within the deadline and ensure you have the time, space, internet connection, and quiet to focus on the test. The countdown clock at the top of the screen will help you keep track of the time. Make sure to read each question carefully and review your answers before submitting. Only change your answer when you know with certainty that your other answer was a mistake. Changing your answer based on a whim is a bad idea. Here are some of my other favorite tips:

  • Use the process of elimination. Sometimes when you read the question, you won’t be sure what the correct answer is. But chances are you’ll know that some answers are incorrect. Eliminate them and don’t look at them again. This will free up your working memory to focus on the final two or three options remaining. 
  • Prime your mind. The power of association is strong. And according to this study, the sense of smell most strongly recalls memory. So, if you chew mint gum while studying for your SAFe exam at the desk in your home office at night, research shows that you’ll be better primed to do well on the exam if you chew mint gum while taking your SAFe exam at the desk in your home office at night. Some people use a scented perfume, lotion, or lip balm to elicit the same effect. And as long as you were in a good headspace while studying, you’ll likely be in a good headspace while taking the exam.
  • Calm your nerves. Many people have test anxiety. Knowing what to expect for the exam can help significantly. Being confident from knowing that you studied the content can ease your nerves. Keeping in mind that you are well-prepared always helps. If worse comes to worst, and you don’t pass the exam on the first try, knowing that you can take the exam again and pass can be a comforting feeling.

About Emma Ropski

Emma Ropski scrum master and SAFe Program Consultant

Emma is a certified SAFe 5 Program Consultant and scrum master at Scaled Agile. As a lifelong learner and teacher, she loves to illustrate, clarify, and simplify helpful concepts to keep all teammates and students of SAFe engaged.

View all posts by Emma Ropski


Back to: All Blog Posts

Next: Avoid Change Saturation to Land Change Well

Avoid Change Saturation to Land Change Well with SAFe – Agile Transformation

This is the second post in my short series on landing change well. Read the first post here.

Managing change is as much of an art as it is a science.

As we have learned through decades of project management and big-bang releases, even the best-planned and best-executed changes at large scale can land poorly. 

Consider a large software system change that impacts many disciplines within an organization. The change impacts the HR generalist, who has been doing her job effectively in the legacy system for years. Nobody asked her opinion of the new system and now that the new platform has arrived, she feels confused and inefficient. The same story is playing out with the sales team, finance, legal, product, and others. Big batches of change do not land well, because as people, we don’t handle change well. 

Change is not typically something that we choose; it’s more likely something that is imposed upon us. Change is hard. Change is uncomfortable. Without the perspective of the why, change is outright painful.

Avoid Change Saturation
The Satir Change Model reminds us of the emotional toll of change.

Several years ago while working with a client to adopt new ways of working, I was introduced to the discipline of change management (CM), and since, it has proven to be one of the most effective tools I’ve found to help organizations adopt a Lean-Agile mindset, strategy models, budgeting, and to deliver value.

The CM team helped me better understand the organization, determine who were my advocates and adversaries, as well as develop plans for how to best influence the organization. And, as was introduced to me by Lisa Rocha, how to avoid change saturation through the use of Change Air Traffic Control to ‘land change well.’

One of my favorite things about living in Denver is the drive to the airport. If you are familiar with the city, you know that the airport was built far outside of downtown on the plains (and when you landed in Denver for the first time, I’m sure your thoughts were similar to mine: where are the mountains?!). 

What makes the drive from the city to the airport so interesting is that the lack of terrain combined with the Colorado blue sky makes it easy to see the air traffic patterns. This is a hugely effective metaphor for Lisa’s concept of Change Air Traffic Control: though you may have many changes in flight, you can only land one at a time. 

After thinking deeper about Lisa’s idea, I started to realize that the phases of landing change with SAFe actually match air-traffic patterns rather well.

Avoid Change Saturation
Landing change with SAFe.

Phase 1: Feeder routes
Portfolio funnel

Change begins with an idea. In a Portfolio, these ideas are welcomed by everyone and are captured in the Portfolio funnel, which serves as an initial filter for ideas. Portfolio leadership explores each one and decides if the good idea aligns with the Portfolio strategy, if they want to learn more, or if the Portfolio is not ready to explore the concept at that time. 

Phase 2: Initial approach

Epic analysis

When the Lean Portfolio Management (LPM) team identifies ideas that they are interested in exploring, they conduct an initial analysis to determine the feasibility, Value Stream impact, and other implications through the use of a Lean Business Case. 

This is also the point where the change management team should be engaged to help answer questions around how the change will impact PPTIS, defined as:

People: Who are the people impacted by this change?

Process: What processes are impacted by this change?

Technology: What technology is impacted by this change?

Information: What data is impacted by this change?

Security: How is physical, informational, or personal security impacted by this change?

LPM Team

With the quick picture of the change becoming clear, the LPM team will make a decision whether it’s interested in experimenting further with the idea or not. 

For the ideas earmarked for further experimentation, change managers will begin working with the LPM team to articulate the Vision (the reason why) for the change. As John Kotter often reminds us, people underestimate the power of vision by a factor of 10. 

Phase 3: Intermediate approach
Feature analysis and PI Planning

Once the LPM team has prioritized an idea for investment (considering the Lean Startup Cycle), an MVP of the idea will be defined for the purpose of validating or invalidating the idea within the Continuous Exploration cadence of an Agile Release Train. Working with Product Management and the architecture community, change professionals will start articulating the what, the how, and the why of the change to begin preparing stakeholders who will be impacted. The change impact assessment is updated as a living artifact. 

With guardrails for the work and change established, the solution teams are now ready to build the change. The handoff between strategy and solution happens at PI Planning

Phase 4: Final approach
PI execution

The final approach for introducing change takes place during PI execution. While the Agile Teams are developing the solution representing change, change professionals continue their work by mapping the change to identify who is impacted, the best method to interact with each impacted party, and to determine how each group prefers to receive change.   

This work, performed with the release function, helps prepare the organization and its customers for the release-on-demand trigger for value delivery. 

Phase 5: Land change well

Release on Demand

Once the organization, the customers, or the market determine that the time is right to introduce change, all of the work done by the Portfolio, Agile Release Train, and change professionals will be put into action. 

Though each has done their best to prepare the receiving entity for change, there is more to landing change well than simply preparing. We must also avoid change saturation, which is where the Air Traffic Radar comes in.

Monitoring Change with the Air-traffic Radar

It’s hard to prepare for what you cannot see, and most change falls into that category. To help avoid inundating our organization and our customers with too much change, we need to develop a mechanism to visualize the change that will impact a given audience.The best way I’ve found to describe these learning networks is to share the questions people in these networks are curious about. So, here’s my synthesis of a lot of research around how we share what we learn across enterprises.

air traffic radar

The concept of a change radar involves four perspectives: changes we are inflicting, changes being inflicted by others, changes impacting our internal customers, and changes impacting our external customers. 

To better understand what changes are impacting us, we want to think back to the visual of the air-traffic pattern at the Denver airport: what changes are coming our way and at which horizon. 

With the visual, we can start informing Portfolio and Program prioritization considering our customer’s appetite for change. As is often said: timing is everything. If we land the right change at the wrong time, we run the risk of losing strategic opportunities. 

Change is hard! But with our change partners working with the Portfolio and Agile Release Trains, we can help our organizations achieve Business Agility, deliver value, and land change well.

About Adam Mattis

Adam Mattis is a SAFe Program Consultant Trainer (SPCT)

Adam Mattis is a SAFe Program Consultant Trainer (SPCT) at Scaled Agile with many years of experience overseeing SAFe implementations across a wide range of 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


Back to: All Blog Posts

Next: Experiences Using the IJI Principle Cards

Experiences Using the IJI SAFe Principle Cards – Benefits of SAFe

Games to play with leaders and teams to embed the principles in your organization.

IJI Principle Cards

It’s been over two years since we first launched our popular SAFe® Principle cards. With the advent of SAFe version 5.0, the introduction of a new 10th principle and the launch of a new, updated set of principle cards, it’s a great time to look back at how we’ve been using the cards and the benefits they’ve generated.

This blog post is split into four sections, covering:

  1. A brief introduction to the cards (and where to get them)
  2. Engaging executives and other leaders
  3. Reflecting on how well the principles are being applied
  4. Brightening up training events

A brief introduction to the cards

As one of the first SPCTs in Europe, I’ve delivered more than my fair share of Implementing SAFe® and Leading SAFe® courses, and, to be completely honest, I’ve always struggled to get through all of the principles (I’m usually flagging by principle 6 or 7) and thought there must be some way to make them more accessible. To me, it always felt like we were learning the theory behind the principles rather than getting excited about the principles themselves.

Whilst co-teaching with my colleague, and fellow SAFe Fellow, Brian Tucker, I tried to come up with a simpler, more accessible way for people to engage with, sign up to, and remember the principles. The end result was the set of Ivar Jacobson International (IJI) SAFe Principle cards, now updated with the new 10th principle—Organize Around Value.

IJI Principle Cards

The cards try to do a number of things. For each principle, they:

  • Explain why the principle is important
  • Describe it in a form that is more like a principle and less like an instruction
  • Provide a snappy quote or aphorism that can be used to support it
  • Bring it to life with examples of what awesome and awful behaviour would look like
IJI Principle Cards

All on something the size of a small playing card.

In the old days, the full set would readily fit on one sheet of paper, but now with the introduction of the new 10th principle, we’ve had to expand to two sheets of paper.

The cards are freely available from the IJI website here.

Engaging executives and other leaders

Our experience with executives is that you are unlikely to get them to attend a two-day course or sit through an hour or more’s lecture on the SAFe Principles. They will play the penny game, but their appetite for being talked at is minimal.

This is a shame, as it is absolutely essential that they support and embody the principles in their day-to-day work.

Using the SAFe Principle cards to play the ‘principle ranking’ game, we’ve found that we can get them to engage with, understand, discuss and sign up to the SAFe Principles—all in under 30 minutes (20 is usually enough).

The game itself is very simple and can be played in a number of ways.

It is best played in groups of 3 – 4 people, as this maximizes discussion and ensures that everyone stays engaged throughout.

Equipment: One set of cut cards for each group and one set of uncut cards for each participant. The cut cards will be used to play the game and the uncut cards as a reference. If you want to look up a specific principle, it’s a lot easier to find it on the uncut set of cards than in a pack of cut cards.

The game: Give each group a set of cut principle cards and ask them to rank them in importance to the execution of their business. Separate any that don’t apply, or that they explicitly disagree with, from those that they would actively support.

Once the groups have finished their rankings, ask them if there are any principles they would discard.  We’ve done this many times, at many different organizations, in many different industries and no one has ever discounted or rejected any of the principles. There are a number of ways to produce the ranking:

  • Higher/lower. Someone takes the lead and places the first card on the table. The group discusses and makes sure they understand the principle. The next principle is then selected, discussed, and placed higher or lower relative to the ones already in play. The game continues until all cards are placed.
  • Turn-based. A more formal variation of the previous approach where the members of the group take turns to either add a card to the ranking or reposition one of the cards that have already been played, explaining and discussing their justification as they place or move the cards. The game continues until no one wants to move any of the cards.
  • Four piles. A simplified ranking where you distinguish the top three, the bottom three, and any rejected cards, and leave those not selected in a pile in the middle. This usually results in three piles as typically none are rejected.

Whichever way you choose to rank the cards, remember that it is OK for cards to have the same rank.

The results of the ranking can be interesting, particularly the difference between the different groups—but really this is just a forcing function to make them play with the cards. These pictures show the results from playing this game with a company’s IT leadership team. I’ll leave it as an exercise for the reader to spot which group was the architecture team.

IJI Principle Cards

The real goal of the exercise though isn’t the ranking itself; it’s to get everyone actively engaged with and discussing the principles. The discussions can get quite lively with the participants often referring to the awesome/awful caricatures as well as the descriptions of the principles themselves.

As mentioned above, we’ve never seen any of the principles rejected but we have seen many different rankings. Rankings that often reflect the executive’s area of responsibility— for example, the CFO will typically place the cards in a different order to the head of human resources (HR).

This activity has always gone down really well—it’s active learning, engages everyone in the discussion and doesn’t take a lot of time. It has been so well received we’ve had executives ask to take the cards away to share with their teams. In one case, the head of HR grabbed one of the cards and said, “This is just what I need. I thought one of the ‘Agile’ team leaders was encouraging the wrong behaviours, but I had nothing to challenge them with.”

A good trick to close out the activity is to ask them, as they now understand the principles, “Would you be prepared to sign up to them?” If they say yes, take an uncut set of cards and get them all to physically sign them.

We’ve found that this exercise works almost as well in a virtual environment as it does face-to-face. Using tools such as Mural, it is possible to create an interactive experience that is close to that of playing with the cards face-to-face (but let’s be honest, nothing beats standing up with the cards in your hands).

Reflecting on how well the principles are being applied

The cards are a great tool to use in retrospectives to remind people of the principles they should be applying and to generate actions to encourage everyone to be better at applying them.

One simple way is to use them as a trigger for improvements during a retrospective. The two most effective approaches we have used are:

Pick a card. A very simple activity that throws a bit of randomness into the retrospective process. Every so often (every other retro / once a PI), randomly pick one or two cards to discuss and generate ideas for improvement. To make things fun, you could generate your own awesome and awful examples. The more methodical of you might want to work your way through all the principles one at a time—reducing the set of cards to be picked from each retrospective until you’ve got through all 10.

IJI Principle Cards

Value versus practice.

  1. Create a three-by-three grid with the x-axis being how important the principle is to the group (high, medium, low), and the y-axis being how well the principle is being applied (badly, meh, excellently).
  2. For those in the highly important/badly applied section, discuss what is going on, identify specific examples of bad behaviour, and generate concrete actions for improvement.

You can also use the cards to do a simple principle-based assessment. This is a great complement to the SAFe self-assessments and other practice-based assessments.

The simplest approach is to create a ‘happiness radiator’ with four columns (principle, happy face, neutral face, and sad face) and then get the assessors to tick the relevant box—as shown in the photos below. This can be done at the team level, train level, or even for the whole organization. The important thing is that everyone has their own vote—you want to avoid consensus bias as much as possible.

Note: If people are new to the principles, play the ranking game first to ensure that they understand the principle before voting.

IJI Principle Cards
Here are examples of the cards being used in Mural to perform both the ranking exercise and to build a happiness radiator, respectively.
IJI Principle Cards
The Mural Template for both these exercises is freely available from the IJI website here.

These assessments could, of course, be done without using the cards, but we’ve found that having the cards in their hands really helps people relate to the principle and tick the correct boxes. Even when working virtually, being able to see and manipulate the cards is invaluable.

To make life interesting, the feedback can be generated about a specific community or aspect of the framework such as Product Management and Product Ownership. The table below shows a set of results generated at the Global SAFe Summit in 2017. It also shows the results of performing the assessment at a meetup in Amsterdam.

It is scary how few Product Management Teams are exemplifying the SAFe Principles. I was shocked to see that only 13 percent of the SAFe practitioners surveyed at the SAFe Summit (about 100 people) thought that the Product Managers in their organization took an economic view. If the Product Management Team isn’t adhering to our underlying Lean and Agile principles, then I truly believe this will severely limit how Agile and effective the teams can be. If the Product Managers and Product Owners are not behaving in an Agile way, then there is no way that their teams can be truly Agile.

IJI Principle Cards

To help with these role-based assessments, we have produced sets of role-specific principle cards, one of which is shown on the left.

To get access to these cards and for more information on how to use them, go to the main Principle card page here. RTE and Architect cards are also in the works and will be accessible from the same area.

About Ian Spence

Ian Spence is an Agile coach, SAFe® Fellow

Ian Spence is an Agile coach, SAFe® Fellow, and Chief Scientist at Ivar Jacobson International. He has helped literally hundreds of organizations in their Agile transformations by providing leadership, training, consultancy, facilitation and all levels of coaching. An experienced Agile coach, consultant, team leader, analyst, architect, and scrum master, Ian has practical experience of the full project lifecycle and a proven track record of delivery within the highly competitive and challenging IT solutions environment.

View all posts by Ian Spence


Back to: All Blog Posts

Next: Quarantine and COVID-19: Beware of Burnout

Ten Steps to Landing Meaningful Change Well – Business Agility Planning

Change is hard. 

For more than a decade, I’ve used that simple reminder to start every discovery and transformation engagement. Even with that warning in mind, those responsible for leading change in any business will often underestimate just how hard it can be to land meaningful change well. Change is a very personal thing. Only by proper agility planning one can land meaningful change in any business.

In general, people will process change in three stages, beginning with shock before finally accepting the change and moving on.

Business Agility Planning

Though no formula can smooth the change adoption curve, there are things we can do to help people as they move through the stages of acceptance and shorten the amount of time between shock and ‘the new normal.’

  1. Address the humanness of the system. When introducing change, we are often tempted to focus on the system, the process, or the outcome. We inadvertently marginalize the most critical component to successful change: the people. By placing the people first and doing our best to understand how the change will impact the organization and customers, we can do our best to forecast and mitigate the negative emotions that may emerge. Ask yourself: “What fear may emerge as a result of this change?”
  2. Start with leadership. Change must be thoughtfully led. Too often, change initiatives fail because a leader will issue a directive and then check out. Change needs a champion, and the broader the impact, the stronger advocate that change will need. When leading change, it’s best to be visible, be consistent, empathize with the current, and maintain focus on the goal.
  3. Involve everyone. When introducing change, it’s important that those involved do not feel that there are two sides: those impacted (us) and those imposing (them). Again, change leaders need to create an environment that is empathetic to the pain of change (all of us, together) and keeps those involved focused on the outcome resulting from having changed.
  4. Create a compelling business case. Start with why. Why is this change important? What risk is it mitigating? What opportunity is it enabling? What efficiency will we be able to exploit? How will we be better positioned to serve our customers? John Kotter notes that we underestimate the power of vision by a factor of 10. That perspective proves true no matter the size of change. Without understanding why the pain we are about to endure is worth it, change is harder to overcome.
  5. Create shared ownership. Change in an organization or value stream is not something to be done in isolation. If the change is beholden to a single person or small group, it will matter much less to others and quality will suffer. Change outcomes are a shared responsibility of the team. Creating an all-of-us-together culture helps avoid feelings of pain endured in isolation.
  6. Communicate the message. Communicate the message early, communicate it consistently, and communicate it often. In alignment with the SAFe® Core Values, we must assure alignment and transparency in the system to achieve optimal outcomes.
  7. Assess the cultural landscape. Even if we prepare the organization well for change, even if we say and do all of the right things, organizational culture will dictate how well people in the system process change. I am often reminded of the wise words of Kim Scott: “Culture is what is said in the halls, not what is written on the walls.” Employee engagement surveys, rolling feedback walls, and hallway conversations can go far in helping change leaders understand how people are really feeling.
  8. Address cultural challenges directly. If understanding the cultural landscape is step one, doing something with what you learn is step two. When the pain of change rears its ugly head, change leaders must address this pain immediately and directly. This is not a time for political grandstanding but for using the organization’s own words with a sense of empathy. Remember, as Brené Brown teaches us, being empathetic does not always mean fixing the pain. Simply acknowledging the circumstance and validating how people feel can have a profound impact on morale.
  9. Prepare for the unknown unknown.  As Murphy’s Law reminds us, if something can go wrong, it will. Though there is not a lot we can do to prevent unforeseen circumstances, we can prepare for them. Actively seek risk, break things, pressure test, and create fallback and recovery plans. The SAFe approach to DevOps can serve as a good guide to monitor for and respond to the unknown.
  10. Speak to team members. The most important component in addressing the human element of change is to talk to the people involved. Be visible, be accessible, and be the kind of leader that people trust. When leading change, if you can successfully manage the emotional component, you are well on your way to helping the team land change well.

    The next challenge? Avoid change saturation to land change well. Stay tuned!

About Adam Mattis

Adam Mattis is a SAFe Program Consultant Trainer (SPCT)

Adam Mattis is a SAFe Program Consultant Trainer (SPCT) at Scaled Agile with many years of experience overseeing SAFe implementations across a wide range of 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


Back to: All Blog Posts

Next: POs and PMs: A Dynamic Duo