Let’s talk about retrospectives. Inviting feedback on your team’s performance is a critical part of building a continuous learning culture. Retros can quickly tell you whether your team is still storming and norming (per Tuckman’s stages of group development) or humming with psychological safety.
But we’ve heard stories about retrospectives devolving into blame-a-thons where people just point fingers. Or there are the retros with crickets, because no one wants to speak up. And if you do them after every iteration, retrospectives can easily start to feel stale.
For scrum masters, the ultimate servant leaders, retros can be particularly challenging. You’ve got to keep your team engaged and try to make sure every team member’s voice is heard. You have to get your team to share feedback that’s thoughtful and constructive, rather than critical of individuals or other teams. And you have to facilitate this one-hour event—in all its tense, emotional, or boring glory—into tactical improvement items. No big deal.
Whether your team is phoning it in during retrospectives or you’re just looking for ways to improve yours, here are Leadership agility ideas to try.
1. Start with appreciations.
This retrospective advice comes to us from Lloyd Chaka of Emerson Solutions. Before adding your retro items to the team board, begin with shout-outs to fellow team members. Research shows that giving and receiving recognition can have a huge impact on people’s engagement and productivity. And productivity can improve the entire organization’s performance. Plus, appreciations just feel nice.
2. Play music.
Here’s a tip we learned from Sina Bleckwedel, now an RTE at NXP Semiconductor: Ask your team members what their favorite songs are. Then, start your next retrospective by playing one of those songs. Sina found that playing her team’s preferred music in the background while they were adding items to their retro board helped create a relaxing, fun, and familiar mood.
Hear more tips from Sina, Lloyd, and other scrum masters and RTEs in “Common Daily Challenges of a SAFe Professional” at the SAFe Community Forum.
3. Try out the retrospective templates in SAFe® Collaborate.
If your team’s getting sick of traditional stickies-on-a-board, we’ve got some plug-and-play templates to help you reframe your retros. Here’s one: imagine your team as a sailboat. In the last sprint, what felt like an anchor, and what puts wind in your sails? Log into the SAFe Community Platform, open SAFe Collaborate under the Implement tab and then search for “retro” to see all the templates.
4. Integrate an icebreaker.
Okay, so your team trades memes on Slack or stares at each other’s faces in video chats. That doesn’t mean you really *know* each other. Icebreakers can be a great way to encourage openness and build trust, which is what you need to create retros that are actually helpful. Here are some icebreakers recommended by SAFe scrum masters in the SAFe Community Platform’s Scrum Master Forum, and here’s a huge, crowd-sourced list of even more icebreakers.
5. Pull your retrospective into your daily stand-up.
Turn your stand-up into a quick retro with this great technique suggested by one of our members in the Scrum Master Forum, who learned it from the Chelsea football team. To encourage reflection, accountability, and improvement, ask these four questions during your stand-up. (If you do them near the beginning of the day, ask the questions about yesterday; if you do stand-ups near the end of the day, ask the questions about today):
What did I want to happen yesterday?
What actually happened?
What caused the gap between my plans and reality?
What am I going to do differently, or how could the team help?
If you’ve set your SAFe Community profile to include your role as scrum master, when you log in you’ll now see a dedicated scrum master home page. This page can help you find the scrum master resources you need, faster.
We’ve also developed new guides designed to help you improve your day-to-day facilitation of SAFe events. These facilitation guides reflect input from professional enterprise scrum masters that we think you’ll find extremely useful! Visit the Implement > SAFe Art & Team Events > Team Events page to find guides for running daily stand-ups, iteration planning, iteration reviews and demos, backlog refinement, and of course, iteration retrospectives.
Have fun, do great work, and please share your feedback with us!
About Madi Fisher
Madi is the scrum master for the Information Technology and SAFe® Collaborate teams at Scaled Agile. She believes in the power of people and what they can accomplish as a team. And she loves being the glue that helps teams stick to a common goal—all while having fun. Madi’s secret sauce mixes the spirit of collaboration, a shared vision, and being customer-centric. Connect with Madi on LinkedIn.
We all know that any time you start something new in an organization it takes time to make it stick, and if teams and leaders find value, they will work to keep a program flourishing. The same is true when you implement a Measure and Grow Program within your organization. It takes planning and effort to get it started, but the rewards will definitely outweigh the efforts in the end.
At AgilityHealth®, our Strategists work with organizations every day to help them set up Measure and Grow programs that will succeed based on their individual needs. Through their experiences, they have noticed some consistent patterns across our customers, both commercial and government, for- and non-profit. Understanding these patterns can help you set up a program that’s right for your organization.
Before we jump into the patterns, let’s review what a Measure and Grow program is. Simply stated, it’s how you will measure your progress toward business agility. When we look at how Enterprise Business Agility was defined by Sally Elatta, AgilityHealth Founder, and Evan Leybourne, Founder of the Business Agility Institute, you can see why this is important.
The ability to adapt to change, learn and pivot, deliver at speed, and thrive in a competitive market.
Sally Elatta, CEO AgilityHealth and Evan Leybourn, Founder, Business Agility Institute
We need to maintain our competitive edge, and in the process, make sure that healthy teams remain a priority—especially as we start to identify common patterns across teams.
Patterns
Define how you will measure success.
Bertrand Dupperin said, “Tell me how you will measure me, and I will tell you how I will behave.” This is true of our teams, our team members, and our leaders. After this success criteria have been defined, allow the team members to measure themselves in a safe environment where they can be open and honest about their maturity with a neutral facilitator. The process of actioning on the data is very powerful for teams.
Provide a way to help teams grow after you measure them.
“Measurement without action is worthless data.” (Thanks, Sally, for another great bit of wisdom.) When you set up your Measure and Grow program, make sure it includes a way for teams to learn and mature.
Some of the common ones we see are:
Dojo teams—high-performing teams paired with new or immature teams to help them learn
Pre-defined learning paths for teams using instructor-led or virtual learning
Intentional learning options for teams through Communities of Practice or other options
Pairing/Mentorship/Accountability Partners
Tie the results to the goals.
“Why are we taking the time to do this?” This is a common question that teams and leaders ask when we are starting Measure and Grow programs. They feel that the time reserved for an Inspect and Adapt session could maybe be used to tie up those last few story points or test cases, when in reality there is a corporate objective to mature the teams. Be sure to share these kinds of goals with your teams and managers so they understand that this is important to the organization.
Provide a maturity roadmap that takes the subjectivity out of the questions.
We all have an idea of what “good” looks like, but without a shared understanding of “good”, my “good” might be a 3, my teammate’s might be a 4, someone else’s might be a 2, and so on. When you share a common maturity roadmap to provide context for your assessment, your results will be less subjective.
Measure at multiple levels so that you can correlate the results.
When we just look at maturity from the team perspective, we get one view of an organization. When we look at maturity from the leadership and stakeholder perspectives, we get another view. When we look at both together—the sandwich model—we get a three-dimensional view and can start to surmise cause and effect. This gives a clearer picture of how an organization is performing.
Minimize competing priorities and platforms.
Almost all teams, regardless of organization, share that there are too many systems, too many priorities, too many everything (except maybe pizza slices …). Be sure to schedule your measurement and retrospective time when the team is taking a natural break in their work. Teams should take the time to do a strategic retrospective on how they are working together at the end of every PI during their Inspect and Adapt, so use that time wisely.
Engage the leaders in the process.
When this becomes a “we” exercise and not a “you” exercise, then there is a sense of trust that is built between the teams and their leaders. Inevitably the teams are going to ask the leaders for assistance in removing obstacles. If the leaders are on board from the start and are expecting this, and they start removing them, this creates an atmosphere of psychological safety where teams can be honest about what they need and leaders can be honest about what they expect.
Remember, this is all change, and change takes time.
Roy T. Bennett said, “Change begins at the end of your comfort zone.” It takes time, perseverance, and some uncomfortable conversations to change an organization and help it to grow. But in the end, it’s worth doing.
Get Started
Setting up a Measure and Grow program isn’t without its struggles, but for the organizations and teams that put the time and effort into doing it right, the rewards far outweigh the work that goes into it. If you would like to chat with us about what it would take to set up your Measure and Grow program, we’re ready to help.
About Trisha Hall
Trisha has been part of AgilityHealth’s Nebraska-based leadership team since 2014. As VP of Enterprise Solutions, she taps into her 25 years of experience to help organizations bring Business Agility to their companies and help corporate leaders build healthy, high-performing teams. Find Trisha on LinkedIn.
Why do some people find SAFe® to be helpful in empowering teams, while others find implementing the Framework painful? To be honest, both scenarios are equally valid.
As I was beginning to refocus my career on transforming the operating models and management structures of large enterprises, I found that the behavioral patterns of Agile and the operational cadence of Scrum shined a spotlight on an organization’s greatest challenges. As a byproduct of working faster and focusing on flow, impediments became obvious. With the issues surfaced, management had a choice: fix the problems or don’t.
As we scale, the same pattern repeats, though the tax of change is compounded because change is hard. Meaningful change takes time, and the journey isn’t linear. Things get better, things get worse, then they get better again.
Consultants will often reference the Dunning-Kruger curve when selling organizational change.
The Dunning-Kruger curve illustrates change as a smooth journey. One that begins with the status quo, dips as the change is introduced, and then restores efficiency as organizations achieve competence and confidence in the new model. Unfortunately, that’s not how change works, and depicting organizational change this way is misleading.
When I’d spend time doing discovery work with a prospective client, I’d instead cite a more accurate picture of change: the Satir curve. The Satir image depicts the chaos of change and better prepares people for the journey ahead. Change is chaotic, and achieving successful change requires a firm focus on the reason why the change is important—not simply the change itself. Why, then, can a SAFe transformation (or any other change) feel painful? Here are the patterns of SAFe transformation that I observed pre-COVID.
The Silver Bullet
An organization buys ‘the thing’ (SAFe) thinking it’s a silver bullet that will solve all of their problems. For example, the inability to deliver, poor quality, dissatisfied customers, unhappy teammates, and crummy products. SAFe can help address these issues, but not by simply using the Framework. The challenge we often face is that leaders just want ‘the thing.’ Management is too busy to learn what it is that they bought. That’s OK though. They did an Agile transformation once and read the article on Wikipedia.
How can you lead what you don’t know? How can you ask something of your team that you don’t understand yourself? Let’s explore.
Start with Why
Leaders don’t take the time to understand what SAFe is, what problems it intends to help organizations solve, or the intent with which SAFe is best used. Referencing the SAFe Implementation Roadmap, its intent is to avoid some of this pain. We begin by aligning senior leaders with the problems to solve. After all, we’re seeking to solve business problems. As Kotter points out, all change must start with a compelling vision for change.
With the problem identified, we then discuss if SAFe is the best tool to address those concerns. We continue the conversation by training leaders in the new way of working, and more importantly, the new way to think to succeed in the post-digital economy.
Middle Management
Middle management, sometimes distastefully referred to as the ‘frozen middle,’ is the hardest role to fill in an organizational hierarchy. Similar to how puberty serves as the awkward stage between adolescence and adulthood, middle management is the first time that many have positional responsibility, but not yet the authority to truly change the system.
Middle managers are caught in a position where many are forced to choose between doing what’s best for the team and doing what’s best to get the next position soon. Often, when asked to embrace a Lean and Agile way of working, these managers will recognize that being successful in the new system is in contrast to what senior leaders (who bought the silver bullet but could not make time to learn it) are asking of them.
This often manifests in a conversation of outputs over outcomes. In that, success had traditionally been determined by color-coded status reports instead of working product increments and business outcomes. Some middle managers will challenge the old system and others will challenge the new system, but in either context, many feel the pain. This is the product of a changing system and not the middle manager’s fault. But it is the reason why many transformations will reset at some point. The pain felt by middle management can be avoided by engaging the support of the leadership community from the start, but this is often not the case.
Misaligned Agile Release Trains
Many transformations begin somewhere after the first turn on the SAFe Implementation Roadmap. Agile coaches will often engage after someone has, with the best of intentions, decided to launch an Agile Release Train (ART), but hasn’t understood how to do so successfully.
As a result, the first Program Increment, and SAFe, will feel painful. Have you ever seen an ART that is full of handoffs and is unable to deliver anything of value? This pattern emerges when an ART is launched within an existing organizational silo, instead of being organized around the flow of value. When ARTs are launched in this way, the same problems that have existed in the organization for years become more evident and more painful.
For this reason, many Agile and SAFe implementations face a reboot at some point. Feeling the pain, an Agile coach will help leaders understand why they’re not getting the expected results. Here’s where organizations will reconsider the first straight of the Implementation Roadmap, find time for training, and re-launch their ARTs. This usually happens after going through a Value Stream and ART Identification workshop to best understand how to organize so that ARTs are able to deliver value.
Moving Fast Makes Problems More Obvious
Moving fast (or trying to) shines a big spotlight on our problems and forces us to confront them. Problems like organizational silos, toxic cultural norms, bad business architecture, nightmarish tech architecture, cumbersome release management, missing change practices, and the complete inability to see the customer that typically surface when we seek to achieve flow.
The larger and older an organization is, the more problems there are, and the longer it takes to get to a place where our intent can be resized. Truly engaged leadership helps, but it still takes time to undo history. For example, I’ve been working with one large enterprise since 2013. It’s taken eight years since initial contact for the organization to evolve to a place that allowed them to respond to COVID confidently and in a way that actively supports global recovery. Eight years ago, the organization would have struggled to achieve the same outcome.
When I first started working with this organization, it engaged in multi-year, strategic planning, and only released new value to its customers once every three years. The conceptual architecture diagram resembled a plate of spaghetti—people spent more time building consensus than building products. And the state of the organization’s operations included laying people off with a Post-it note on their monitor and an escort off-campus.
Today, the organization is much healthier in every way imaginable. It’s vastly better than it was, but not nearly as good as it will be. The leadership team focuses on operational integrity, and how maintainable, scalable, and stable the architecture is—and recognizes that the team is one of the most important assets.
Embracing Lean and Agile ways of working at scale begins with the first ART launch. It continues with additional ART launches, a reconsideration of how we approach strategy, technology, and customers. And it accelerates as we focus on better applying the Lean-Agile mindset, values, and principles on a daily basis. This is the journey to #BecomingAgile so that we can best position the team and our assets to serve customers.
Change Is Hard
Change takes time, and all meaningful change is painful because the process challenges behavior norms. The larger the organization is, the richer the history, and the longer it may take to achieve the desired outcome. There will be good days, days when things don’t make sense, and days when the team is frustrated. But all of that is OK. You know what else is ok? Feeling frustrated during the change. It’s important to focus on why the change is taking place.
A pre-pandemic pattern (that I suspect may shift) is that change in large organizations often comes with evolution instead of revolution. With the exception of a very few clients, change begins with a team and expands as that team gains success and the patterns begin to reach other adjacent areas of the operation. The change will reach a point where supporting organizational structures must also change to achieve business agility.
As mentioned, moving fast with a focus on flow and customer-centricity exposes bottlenecks in the system. At some point, it will become obvious that structures such as procurement, HR, incentive models, and finance are bottlenecks to greater agility. And, when an organization begins to tackle these challenges, really cool things start to happen. People behave based on how they are incentivized, and compensation and performance are typically at odds with the mindset, values, and principles that are the foundation of SAFe.
Let’s Work Together
SAFe itself is not inherently painful. The Framework is a library of integrated patterns that have proven successful when paired with the intent of a Lean-Agile mindset, set of core values, and guiding principles. Organizations can best mitigate the pain associated with change by understanding what’s changing, the reason why the change is being introduced, and a deliberate focus on sound change-management practices. If you’re working in a SAFe ecosystem that feels challenging, share your experience in the General Discussion Group forum on the SAFe Community Platform. Our community is full of practitioners who represent all stages of the Satir change curve, and who can offer their advice, suggestions, and empathy. Together, we’ll make the world a better place to work.
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.
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.
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), 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.
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.
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.
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?”
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.
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.
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.
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
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.
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. 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.
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
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.
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?
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 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.”
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:
Understand the SAFe exam format
Study for the SAFe exam by interacting with the content in multiple ways
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
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 clues to understand the key knowledge being tested: Action words are a great way to determine what is being asked inside the question and what level of knowledge is being tested. This can help you dive deep to find the answer.
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 it’s probably incorrect unless the answer is obviously true.
Make predictions: After reading the question, guess the answer before reading the choices. If one of them is the same as the answer you came up with, it’s probably the correct one.
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 return to later during the exam. Review the instructions at the beginning of the exam to understand how to flag.
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.
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.
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.
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
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
Take the SAFe exam as soon after class completion as possible. For the best chance of success, we recommend waiting no more than 30 days. Also, 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.
About Emma Ropski
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.
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.
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.
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.
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.
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.