SAFe Scrum Master: 13 Unexpected Takeaways

These are the bonus fries from my SAFe Scrum Master training course.

Bonus fries are those extra fries you find at the bottom of the fast-food bag just when you thought all your fries were gone.

I expected to learn about SAFe, but I walked away with quite a few bonus tidbits that can be beneficial to others, regardless of what approach you’re using.

1. Miro is Awesome

Given that we’re in the middle of a pandemic, we’ve all had to find ways to be efficient in a remote world. My SAFe Scrum Master course was no different. Trainers have had to adjust from an in-person class filled with post-its and markers to a remote course delivery platform.

So how does one successfully make this transition and still maintain the vital interactive elements of the course? Miro!

I was impressed with how the instructor could get even noobs up to speed on the basics of Miro. Our instructor divided us into teams of four people, where we completed interactive exercises using Miro in conjunction with Zoom breakout rooms.

If you have remote teams and aren’t using Miro, stop reading and check it out now.

2. SAFe: The Agile Amalgamation

If we can compare the various agile approaches, practices, and techniques to a kitchen pantry, SAFe is the carefully crafted meal designed by a chef.

We start with Scrum, add in some XP, slather on some Lean portfolio management, and voila! We have a lovely big platter of SAFe. That is way oversimplified, but I think you’re probably picking up what I’m putting down.

There seems to be a lot of shade thrown at SAFe from the agile community. I won’t say that this single course wholly swayed me, but I am a fan of borrowing whatever practices work for your team, and SAFe follows that objective.

3. Cross-functional Teams, Not Cross-functional Individuals

I’ve always felt that the concept of cross-functional teams is a bit of a spectrum. On the right, we have a team of unicorns. Every person on this team possesses all of the skillsets needed to perform any task. On the left, we have a team of specialists. These specialists apply extreme collaboration; thus, with their powers combined can do great things.

Depending on the source covering the concept, you tend to get one extreme or the other. The truth (and best implementation) is somewhere in the middle. However, building a team of people with complementary T-shaped skills isn’t always a cakewalk.

Touching on cross-functional teams in this class helped me solidify my thoughts on this concept.

4. More Values and Principles

SAFe has its own set of values and principles. I don’t know about you, but I’m starting to get a little apathetic when learning yet another set of values and principles.

Although the various statements feel a bit repetitive, I can admit that reviewing those of other agile approaches can help identify potential areas where my teams could improve. It’s a bit like the mindset we’re trying to align with is three-dimensional and reviewing the values and principles of other approaches gives me the view from a different angle.

Irrespective of my lack of enthusiasm, if you’d like to check them out, you can find SAFe’s core values and principles on SAFe’s website.

5. Innovation as a First-Class Citizen

A common problem I’ve faced with agile teams is finding the time to focus on innovation and training.

We’ve tried allocating a fixed percentage of time or velocity toward these activities, but it’s always problematic to track. There is also the issue of timing. There never seems to be an acceptable time to pause the urgent to take care of the non-urgent but essential work.

Thus far, the best success I’ve seen was a team that allocated two days to each team member. Each team member was responsible for scheduling when they would use their time, just like a vacation. During this period, team members could work on innovative or training activities. Afterward, they’d do a cross-training with the team to share their learnings.

In SAFe, every fifth iteration is set aside for innovation and planning. In this way, everyone has the same opportunity to spend time on training and innovation. Expectations are set with stakeholders that during this time, new features are on hold. Team members can team up with others to make more progress on the innovation. It is also less likely that business-as-usual activities will eat up this planned time.

A synchronized, scheduled time set aside for innovation fills a gap I’ve seen in many teams. It might be challenging to sell leadership on this process change if you’re not a SAFe organization, but I believe the benefits are worth the attempt.

6. Product Owner vs. Product Manager vs. Program Manager

It seems to me that there is no consistent definition of these roles or how they differ. I suspect that there are two main reasons for this:

1. Various agile approaches define these roles slightly differently.
2. HR, which typically plays a hand in defining job descriptions, isn’t always up on these roles’ latest agile definition.

This leaves us with a very muddled understanding of these roles and their associated expectations. In SAFe, though, the roles serve two different purposes and are separate and defined. The Product Owner is a member of the agile team, and the Product Manager is customer and product vision focused.

7. Design Thinking

I must have been hiding under a rock somewhere because my first exposure to Design Thinking came as I started researching SAFe.

Although I’m familiar with some of the techniques used (personas and paper prototyping, for instance), I was unfamiliar with the “Design Thinking” process.

Design thinking is an iterative and customer-focused process for design work. This process ensures that we solve a problem that the customer needs in a way that works for the customer. All too often, businesspeople get in a boardroom and decide they know what is best for the customer. The result is that we build products that solve problems the customers don’t have, or we solve their problems in such a convoluted way that the system is unusable.

Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.

• Tim Brown, Executive Chair of IDEO

Design Thinking seeks to stamp out this disconnect by making the customer an integral part of the design process. If you’re interested in learning more about Design Thinking, I suggest you start at IDEO’s website.

8. Enablers and Architectural Runway

The proper and efficient handling of technical requirements is a consistent struggle I’ve seen across many teams. These foundational elements that support new features always seem to get the shaft when it comes to prioritization.

Some coaches advise that if work provides no customer value, then we shouldn’t do it. If we can realize customer value from the effort, then we should express that work as a user story, articulating that effort from the perspective of the value it will provide to the customer.

Sometimes when we attempt to word technical tasks in terms of customer value, the result is an obfuscated user story that makes no sense to the rest of the team (especially the product owner). This confusion generally results in the delay of important work sets the stage for successfully implementing future features.

In SAFe, we treat the architectural runway as a first-class citizen, not merely a side effect of some feature we’re delivering to customers. We work on enablers that extend the architectural runway as needed to support future customer value.

I believe that adopting similar terminology in non-SAFe implementations could go a long way toward increasing transparency and relieving tensions.

9. TIMWOOD is a Waste

I don’t have direct experience with Lean, but I am familiar with some of its concepts. One of the aspects of Lean that always resonated with me was the idea that there are seven types of waste. Clearly, eliminating waste should help our teams be more efficient, but I could never remember the seven types until now.

TIMWOOD is a nifty mnemonic to help you quickly recall all seven types of Lean waste

• (T)ransport
• (I)nventory
• (M)otion
• (W)aiting
• (O)verproduction
• (O)over-processing
• (D)efects

Some add an eighth waste:

• (S)kills

You can throw the “S” onto the end of the acronym if you like. The alternative argument is that the skills waste is just one of the seven original wastes in disguise.

Bonus: Poka-yoke

This word is just amusing to say. It’s a Japanese word that means “mistake proofing.” It came up when discussing lean waste.

Try to use this in a sentence today!

10. Systemic Impediments

Throughout the course, we watched a couple of videos created by SAFe. In one of those videos, the girl used a term that resonated with me “Systemic Impediment.”

A systemic impediment would be an impediment affecting more than one group. Something more extensive than the team.

Sometimes it feels like most of the impediments encountered by my teams are systemic impediments. This term seemed like one worth remembering.

11. Working Agreements

Working agreements can be powerful tools but seem to be commonly overlooked or considered too basic. It may seem a bit excessive to document how we agree to act. Who will ever go back and read those once they are defined? If used correctly, though, I think they could be invaluable.

I encourage you to take a moment to consider how working agreements might help in the following scenarios:

• Resolving conflict
• Onboarding new team members
• Breaking ties when planning poker

When the class started, we established some working agreements regarding breaks and camera expectations. It was very discreet, and everyone followed the rules afterward because everyone had been part of setting those rules.

It prompted me to think about how my teams might benefit from a reboot of our working agreements.

12. Powerful Questions

As you can imagine, the SAFe Scrum Master course focuses heavily on the skills and characteristics of the Scrum Master. One of these skills is coaching. Helping the team reach an answer without dictating the remedy is one of the core aspects of coaching.

This can be a hard line to straddle, especially when you think you know the best solution. One tactic to bridge this chasm is to ask open-ended questions. I find that I’ve developed this tactic naturally throughout my career. When the SAFe Scrum Master course covered asking powerful questions as a skill, it made me wonder if I might be able to expand on my repertoire.

One can probably never have too many open-ended questions ready to fire off at will.

13. SDET

SDET is an acronym that stands for Software Development Engineer in Test.

The role appears to have been popularized by Microsoft and Google.

Depending on what articles you read, the definition of the role differs slightly, but the basic concept is that an SDET is a tester who can also write code. This role intrigues me due to its potential to help smooth out the handoff from development to QA.

There seems to be a big push in the community that all developers also be testers. The goal seems to be the desire to eliminate the pure QA role and move toward what people consider to be a cross-functional team. I covered this a bit in #3 above and consider this to be a misinterpretation of cross-functional teams.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

-Agile Manifesto

The funny thing is, I’ve never worked with a team that thought this was a good idea. Most QA folks I worked with were not interested in learning how to write code. They liked what they did and felt they provided value without having that additional skillset.

Likewise, most developers I talk to aren’t chomping at the bit for the chance to test another developer’s code. Please don’t sneer and chalk that up to lazy developers. I’ve had some brilliant people point out that QA is a different mindset than that or development. Not everyone will possess the ability to slip between the different headspaces efficiently.

What piqued my interest most with the SDET role is not the potential that such a role could replace that standard QA role, but this role could help bridge the gap between QA and development. Similar to how a Product Owner bridges the gap between the customer and developers.

TLDR

Going into the course, I expected to learn about SAFe, but I was happy to get these extra tidbits of approach agnostic information. Just like I’m always delighted to get those extra tidbits of potato at the bottom of my fast-food bag.