A few weeks age I attended a 4-day Scaled Agile Framework class with a result of sitting for my SAFe Program Consultant (SPC) test. A few days after the class, I received an email telling me I passed the exam. I am now a proud and newly minted SPC. This enables me to teach several SAFe courses, to kick-off and coach Agile Release Trains (PSI’s), and to generally coach organizations that are adopting SAFe.

But to be honest, I’m still digesting SAFe. It’s not that I’m having trouble with the concepts or approaches. It’s more so that I’m having a challenge fitting them into my own experience in a useful way. You see much of what I learned in the class I’ve been using and doing for a long time in my own agile journey. But I’ve couched those techniques under Scrum of Scrums for agile scaling—and with fairly good success.

For example, I’ve been leveraging synchronized Agile Release Trains and Hardening Sprints for years and years. For portfolio planning, budgeting and forecasting I’ve leveraged an extension called the S3 or Scrum of Scrums of Scrums that I saw implemented in 2007. The foundation of all of my program level Scrum of Scrums execution has been Release Planning, which I described well in this article. And I’ve always coached Scrum teams to leverage Extreme Programming technical practices.

All of these approaches are in many ways a part of SAFe. So from that point-of-view, I guess I’ve been an early adopter of SAFe. In the remainder of this piece, I want to explore my SAFe discoveries in more detail. Consider it part a review of the class itself, but also providing some general feedback on the framework.

I hope you find it useful.

Going In

I was certainly apprehensive going into the class. I’ve done quite a bit of research on SAFe. I’ve seen Dean Leffingwell provide various overviews both in video and in person. I’ve also coached some teams who had/have adopted it in some form our fashion. These teams were part of larger scale adoptions, which are difficult to orchestrate with or without SAFe. However, I did see some patterns in the implementations.

I shared most of my concerns in this blog post.

But beyond all of the reservations and assumptions, I tried very hard to go into the class with an open mind. I wanted to listen, learn, clarify, and fully engage the class. I guess my point is—I wanted to give it a chance. And I feel I did that. In the remainder of this article I’ll explore my learning’s, reactions, and concerns about SAFe.

Background

If you don’t have a clue about what SAFe is, then this 1-hour overview might be helpful to you. And of course, here’s a link to the “big picture”.

Before SAFe, Agile at Scale

As I said earlier, there is quite a bit of SAFe that I agree with. Forget that. I not only agree with it, but I’ve been using them at-scale for many years. Here’s a list of the things that I like and have used:

  • Notion of Scrum + XP practices for team level execution with a strong focus on technical practices and the craft in software development. This also includes Continuous Integration and Automated Testing.
  • Agile Release Training (ART) with a fixed number of 2-week iterations. SAFe seems to be more prescriptive than I’ve been in the number of recommended sprints, but the intent is the same.
  • Synchronized sprints across all teams within the ART. For a long time I’ve been a proponent of synchronized work at-scale. It simply works better, particularly from a dependency & integration perspective.
  • HIP Sprint (Hardening, Innovation, and Planning) as a transition from one ART to the next. Now I haven’t made innovation & planning a direct part of the hardening sprint, but the activities between ART’s have been the same.
  • Actively spiking work within sprints; emphasizing architectural and design look ahead.
  • Integrating cross-cutting groups like architecture, UX, and DevOps in the PSI Planning and Release Train execution.
  • Leveraging Release Planning as a central activity to gain x-team collaboration. With a strong emphasis on high-level Visioning, Road-mapping, and Strategy.
  • Whole-team commitment to Release Plans, including “negotiation & acceptance” with leadership.
  • Capacity allocation within the backlogs was mentioned at both the Program and Team levels. I’ve been talking about this as part of solid Backlog Management for the better part of 10 years. I also liked the fact that they spoke about inputs from: the program, the team, and other stakeholders.
  • Using x-team Sprint Reviews as a synch point with leadership and stakeholders.
  • High-level qualification of Epics for Business level and Architectural level soundness by leveraging early “Grooming” activity.

Have all been useful tactics when I’ve scaled Scrum. As I’ve said, I couched all of them under a Scrum of Scrums wrapper, but now with SAFe, I might start referencing it more often. That way I don’t have to keep reinventing the wheel when it comes to framework definitions and basic training.

And beyond that, SAFe provides some new things or ideas.

For example, I’ve always struggled with a model for helping clients grasp the collective approaches to agile at scale. Sure, I could say Scrum of Scrums, but there wasn’t a lot of ‘meat’ behind those words in terminology, tactics, and recommendations. SAFe has filled that void. Whether you like it’s approach or not, you must agree that the overall agile community had left a VOID when it came to cohesive scaling recommendations and SAFe has filled it.

Providing the notion of different levels of Sprint Review is an interesting idea. There were three introduced:

  1. Team Review
  2. System Team Review
  3. PSI or ART Review

I’ve been using a combination of these, but have been recasting the end of sprint review (Team Level) to cover the other two. From my perspective, it’s simpler that way. But there are advantages to the way SAFe targets each review to a different focus and target audience.

There was brief mention of Backlog Grooming or Refinement at the team level in preparing their backlogs. From my perspective, the role of team level Product Ownership and backlog management was significantly under represented in the class. Perhaps that’s because it was an SPC class where attendees were assumed to have team-level execution experience? Nonetheless, I would have liked to have seen at least mention that they were intentionally glossing over these activities. As I begin to teach and coach SAFe, I will not be making this mistake and the discussions will cross the team AND program levels.

The notion or abstraction of Architectural Runway can be quite useful. And instead of spikes or Sprint #0 as being your only way of look-ahead, this is actual infrastructure work that is designed and built slightly ahead of the need. I do worry about the “integration” of physical architects within the teams—so that we don’t create a "glass house effect" of specialized engineers handing off guidance to the teams. There’s also the danger of this across UX and DevOps. And the way the framework layers these activities it almost creates and supports these sorts of functional silos.

I’m warming up to the idea that teams don’t externally commit to User Stories. Instead they commit to PSI Objectives as part of PSI Planning and sprint execution. I see value in the “wiggle room” this leaves for the team (and the Product Owner) in interpreting and delivering on aspects of the User Stories. There’s also a strong connection to Business Owners engaging with and approving the goals as part of PSI Planning that I like.

There was an incredibly healthy focus on NFR’s (Non-Functional Requirements) throughout the framework at all levels of work evolution through Epic – Feature – Story. All agile teams should take note of this point and learn from it.

While there is a focus in SAFe on quality activities, the emphasis was strongly towards three areas:

  1. Agile Architecture
  2. Continuous Integration
  3. Test-First

I was happy to hear, from a Test-First perspective, the recommendation that “all automated tests” for a particular User Story should be written in the sprint in which the story is delivered. I’ve been recommending this practice for years, but most clients think it virtually impossible to deliver on it. Perhaps SAFe’s recommendation will add renewed focus on testing and automation.

But I was also disappointed that only three quality activities were mentioned and all of them were developer/technology focused. For example, there was a total lack of focus or mention of: Exploratory Testing, Risk-based Testing, or Manual Testing as being viable techniques. Even the focus on NFR’s, was from the perspective of the story and not from a testing perspective.

Also missing was a focus on inspections and reviews. And you know what? I only heard references to Done-Ness or Definition-of-Done requirements once or twice in the entire class. I personally think of these as fundamental to the quality proposition of agile teams and the ART.

I’ve “heard” that in SAFe 3.0 there will be a new focus on leadership or management even to the point of defining roles for them. On the one hand, I like that “management” is being included in the framework, but again, it’s fairly prescriptive (see my concern #2 below). I’d rather that each instance of SAFe have the leadership and management teams FIND their roles and engage with their teams more. I’d like to get their commitment to more team level engagement and not hear the “I don’t have the time” excuse very often.

But all is not rosy in SAFe-ville, so I’d like to explore some concerns I still have after taking the class.

Top 5 Concerns

Coming out of the class, I do have some concerns. While I have more than five, I forced myself to order them by priority and here are the Top 5:

1.  As I’ve said in several blog posts, SAFe seems more targeted towards organizational leadership as a “package” to “buy” in order to implement agility. So it’s focus is mostly upward. Given that, I worry that the teams may be “left behind” in their training and treatment. While I was worried about this before the class, the class did nothing to decrease that worry. It affirmed for me that the primary focus is the upper two tiers of the model—i.e. towards leadership & management, and projects.

2.  There was tremendous emphasis at the beginning of the class on the importance of establishing solid agile leadership. How important this was in order to make SAFe, dare I say it, safe from a congruent leadership point of view. So I was looking forward to recommendations on how we would do that. In the end, out of four days of class time, we only spent about an hour on leadership dynamics in SAFe. The module was placed at the end of the materials and we simply ran out of time.

I think this is indicative of much of the SAFe focus. It stays away from or glosses over the “hard bits” and focuses on prescriptive guidance downward to the teams and towards execution. I’d much rather have a focus on leadership and management training & coaching and team level empowerment to get the balance right. But unfortunately they shied away from that.

3.  I generally got the feeling that the instructors (and perhaps Scaled Agile itself) were emphasizing SAFe over Scrum, XP, and Kanban. While they kept saying that they appreciated, supported, wanted to build on, and respected the methods that came before them, they clearly didn’t.

a.     For example, they ignored the Scrum guidance regarding number of Scrum Masters and Product Owners per team, the answer is one by the way, and recommended overloading both roles.

b.     Or the way they encouraged (forced) backlog prioritization to use Weighted Shortest Job First (WSJF) as the only way to prioritize work. While I liked the introduction of “economics” into things, I’m not sure if every organization needs to leverage this model—again, very prescriptive.

c.     Or the way they prescribed individual formats for Epics, Features, and User Stories.

4.  In my opinion SAFe travels way too far in establishing predefined roles and responsibilities. There are implications to Product Management and Release Management. There is the formation of a System Team. And there is the new role of a Release Train Engineer or Uber Scrum Master and Epic Owners. It’s not that the roles are bad; in fact I’ve seen and been a part of teams at scale who created similar groups or roles. It’s the fact that SAFe is prescriptive in creating these roles in ALL instances. Instead of that, I’d rather each organization think about their own needs and craft their own groups and roles based on their context.

5.  I did not appreciate the notion of aggregating velocity across teams and the implication of comparing and measuring teams together. Sure this makes forecasting across multiple teams in an ART simpler, but it sets a dangerous precedent and focus towards measuring performance by points. BTW: the magic number is 8 points per full-time person per 2-week sprint. Or roughly 40 points for a typical Scrum Team. Or roughly 1 point per person per day.

Wrapping Up

So do I unabashedly support ALL aspects of the SAFe framework now?  Or is SAFe the ONLY way to scale an agile organization?

No.

But I have learned what it’s all about and I have renewed interest and respect for its place in organizations trying to install agility at scale. More importantly I can now make my recommendations and adjust my coaching from a position of knowing rather than conjecture.

I also think the intentions of the SAFe community are largely pure in nature. For example, our instructors went out of their way to amplify respect of the agile ideas that came before SAFe. They also tried incredibly hard to explain the balance that is required to instantiate SAFe effectively. Balance between self-direction and prescription; between team and leadership; and between following SAFe and adjusting it.

And if you look below the surface, I believe there’s quite a lot of value in SAFe for the agile interested Enterprise. But if I had a word of caution, I’d say please, please, please don’t go it alone. And don’t go with consultants whose only tool and experience is SAFe-centric—or RUP-centric for that matter.

What I’d recommend is you look for deeply experienced and balanced agile coaches who’ve operated at-Scale with several frameworks—having multiple tools and experiences in their toolboxes. Then leverage them to guide your adoption and decision-making as to what to leverage and what to adjust.

One of my biggest takeaways from the SAFe class is that I’ll be having plenty of opportunities to help companies moving in this direction. So from that perspective, I think SAFe is a godsend. It gives companies a scalability framework and hopefully encourages them to go get some help in implementation and deployment. I can’t see SAFe truly being safe any other way!

Stay agile my friends,

Bob.

7 Comments