Category: Resources

Podcasts, videos, customer stories, blog posts, white papers, press kit images

SAFe® Program Dependency Board Retrospective – PI Planning and Execution

Posted on

Learning from the program dependency board

SAFe® Program Dependency Board Retrospective

The SAFe program board, or program dependency board, is a key artifact used in PI Planning and execution. The Agile Release Train (ART) teams and stakeholders used it to align, anticipate risks, and adapt the plan accordingly.

This inspection and adaptation of the plan based on insights from the program dependency board is first-loop learning—making changes in the plan based on what we see.

Deeper learning from the program dependency board

What we rarely see, though, is deeper learning from what the program dependency board shows us. It’s like the good old times where you would see a project manager/PMO working their Microsoft Project Gantt Chart, moving things around, but rarely stopping to ask deeper questions around the base structure of their plans and why they’re based on a waterfall model.

Program dependency boards can drive deeper learning about the structure of our ART and its alignment with the kind of mission/vision we’re pursuing, and the backlog of features we’re working on. If we see too much red yarn on our boards, it isn’t something to be proud of. Yes, we can be proud that we identified the dependency and even more that we were able to massage our PI plan to deal with it in a reasonable way. But too much red yarn means too many dependencies. Too many dependencies mean our Value Stream network isn’t configured well. It means we should probably look at ways to reconfigure the network (meaning restructure teams and maybe even the ART).

When to do this deeper learning

I get it. This sort of learning is hard to pursue in the heat of PI Planning. And all too often when PI Planning is done and we have a workable plan in hand, it’s tempting to just move into execution. Resist the temptation. Let the dust settle, but find the time that makes sense to have a deeper retrospective that is based on the patterns you see on the program board. This can be a good discussion in your Scrum of Scrums or with an extended forum that includes the wider ART leadership.

SAFe® Program Dependency Board Retrospective

There’s no need to wait for the next inspection and adapt (I&A). It’s fresh now and outcomes from this retrospective might anyhow require a lot of refinement and consideration before they’re actionable. Start the process early in the PI, so hopefully, you’ll be in a position to reconfigure the network going into the next PI as needed.

A typical pattern is when such a retrospective raises the need to rerun a Value Stream identification (VSI) workshop.

Validating the Value Stream design hypothesis—a key but often skipped step

Speaking of the VSI workshop, one key element in it that many practitioners skip is the validation of your Value Stream design hypothesis. After identifying a development Value Stream, run some water through the pipes—take some work in the form of Features or even higher-level Epics/Themes and explore how they will flow through this Value Stream/ART/Solution ART. If the work flows nicely with a minimal number of dependencies, you found a good setup. If even in this ‘dry run’ you already see you have too many dependencies, time to rework the design!

PI Planning dry run

And yes, what this dry run means is that ideally, even in this early phase, before even launching the ART, you should consider doing a light version of PI Planning with the Value Stream design you have in mind to see that it makes sense. You don’t want to train everybody, spend a serious amount of time on preparing to launch the ART, and then find it’s not a self-sufficient ART or that it’s comprised of teams that aren’t self-sufficient.

Summary

I’ve talked about some recommended SAFe best practices here—some are implicitly mentioned in SAFe, and some complement the formal guidance. The key point I wanted to make is how important is it to aim for the right Value Stream network and to continuously inspect and adapt so that value can easily flow with minimal dependencies and slowdowns. And if your Value Stream network is configured well, everything else becomes much easier.

If you’d like to read more about my SAFe experiences in the trenches, I’ve written an e-book. I’ll also be at the upcoming 2020 Global SAFe Summit on the Agile Marketing panel, at the AgileSparks booth in the Partner Marketplace, and at the SAFe Experts Coaching Station. I look forward to connecting with you.

About Yuval Yeret

Yuval Yeret is the head of AgileSparks (a Scaled Agile Partner)

Yuval Yeret is the head of AgileSparks (a Scaled Agile Partner) in the United States where he leads enterprise-level Agile implementations. He’s also the steward of The AgileSparks Way and the firm’s SAFe, Flow/Kanban, and Agile Marketing. Yuval is a SAFe Program Consultant Trainer (SPCT5), a Professional Scrum.org Trainer (PST), an internationally recognized Kanban Trainer, a thought leader, recipient of the Lean/Kanban Brickell Key Award, and a frequent speaker at industry conferences.

View all posts by Yuval Yeret

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: The Power of Informal Learning Networks

Read the Blog Post

The Power of Informal Learning Networks

Posted on
Learning Networks

I can remember the exact moment when I went from being a transactional learner to a lifelong learner. I was in a meeting with my leader at that time, checking in on how things were going. “Just keep doing what you’re doing,” was his response. I don’t know if any of you have heard those six words in a corporate setting, but they were life-changing for me in terms of learning.

When I heard those six words, my immediate thought was that I didn’t want to. It felt like my learning journey was about to be stalled.  With that in mind, I started to think long and hard about what I wanted to pursue next in terms of my career, and what I needed to learn in order to get there.  Knowing that there were no current opportunities for formal, external training, I had to find another way to continue my learning journey. 

Through these reflections, I realized that I didn’t always have to attend external training or a conference to keep learning. Don’t get me wrong, I’m grateful for all of the events I’ve had the opportunity to attend, all the times I shared what I learned with my colleagues, and how doing that helped me deepen my learning.

My aha moment came when I started to think about how I could learn from other associates in my enterprise and share what I learned with them. What I didn’t expect was that while learning from others, I uncovered a wealth of knowledge and experience in my own enterprise that was way beyond my expectations. And here I was, just starting to tap into it!

My first learning network

It was a typical cold and snowy day in January in Chicago when I started my first conversation around creating an informal learning network. What happened as a result forever changed how I approached learning. Another Agile coach in a completely different business unit and geographic location reached out to me to inquire about some of the workshops that I was creating and facilitating. Throughout our conversation, he shared some of the amazing things he was doing to coach his Lean-Agile transformation, and connected me with some other coaches and trainers in the organization. The more we collaborated, the more we learned from and with each other, and the more excited we were to start additional learning networks within and across our business units.

Fast forward more than three years and a move to another company, I’m still part of a number of informal learning networks with many of my colleagues from that organization. Every time we learn something new that we feel would be beneficial to the others in the network, we share it. And we learn more every time we share in these moments.   

What is a learning network?

If you were to research the words “learning network” via books or an online search, you might come up empty. There isn’t much out there on the topic. In fact, I was excited one day to see “learning network” listed in the index of one of my learning books. But it pointed me toward networks in general, which wasn’t helpful. Not long after that I was telling a colleague about one of my informal learning collaborations and I called it a learning network. It just seemed like the right way to describe it.

Learning Networks

So, here’s my personal definition: A learning network is a community of people with a passion for learning and growing. Often, these are formal gatherings; you’ve probably been a part of one at some point in your career. Now, let’s extend that definition to an informal learning network where a community of people catalyze learning in and through others across and beyond their enterprises. I drafted this broad definition based on my own personal experiences reading books and articles, watching videos, and through lots of conversations with colleagues around the world.

Now that we’ve got a working definition, let’s dive into exactly what comprises an informal learning network.

Characteristics of informal learning networks

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.

Learning Networks

And here’s something else I’ve learned about informal learning networks that grow over time. The most important skill you need to improve as a learner is to start asking questions like:

  • How do I learn faster?
  • What will you do about it? This happens when you realize you want to learn something and no one in your network has that skill.
  • What more can I be doing?
  • What can I change?
  • How do I sharpen my skills in this area?

Learning networks are successful in part because of some informal assumptions. An open-door policy (everyone is welcome), the fact that there are no rules, and that there’s no planned start or perceived end.

Sharing and reflecting

There is a flow to a typical conversation where people share and then reflect.

I know what you’re thinking: “How do people in these networks do their day-to-day work and still have time for these network activities?” 

Learning Networks

Engaging and spending time within these networks is not a time-consuming effort that is separate from current initiatives. Rather, it complements and enhances current delivery. Imagine if you were interested in working on a specific feature, yet didn’t have all of the knowledge and experience that was needed to accomplish it. Rather than pursuing something else to work on, you became curious about who in your network, or enterprise, may have the skill you need and would be open to offering you the opportunity to learn from them. This is one of the best ways to create learning organizations and extend them across an entire enterprise to create a continuous learning culture.  

Your personal learning journey

I believe learning within an enterprise takes on many forms, shapes, and sizes. I believe that the learning networks that I’ll be introducing to you in this blog series are the best kept secrets in enterprises today. And I also believe that each and every one of you, as change leaders, are best positioned to tap into these networks to create a continuous learning culture.

So, my challenge for you is to start thinking about your own personal learning journey and how these learning networks can help you along the way.

Continue your personal learning journey by reading the second post in my series about how learning networks emerge, the third post about how to uncover those networks, and my final post about connecting your learning networks to SAFe.

About Audrey Boydston

Audrey Boydston is a senior consultant at Scaled Agile

Audrey Boydston is a senior consultant at Scaled Agile and an experienced SPCT, Lean-Agile coach, trainer, and facilitator. Her work focuses on continuous learning, building fundamentals, re-orienting around principles, and helping clients—from senior executives to developers—build networks and communities that support their transformations.

View all posts by Audrey Boydston

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Aligning Global Teams Through Agile Program Management: A Case Study

Read the Blog Post

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

Posted on
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

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Use WSJF to Inspire a Successful SAFe Adoption

Read the Blog Post

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

Posted on
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

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: The SAFe Coach

Read the Blog Post

The SAFe® Coach

Posted on
The SAFe® Coach

Coaching appears in the Scaled Agile Framework® (SAFe®), but there isn’t one place where we define the SAFe coach. According to our recent internal survey of 2,500 SAFe Program Consultants (SPCs), over 70 percent are actively engaged in coaching SAFe implementations. In general, a SAFe coach is a servant leader, someone who can facilitate both change and collaboration at scale. A SAFe coach embodies the attributes of our Lean-Agile mindset as well as a learning and growth attitude to lead by example, while continuously fostering positive change. 

A servant leader

There are many roles or labels the coach could play within a SAFe transformation, including Scrum Master, Release Train Engineer, and SPC. Regardless of the roles and functions inherently associated with a coach, coaching takes place throughout all of SAFe’s core competencies. And all of the competencies have one characteristic in common: to guide organizations in fostering better ways of working. So that we can compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative business solutions.

Within the competencies, servant leadership is unique. It’s a behavior designed to continuously serve the teams, enable product delivery, and benefit the overall enterprise. Using active listening and the collective mindset and principles of SAFe, a coach as a servant leader can become more aware, and more connected to the people within their organization. This approach brings neutrality to the enterprise. So that people feel safe in voicing their thoughts and opinions, and can collaborate to realize the benefits of shared understanding, innovation, learning, and growth. By embodying servant leadership, a SAFe coach can help the organization increase SAFe’s effectiveness and relentlessly expand collaboration, coordination, knowledge transfer, and consistent information flow. 

A facilitator of change

SAFe’s dual operating system enables efficiency, stability, and the speed of innovation. Another key benefit of this system is the ability to evolve the social structure organized around value: the Agile Release Train (ART). This is brilliant, and as referenced in The Power of Empathetic Leadership in an Evolving World, Chuck Pezeshki writes, “How you set up your social structure is THE critical factor in how knowledge and synergies in design will be created. Using Conway’s Law, one can predict a priori what the functional form of a design will be. It matters who talks to who.” 

The SAFe® Coach

By organizing around value and creating the social structure around the ART, we design a social structure that encourages knowledge sharing and helps us use empathy and design thinking to innovate around the value we’re creating for customers. Pezeshki further states, “Inside the social structure, empathy is the dynamic that creates synergies in design. While empathy is always valuable, even within the simplest social structures—people that connect are much more likely to transfer correct information to each other—it is essential in creative enterprises.” In our world of ever-evolving complexity, creating social structures can help us transfer information that is accurate, reduce risk, and continuously increase the speed of delivering value. 

Coaching these social structures or networks is part of SAFe’s approach to the dual operating system. These networks take the form of virtual organizations such as ARTs or Solution Trains. And within these virtual organizations, coaches need to have personal agency as their own values and behaviors, so they can coach empathetically and address change quickly. The coaches are empowered to serve the social structure by using these synergies, creating knowledge flow, and facilitating positive growth and change. 

A facilitator of collaboration at scale

According to Jean Tabaka, author of Collaboration Explained, Facilitation Skills for Software Project Leaders, there’s an intangible component of team and organizational power fostered by collaboration. That component brings out the best in people, and in turn, the value the enterprise delivers to its customers. 

As agilists, it may seem obvious that collaboration is a key component of building software and systems. It is, after all, called out in the third value of the Agile Manifesto: Customer collaboration over contract negotiation. If your leaders ask you why this is so important as a coach, there’s a deeper understanding of the why that’s reinforced in Jean’s book, and that has decades of history in Lean highlighted in Ikujiro Nonaka’s book The Knowledge-Creating Company. He calls out the tacit knowledge—the valuable and highly subjective insights and intuitions that are in people’s heads and difficult to capture and share. 

Collaboration is what helps make that knowledge transferable, or explicit, within your enterprise. Organizations also benefit from converting tacit knowledge into explicit knowledge because it represents a way to express the inexpressible. When building software and systems at scale, there is obvious complexity. There’s literally no one that has all the knowledge. It’s inherently shared across our valued people across the value streams and the enterprise. It takes thousands, if not tens of thousands of people to build today’s computers, cars, aircraft, and satellites.

This evolution of knowledge sharing helps you grow your business through a culture of understanding and aligning with your company’s overall strategic goals. The expanded mission of SAFe 5.0 is to enable the business agility that is required for enterprises to compete and thrive in the digital age. Facilitating tacit knowledge is critical and supported through the extension, behaviors, and mindset of all the SAFe competencies. It’s also measured through the latest Measure and Grow evaluations of how well the enterprise is progressing toward overall business agility. 

The SAFe coach in the enterprise needs to find ways to coach and continuously improve collaboration. Sharing that tacit knowledge through SAFe events is one of the most powerful ways to allow people to continually innovate and gain the knowledge and collective mindset to integrate and deliver the highest level of value. 

Coaches need coaches, too

A SAFe coach needs an extensive toolbox to evolve and accelerate their organization’s SAFe implementation. There are many tools to support coaches in learning how to be servant leaders and facilitate change and collaboration. None of this comes easy. Can you imagine intuitively knowing how to do all of this in your first SAFe coaching gig? Coaches need coaches, too. We learn from others and vice versa. If we model the SAFe coaching behavior we’d like to evolve, it will become a self-reinforcing learning experience that will enable coaches to help each other, cultures to evolve, and people to be happy and heard. All of this can help us truly become that relentless learning organization that solves some of the world’s largest problems. We could all use a little of that right now.

Here’s where you can learn more about evolving your SAFe coaching expertise: 

Stay tuned for upcoming blog posts on SAFe coaching.

About Jennifer Fawcett

Jennifer Fawcett - a retired, empathetic Lean and Agile leader

Jennifer is a retired, empathetic Lean and Agile leader, practitioner, coach, speaker, and consultant. A SAFe Fellow, she has contributed to and helped develop SAFe content and courseware. Her passion and focus has been in delivering value in the workplace and by creating communities and culture through effective product management, product ownership, executive portfolio coaching, and leadership. She has provided dedicated service in these areas to technology companies for over 35 years.

View all posts by Jennifer Fawcett

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Shared Objectives and Collaborative Sense Making

Read the Blog Post

Shared Objectives and Collaborative Sense-Making: Key to Success – SAFe Best Practices

Posted on
product owners (POs) and product managers (PMs)

Welcome to the third post in our series about SAFe best practices to create a healthy relationship between product owners (POs) and product managers (PMs) that helps to achieve business agility and drives product success. You can check out the previous post here.

In this post, we’ll dive into examples of how you might find yourself in the feature In this post, we’ll dive into examples of how you might find yourself in the feature factory described in our first post. Plus, we’ll offer some thoughts about how to get back to strong PO/PM relationships and focus on delivering value.

Scenario One: Who are you talking to?

Picture this: You’re a PM at a company that’s designing a new app. In the spirit of customer centricity, you’re actively getting feedback. You’re regularly talking to a couple of hyper-engaged customers from Company X. It’s a large company and you’ve got a strong relationship with one of their internal champions who’s easy to get in touch with. During one of these customer feedback sessions, a developer on your team joins the call, too. Afterwards, while you’re confident things are headed in the right direction, your developer wonders out loud why the customer thinks to feature A is great if she really hasn’t used it yet.

Contacting the same customer for feedback on every new thing your company is working on isn’t the best approach. Why? If you’re not careful, you might end up thinking about her as representative of all the rest of your customers with the same job title. That’s likely not the case, so you should also be talking to customers at different companies with different needs for whatever it is you’re building. Another thing to think about: if it’s just you talking to the same customer all the time, you’ll often believe that your organization is always building the right thing. Inviting other people in your organization to collaborate with you on those customer calls might uncover a different perspective, as your developer did in the previous scenario. Having those two or three perspectives in the room is greater as a whole than as individual viewpoints.

Scenario Two: What are you measuring?

product owners (POs) and product managers (PMs)

Picture this: Your organization developed a page on a website and is seeing 20 percent user adoption on that page. As the PM, you think that’s successful because you’re hitting a key performance indicator (KPI) revealing that 20 percent of people logging in are using the page. But your PO feels that’s not necessarily true because the metric represents the same handful of people logging in, not 20 percent of overall users, which is how they interpreted the KPI of “20-percent adoption.” To address the data conflict, you and the PO look at the feature to see what the details of the KPI were. Turns out there aren’t any details, nor is there any mention of baseline metrics. So, neither of you know if the page was successful or not, or if you should pivot or persevere, or what to compare the data to. And the team’s efforts turned into a feature factory because the goals were really about getting the features out the door instead of the goals themselves.

It seems really apparent that PMs and POs need to agree on what measurements translate to a successful outcome, and how they’ll be tracked and interpreted. But we often skip over that part, just assuming all that will be obvious when the time comes. But actually, that assumption often leads to data conflicts. Aligning on metrics is hard work. You may not even know exactly how to measure success yet and you might have to slow down before you speed up, but agreement is critical to avoid future data conflicts.

Get smart 

The same applies to determining the goal of the work and the value to the customer using SMART objectives. Many of us are familiar with these. But really, how often do you and the team take the time to get alignment and a clear, shared understanding of all the details of your objective? Is it specific, measurable, achievable, realistic, and time-bound (SMART)? Or is it just specific but not measurable?

And remember, it’s ok to fail, as long as you’re learning and applying what you learn to improve. The learning part is only possible in a culture that allows for failure, for example, where you’re not hitting the metrics. It’s a culture where people don’t feel the need to mess with the data or avoid committing to a measure from the beginning. It’s part of the innovation process to fail. If the culture doesn’t allow for that, then you’ll get a culture of people that skip that step on purpose to make it look like they’re successful..

The trap of the feature factory is easy to fall into. I hope now that you have a clear path to: 

  • Improve how you collect and perceive customer feedback
  • Write clearer KPIs with baseline metrics
  • Clearly define and align on SMART goals across teams

Armed with this information, you can better recognize the trap, and use your PO/PM relationship to stay out of it. 

Check back soon for another post in our PO/PM success series.

About Lieschen Gargano Quilling

Lieschen Gargano is an Agile coach

Lieschen Gargano is an Agile coach and conflict guru—thanks in part to her master’s degree in conflict resolution. As the scrum master for the marketing team at Scaled Agile, Lieschen loves cultivating new ideas and approaches to Agile to keep things fresh and exciting. She also has a passion for developing best practices for happy teams to deliver value in both development and non-technical environments. Fun fact? “I’m the only person I know of who’s been a scrum master and a scrum half on a rugby team.”

View all posts by Lieschen Gargano Quilling

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Agility Fuel

Read the Blog Post

Agility Fuel – Powering Agile Teams

Posted on
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:

Metric

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

Category

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

Stock

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.

Type

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.

Delay

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.

Limits

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

Discussion:

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

Discussion:

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

Discussion:

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.

Caution

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.

Conclusion

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

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Tips to Pass Your SAFe Exam and Get Certified

Read the Blog Post

How to Pass a SAFe Exam and Get Certified

Posted on
SAFe Exam and Get Certified

I’ve always been a good test-taker. I also spent almost two years teaching students how to raise their scores on standardized tests like the ACT, SAT, PSAT, and HSPT. 

I relied on this previous experience when I studied for and took my SAFe® exam, and it worked. I passed. 

I’m sharing the following study and test-taking guidelines to help you pass your SAFe exam:

  1. Understand the SAFe exam format
  2. Study for the SAFe exam by interacting with the content in multiple ways
  3. Take the SAFe exam in prime condition

Learn more about each tip in the following sections.

Tip One | Understand the SAFe® Exam Format

Before you can begin studying, you should understand the test format and structure. Important things to know about your exam include

  • Exam style
  • Number of questions
  • How much time you have to complete the whole exam
  • Average time per question
  • Passing score
  • Exam rules

SAFe® exam question types

Example of a multiple choice question
Example of a multiple choice exam question

All of our SAFe 6.0 exams are multiple choice (one answer). However, the number of questions and time you have to complete your exam vary. 

Here are some tips for tackling these types of questions:

  • Look for clue words and numbers: Opposite answers usually signal one is correct, absolutes (always, never, every time) are usually incorrect whereas non-absolutes (sometimes, often, seldom) are usually correct, and the verbs and tenses of the correct answers will agree with the subjects and tenses used in the question. 
  • If the answer is only partly true, it’s probably incorrect: Don’t convince yourself an answer is true if it isn’t. We don’t put trick questions in our exams, so unless the answer is obviously true, it’s probably incorrect. 
  • Make predictions: After you’ve read the question, guess what the answer is before reading the choices. If one of them is the same as the answer you came up with, it’s probably the correct one.
  • Review phrases: If answers repeat exactly what was stated in the question, they’re usually incorrect. Additionally, scientific words are usually correct over slang words. 
  • If you get stuck on a question: Skip it and come back. Other questions and answers may jog your memory. Our exam platform, QuestionMark, makes skipping questions easy because you can flag questions to come back to at a later point during the exam.   

To see your specific SAFe exam details, visit the certification exams page in SAFe® Studio.

Tip Two | Interact with the SAFe Exam Content in Multiple Ways

The first way to learn exam content is by participating in your SAFe course. Once you’ve learned the content, here are a few ways to remember it.

Course digital workbook for Leading SAFe®

Step One: Study SAFe® materials

The My Learning section in SAFe® Studio is the best place to start when studying for your exam. When you log in, you’ll see materials for each course you’ve taken. These materials include

  • The course digital workbook
  • The SAFe exam study guide
  • The practice test

Review the course slides and your notes after the class. Then download the SAFe exam study guide provided and read through it.

Example of a SAFe exam study guide

The exam study guide is a great tool for determining what percentage of the exam will be made up of a specific domain and the topics within it. These topics will also show in the feedback reports for both the practice test and exam.

You can also learn from others’ experiences in the SAFe Community Forums. When in doubt about which forum to start with, use the general SAFe discussion group. Someone will guide you to the appropriate forum from there.

Additionally, there are plenty of SAFe videos that break large Framework concepts into smaller, visual pieces that can be easier to study if you’re a visual learner. 

When all else fails, ask a peer who has already passed their exam which materials they found most helpful when studying.

Step Two: Target your weaknesses by taking a practice test

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 this is by taking the practice test in the same conditions in which you’ll take the certification exam. 

In SAFe practice tests, you can see which questions you got wrong but not the correct answers. You can also see a category breakdown and the percentage you got right in each. This breakdown gives you specific topics to focus on when studying.

A screenshot of practice test results
A screenshot of practice test results
A screenshot showing how the practice test displays the breakdown of each category and the percent you got correct
 How the practice test displays the breakdown of each category and the percent you got correct

I recommend using the practice test to guide your studying. Take it after you’ve finished the class before you’ve begun studying earnestly. Then prioritize studying the categories in which you received the lowest scores. 

A word of caution: do not try to memorize the practice test. The questions on the actual exam aren’t the same. 
Focus instead on the concepts. Ensure you’ve clarified all the terms and content you felt shaky on in the practice test.

Step Three: Engage creatively with the content

Now you need to try to learn the material you’re weakest in; reading the articles over and over isn’t going to cut it. These were my favorite ways to engage creatively with the content and study.

Teach the material to someone unfamiliar with it

Explain the Big Picture to someone. If you’re familiar with all of the icons on the Big Picture and can explain them well, you’re in good shape.

Bonus points if it’s someone not familiar with the Big Picture or SAFe. They’ll have many questions to test your knowledge further.

Build a case study

Use a real company, your company, or a fictitious company and try to apply some of the abstract concepts with which you’re struggling. 

While studying for the SPC exam, I created a fake company called Lib’s Lemonade. I outlined its strategic themes and objectives and key results (OKRs). I then made a Lean business case for a proposed product. Finally, 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.

Review your work through a SAFe lens

What matches the Framework? What doesn’t? Does your team write stories using user-story voice? Do you 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. If you have some influence, make some of these changes. Or shadow and learn from someone in your company who works in the same role for which you took the course.

Have someone quiz you on high-level topics

Make flashcards with questions on the front and the answers on the back. Then ask a friend to quiz you with the cards with the question side facing you and the answer side facing them. This method lets you simultaneously see the question while they check the answer on the back.

Find a study partner

If you know someone who took the class with you and is also studying for the exam, meet up to study with them. Ask each other questions, hold each other accountable, and wish each other luck when you take the exam. 

Preparing for an exam with a partner makes it more approachable and can make the experience more fun and comfortable.

Take the SAFe Exam

SAFe Exam and Get Certified

The only thing left is to take the exam. If you’re like me, it’s probably been a while since you last took an exam. 

Here are some of my favorite test-taking tips to help dust off the cobwebs.

Don’t wait until the last minute

You have 30 days after you’ve completed your course to take your exam. Don’t wait until the last two hours of this deadline; it will only increase the pressure. Take the exam when you have the appropriate time, space, internet connection, and quiet to focus.

Track the time

The countdown clock at the top of the screen will help you keep track of the time. Use this to pace yourself throughout the exam.

Read each question carefully

You can also read them aloud to ensure you slow yourself down and reduce your chances of misreading the question. Once you’ve read the question, don’t forget to read all the answer choices, even if you think you know the answer before you’ve read them all. There may be a more correct answer waiting for you to select it.

Review your answers before submitting

Make sure each answer you chose actually answers the question. Also, only change your answer when you know with certainty that your previous answer was a mistake. Changing your answer based on a whim is a bad idea.

Use 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 technique 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 article, 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 prime yourself 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 decrease this anxiety significantly. 

Confidence from studying the content can also ease your nerves. Going into the exam 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 also be a comforting feeling.

Conclusion

Here are some additional resources to help you with studying for and passing the exam:

Please note that we highly discourage visiting websites that claim to have real SAFe exams or answers. Test material changes often, and it’s a violation of our ethics and certification standards to use these resources.

There you have it: the keys to passing a SAFe exam to get certified. And after you pass your exam, don’t forget to claim your well-earned certification badge. Here’s how.

Now it’s time to begin your exam. Good luck from the Scaled Agile, Inc. team! You’ve got this.

Take your exam. You've got this! Log in Now

About Emma Ropski

Emma Ropski scrum master and SAFe Program Consultant

Emma is a Certified SPC and scrum master at Scaled Agile, Inc. As a lifelong learner and teacher, she loves to illustrate, clarify, and simplify to keep all teammates and SAFe learners engaged. Connect with Emma on LinkedIn.

View all posts by Emma Ropski

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Avoid Change Saturation to Land Change Well

Read the Blog Post

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

Posted on

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?

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. 

LPM Team

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) 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

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Experiences Using the IJI Principle Cards

Read the Blog Post

Experiences Using the IJI SAFe Principle Cards – Benefits of SAFe

Posted on

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

Share:

Back to: All Blog Posts

Explore more Blog Posts

Next: Quarantine and COVID-19: Beware of Burnout

Read the Blog Post