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

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

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

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

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

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

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

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

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

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

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

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

Avoid Change Saturation
Landing change with SAFe.

Phase 1: Feeder routes
Portfolio funnel

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

Phase 2: Initial approach

Epic analysis

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

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

People: Who are the people impacted by this change?

Process: What processes are impacted by this change?

Technology: What technology is impacted by this change?

Information: What data is impacted by this change?

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

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 headshot

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

Next: Experiences Using the IJI Principle Cards

Experiences Using the IJI SAFe Principle Cards – Benefits of SAFe

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

IJI Principle Cards

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

This blog post is split into four sections, covering:

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

A brief introduction to the cards

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

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

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

Next: Quarantine and COVID-19: Beware of Burnout

Ten Steps to Landing Meaningful Change Well – Business Agility Planning

Change is hard. 

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

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

Business Agility Planning

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

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

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

About Adam Mattis

Adam Mattis headshot

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

Next: POs and PMs: A Dynamic Duo

POs and PMs: A Dynamic Duo – SAFe Best Practices

Welcome to the second post in our series about SAFe best practices to create a healthy relationship between product owners and product managers that drives product success. You can read the first post here.

I’ve heard lots of metaphors used to describe the relationship between a product owner (PO) and a product manager (PM). One of my favorites is oil and vinegar—separately, they’re just liquid on a salad, but mix them together and you’ve got a great dressing.

POs and PMs - A Dynamic Duo

A PO and a PM working together creates a positive tension that leads to a great relationship—despite different opinions—that’s in others’ best interests. But combining the PO and PM into one role is a recipe for disaster. 

I know because I experienced the trouble firsthand.

Think about the core responsibilities for both roles:

  • Be the voice of the customer
  • Analyze data
  • Manage backlogs
  • Make customers happy
  • Organize cross-team syncs
  • Create roadmaps
  • Support planning
  • Seek out competitive intelligence
  • Aid support escalations
  • Help sales activities

One person simply can’t do all these activities in a typical work week. When I’ve been in this situation, I found that the urgent, tactical things come first as people clamor for responses, feedback, and direction on their daily work—ultimately causing important strategies to suffer. Some days, I’d already made two to three stressful decisions before morning tea and was expected to make more at strategic levels. I quickly experienced decision fatigue. When your company and solution are small, you might be able to do it all, but it doesn’t scale.

There’s a strong stereotype that PMs need to be mini CEOs and be just as stressed out. That’s not sustainable as a product person. When a PM is also doing the work of a PO, expecting them to do strategy and manage the team backlog throughout the PI isn’t realistic. You miss the strategic work, you miss pivot-or-persevere opportunities. I’d often ask myself, “Am I really looking at the big picture or just surviving?” 

The power of an Agile team is that it’s a high-functioning group that collaborates. And when the PO and PM roles are performed by two different people, they can work together to support those teams, and ultimately, the organization. When I was a PO working with a PM to deliver a new onboarding experience for our product, we stayed in sync. I focused on what our technology allowed and what the team could implement. She focused on market impact and educating our sales team. We had healthy, productive conversations with positive conflict about what should happen next, and split the duties of attending meetings. All while continuing our business-as-usual activities and still finding time to recharge for the next day.

POs and PMs - A Dynamic Duo

If you’re a leader, avoid having one person take on both roles. If you’re doing both of these jobs, don’t. Perhaps there’s someone in your organization who can help you by serving informally in the other role. Finding the balance that I just described is key to your and your product’s success. POs and PMs don’t have to be in the same places but they need to connect, be aligned, and maintain that positive tension. It’s why we teach these roles together in our SAFe POPM class—you need to know how to best collaborate with your peer PO or PM to excel.

If you’re free on August 26 at 6:00 PM MDT, join Lieschen and I at an online Agile Boulder meetup where we’ll talk about this very topic.

Check back soon for the next post in our series about shared objectives and collaborative ‘sense making.’

About William Kammersell

William Kammersell is a Product Manager and SAFe® Program Consultant (SPC) at Scaled Agile

William Kammersell is a Product Manager and SAFe® Program Consultant (SPC) at Scaled Agile. With over a decade in Agile software development, he loves researching customer problems to deliver valuable solutions and sharing his passion for product development with others. William’s journey as a developer, scrum master, Agile coach, product owner, and product manager has led him through a variety of B2B and B2C industries such as foreign language learning, email marketing, and government contracting.

View all posts by William Kammersell

Share:

Back to: All Blog Posts

Next: How Planview Executed a Successful, Virtual PI Planning

Learn How Planview Executed a Successful Virtual PI Planning – Agility Planning

Virtual PI Planning

Program increment (PI) Planning plays a critical role in ensuring cross-team alignment and collaboration. Typically done as a two-day, in-person event, PI Planning brings teams and leadership together to create program plans based on a shared mission and vision. As our marketing team approached its most recent PI Planning, we faced a challenge: how could we execute a successful PI Planning event in a completely virtual way?

The answer: surprisingly well. In our recent webinar, We Survived Virtual PI Planning, event participants shared how we prepared for virtual PI Planning, what went well, and lessons learned. In this blog post, we take a closer look at how the Planview go-to-market (GTM) ART not only survived virtual PI Planning but pulled it off with flying colors.

Before the event: The importance of preparation

All of the webinar panelists emphasized the importance of preparation. “Preparation always matters for a PI event,” explained Agile Coach Steve Wolfe from Peak Agility. “But it matters even more for a virtual event. We wanted to make sure that we covered every possible item and contingency.”

Steve and I (our part-time RTE) began planning for the virtual event several weeks before it occurred, using a T-minus calendar to ensure conversations started early and occurred often. We first decided on communication platforms, selecting existing enterprise channels Zoom and Slack for ease of use and familiarity. With the standard whiteboards and sticky notes off the table for planning itself, we looked to Planview LeanKit as our visualization tool. Next, we considered timing. Two full days felt long even in person, so we elected to spread the event out over four half-days, in the morning in North America, which ended up being a critical component of the virtual PI planning event’s success.

We developed the event agenda with even greater attention to detail than usual. We consciously limited the number of time people spent just listening, added a dedicated number of inter-and cross-team breakout sessions, and cut back on vision and context content while making it more interactive with an executive Q&A session. In addition, we ran orientation sessions before the virtual PI planning event with leaders, teams, facilitators, and scrum masters to set expectations. We sent out recordings to walk people through the structure of the event and detailed process documentation to explain prep work needed and desired outcomes.

At the team level, leaders like the Director of Product Marketing and GTM Head Brook Appelbaum focused on gaining the vision and context necessary to guide PI planning. “We met with leadership early and often to discuss what was going on with our business and customers,” Brook elaborated. “Now that everyone was distributed, what did it mean for our programs? This gave us direction on how to pause, pivot, or persist with our campaigns and shape our collective understanding of our business going into virtual PI Planning.”

Brook and her peers complemented their meetings with executives, sales, and customer success leaders with a metrics deep dive. “We went through the numbers to see where we were from a pipeline perspective and the details of our programs and campaigns, down to the media, tactics, and channels,” she continued. “It gave us greater insight into what was performing well and what needed to be adjusted.” We also held brainstorming sessions, facilitated by panelist Leyna O’Quinn, content strategist and scrum master. The team talked through their ideas, then compared their inputs to their current backlog items and reprioritized accordingly. This allowed them to bring the most current thinking into PI planning.

Leyna helped the team finish work in progress from its current PI as well, so they could prepare for their final demo and review their backlog. They reviewed metrics, within LeanKit, from the current PI to see what worked and what didn’t, including:

  • Queues, to reflect each work item’s total lifecycle
  • Lead time and cycle time, to understand how long it takes for work to flow through the process
  • Throughput, with information like completed cards per day or week and story points for interaction
  • Cumulative flow, as a visual representation of work in progress as it flows

According to Leyna, “These visual reports and ceremonies allowed the team to have an open dialog and discuss ways to improve processes, tweak our board, and create a culture of continuous improvement.”

During the event: Synchronous engagement and executive commitment

With their thorough preparation behind them, the GTM ART kicked off its fifth PI Planning event—and first fully virtual event.

It quickly became clear that the four half-day approaches was a winner. Head of EMEA Marketing Verena Bergfors described why it mattered to her team. “When it was a two-day event, we couldn’t participate in the whole thing because of the time difference. We had to listen to recordings from the previous day to try to catch up and provide relevant feedback. With the virtual event, we could read out live with everyone listening and adjust and adapt in real-time. It was the first real PI planning that the EMEA team has been able to fully participate in.”

Chief Marketing Officer Cameron van Orman praised the four-day format as well. “Before we went all virtual, we were talking about flying the whole EMEA team out here for face-to-face planning,” Cameron laughed. “There would have been a real cost to that, not just financial but also time and opportunity cost. When we were forced to do it virtually, we saw the power and impact of synchronously planning together across all of our regions.”

Director of Corporate Marketing Leslie Marcotte echoed these sentiments. For her, the virtual PI Planning event allowed for greater collaboration between her shared services organization and the go-to-market teams. The process made work items, like key milestones and deliverables for shared services teams, much more visible and allowed the groups to identify dependencies, increase collaboration, and foster the right conversations. The cross-team breakout sessions were particularly impactful. “It’s much clearer to me how I connect and how I can engage with different teams across the business,” Leslie said.

One of the unexpected benefits of virtual PI Planning played out during the event. During in-person PI planning, executives often pop in and out of sessions, listening to and steering discussions. On reflection, executives and participants alike agreed that this approach could be intrusive and distracting. At the virtual PI Planning event, leaders like Cameron could listen in the background and chime in when appropriate without changing the dynamic of the conversation. It also offered the opportunity for structured time with executives. Planview CEO Greg Gilmore spent 30 minutes with the virtual team communicating his vision while taking questions to create engagement.

Virtual PI Planning

The team’s visualization tool of choice also made a big difference to virtual PI Planning. Agile Coach Steve explained, “LeanKit became essential, enabling us to visualize the whole plan across the entire value stream. Each team had a section to develop their plan during breakouts based on a two-week delivery timeframe. We used colors and cards to quickly visualize the work of each team and connected cards to see dependencies. Boards included links to Zoom breakouts and Slack channels, so from one board, you could get to wherever you needed to go. We used LeanKit before, during, and after the event for everything from readouts to the final confidence vote. It is a powerful tool and a key enabler for pulling off a successful event.”

After the event: Hardening, validation, and continuous improvement

Following the successful conclusion of the four-day virtual PI Planning event, the team focused on validation. “We spent the next week on hardening our plan,” Brook said. “We dedicated time to reviewing and overcommunicating our plans to make sure everyone was on board.” This included readouts in numerous business steering meetings, all the way up to the Board of Directors. The team used its LeanKit boards in those conversations to demonstrate its plans and achieve further alignment.

With their plans validated, the GTM ART went into execution ceremonies and cadences. Immediately after the virtual PI planning event, they hit the ground running with an LPM T-minus calendar. They plan to drive continuous improvement through ongoing communication and collaboration with the business and consistent metrics deep dives that show how they are performing mid-flight, not only at the end of the PI cycle.

Top 5 lessons learned

  1. Prepare thoughtfully and thoroughly. Focus on vision, context, and programs during preparation to create the guardrails that help define plans but resist the urge to go too far into tasks and items before the event.
  2. Create a visual collaboration space. Enterprise-class tooling is critical. Rethink how you can use tools like LeanKit to replace whiteboards and sticky notes and enhance collaboration.
  3. Utilize cross-team breakouts. Every participant in the GTM ART’s virtual PI Planning event found tremendous value in the cross-team breakouts, from tactical benefits to greater empathy for their colleagues.
  4. Engage your executives. An engaged but unobtrusive executive presence demonstrated commitment to the process and the people involved in PI Planning.
  5. Respect your team’s humanness. Virtual PI Planning only worked because its leaders thought hard about the experience. From the four-day structure to frequent breaks to mitigating Zoom fatigue to greater inclusion of global teams, all participants agreed that the event worked well because they were intentional about how it was structured.

“If you’re doing Agile and you’re thinking about doing PI Planning, but you’re hesitant because of the virtual workforce, just do it,” concluded Cameron. “Think about the prep work, visual collaboration, and technology enablers. Have clear outcomes, objectives, and roles. As a business, you can’t wait weeks or months hoping that it will go back to the way it used to be; alignment, shifts, and changes are too important. It may be messy, but there are a lot of things that are better in an all-virtual environment.”

About Emily Peterson

Emily Peterson

Emily Peterson is a demand-gen strategist for Planview’s Lean & Agile Delivery Solution and serves as a part-time RTE for the Go-To-Market Agile Release Train. She uses her professional experience in Agile marketing to leverage new ways of working across the organization, connecting all parts of the business to the overall goals of the organization.

View all posts by Emily Peterson

Share:

Back to: All Blog Posts

Next: Product Owners, Product Managers, and the Feature Factory

Product Owners, Product Managers, and the Feature Factory – SAFe Structure

Product Owners and Product Managers

Both product owners (POs) and product managers (PMs) have “product” in their titles. Both roles connect people to the customer to ensure we’re building the right thing. Both roles rely on data to inform decisions and spot trends by correlating that data to everything that’s going on across the organization. Both roles manage backlogs. And both roles make customers happy. So, what’s the difference between a PO and a PM?

Product managers concentrate on the program backlog and features, look one to three program increments ahead, and focus on product viability. They collaborate with business owners and those at the solution and strategic levels within SAFe®

Product owners concentrate on the team backlog and stories, look one to three months ahead, collaborate with the team, and focus on product feasibility.

Seems straightforward enough, but we’ve heard feedback from people in the field that the PO-PM structure within SAFe isn’t so great.

“I’ve trained dozens of teams who are using SAFe and I have never seen this work well. The Product Owners are disconnected from their users and incapable of creating effective solutions for them that really solve their problems, because they do not understand the problems well. The Product Managers are essentially ‘waterfalling’ down the requirements to them and the teams are not allowed to prove if these are the right things to build or not. No one is doing validation work.” 

—Melissa Perri, Product Manager vs. Product Owner

The feature factory

What’s described above is something many call “the feature factory.” Organizations quickly fall into the feature-factory trap when POs stop talking to external customers, going with the word of the PM instead and losing sight of the user’s needs. It also happens when PMs become disconnected from the teams, choosing to write requirements that are handed off to POs instead of aligning with teams and POs on objectives about how to best achieve them. By not connecting with the team, over time, PMs start making all the decisions on their own and there’s no room for teams to provide ideas to their own backlogs—essentially ‘waterfalling’ their PIs as described above and creating a culture of meeting acceptance criteria instead of focusing on objectives. 

We often also see feature factories when PMs and POs never say “no” to requests from customers or business owners. Catering to the desires of a few large clients or to executives’ individual objectives can cause PMs and POs to drop validation work and strategy in response to those requests. Without validation work, there aren’t any clear pivot-or-persevere moments for checking in to see if we’re understanding the problem correctly or even solving their problems. Instead, we’re practicing waterfall and calling it SAFe.

In this blog series, William Kammersell, our curriculum product manager, and I will share practices to help you avoid the feature factory and create a healthy PO-PM relationship that drives product success.

Read the next post in the series here.

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

Next: Elevate Your Remote Production to Super Awesome

Scrum Master Stories: Building Relationships – Agility Planning

Scrum Master Stories: Building Relationships

Not that long ago, we had a transition in leadership on our team. Our product owner at the time was taking a sabbatical and we were in the process of finding a new one. It was challenging for me as a scrum master to make sure that the team felt grounded and engaged during that time of transition—oftentimes teams lose their sense of direction when big changes happen. But that challenge was then rewarding when the team came together to meet our PI objectives, which included releasing two new courses to market and updating others and having fun in the process.

To keep us on track, we focused on our shared goals. We co-created our iteration goals and reviewed them consistently throughout the iteration to remind ourselves what we were working toward. To keep the team dynamic healthy and strong, I filled a treasure chest with prizes to use during our daily stand-up. The team member who could act out the best emoji animal of the day got to open the treasure chest and pick their prize. This game helped keep things light during the transition.

There’s more to being a scrum master than facilitation, process, and team efficiency. We have the ability to make connections with our teammates and our team members and help them through difficult times. To make sure the team had what they needed, I leaned heavily on the great group of scrum masters that we have at Scaled Agile and pulled from their different viewpoints about team engagement, leadership through uncertainty, and healthy team dynamics. I really cherished those relationships during that time—they inspired me to stay strong for the team and served as my support network in  keeping the team moving forward.

One of my key takeaways from that experience was to trust your intuition. Trust that the relationships you’ve built can impact people in a positive way and get them through something that’s really hard.

About Madi Fisher

Madi Fisher - scrum master for the Information Technology and SAFe® Collaborate team

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.

View all posts by Madi Fisher

Share:

Back to: All Blog Posts

Next: 2020 European SAFe® Summit: Tips for Virtual Attendees

What’s a Product Owner to Do – PO role within SAFe

Product Owner

When I coach companies on Lean and Agile methodologies, I strive to have dedicated, co-located Product Owners (POs), Scrum Masters, and teams. In the 21st century and given our current context, many companies involved in a SAFe® transformation have POs and Scrum Masters who are leading multiple remote teams. 

It can be challenging to coach Agile teams remotely and consistently on the Agile Manifesto and SAFe principles and values, such as Business people and developers must work together daily throughout the project or Program Execution. Often during these transitions, some companies expect an employee to be a part-time PO in addition to his/her day job.

Many times I have had Product Owners ask me to help supervisors understand the time commitment involved with the role. One way is to describe what a typical PO does each day. In this post, I’ve created a list of what a PO does on a daily basis. This list is not exhaustive, nor is it in any specific order:

  • Attends the team’s daily stand-up meeting to understand the team’s progress and impediments toward the Iteration goals.
  • Capture customer requirements and ideas by writing (or helping others write) stories and Enablers.
  • Continuously accepts or rejects completed stories and Enablers. 
  • Is available to the team each day to answer questions and clarify stories.
  • Works with the System Architect to ensure Enablers are properly prioritized so as not to mortgage the future of the architecture.
  • Verifies that stories are in the proper format, contain valid confirmation (aka acceptance criteria), and are in line with the Program vision and scope. This includes any necessary design details, business rules, NFRs, etc.
  • Ensures that the team is aligned to the PI Objectives, and Iteration goals are clearly defined and communicated.
  • Helps remove or escalate obstacles to Product Management.
  • Makes sure that the Agile team has a direct connection with the business through story development and the Iteration review.
  • Meets regularly with Product Management (e.g. PO Sync) to keep stakeholders informed on how much incremental value has been generated.

In addition to that, on a cadence, POs:

  • Participate in the Iteration retrospective event.
  • Present the stories and Enablers during Iteration Planning.
  • Meet with the team each week to refine the Team Backlog.
  • Work with the team to decompose stories and Enablers into small increments. Ideally something that can be completed every two to three days.
  • Prioritize and update the Team Backlog.
  • Work with the team to create and commit to Iteration goals.
  • Collaborate with team members to form PI Objectives.
  • Help identify dependencies with other teams during PI Planning.
  • Meet with Product Management and stakeholders regularly to field questions and inform them of any updates or changes to scope.
  • Conduct the Iteration review with the team and participate in the System Demo to demonstrate the incremental functionality to the Agile Release Train and stakeholders.

In your context, look at all the activities that your POs are engaged in and consider whether it’s realistic for a part-time PO to do them all. If it’s not, speak to your part-time POs and have them present this data to their managers or as an issue during your Inspect & Adapt workshop.

To learn more on the PO role within SAFe, read this article.

About Joe Vallone

Joe Vallone, SPCT, SAFe Fellow, is an experienced Agile trainer

Joe Vallone, SPCT, SAFe Fellow, is an experienced Agile trainer who has helped coach several large-scale Agile transitions at Zynga, Apple, Microsoft, VCE, Nokia, AT&T, and American Airlines. He’s also an effective leader and speaker with more than 20 years of software development and management experience. As a change agent, Joe is passionate about teaching and coaching organizations to reach their full potential by embracing Agile values and Lean thinking.

View all posts by Joe Vallone

Share:

Back to: All Blog Posts

Next: We Did It! Our Very First, Fully Remote, Distributed PI Planning.

We Did It! Our Very First, Fully Remote, Distributed PI Planning – Agility Planning

As COVID-19 quickly spread worldwide, lots of organizations, including ours, realized that our next PI Planning would have to be entirely remote and distributed. We’d done distributed PI Planning before, where some employees joined on their laptops from global locations, but never one where everyone was remote and in their homes. So, just how were we going to pull this off?

Watch the video for a high-level look at what we did and keep reading the post for a bit more detail.

Planning the Event

For starters, we knew we had to answer lots of questions around locations, agenda, facilitation, tools, and working agreements. So, we started laying the foundation of our event by following the guidance in the advanced topic article from our Framework teamDistributed PI Planning with SAFe, and built our plan from there.

Agenda

I collaborated with our scrum masters and leaders to flesh out what this event would look like, and we knew that a two-day agenda wasn’t going to work. Not just because it’s hard to stay focused and engaged for two full days over video calls, but because we have people in China, England, Germany, India, Japan, Mexico, Singapore, and across the U.S.

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.

We had to accommodate all the different time zones to make sure people weren’t working in the middle of the night (more about that later). So, I set up a recurring weekly meeting with our scrum masters to craft a detailed event schedule. We landed on a three-day agenda that had some people starting early in the morning and others joining toward the evening (and later at night) for a shorter amount of time.

Distributed PI Agenda

Facilitation

Distributed PI Facilitation

We knew that to engage people remotely over three days, we’d need to get creative. So we came up with icebreakers featuring our talented employee musicians, a crazy hat theme, social video meetups to see people’s pets, a guided meditation session, and random quizzes to keep things light and fun.

In the spirit of relentless improvement, we sent out daily surveys to capture everyone’s feedback about what was going well and what wasn’t, and incorporated that into the next day’s activities.

Tools

The scrum masters and I worked with our information and technology team to figure out how to best use the tools we had to run the event. We set up a central location on our intranet and used our internal collaboration tool to create a main information hub and virtual rooms for each team, the program board, presentations, and the Scrum of Scrum meetings. We use the Google suite at Scaled Agile, so team breakouts happened via Google hangouts, and each team also had a dedicated channel in Slack that other teams could use to discuss joint projects and dependencies, and ask questions.

Hiccups and Takeaways

Overall our event went pretty smoothly, but we did run into some issues. When we set up the team spaces in our collaboration tool, we didn’t realize they were limited to just the individual team members. This meant people on other teams couldn’t access those spaces to interact with the teams they needed to. We managed to fix that issue on day one but it was pretty chaotic and time-consuming. 

Another thing we discovered is that it took a while for all of us to get used to communicating with each other both in the main space and in our individual team rooms. There was one hangout link to the main PI Planning room and different hangout links for each team to use during their breakout sessions. On day one, some people got lost in the transition, but by day two, all of us were seasoned pros. 

We’ve definitely got a list improvements we plan to make for our next PI Planning, including:

  • Being more intentional about team synchronization points so the teams come together more regularly throughout each day.
  • Adjusting the agenda to four days versus three to shorten the hours per day and better accommodate our international folks (at least one of them was online until 2 AM—sorry, Gerald).
  • Allowing more time for team breakouts, just because collaborating remotely takes longer.

To get even more details about how we executed our first fully remote, distributed PI Planning, I invite you to watch our Fireside Chat webinar on our Community Platform (login required). 

For more guidance around running remote PIs, ARTs and teams, listen to episode 27 of our SAFe Business Agility Podcast, which takes a deep dive into the topic.

About Jeremy Rice

Release Train Engineer at Scaled Agile

As the Release Train Engineer at Scaled Agile, Jeremy is a leader with a desire to help others achieve their greatest success. A U.S. military veteran, Jeremy has a diverse background in technology, engineering, and coaching, mixed with a bit of linguistics and work as a chaplain.
You can also find him occasionally posing with baby goats, cows, and pigs on his hobby farm.

View all posts by Jeremy Rice

Share:

Back to: All Blog Posts

Next: From Boots to SAFe: A Veteran’s Career Move

From Boots to SAFe: A Veteran’s Career Move – Agile Transformation

From Boots to SAFe - A Veteran’s Career Move

In 2006, I enlisted in the U.S. Army as a Forward Observer. Basically, that meant I spotted artillery rounds to ensure they landed on targets. Every time I neared the end of my contract, I reenlisted to avoid facing the fact that I had no idea how to translate my experience outside of the military. What was I supposed to do: walk into a prospective employer’s office and say that I was really good at land navigation, and ensuring close air support and artillery rounds hit targets? Yeah, not so much.

So, I changed my job to a Criminal Investigation Division Special Agent—think Naval Criminal Investigative Service (NCIS), FBI, or Secret Service but for the Army. I figured that my expertise in areas like interrogation, crime-scene examinations, digital forensics, crisis negotiation, protective service operations, and undercover and surveillance operations would definitely transfer directly to non-law enforcement jobs in the civilian world. Again, not so much.

So, time for plan B. I took what I knew, retired from the military, and got a job at a bank making just about minimum wage. With 10 years of leadership experience, I was barely providing for my family. When my 401k was just about empty, I decided I needed to find a career that could help me give my family the life they deserved.

Making the transition

This isn’t a unique story. Servicemembers looking to get out of the military face two big challenges. Either they can’t commit to leaving or—if they do commit—their roles in the military don’t translate to civilian occupations. Which means they end up in dead-end jobs. The stress adds up: veterans holding cardboard signs asking for help and money appear on every corner, substance abuse/recovery facilities are filled with green duffle bags, and even worse, veterans are committing suicide. There’s a scary statistic cited in a recent report that in 2017, nearly 17 veterans died by suicide each day. It shouldn’t be this hard for transitioning freedom fighters. 

But here’s some good news: shifting to a position in an Agile environment can help open doors for veterans, relieve some of that stress, and provide a lucrative career. Remember that dead-end bank job and my determination to find something better? I found it as a Scrum Master at Scaled Agile, and the skills I’ve learned here translate almost perfectly to military roles.

In this blog post, I’ll explain how the roles within the Scaled Agile Framework® (SAFe®) correlate to military positions. I relied on my background and experience to translate the roles into terms aligned with the U.S. Army, U.S. Marine Corps, and the Special Operations community, but veterans worldwide can relate to this.

Agile teams

When you mention Agile teams, most people think about software developers congregating in incubator garages across Silicon Valley. While these folks can be pretty Agile, I personally think that U.S. military teams are the most Agile because they’re on the ground making life-changing decisions instantly. These teams take the most up-to-date information and intelligence and iterate on the plan. Likely, this plan started with a conversation, moved to some sort of slide deck, then to the teams who practiced it using mock cities, sand tables, shoot houses, and other high-speed planning techniques—all to all be derailed by an IED, small arms fire, or chasing terrorists down an unexpected tunnel system. It makes me think of the famous quote often attributed to Dwight Eisenhower: “Plans are worthless, but planning is everything.”

In the military especially, we need Agile leaders who don’t get stuck by analysis paralysis, but rather who can prioritize, execute, and coach their team to get the job done. Aside from the life-and-death implications, the only big difference between working in the military and working in an Agile environment would be that Agile encourages working at a sustainable pace. We want to ensure predictability—always burning the midnight oil creates an unstable and unpredictable environment.

Within SAFe, Agile teams are the foundation of and critical to any Agile transformation. Fortunately, Agile roles translate easily for transitioning veterans in part because Agile teams are essentially a patrol. Using the basic makeup of a patrol, you have a radio transmitter operator (RTO), team leader, pointman, and the gunners on each side. 

The RTO is essentially the Scrum Master. This is the person who provides clear and concise communication organization-wide, and removes impediments for the Agile team if it can’t on its own. The Scrum Master has a wider role as well, but I’ll cover that later in this post. 

The pointman is most compared to the Product Owner. This person represents the customer on the team and helps the team prioritize its work, guiding it to deliver value that’s aligned with what customers want and with the organization’s goals. 

RTO is essentially the Scrum Master

The remaining members of the patrol are considered the Agile team. Because they’re the folks with the intel on the ground, they know what needs to be done to achieve the mission—similar to what’s called the Program Increment (PI) Objectives in an Agile environment. The Agile team can take the priorities from the Product Owner, provide realistic feedback on what is actually achievable, and complete the mission. 

To be successful, Agile teams and fire teams need leaders who can put the team/mission/people above themselves. Leaders provide the intent, the motivation, and the way to get people on the team to act.

Frameworks

In military environments, leaders are responsible for defining the concept of the operation in time, space, purpose, and resources (ATP 3-21.8). The Operational Framework greatly supports that by defining associated vocabulary and a way to organize. 

In a civilian workplace, leaders are responsible for the same successful outcomes, especially in Agile environments. SAFe is one approach enterprises use to support their transformations and provide full transparency across the entire organization. There’s definitely a learning curve associated with SAFe, and understanding the colloquialisms and jargon is key to a veteran’s transition in any workplace.

To illustrate this, I labeled applicable areas of the SAFe Big Picture with common military terms. Use your mouse to zoom over each image for a closer look.

SAFe 5.0 for Veterans

The SAFe Big Picture has three configurations—Portfolio, Large Solution, and Essential. These translate to Division, Battalion, and Company levels. 

Within Essential SAFe, there are key positions on the left side of the Big Picture—the Agile Team (which consists of 5–11 people) and two specialty roles: the Scrum Master and the Product Owner. Correlating these to military roles, the team is the squad or team, the Scrum Master is the RTO, and the Product Owner is the pointman. 

SAFe 5.0 for Veterans

Also in Essential SAFe, above the Agile Team layer, are three additional roles: 

  • The System Architect/Engineer, which is your S2 or company-level intel shop
  • Product Management, which is your Company Commander
  • The Release Train Engineer, who’s in charge of keeping the Agile Release Train (ART) on the rails, closely relates to the Executive Officer (XO) 

Multiple Agile Teams are part of the ART, which is a company-sized element of people navigating the Agile world. The ART has many mandatory events. To kick off a Program Increment (PI) or deployment—which is a set duration of time, usually a quarter of the year—all members of the ART attend PI Planning. This is where all teams on the ART provide the PI Objectives to the company and plan each of their iterations. 

In the context of an Operation Order (OPORD) within the US Army, here’s how Agile works:

  1. Situation can be rolled into the PI Objectives
  2. Mission can be rolled into the PI Objectives
  3. Execution is how the Agile Team operates—it can use Scrum, XP, Kanban, Design Thinking, and other techniques to satisfy the Customer (taxpayers)
  4. Command & Control happens throughout the entire delivery pipeline by means of Daily Stand-ups, Scrum of Scrums, Product Owner Syncs, and other meetings, which focus on consistent communication and updates.
  5. The Sustainment phase of the OPORD directly relates to Built-In Quality and the Architectural Runway.

The double diamonds representing Design Thinking on the Big Picture basically represent sand-table planning and shoot house for the actual mission. Design Thinking allows team members to diverge and converge thinking to release the right product at the right time. 

On the bottom right of the Big Picture is the SAFe Program Consultant (SPC)—the change agent who leads all levels of an organization through a Lean-Agile transformation at scale by training, coaching, facilitating, and mentoring. This servant leader plays a critical role by applying expert knowledge of SAFe, and most closely aligns to a Warrant Officer.

Why SAFe?

One of the biggest reasons to go from boots to SAFe is the doors it can open. There are more than 300 Scaled Agile partners, and countless veteran-friendly enterprises undergoing agile transformations—including government contractors and U.S. government entities. As a veteran, once you understand the terminology, your opportunities in the Agile space as a Scrum Master, Product Owner, Agile Coach, Release Train Engineer, SPC (and many others) are virtually endless.

Get started: paying for SAFe Certifications

Taking a SAFe course and earning a certification are the first steps toward jump-starting your career in the Agile space. And there are ways for veterans to get financial assistance.

VR & E program

Through eBenefits associated with the U.S. Department of Veterans Affairs (VA), eligible Veterans and Service members can apply for either Vocational Rehabilitation and Employment (VR&E) benefits or Education/Career Counseling. It’s simple to apply; just follow these steps on the VA website:

VR & E program
  • Log into your eBenefits account.
  • Select “Additional Benefits” from your dashboard.
  • Select “Vocational Rehabilitation and Employment Program.” Be sure to read the program information, update your contact information, and apply for either the “Vocational Rehabilitation and Employment Program” or “Education/Career Counseling.”
  • If you’re deemed eligible, you’ll be invited to attend an in-person orientation session at the nearest VA Regional Office.

Servicemembers with a disability that began or became worse during active duty and who haven’t yet received a service-connected disability (SCD) rating, don’t need to wait to apply (see VA Form 28-0588 for further instructions). Additionally, ill or injured Servicemembers who haven’t yet received an SCD rating don’t need to wait to apply. Servicemembers expecting a discharge other than dishonorable and who possess a VA memorandum or Integrated Disability Evaluation System (IDES) rating of 20 percent or more—as well as Servicemembers currently going through a Physical Evaluation Board—may be eligible to receive VR&E services.

Just ask

Many of our 300+ Scaled Agile partners that provide SAFe training also offer military discounts. All you need to do is lean forward in the foxhole and send an email to these trainers to find out. Remember, you can catch more bees with honey, so be nice and polite when asking for a discount.

Check out these other helpful links to learn more about SAFe, courses, certification, and partners:

About Clint Gershenson

Clint Gershenson Scrum Master for the Learning and Certification team at Scaled Agile

As a Scrum Master for the Learning and Certification team at Scaled Agile, Clint thrives at enhancing capabilities across teams by combining his expertise as an Agile coach at multiple technical companies with his experiences as a 10-year U.S. Army veteran. He’s also a family man who’s had the pleasure of watching Frozen 200+ times and the Grinch 100+ times with his young son and daughter.

View all posts by Clint Gershenson

Share:

Back to: All Blog Posts

Next: Join Me at the 2020 Virtual European SAFe® Summit