agile team Archives

Five Tips from a SAFe Product Owner

Posted on April 26, 2023

I’ve been a SAFe® Product Owner (PO) for two years and I’ve learned that showing up well in this role is more than just a skill set you build. It becomes an art that deserves practice, consideration, professional development, and your authentic personality.

As a PO of a very busy team that is charged with understanding and delivering on customer journeys with SAFe learning content, my daily work life can include:

See formal guidance on the PO role in the PO Framework article.

In short, my day can hold many twists and turns. Over the last two years, I’ve developed some habits and practices that help me bring my best self to this role as often as possible:

Treat the work as an important teammate
Treat yourself as an important teammate
Know whose opinions matter most to you
Practice setting boundaries
Form a great bond with your team’s Scrum Master/Team Coach

In the following sections, I’ll explain these practices in more context and share resources to help you accomplish them on your team.

SAFe^® Product Owner Tip One: Treat the Work as an Important Teammate

POs often face competing priorities, needs, and opinions.

This means I may hear from someone in one part of the organization why we need X and then hear from someone on my team why X is a terrible idea. I can learn why someone desires to work on something new and learn why we won’t be pursuing that idea in the same hour. I often do.

One way I resolve this is to treat the work as a teammate that deserves respect, care, and consideration.

Here’s an example of how this works.

A high-performing team member shared she was interested in enabler work towards researching and selecting upgraded tools. However, her work in the upcoming PI was heavy in iterations one, two, and three. This planned work was for committed deliverables in iteration four.

Architecture also approached me to help get alignment on having that team member work with them on this tool selection. They proposed several longer-than-average meetings with this team member in iterations one, two, and three as well as asking for exploration work from this team member in iterations three, four, and five.

I knew my team member was invested in choosing the right future tool for our work. I also knew we would miss our PI objectives and delivery of products without the crucial work she was planning in the early part of the PI.

I thought of my teammate and the work as equals, having needs and deserving a thoughtful decision. I worked with Architecture and the teammate to craft expectations for this PI and an extended timeline for the enabler work so the team’s work, the teammate, and Architecture all had a path forward.

SAFe Product Owner Tip Two: Treat Yourself as an Important Teammate

SAFe Product Owners and Scrum Masters/Team Coaches have specialty roles AND are a part of the team. This can be confusing sometimes. Should you add items to the team retro or vote in estimating poker? What happens when you have a family emergency or take vacation? Can you plan stories?

Having a different title or being a decision-maker can serve to distance you from teammates. In my first two PIs as a PO, I felt this keenly and decided to think about it differently.
My skills help the team deliver value and understand who will consume it and what they need. Once I started thinking about myself as a contributor rather than a “distanced person with a different role,” it made it much easier to decide: Yes, and.

YES, I should add items to our Team’s iteration retrospective! AND maybe I should mind my airtime and let others go first when the team is discussing which actions or changes they’d like to pursue in the next iteration.
YES, when we take team assessments such as the Team and Technical Agility assessment, my voice matters, AND if I have areas of disagreement, I’ll wait for my Scrum Master/Team Coach to facilitate conversations.
YES, I can vote in estimating poker when we’re sizing stories, AND if the person doing the work has a strong feeling or the rest of the team disagrees with my estimate, I’ll cede my opinion.
YES, I can take a long vacation AND find ways for my team to move stories through our Kanban while I’m unplugged.
YES, I can write stories! If there are areas of expertise I can leverage to help us develop our products, I can and should write stories! AND, when I have the opportunity to learn more about how others on the team are completing work, this builds my T-shaped skills and helps me plan work on our team with more knowledge and empathy.

Since making this shift, I’ve become more equipped to

Know what work we’re doing
Understand the how and why
Help our team reach out cross-functionally in the ART or to work with customers

Our team has been on a high-performing trajectory since this shift. While correlation isn’t causation, I intend to continue this mindset.

SAFe Product Owner Tip Three: Know Whose Opinions Matter Most to You

I like to joke about what I do for a living because (let’s be honest) parts of my family struggle to understand what I do at work. Sometimes I tell people I solve problems just-in-time for a living. Sometimes I tell people I negotiate and set boundaries for a living. Often I tell people I make someone unhappy nearly every day for a living.

Making people unhappy is one of the hardest parts of being a SAFe Product Owner. Because I’m involved in a team executing product development, maintenance, and delivery while acting as an interface with other teams we need work from or need work from us as they execute, misaligned needs and timing will arise.

Every decision I make, negotiate, share, or support, can potentially frustrate a teammate, someone on another team, someone on the extended product team, our business owners, or any combination of these folks.

People’s work is personal. This is their career, their time away from their family, their commitments, and the products they love and use. Their feelings about work are valid.

I’ve learned to accept and sit closely with someone having uncomfortable feelings about a decision. I put intense work into validating feelings, no matter how strong they may be and regardless of my agreement about that person’s wishes or ideas.

It can be challenging to stay calm with someone in an emotional situation. This is even harder to do without talking them out of their experience. I can’t do it unless I hold deep and important knowledge—I’m ok even if people disagree with me today. Not everyone’s opinions of me need to shape me in every moment.

I extend unconditional positive regard for people while building a working relationship with them. I assume good intent. And after that, the people who really stick with me respond to my brand of being me and getting work done.

This means I can live with some people who are unhappy with the news, decision, or strategy I’ve just shared. I can stay calm, professional, and empathetic without agonizing over the interaction.

It may sound like I care less about some people. However, what results from this approach is room for me to care deeply about the people I work with most frequently and maintain room for my own work, their needs, and new work relationships to grow.

Early in my life as a PO, carrying everyone’s thoughts and feelings kept me up at night and sometimes prevented me from saying things that needed to be said.

Rejecting this mindset has made me a better, more decisive, and more reliable PO.

SAFe Product Owner Tip Four: Practice Setting Boundaries

SAFe Product Owners often need to tell their team, Product Manager, an engineer or architect, other teams, ART, or Business Owners “no.” No feels like such a scary word. No can sit on the tip of my tongue and raise questions like, “Will this cause anger? Disappointment? Personal dislike?”

In the end, saying no to some things allows teams to say yes to others, and to take meaningful action on those commitments. It’s what allows us to create quality products. Conversely, saying yes to everything leads to poor quality, missed commitments and objectives, and personal and professional disappointments.

I decided to take a deep dive into setting boundaries. I started by considering how I could say “no” or “maybe” with clarity.

These are a few of the ways I trained myself to respond so I could communicate boundaries without shutting down necessary conversations.

For some time, I had these on a sticky note on the wall behind my desk. I rehearsed them and queued myself to remember to use these phrases.

After several PIs, my team started asking how I got so measured and productive at setting boundaries. We now brainstorm as a team ways to set boundaries before we go into PI planning. Here are some of the boundary-setting phrases our team has come up with:

The truth is these phrases are useful outside of PI planning throughout iterations. The bigger truth is they’re helpful in day-to-day life outside of work.

SAFe Product Owner Tip Five: Form a Great Bond with Your Team’s Scrum Master/Team Coach

I am lucky to have the kind of relationship with my team’s Team Coach where we happily grab taco dinners together. I don’t think all POs must be buddies with their teams’ Scrum Masters/Team Coaches. But it does help the work and team for POs to have good working relationships with the person in this role on the team.

As a SAFe Product Owner, you have your eyes on the needs of the customer (i.e., anyone who consumes your team’s work) and the work. I like to say, “I’m not the boss of anyone. I represent the work.”

The Scrum Master or Team Coach has their eyes on team performance, work progress, and delivery. I’ve found that having a great working relationship with the Team Coach on my team means we can coordinate to support the team and work and fine-tune our team and technical agility.

Ways I’ve coordinated with my Team Coach to support the team include:

Proposing breaking our Agile team events up differently
Devising ways to handle things asynchronously when we have scheduling traffic jams
Asking me powerful questions when I’m facing hard decisions on priorities and moving the work forward

I can also go to our Team Coach and propose agenda items for our team events, ask for help getting data and metrics, and collaborate on thinking through team challenges and needs.

It’s so rewarding to have a relationship with our Team Coach where I can talk candidly about where we’ve been as a team, where we’re headed, and the ways we can both leverage our skills and perspectives to help the team succeed.

This makes it enjoyable to collaborate on planning team celebrations. We’ve worked together to coordinate

A “game show”-themed gathering
Gift bags
Creative ways for the team to learn about one another and appreciate each other more
A remote cookies and hot cocoa gathering
Team meals

By far, the best part of working so well with my Team Coach is that we can support and challenge each other. When my Team Coach had a professional development goal to become an SPC and SAFe Trainer, I covered team events and cheered him on.

Likewise, he got creative with ideas for story acceptance and team events I usually handle so I could take a long vacation.
We also push each other to look at our team’s metrics, consider new ways to engage the team in Agile team events, share successes and improvements with the ART, and share our talents beyond the team level.

In this relationship, each of us has grown into our roles and pushed ourselves and each other. The team has also been recognized as high-performing in qualitative and quantitative ways.

Enhance These Tips with Some PO Resources

I hope including these tips, practices, and mindsets helps you consider your own development as a PO and how your work positively impacts your team’s work. Lean into the art of being a PO in your own way as you try some of these ideas out:

Videos

Blogs

Assets

PO resources in SAFe Studio

Get them now

About Christie Veitch

As a writer and education nerd who loves processes, Christie seeks to move the needle on what learners can do and what educators and trainers will try with learners. She designs and delivers compelling content and training and builds communities of avid fans using these resources as a Scaled Agile, Inc. Product Owner. Connect with Christie on LinkedIn.

SAFe Metrics at the Team Level: Corporate Communications

Posted on December 15, 2022

Blog banner: Contextualizing SAFe metrics: corporate communications edition

We started this series on SAFe® team metrics with the simple acknowledgment that contextualizing SAFe metrics for a non-technical Agile team can be difficult. To continue learning how other teams adapt SAFe metrics to their specific context, I sat down with Amber Lillestolen, the Scrum Master of the Corporate Communications (Comms) team at Scaled Agile, Inc. Here’s what she shared about applying SAFe metrics for a ‘traditional’ communications team.

Applying SAFe® Metrics in Marketing for a Communications Team

Scaled Agile has a few small cross-functional marketing teams to support different business areas. Corporate Comms is one of these small teams. Their purpose is to propel market growth through a cohesive, compelling brand experience that inspires delight, confidence, and loyalty in current and prospective customers.

The team works across the company—from public relations to customer stories and brand work for new product launches. Rather than debugging and deploying, communications professionals help simplify and communicate complex messaging, refine product value propositions, develop thought leadership content, and much more. This work requires significant cross-functional skill, research capabilities, collaboration, qualitative reasoning, and the ability to build alignment while planning for future releases.

Their common work items include

Company-wide brand reviews
Auditing and updating brand guidelines
Market research
Developing product messaging and value propositions
Understanding customer needs and building messaging frameworks with other marketing teams
Thought leadership content development with executives
Public relations strategy and management
Material preparation for events and conferences
Recruiting and curating event customer stories
Naming and messaging standardization across the organization

Amber is Corporate Comms’ first Scrum Master, about four months into serving the team. Corporate Comms is a unique team because they are a shared service across the organization. This means they receive a significant amount of walk-up work from other teams. Since this type of work consistently (though not always predictably) consumes a portion of the team’s capacity, it’s important to track it using metrics.

Below, Amber shares her process for tracking the team’s performance, including which metrics she uses to coach and guide the team. We separated these team metrics into the three measurement domains outlined in the metrics article: outcomes, flow, and competency.

Outcomes

Question: What metrics do you use to measure outcomes?

Outcome metric #1: PI Objectives

The Corporate Comms team reviews PI objectives throughout the PI to ensure that their related features are progressing. This helps the team determine if they are ahead, on track, or behind on the outcomes they promised to deliver in the PI.

Here’s a basic example of a Corporate Comms PI objective:

In support of SAFe’s evolving brand, provide enablement resources for applying new communication messaging and naming to team-level assets.

Outcome metric #2: Iteration Goals

The team creates goals every iteration and tracks their progress. They create goals related to the high-priority stories planned for the iteration.

Flow

Question: What metrics do you use to measure flow?

PI objectives

For Amber, flow is about delivering value, so she also included PI objectives under the flow metrics category. The Corporate Comms team uses PI objectives to measure its flow as part of the Operations Agile Release Train (ART). She reviews the team’s objectives during iterations to help the team understand what value they’re bringing to the organization.

If you don’t remember seeing PI objectives in the flow section of the SAFe Metrics article, you’re right. flow metrics, like predictability, show how well teams achieve outcomes like a PI Objective.

But for the Corporate Comms team, tracking the degree to which an objective is completed functions as a handy ‘pseudo-flow’ metric for the comms team. Ultimately, their PI objectives will roll up into broader Program Predictability Measurements, but this is a good way to track flow predictability on a smaller scale at the team level.

This is a good example of adapting metrics to meet their team needs, and simplifying their measurement process to retain its simplicity and usability. If objectives are continually missed over several PIs, this means value isn’t flowing. And value flow is the purpose of flow metrics.

Amber combines PI Objective progress with a review of the team’s velocity to understand the flow of value and completed work each iteration.

Flow Distribution and Flow Velocity

Flow distribution measures the amount of work type in a system over time, which is important for the Corporate Comms team to track.

As mentioned above, Corporate Comms is a shared services team. This means the entire organization is an internal customer of their work. As a result, the team has frequent walk-up work from other groups. Some examples of the team’s walk-up work include:

Booth designs for domestic and international events
Market research and analysis when a change occurs
Reviewing other teams’ slide decks and presentation materials

Because this walk-up work is a regular occurrence for the team, they reserve some of their capacity for it each iteration. It’s important for the team to see how their work is distributed across planned and unplanned work so they know how much capacity on average to reserve for walk-up work each iteration.
They track their capacity in an ALM tool using the following views:

screenshot of Iteration Summary view in Rally — Iteration Summary view in ALM tool

Screenshot: Team planning view in Rally — Team Planning view in ALM tool

Team planning view in ALM tool (work items blurred for confidentiality)

The team looks at their capacity and velocity metrics during iteration planning to see if they are over capacity.

Flow velocity measures the number of backlog items completed over a period of time; in Corporate Comms’ case, this period of time is an iteration.

They review these metrics at iteration review to see if they finished all planned work. Amber also uses the team planning board in an ALM tool to show if the team is over capacity and discuss what items need to move at iteration planning to adjust their capacity.

Using capacity metrics to move stories

If the team discovers they’re over capacity, it’s usually for one of two reasons:

1) Long review cycles

2) Undefined work

A lot of the team’s work is tied to cross-functional changes across the business, and those carry unknowns. As strategy evolves, sometimes the work changes to match what’s new.

Marketing teams are prone to getting buried in last minute requests and repeated context switching. SAFe provides a shared language and approach to work that teams can use to define:

What work can be done
How long that work will take
Dependencies
What other work needs to move or change to accommodate priority requests

This is a helpful level-set on expectations for how other teams can protect the time and resources needed to deliver planned value.

Reserving capacity for walk-up work

Amber also tracks the work that comes in and the team adds stories for walk-up work. They use this data to measure unplanned work requests during the PI compared to the work planned during PI Planning.

During the last PI, which was the team’s first PI Planning with a Scrum Master, Amber encouraged the team to plan to only 80 percent capacity to allow for any walk-up work. She arrived at this number based on the 20 percent of walk-up work from previous capacity and velocity metrics.

The team also uses ‘bucket’ user stories every iteration for team members who run office hours and complete other routine work. Office hours are blocks of time reserved for people from other teams in the organization to bring items to Corporate Comms for review. These brand office hours occur three times a week for an hour.

Any work brought to office hours that will take over two hours becomes a story with points and is added to the iteration based on urgency and capacity. Tracking their work this way creates a reliable record of capacity needed to address business as usual items, planned new work each iteration, and walk up requests.

Velocity Chart and Cycle/Lead Time

As the Corporate Comms team grows, Amber wants to track the team’s flow better and share more data with the team during Iteration reviews. Specifically, she plans to use the velocity chart to see how the team’s velocity changes throughout each iteration:

Screenshot of a velocity chart on the Corporate Comms team — Velocity chart

She also plans to use the cycle/lead time report to see how long it takes the team’s work to flow through the iterations.

Because dependencies impact the speed at which the team can do their work, Amber would like to start tracking how dependencies impact the team’s flow. Currently, the team uses daily standups and retrospectives to discuss work going through the kanban and when things don’t get finished in an iteration.

Competency

The Corporate Comms team recently completed a Team and Technical Agility assessment.

Amber is reviewing the organization-wide results with the LACE team and discussing how to analyze the results to determine next steps. But she has shared initial results with her team. Corporate Comms identified growths and strengths based on their results and retrospectives.

Growth area

They need to continue to work on their capacity/velocity to help their flow.

Strength area

They are great at collaboration and peer review as a team.

Team formation

Since their formation less than a year ago, the Corporate Comms team has learned a lot about how to work as a shared service for the whole company. They’ve created new outlets of communication and coordination to increase the value they can deliver.

About Amber Lillestolen

Amber is a Scrum Master at Scaled Agile. For years, she has used empathy and understanding to coach teams to reach their full potential. She enjoys working in a collaborative environment and is passionate about learning. Connect with Amber on LinkedIn.

About Madi Fisher

Madi is an Agile Coach at Scaled Agile. She has many years of experience coaching Agile teams in all phases of their journeys. She is a collaborative facilitator and trainer and leads with joy and humor to drive actionable outcomes. She is a true galvanizer! Connect with Madi on LinkedIn.

How Does a Scrum Master Coach a Team with More Experience Than Them?

Posted on October 26, 2022

I’ve found myself in many different contexts throughout my career as a SAFe scrum master:

Multimedia
Instructional design
Marketing
Globalization
Data analytics

Make no mistake. I am neither an animation artist nor an instructional designer, nor a digital marketer, nor fluent in a second language, nor can I write SQL (or any code for that matter).

So how do I effectively work as a scrum master when I don’t share technical experience with my teammates? I’ll help you answer that common question by focusing on three areas:

What does a scrum master do?
What if I’m a scrum master without experience?
Setting scrum master improvement areas

What does a scrum master do?

This sounds simplistic, but there’s a reason! Reviewing the basics, in this case the role of scrum master, can help reaffirm your role on the team you serve and help you clearly state it to others.

Your goals are simple (not easy), and they often include:

Helping the team navigate ART practices and processes. In doing so, the team can participate fully and have their interests, concerns, questions, ideas, and voices heard. This is especially true for new team members. Everyone will need time and support to adjust to a new way of working, no matter their experience level. Scrum masters are a little bit like the glue that holds cross-functional teams and ARTs together.
Allowing teammates to focus on execution. As experts in their domain, your team members are usually deep in the trenches of value delivery. Most other team responsibilities are shared between you, the product owner, and the product manager. This means scrum masters need to be experts at supporting the PO, PM, and other team members at defining the why, gathering requirements, prioritizing work, and knocking on doors to unblock progress.
Being a champion of relentless improvement. You should help define success metrics, measure the team’s value delivery, and create a forum for the group to view and discuss the results. Teams might think they’ve defined value delivery well, but scrum masters are uniquely positioned to provide essential perspectives from the ART, customers, business owners, and other teams. Aside from objective metrics, you can also discuss qualitative experiences like team dynamics. In partnership with the product owner, you can create a system to start incrementally improving. The organizational value realized from increasing and sustaining employee participation is always significant.

The full SAFe® scrum master article has more extensive guidance to help you define role expectations and responsibilities. As a quick reference, the image below will help you visualize three core areas where any scrum master can immediately start to add value.

SAFe Scrum Master Areas of Focus: ART & team events, value delivery & team progress, flow & team dynamics

Does this work require you to know what the team is making and how? Yes, to an extent. But it often doesn’t require the depth of specialized knowledge needed to build end solutions. In fact, another voice with the same experience and biases might only add to a myopic perspective and goals.

What if I’m a scrum master without experience?

Starting as a scrum master without experience is a little overwhelming.

When it feels like too much, there are some foundational concepts you can use to stay grounded and help your team succeed.

Below are three key reminders for scrum masters that are new to their role or serving an experienced team in an unfamiliar domain.

1 | The team is expert in their way, you are expert in your way

To coach a team effectively, you need to understand and maintain focus on:

The team’s value flow
Typical bottlenecks
Impediments to high quality

The rest is simply nice to have. Understanding flow, bottlenecks, and quality will allow you to quickly grasp what holds the team back and how they achieve success. This will also help you relate to your team’s emotional dynamics, including what makes them personally frustrated or fulfilled. Empathy will break through differences in experience levels and foster lasting relationships.

If you’re still skeptical, think of it this way; the product owner is backlog and content authority for the team. They still do backlog refinement with the team. Why? Because team members are the experts! That’s their thing. That’s why they were hired.

A scrum master isn’t an expert in the same areas. That’s not their job. Their job is coaching and enhancing the PDCA cycle, customer centricity, flow, dependency visualization, bottleneck identification and removal, conflict management, and listening.

2 | Build initial trust levels with authenticity

The not-so-secret ingredient in serving any team is trust. If you share technical expertise with your teammates, building initial trust may be easier. Teammates will know that you understand their impediments and have insight into root causes because you may have experienced them before. Your coaching may be well received because “you know what you’re talking about,” and teammates can immediately talk shop with you.

There may be some initial distrust if you don’t share technical knowledge with your teammates and they don’t understand how you contribute. If this situation sounds familiar, it’s best to start with openness about your background and willingness to learn. Emphasize that you’re not a technical expert but you do fill many other roles that help them work better, including:

Servant leader
Live-in consultant
Advisor
Team protector

Your expertise starts with process, method, and people.

Trust is particularly key when your work environment prioritizes honesty, candid feedback, and personal responsibility. Technical competency is a must for most roles, but emotional intelligence and interpersonal skills are vital for helping teams and individuals thrive. Organizations using SAFe should create ample space for digging into messy issues, feedback, processes, and team performance. Scrum masters can build trust in these complex emotional environments in several critical ways:

Help everyone approach discussions in good faith
Create a safe environment for all feedback
Find and equip team members with the right tools and methods to provide feedback
Encourage participation by all; not only the loudest or most persistent voices
Communicate feedback clearly to others, demonstrating advocacy for the team

3 | Promote self-organizing teams

A scrum master’s best tools are powerful questions and intentional listening. If you share deep technical expertise with your teammates, you may have a bias when determining problems and solutions.

You might make more assumptions and be more suggestive because you have so much familiarity with the team’s work. Scrum masters without technical experience have the benefit of an outsider’s perspective and have no choice but to truly listen, clarify, and guide the team to their own solutions.

Setting scrum master improvement areas

It’s helpful to build trust and develop personal relationships. But you’ll need concrete growth goals to gain competency and confidence.

The list of scrum master improvement areas below will give you a big head start in owning your role:

Identify the team’s value stream(s). The team might already have a value stream visualization. Maybe the product owner knows it well. Or maybe there’s a great opportunity for the team to work on identification. This will help both you and your team understand how work flows and the most essential tools and processes the team uses. You’ll likely find areas for immediate improvement!

Ask obvious questions. Though it might feel like you’re slowing the team down, asking foundational questions is actually beneficial for everyone. Here are just a few obvious benefits:

You need to learn more about team content
The teammate receiving the question needs to think about the purpose and processes behind their work
Other team members who aren’t involved in that work may have the same question

Schedule one-on-one meetings. Learn team member’s professional goals and interests. Ask about their pain points, what keeps them up at night, dynamics within the team, dynamics with other teams, etc. Build empathy to help smooth over inevitable future difficulties. Also, if your teammate is comfortable with it, you can ask to shadow their work while they narrate and complete day-to-day tasks.

Always have a Google tab open. Answers to technical questions are often difficult to grasp. You can’t expect to know everything your team does. Instead of scheduling an hour lecture with a teammate every time curiosity strikes, try checking internal directories, knowledge wikis, and even Google to find a quick answer. Continuous learning is imperative.

Use an assessment to measure your progress. The AgilityHealth Scrum Master Radar Assessment (or a similar tool) can help you understand your current performance and identify areas for improvement.

Learn more about the team’s work. This shouldn’t necessarily be your first priority, but it’s definitely worth your time. Common examples include joining a lunch book club, attending a conference, creating content that requires you to learn new material, and reading technical articles. You’ll deepen your knowledge and show that you truly care about the team’s work.

Hone your craft. Consistently prioritizing professional development will demonstrate your growing expertise to the team. Whether you’re trying new approaches to retrospectives or diligently protecting and coaching team members, your efforts will earn trust.

If you’re still unsure about exactly where to spend your time, the graphic below breaks down how real scrum masters (in our company) spend a typical week. You can use this tool as a gut check for balancing priorities, assessing your time management skills, and planning for a productive iteration.

More Resources for You, Scrum Masters!

Even with prior scrum master work experience, serving a team with technical expertise that you don’t have can feel daunting. But a skilled scrum master can quickly bring significant value. By clarifying how you serve the team, building trust, and continuously learning, you and your teammates can work together to build a self-organizing, high-performing team.

Here are some additional resources to help you learn more about how scrum masters of all experience levels can continue improving and serving well:

Read about the scrum master role in improving team dynamics and productivity
Learn how to assess your team’s agility from a scrum master Q&A
See how scrum masters help handle conflict resolution
Join the Scrum Master forum in the Scaled Agile Community Platform (available to current community members)
Attend a SAFe® Advanced Scrum Master course

About Emma Ropski

Emma is a Certified SPC and scrum master at Scaled Agile

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

View all posts by Emma Ropski

True Agile Teams and Trains – SAFe Implementation

Posted on June 1, 2022

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

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

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

is.

True Agile Teams

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

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

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

Empowered Teams

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

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

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

So how do you empower teams?

Remove Constraints around Team Members

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

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

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

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

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

Change the Culture

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

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

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

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

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

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

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

Crave Fast Feedback

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

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

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

“Team Leader” Is an Antipattern

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

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

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

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

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

Getting Started

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

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

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

About Dwayne Stroman

Dwayne is an Enterprise Transformation Coach and Trainer and SAFe Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn.

SAFe® Product Owner Tip One: Treat the Work as an Important Teammate