Addressing some SAFe concerns

Quite often, I encounter concerns with the Scaled Agile Framework. When looking at the Big Picture, and what many companies make out of SAFe, these concerns are valid - and should be taken serious. On the other hand, none of these concerns couldn't be addressed by a capable SPC and a management who cares about making a meaningful difference in their ways of working. In this article, I'm looking at some of them.

SAFe- Blessing or curse?

Typical Concerns with SAFe

Before digging in: I do believe that the skills and experiences of your SAFe Practice Consultants are critical for the success of SAFe. If you rely on people who don't understand the consequences of any advice they give, you're in for a rough ride. An SPCT friend of mine recently said, "Having the wrong SPC's - or skipping the guidance of an SPC altogether - will easily cost you tenfold of what a good SPC would cost you." I agree. Good SPC's are worth their weight in gold. Unfortunately, they don't grow on trees ... but that's a different story.
Now, let's take a look at some of the concerns I typically encounter, and what we need to consider.

SAFe caters to traditional mindset

SAFe acknowledges and respects that many organizations transitioning to agile practices still have a traditional mindset. Therefore, a lot of material in SAFe is written in a way that might be more palatable to people who have a low understanding of agility. This is the idea of "meet people where they are." Yes - that's contentious, but it's by far better than affronting the very people you need in order to make a change. What happens after we met them - that depends a great deal on their motivation to change, and the ability of the SPC to lead change.

Complexity overkill

First things first - if you don't have the problems SAFe addresses, don't use it. With that out of the way, SAFe can't - and usually shouldn't - be applied completely. Much rather, when we spot a problem for which SAFe proposes a solution, we can look at what SAFe says, have a discussion on whether that's worth a try - and if it is, then go for it. That neither means that you need to do things that solve problems you don't have, nor that you have to do things the way SAFe says if that doesn't work for you. For myself, when someone comes to me and says, "We're using SAFe, and have this-or-that problem," I commonly refer to a SAFe article, and the original source pointers SAFe refers to, and take the discussion from there. To me, SAFe is a discussion starter - not the panacea for all ails.

Dependencies everywhere!

SAFe recognizes that dependencies can be a challenge in complex organizations. It provides clear guidance and practices that make dependencies visible, and then offers a way to address these dependencies systematically. In many organizations, dependencies are inevitable - but at least we know which troubles we have because of them, and can start the discussion of what to do about them. I have encountered more than once that teams found their dependencies unworkable and decided to re-organize. A great discussion to have.

Length of planning intervals

SAFe employs a cadence-based planning approach with fixed-length Planning Intervals (PIs) typically spanning 8-12 weeks. Longer planning intervals provide stability and predictability for teams at the expense of flexibility. However, you can adjust the duration of PIs based on your own context. I have seen Agile Release Trains running 3 1-week Sprints plus a 1-week IP Sprint. That even fits Scrum's old slogan of, "Working Software in 30 days or less" - at scale! Try what works for you, and have the discussion.

Top-down planning processes

Maybe we have the wrong picture in our heads, but who can blame us - when we've been conditioned to think in hierarchies? In a SAFe context, we'd like to decentralize that which makes sense - but not everything makes sense to decentralize. For example, the Product Management function in SAFe could be staffed from team Product Owners, if they have the skills and capacity to succeed in that role, so it doesn't need to be hierarchical. What we need is a clear focus on the bigger chunks of value, and align all teams around them. How this happens can vary per organization, but having each team decide by themselves - doesn't bode well. Please be aware that SAFe encourages active involvement and empowerment of teams and individuals in making decisions.

Not proper Scrum

SAFe is not a strict implementation of Scrum, but rather a framework that incorporates agile principles and practices from various sources, including Scrum. Since many teams already run Scrum and are familiar with the core concepts of Scrum, SAFe has taken advantage of that and it retains the fundamental principles of transparency, inspection, and adaptation. When I coach SAFe teams, I quite often refer to the Scrum Guide, and suggest that understanding and practicing Scrum really well helps a lot getting the scaling part right. Unfortunately, what I see quite often is that organizations have already used a highly dysfunctional Scrum for years, and now want to change that. If anything, the SAFe transformation could be an opportunity to fix the Scrum stuff that was always broken and never got addressed.

Teams become Feature Factories

That's already a dysfunction - because SAFe features should focus on value, not on maximizing quantity of work delivered. We should only have a single ART Kanban that's prioritized by value - and teams should collaborate on shared objectives, using common backlogs and cross-team events to ensure a cohesive system solution that maximizes value. While sometimes, we see that individual teams may focus on delivering their own features irrespective of value, SAFe provides mechanisms such as System Demos and Inspect and Adapt events to ensure they don't go off on a tangent and do a large quantity of low-value work.

Fallacious estimation processes

A lot could be said about SAFe's estimation process, and I have my own opinion on the guidance they give. To keep it simple: its guidance is only for people who don't know how to get started. Coaching and empiricism should lead to an approach that meets the needs of those who need the estimates. We should realize that in larger organizations, where quite often multiple stakeholders, other teams and potentially large amounts of money depend on making fairly accurate forecasts for completion, estimation may have implications that don't exist in smaller contexts. My own go-to example is that we need to absolutely know whether the feature will be ready for the Trade Fair, or whether we need to mitigate. But "Well, we might or might not be ready in time for the fair" - could lead to a major PR disaster, and is probably unacceptable.

One Continuous Improvement event every 3 months is too little, too late

While the Inspect and Adapt (I+A) event occurs at the end of each Planning Interval (PI), SAFe encourages continuous improvement throughout the PI, with both the Scrum-of-Scrums (SoS) and Retrospectives being opportunities to surface and address cross-cutting issues. I myself like to give the guidance that teams are expected to make their own changes and improvements independent of the I+A event, and even share learnings with other teams during that event. I expect teams to bring short-term issues to the SoS, and only bring issues to the I+A which require longer preparation and observation periods, and have an impact far beyond the team boundaries. Most of all, we need to consider that the I+A is a point of reflection, where we detach from the daily routine, and come together as a team-of-teams to discuss the things we need to discuss that we never got to discuss before. There's always something. Yes, we could have such events more often - if you feel that it could help, there's nothing in SAFe stopping you. Try it.

Conclusion

I agree that the Scaled Agile Framework (SAFe) has areas of interpretation and concerns. Expecting it to be a silver bullet is completely unrealistic. It does provide a structured approach for larger organizations trying to make sense of this entire "Agile" thing, though - but that only works if they have someone who understands more than just what the material says. When you can address the complexities of large-scale development, cross-team collaboration and overall alignment while continuously improving, you've succeeded with SAFe. To get there, you absolutely must customize SAFe, and use it wisely - otherwise it will become a mess, and that's why you need some folks who know what they're talking about. And I've seen that mess: The shambles take years to clean up. The people who support your change initiative need to be able to address critical concerns based on their own experience and learnings. And the people in your organization who have concerns need a time and place to voice these concerns - because only then can we truly improve.

SAFe Values - no real value!

Transparency, Built-in Quality, Alignment. Program Execution.

These are the four "SAFe Core Values." But - are they actually, "values?"

What are SAFe Values?

According to the official SAFe website, the SAFe Core Values are:

The four Core Values of alignment, built-in quality, transparency, and program execution represent the fundamental beliefs that are key to SAFe’s effectiveness. These guiding principles help dictate behavior and action for everyone who participates in a SAFe portfolio.

I would like to focus your attention to the highlighted terms:

1. Fundamental beliefs: In order for "SAFe Values" to make any sense, you must buy into this belief system. If you don't share one or more of the underlying beliefs, the cookie crumbles and the "Value System" of SAFe becomes meaningless. Let's also mention that the idea of "fundamental beliefs" originates from religion - it doesn't coincide well with science.
2. Guiding principles: What is a guiding principle? Let's examine the meaning of a principle: "a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning." Here, we're pretty close to circular reasoning: SAFe Core Values are fundamental - because they are fundamental. A foundation isn't negotiable, because everything built on it collapses without that foundation. But - are these "fundamental truths" axiomatically true - or are they based on perspective?
3. Dictate behaviour and action - "Dictate" is a much stronger term than, for example, "orient" or even "inform." Based on the fundamentals, you have only one course of action, and it's not open to negotiation or discussion: it's mandatory.

From a linguistic perspective, the SAFe values are beyond scrutiny and would be considered a totalitarian rule: You must believe them, and you must do what they say.

Fundamental beliefs dictating behaviours coincide neither with science - nor agility.

Without getting any further into this matter, let me first clarify that I have never, ever experienced a SAFe fanatic. I have seen my share in the Scrum community, but SAFe practitioners - by and large - tend to be very pragmatic. "Doing what makes sense" is high on the list, and hence, I would give both the idea of "fundamental" beliefs and the idea of "dictating" behaviour a break.

That's just half the matter, though.

The other half is - how these terms tend to be understood in a larger corporation.

Much of an enterprise system is built around the idea that transparency is a one-way street, alignment equals incorporating others' opinions, quality a matter of governance. "Program execution" - well, it requires setting up programmes. With a separation between coordination and execution.

Not-so-fundamental beliefs

A problem of SAFe's core values is that these very underlying beliefs aren't defined from an agile point of view - when a company introduces SAFe, they are taken as "fundamental." Management understands these terms in a certain way, and discussing a "fundamental truth" seems to be a waste of time, because - they're fundamental, and we already understand them. Hence, the crucial discussion, "What do these terms mean?" won't happen. Instead, the terms become a projection of status quo onto an agile organization.

If you start with these four key premises:

1. Transparency: We require a chain of command giving clear orders, and we rely on detailed reports.
2. Alignment: We must ask for the opinions of people not doing a specific piece work, and only do things they agreed to.
3. Built-in Quality: We need some kind of governance telling people what their job is, and how to do it properly.
4. Program Execution: We must set up large programmes which bind a lot of time, money and manpower.

... then congratulations: the core idea of "Agile" is already dead and buried.

Hence, we first need to discuss how we want to understand these terms before we can build an agile organization where these terms even make sense.

What's (a) Value

Unlike beliefs, values aren't "fundamental," "truths," or "principles."

Value, as defined in Oxford dictionary, is:

Value - how much something is worth in money or other goods for which it can be exchanged.

Note again, that there are two critical statements here: worth and exchange.

A value is about the "worth" of something, not a boolean attribute. 

When asking, "What's the value of this car?", you wouldn't expect "Yes" as an answer.

Value only exists when there is a metric and a conversion rate towards another entity, so that people can decide what kinds of trades they would make - and which they would not.

For example, let's assume we measure quality on a scale of 1-10, and you have a quality level of 5. That's merely a measurement: It's not a cross-referenced metric. If you want quality to have value, you would need to relate it to something else, such as "1 quality is worth 3 time."

The statement, "we must have all of built-in quality, alignment, transparency and program execution" would not define "core values." To have an actual value system, we must be able to make trades between quality, alignment, transparency and execution - and we must be able to determine which trade-offs are advantageous, and which aren't.

How much execution are you willing to invest into alignment instead? How much quality would you give for transparency?
These aren't values, unless you can answer those questions.

And for the record - if you'd answer, "None," then you have just discarded the value entirely.

You only have a "value" if you can trade for it.

Considering a SAFe value system

In order to turn "beliefs" into values, we need to be able to make trade-offs based on something. We need to state how much we are willing to give, in order to gain some of what we believe in.

The easiest way to make trade-offs is by investing more or less time or money.

Quality

makes a formidable value, since we can immediately relate it to money: We can determine the cost of poor quality (i.e., the failure to produce high quality) based on projected cost of failure and/or rework. This cost is so staggeringly high that quality has an extremely high value, and the price of reducing it is extremely high. Although the numbers for reducing quality rarely add up, we can do it, and clearly quantify cost, benefit, exchange rate and margins.

Alignment

converts formidably to time - we could do something now, and show the outcomes. Or we could first align, which would mean that we will have no results until alignment is done. It also means that we're not earning money in the meantime. Plus, we're spending effort. Hence, we can assign a financial cost to alignment.

When we can say how many days an improvement / reduction of 1 point on our alignment scale will gain or cost, and how much money we gain / lose during that time, then alignment might become a value.

Transparency

is very hard to turn into a value, because it's extremely hard to define.

What is transparency even - and how would the gain or loss of one point on our transparency scale convert into time or money? We could measure the cost of information inavailability, which in itself is only visible via second-degree indirection - we must peek at the delays incurred by waiting for information to become available, and at the cost of that time. We could also measure the cost of evitable, wrong decisions that were made because people made choices in the absence of existing information. We then also need to reverse the calculation, computing the cost and time required for producing information not required for decision-making ("information waste").

Companies capturing this kind of data are so rare that the measurement of transparency remains elusive.

 

Execution

simply doesn't make sense as a "value." How much time or money is one unit of "not doing anything" worth? How many would we want? Is there ever even a potentially valid scenario where having a plan, and not acting upon it, has a positive value attached? If so - we should immediately ditch that plan! 

And that's not even digging into the question whethere there's value in a "program," that is, a large-scale initiative. Skunkworks has already shown two generations ago that programmes are often more of a problem than a solution.

SAFe Core Values - a wishlist for Santa!

When we're talking about "SAFe Core Values", we're not talking about values at all, since we're not even discussing potential trade-offs.

Quality is the only "value" of SAFe that managers would actually consider trading off, despite being so ridiculously expensive that this isn't economical: The best quality has the lowest cost - "less costs more and brings less." It's absolutely something an economical thinker would want to maximize.

Alignment, as commonly understood, comes with a negative net benefit - "more costs more and brings less." So, it's not something of value. Why would we want it, besides clinging to a belief that it's somehow important?

Transparency is too elusive to be considered a value: Everyone wants it, but nobody can really say what, or how much, we'd want to trade for it.

Program Execution doesn't make sense as a value. It's boolean: If we want to do something, just do it. If we don't want to do it - why is it relevant?

Hence, SAFe's "core values" are nothing more than a wishlist for Santa - something that almost every manager in the world will say they want, and nothing they'd be willing to pay a price for. 

Anything for which you're unwilling to pay a price, has no value. It therefore can't be considered a value.

SAFe has only one real value: built-in quality. And that's the first ones most organizations kick out of the window.

If you want SAFe "Values", you'll need to do a lot of groundwork and figure out what it is that you actually want: You're not done with simply accepting them.

The "Planning Tetris" Antipattern

 "We need to utilize all of our Story Points" - that's a common dysfunction in many Scrum teams, and especially in SAFe's Agile Release Trains where teams operate on a Planning horizon of 3-5 Sprints. It results in an antipattern often called "Planning Tetris." It's extremely harmful, and here's why.

Although the above feature plan appears to be perfectly optimized, reality often looks different: all items generate value later than they potentially could - at a higher cost, in longer time and with lower efficiency!

Accumulating Work in Process

Planning Tetris often leads to people starting work on multiple topics in one Sprint, and then finishing it in a later Sprint. It is resource-efficient (i.e. maximizing the utilization of available time), not throughput-efficient (i.e., maximizing the rate at which value is generated.)

That leads to increased Work in Process, which is a problem for multiple reasons:

Value Denial

Just like in the sample diagram above, "Feature 1" and "Feature 2" could each be finished in a single Sprint. And still, Feature 1 doesn't provide any value in Sprint 1, and Feature 2 has no value in Sprint 2. So, we lose 1 Sprint of marketability on Feature 1 (our highest priority) - and on Feature 2 as well:

A perfect example how utilizing the team makes the value come later!

Loss of money

Imagine now that every feature costs less than it's worth (which it should, otherwise it wouldn't be worth developing) - and you see that the "saved" efficiency of having worked on features 3 and 4 before finishing feature 1 costs the company more money than the added benefit .

Efficiency loss

You may argue, "different people are working on the features, so there's no multitasking."

Yes - and no. What is happening?

Sprint Planning for Sprint 1 has to discuss 3 features: 1,3 and 4. This means that the whole team is discussing three different topics, (none of which will be delivered in that Sprint.) The same happens in Dailies and Review. And, potentially at a source code level as well. The feature interference may also bloat up the complexity of technical configuration, deployment processes and the like.

The team becomes slower, hence less efficient.

Adding needless risk

In statistics, there's a phenomenon called "the high probability of low probability events." Let me explain briefly:  There's an infinite amount of almost infinitely-unlikely events, but unfortunately, high infinity divided by low infinitiy is still a number close to one: Something will happen. You just don't know what, and when, so you can't prepare or mitigate. Since you don't know which aspect of your plan will be affected when a risk hits, you'll always be caught by surprise.

How is that a bigger problem in Planning Tetris than in sequentialized delivery?

Massive ripple effect

When you're working on one topic, and an event hits that affects your entire team, you have one problem to communicate. When the same happens as you're working on multiple topics, all of them are impacted, and you're generating a much stronger ripple effect.

Complex mitigation

As multiple topics are in process, you suddenly find yourself mitigating multiple topics. And that means multiplicative mitigation effort - less time to work, and at the same time a higher risk that not all mitigations are successful. You end up with a higher probability of not being able to get back on track!

Chaotic consequences

Both the ripple effect into the organization and the mitigating actions could lead to unpredicted consequences which are even harder to predict than the triggering event. In many cases, the only feasible solution is to surrender and mark all started topics as delayed, and try to clean up the shards from there.

Prepare to Fail

There's Parkinson's Law - "work always extends to fill the amount of time available." That's often used as an argument to start another topic, because it stops gold-plating and keeps people focused.

But there's also the (F)Law of Averages: "Plans based on averages fail half the time."

The latter makes planning tetris a suicidal approach from a business perspective: it starts a vicious circle.

Predictable failure

Because there's no slack built into planned tetris, the mid-term plan will automatically fail as soon as a single feature turns out more complex than planned. The more features are part of our tetris stack, the more likely at least one of them will fail. And the team will usually get blamed for it. Because of that, we end up with

Conservative estimates

Teams must allocate the slack buffers into their feature estimates to reduce the probability of failure. When a Tetris plan spans multiple Sprints, some feature content may not be "Ready" for implementation during the Sprint when slack would be available - so we end up with Parkinson's Law, the buffered estimates don't reduce failure probabilities. 

Declining throughput

At this point, Parkinson's Law tag-teams with the Flaw of Averages to KO the team: Regardless of how conservative the estimates, the team will still end up failing half the time. The consequence is that business throughput continues to decline (there's an interesting bottom: when a Sprint only contains one feature!) 

Strangulating the team

Let's take a look at the psychological impact of Planning Tetris now as well:

No space for Creativity

I have never seen an organization where Product Management was happy that developers would add "creative spaces" into a Tetris Plan. It's all about churning out feature, after feature, after feature, without a pause, without a break. When one feature is done, another is already in progress. There is no room to be creative.

No space for Growth

The only relevant business outcome in Tetris Plans is usually business value delivered. It ignores that developers are the human capital of the organization, and growing them is growing the organization's ability to deliver value. Especially in the rapidly changing tech industry, not growing equals falling back until eventually, the team is no longer competitive.

No space for Improvement

I often advise that developers should take some time to look at "Done" work to reflect how it could have been done better, and turning that better way into action. With Planning Tetris, that opportunity doesn't exist - another feature is waiting, and improving something that exists is always less important than delivering the next big thing. That often ends in terrible products which are no joy to deal with - for developers and customers alike!

Now ... what then?

The point that Planning Tetris is a terrible idea should be blatantly obvious.

"Now what's the better way then?" - you may ask.

It sounds incredibly simplistic, because it is actually that simple.

1.  Reduce the amount of features the team is working on in parallel to an absolute minimum. This minimizes blast radius.
2.  Instead of having people parallelize multiple topics, let "inefficient", "not-skilled" people take easier parts of the work to step up their game. That reduces the impact of low-probability events and gives everyone air to breathe.
3.  Put slack into the Sprints. The gained resilience can absorb impact. It also reduces the need for buffered estimates, countering Parkinson's Law and the Flaw of Averages. It also gives people air to breathe.
4.  Agree on Pull-Forward. When the team feels idle, they can always pull future topics into unused idle time. Nobody complains when a topic is finished ahead of time, everyone complains when something turns late. Pull Forward has no ripple effects or chaotic consequences.

Ok, too many words, so TL;DR:

1. Sequentialize.
2. Slack.
3. Pull.

All problems mentioned in this article = solved.

Why WSJF is Nonsense

There's a common backlog prioritization technique, suggested as standard practice in SAFe, but also used elsewhere, "WSJF", "Weighted Shortest Job First." - also called "HCDF", "Highest Cost of Delay First" by Don Reinertsen.

Now, let me explain this one in (slightly oversimplified) terms:

The idea behind WSJF

It's better to gain $5000 in 2 days than to gain $10000 for a year's work. 

You can still go for those 10 Grand once have 5 Grand in your pocket, but if you do the 10 Grand job first, you'll have to see how you can survive a year penniless.

Always do the thing first that delivers the highest value and blocks your development pipeline for the shortest time. This allows you to deliver value as fast and high as possible. 

How to do WSJF?

WSJF is a simple four-step process:

To find out what the optimal backlog position for a given item is, you estimate the impact of doing the item ("value") and divide that by the investment into said item ("size") and then put the items in relation towards each other.

It's often suggested for estimated to use the "Agile Fibonacci" scale, so "1, 2, 3, 5, 8, 13, 20, 40, 80..."

The idea is that every subsequent number is "a little more, but not quite twice as much" as the previous one, so a "13" is "a little more than 8, but not quite 20". 

Since there are no in-between numbers, when you think you're not sure whether an item is 8 or 13, you can choose either, because these two numbers are adjacant and their difference is considered miniscule.

Step 1: Calculate "Value" Score for your backlog items.

Value (in SAFe) is actually three variables: User and/or Business Value, Time Criticality, Enablement and/or risk reduction. But let's not turn it into a science. It's presumed value.

Regardless of how you calculate "Value", either as one score or a sum or difference of multiple scores, you end up with a number. It becomes the numerator in your equation.

Step 2: Calculate "Size" Score for your backlog items.

"Size" is typically measured in the rubber-unit called Story Points, and regardless of what a Story Point means in your organization or how it's produced, you'll get another number - the denominator in your equation.

Step 3: Calculate "WSJF" Score for your backlog items.

"WSJF" score, in SAFe, is computed by dividing Value by Size.

For example, a Value of 20 divided by a size of 5 would give you a WSJF score of 4.

Step 4: Sort the backlog by "WSJF" Score.

As you add items, you just put them into the position where the WSJF sort order suggests, with the highest value on top, and the bottom value on the bottom of the backlog.
For example, if you get a WSJF of 3 and your topmost backlog item has a WSJF score of 2.5, the new item would go on top - it's assumed to be the most valuable item to deliver!

And now ... let me dismantle the entire concept of WSJF.

Disclaimer: After reading the subsequent portion, you may feel like a dunce if you've been using WSJF in the real world.

WSJF vs. Maths

WSJF assumes estimates to be accurate. They aren't. They're guesswork, based on incomplete and biased information: Neither do we know how much money we will make in the future (if you do, why are you working in Development, and not on the stock market?) nor do we actually know how much work something takes until we did it. Our estimates are inaccurate.

Two terms with error

Let's keep the math simple, and just state that every estimate has an error term associated. We can ignore an estimator's bias, assuming that it will affect all items equally, although that, too, is often untrue. Anyway.

The actual numbers for an item can be written as:

Value = A(V) + E(V)  [Actual Value + Error on the Value]

Sizes = A(S) + E(S)  [Actual Size + Error on the Size]

Why is this important?

Because we divide two numbers, which both contain an error term. The error term propagates.

For the following section, it's important to know that we're on a Fibonacci scale, where two adjacent items are always at least 60% apart.

Slight estimation Error

If we over-estimate value, an item will have at least 60% higher value than estimated, even if the difference between fact and assumption is miniscule. Likewise, if we under-estimate value, an item will have at least 30% lower value than estimated.

To take a specific example:

When an item is estimated at 8 (based from whatever benchmark), but turns out to actually be 5, we overestimated it by 60%. Likewise, if it turns out to actually be 13, we underestimated it by 38.5%.

If we're not 100% precise on our estimates, we could be off by a factor of 2.5!

The same holds true for Size. I don't want to repeat the calculation.

Larger estimation error

Remember - we're on a Fibonacci scale, and we only permitted a deviation by a single notch. If now, we permit our estimates to be off by two notches, we get significantly worse numbers: All of a sudden, we could be off by a factor of more than 6!

Now, the real problem happens when we divide those two.

Square error terms

Imagine that we divide a number 6 times larger than it should be, by a number 6 times smaller than it should be, we get a square error term.

Let's talk in a specific example again:

Item A was estimated as 5 value, but it was actually a 2 value. It was estimated as 5 size, but it was actually a 13 size. As such, it had an error of 3 in value, and an error of 13 in size.

Estimated WSJF = (2 + 3) / (13 - 8) = 1

However, the Actual WSJF = 2 / 13 = 0.15

Now, I hear you arguing, "The actual numbers don't matter... it's their relationship towards one another!"

Errors aren't equal

There's a problem with estimation errors: we don't know where we make errors, otherwise we wouldn't make them, and we also make different errors, otherwise, they wouldn't affect the scale at all. Errors are errors, and they are random.

So, let me draw a small table of estimates produced for your backlog:

Item	Est. WSJF	Est. Value	Est. Size	Act. Value	Act. Size	Act. WSJF
A	1.6	8	5	5	5	1
B	1	8	8	3	20	0.15
C	0.6	3	5	8	2	4
D	0.4	5	13	13	2	6.5

Feel free to sort by "Act. WSJF" to see how you should have ordered your backlog, had you had a better crystal ball.

And that's the problem with WSJF

We turn haphazard guesswork into a science, and think we're making sound business decisions because we "have done the numbers", when in reality, we are the victim of an error that is explicitly built into our process. We make entirely pointless prioritization decisions, thinking them to be economically sound.

WSJF is merely a process to start a conversation about what we think should be priority, when our main problem is indecision.
It is a terrible process for making reliable business decisions, because it doesn't rely on facts. It relies on error-prone assumptions, and it exacerbates any error we make in the process.

Don't rely on WSJF to make sound decisions for you. 

It's a red herring.

The discussion about where and what the value is provides much more benefit than anything you can read from a WSJF table. Do the discussion. Forget the numbers.

 

PI-Planning: Factors of the Confidence Vote

 The "Confidence Vote" is a SAFe mechanism that is intended to ensure both that the created PI Plan is feasible, and also to ensure that people understand the intent behind creating the common plan - what it means, and what it doesn't. Implied in SAFe are two different kinds of confidence vote with slightly different focus.

Train Confidence Vote

The "Train Confidence Vote" is taken on the Program Board - i.e. the aligned, integrated PI plan across all teams. All participants of the PI-Planning are asked to simultaneously vote on the entire plan. Here are the key considerations, all of which should be taken into account:

Objectives: Feasibility and Viability

First, we should look at the ART's PI objectives realistic, and does it make sense to pursue them? Do we have our priorities straight, and are we focused on delivering maximum value to our customer?

High Confidence on PI objectives would imply that these objectives are SMART (Specific, Measurable, Ambitious, Realistic, Timebound) within the duration of the PI.

Features: Content and Scope

Do we have the right features, do all of them provide significant progress towards our objectives, did we pick a feasible amount, and did we arrange them in a plausible order and are the right people working on them? Is the critical path clearly laid out, and is the load on the bottleneck manageable?

High Confidence on Features would imply that everyone is behind the planned feature arrangement.

Dependencies: Amount and Complexity

If we have too many dependencies, the amount of alignment effort throughout the PI will be staggering, and productivity is going to be abysmal. You also need to manage external dependencies, where the Train needs something from people who aren't part of the Train, and you need to pay extra attention when these people didn't even attend the PI-Planning.

High Confidence of Dependencies would imply that active efforts were made to eliminate as many dependencies as possible, and teams have aligned already how they deal with the inevitable ones. When people either mark a high amount of dependencies without talking about them, or you feel that some weren't mentioned, that should reduce your confidence drastically.

Risks: Quantity, Probability and Impact

Risks are normal part of life, but knowingly running into disaster isn't smart. Were all the relevant risks brought up? Have they been ROAM'ed properly? How likely will you be thrown off-track, and how far?

When you consider risks well under control, that can give you high confidence in this area - when you feel like you're facing an army of gremlins, vote low.

Big Picture: Outcomes and approach

After looking at all the detailed aspects, take one step back: Are we doing lots of piecemeal work, or do we produce an integrated, valuable product increment? Do we have many solitary teams running in individual directions, or do we move in the same direction? Do you have the impression that others know what they're doing?

When you see everyone pulling on the same string and in the same direction, in a feasible way, that could give you high confidence. When you see even one team moving in a different direction, that should raise concerns.

Team Confidence Vote

During your breakout sessions, the Scrum Master should frequently check pulse on team confidence. The key guiding question should be: "What do you need so that you can vote at least a 4, preferrably a 5, on our team's plan?"

Your team plan is only successful when every single member of the team votes at least a 3 on it, so do what it takes to get there. It's entirely inacceptable for a team member to lean back comfortably and wait for the team confidence vote and then vote 2, they should speak up immediately when they have concerns. Likewise, it's essential that teams have clarified all the issues that would lead them to vote low on their team's plan before going into the PI confidence vote.

When your team can not reach confidence, do not hesitate - involve Product Management and the RTE immediately to find a solution!

Here are the factors you should consider in your team confidence vote:

Objectives

Does your team have meaningful objectives, are you generating significant value?

Understanding

Do you really understand what's expected from you, how you're contributing to the whole, what makes or breaks success for you - what the features mean, what your stories are, what they mean, and what's required to achieve them?

Capacity and Load

Do you understand, including predictable and probable absences, how much capacity your team has?  How likely can you manage the workload? Have you accommodated for Scrum and SAFe events? Would unplanned work break your plan?

Dependency Schedule

Can you manage all inbound dependencies appropriately, do you trust the outbound dependencies to be managed in a robust way? What's your contingency plan on fragile dependencies?

Risks

Are you comfortable with the known risks? Do you know your Bus Count, and have you planned accordingly? Do you trust that larger-scaled risks will be resolved or mitigated in time?

Readiness

Right after the PI-Planning, you will jump into execution. Do you have everything to get on the road?

Closing remarks

This list isn't intended to check each factor individually, and it isn't intended to be comprehensive, either. It is merely intended to give you some guidance on what to ponder. If you have considered all these, you probably haven't overlooked anything significant. If you still feel, for any reason, that you can't be confident in your plan, by all means, cast the vote you feel appropriate, and start the conversation that you feel is required.

It's better to spend a few minutes extra and clarify the concerns than to find out too late that the entire PI plan is garbage.

ART Design - and: Solving the wrong problems

It's amazing how good organizations are at solving the wrong problem, i.e. "doing the wrong thing righter". Here is a great example of how not to design an ART:

This was the outcome of a PI-Planning. Their planning Retrospective led people to conclude that "electronic tools are much better for developing a Program Board than physical boards, because the dependencies are way too difficult to correlate with all those strings floating around, falling off, getting intertwined and so on."

This Train operates based on the assumptions that they have the right ART, the right teams - and are working on the right things. Never did it cross anyone's minds that any of these assumptions might be wrong.

The wrong ART

The first question we need to ask ourselves: do we have the right Agile Release Train?
If there is an extensive dependence on people outside the Agile Release Train, or there's a massive capacity bottleneck within the ART, while people outside the ART do have capacity to do the blocked work, then we might want to slice the ART different.

The wrong teams

It's okay for teams to occasionally depend upon one another. It fosters learning and information exchange. Some Product Managers even go as far as to purposely define features in a way that "swarming" across teams allows the ART to generate value faster. When teams choose to split work  and collaborate in real time to maximize value generation, that's a plus.

What is not okay, and a clear indicator that we have the wrong teams: When no team can get any work done without relying on actions of other teams.

Even Component Teams should be able to release value straight into Production, when teams can only do piecemeal work, those are specialist teams that inhibit the flow of value.

I have seen more than once how teams, guided by experienced SPCs and insightful RTE's, have spontaneously used the PI-Planning to "disband and regroup" - reforming as teams capable of delivering end-to-end value: It's possible!

The wrong work

The above example is a clear example of what leads to doing the wrong work. With so many dependencies, "dependency management" is already a full-time job. It shouldn't be. It should be effortless.
The prime directive of dealing with dependencies is: "Minimize."

When I see two or three dependencies on a PI Planning board, I'm happy - it means, we have decent team constellations and the right skills in the teams.
When I see more than ten dependencies, I will express concerns about team constellation.
When I see more dependencies than features on the board, I would ask the ART to work on resolving their dependencies rather than figure out better ways to manage their dependencies.

A few thoughts on SAFe

I often get asked what my general stance on this framework is, hence I would like to share my personal opinion with you.

The short answer is: “We don’t live in Cockaigne. Making the world slightly better sure beats dreaming up how it would be perfect. Still, that’s not an excuse to get up on the wrong foot.”

The long answer is this post.

Why use SAFe?

Being an enthusiast agilist, people sometimes ask me how I can support this framework. To me, that’s quite easy to answer – although the answer decomposes into a large number of facets.

Premade decisions

Some organizations have decided to implement SAFe before I get involved with them. I see my responsibility to help organizations find better ways of working, and regardless where they stand, I can do this. SAFe can be a vehicle for simplifying portfolio processes, adopting more reliable development practices, remove pointless status meeting and many other things. Is that local optimization? Could be. But it makes peoples’ lives better.

Where SAFe helps

I know that many agilists will cringe at the idea of actively suggesting SAFe. I don’t see SAFe nearly as much as the problem as the wrong expectations associated with it. Depending on where you currently stand, SAFe can be a stepping stone to a simpler, more effective organization with faster, more flexible decision processes. Which portion of SAFe is needed for that? That totally depends on which problem you want to solve. Don’t use a 40t truck to bring a fork from the kitchen to the dinner table – but when you’re stuck with a gigaton of organizational process mud, Scrum just won’t cut through the problems faster than they accumulate.

Getting out of discussion loops

SAFe’s high market penetration and widespread acceptance cuts short a lot of discussions whether certain concepts are “esoterical” or “applicable in Enterprises”. Pointing to SAFe as a resource collection can break stalemates caused by people who didn’t yet spend time familiarizing themselves with lean and agile mindset. Probably the most common concept that’s incredibly difficult to crack without having a chance to demonstrate is that teams need to be told and controlled in regards to “what to do when” in order to get results.

The SAFe Big Picture

I think that SAFe’s Big Picture is a stroke of genius, because it’s a handy diagram that can be used as a discussion starter to point out what is currently amiss, overcomplicated or ill implemented. Having a deep understanding to explain these concepts to the client is – in my opinion – essential to ensure that we don’t just go about implementing something that meets the form and actually solves the problem at hand. Implement SAFe as per picture is an entirely different issue.

SAFe concepts

True to one of Dean Leffingwell’s favorite Bruce Lee quotes, “Take whatever works, and take it from wherever you find it”, there are a lot of great ideas and concepts included in SAFe. While steering clear of mindlessly applying changes to an organization in places where it doesn’t help, SAFe’s comprehensive practice catalog is a great way to focus discussions with people who have never heard about these concepts before.

Common practice

Arguably, there’s nothing new to SAFe. Everything is “common practice” that has been used time and again in many organizations. Applying SAFe principles and practices will neither make you an industry leader nor a thought leader, but it may get companies unstuck and modernized. This, I think is the main value of SAFe.

What to expect from SAFe?

Expectation management is an important aspect of any change initiative. Agilists who expect a simple, flexible organization where teams have full technical and procedural autonomy will find themselves sorely disappointed by SAFe – because environments where that makes sense aren’t the target audience for SAFe.

SAFe addresses complex organizations where teams are bound by higher-order dependencies, either due to the complexity of the product itself or due to the sheer size of the value stream. A single team can easily build a web platform used by millions – and still, that same team would find themselves overchallenged if said platform was just a part of a much larger ecosystem: There’s a reason why companies like Amazon have more than ten developers.

Staying in the Amazon example, that’s an example of a company with Information Technology in their DNA – they know how to create software, build digital value streams and decouple subsystems. Many enterprises have a DNA where IT is just a fulfilment agency of non-digital business models. It would be a category error to treat these enterprises exactly like a Digital Unicorn. SAFe won’t get you there, either – what it can do, though, is set the change process in motion.

SAFe and the meta endgame

Let’s talk about the digital endgame for a bit. Many organizations struggle with survival. Former market leaders fade to insignificance or disappear into bankruptcy because they don’t understand digital product development. Talk about Kodak, Sears, Blockbuster or recently Thomas Cook. Non-digital giants are in their own endgame already. Unless they change massively, they will disappear.

For such organizations, a good implementation of SAFe can bring them closer to finding their place in a constantly disrupted marketplace. Then, they must move on lest they get stuck in a new status quo.

SAFe and success

A SAFe organization would approach enterprise initiatives differently than traditional Project / Program / Portfolio management. Cutting beyond labels, an “Epic” or “Initiative” (whatever agilists prefer) is still a kind of project. An ill-defined Epic won’t fare better in the face of change than a traditional project. There’s a lot to be said about “How” and “Why” we would even want to use an Epic Portfolio. Organizations that fail to address how they go about scoping, budgeting or implementing software will find very limited benefit in SAFe.

To be more successful with SAFe, it has to go far beyond IT. Portfolio management happens at senior management level, and it must be aligned with non-IT business units. Finance must be on board - accounting must change. We must move away from defining scope and content upfront and become rigorous at examining incremental value and axing initiatives when a value hypothesis turns out to be invalid. This requires a level of courage that many organizations lack. Culture must change as well.

SAFe and developers

A common gripe that many developers have with SAFe is that it leads to higher pressure and doesn’t address the fundamental problems. They therefore claim that either nothing has improved or things got even worse. From a developer’s perspective, and having seen many poor SAFe implementations myself, I could even agree.

I need to put this into perspective, though: Some companies I worked with will state that SAFe has cut their time-to-market in half and significantly reduced the failure rate of critical initiatives. What the developers don’t see – these successes that are totally outside their field of vision have secured their paychecks for many months.

To make SAFe a positive for experience for developers, the organization must work on many topics that may elude many managers: putting developers into control of their own work, providing clear, transparent objectives and meaningful work, improving the working environment and becoming an attractive employer across the board. This must be scoped in the transformation as well.

SAFe and massive change

Put bluntly, if you don’t require massive change, SAFe probably isn’t for you. And with this, I don’t mean a giant (maybe intercontinental) shuffling of the Org Chart. SAFe requires you to make drastic changes at every level, in every way. The organizational change is the easy, simple – and shockingly – insignificant part.

You have to rethink what value is, how you create it, how your organization supports it. You have to rethink which structures work, which don’t, what is local optimization and what is global. You have to rethink the importance explicit, implicit and tacit knowledge have for you. You have to rethink what “knowledge work” is and how you treat your workforce. You have to rethink how management works. How leadership works. How accounting works. How controlling works. How customer satisfaction in a digital environment works. How small things affect the Big Picture. And you have to put all of these pieces of the puzzle together to end up with a sustainable organization.

Key Challenges

SAFe has a number of challenges to overcome that aren’t automatically addressed by the implementation – they are inherent to how traditional organizations tick. I believe that these challenges can be overcome by the right people, given time and patience.

Break the Glass Ceiling

SAFe’s big picture is palatable for people who have zero agile experience, and this picture can be used to provide a satisfactory answer for every potential question one could ask. This gives decision-makers the confidence that this approach will work. Unfortunately, this gives them so much confidence that they will gladly delegate the transformation to members of their organization or consultants who are engaged. This delegation means that “the glass ceiling” is often maintained, i.e. that senior management observes, rather than changes themselves. 

The solution? As a manager, get involved. Be part of the transformation: “be the change that you want to see in the world”.

Mind the Context

To quote H.L. Mencken, “For every complex problem there is an answer that is clear, simple, and wrong”. SAFe has many such answers, and why the answer is wrong isn’t because the answer itself is wrong, but because SAFe doesn’t address your local context. Whether an  answer makes sense, and the action is useful in context or a different approach would be more appropriate – isn’t answered by SAFe. The more confident an organization is that SAFe has the right answers, i.e., the more blindly they trust in SAFe, the less Lean and Agile they will become. 

You require highly educated systems thinkers to solve problems at enterprise level.

Learning Culture

SAFe has a highly complex learning portfolio. Many organizations feel overwhelmed by this and simply skip most of it. Only the managers that lead Release Trains go to Leadership training, SAFe for teams costs too much, and SAFe DevOps is “for when we have extra money”.

This creates a catch-22 situation for SAFe: It’s so complex that you need to invest a lot of time and money to understanding it. And because organizations who want SAFe are usually in search of ways to save time and money, this learning doesn’t happen.

As the proverb goes, “you pay the price for learning one way or another”. Most managers opt for the invisible way of lost productivity, because they don’t understand how massive this cost actually is and because of the way organizations are set up: When developers are struggling with productivity for months, that can be argued easier than getting an extra training and coaching budget.

You need to be serious on learning, not only SAFe, but also Lean Management and Agile Development Practices, to get any sensible result out of any kind of “Agile Transformation”.

Question your setup

When I ask managers which elements from SAFe they need, they take seconds to reply: “Everything”. Asking for specific aspects, like the System or Shared Service Team, the answer is “Of course”. Without looking into all of the details of the framework, these elements, as well as the concept of team-level Product Owners, the functional separation of RTE and Scrum Masters, having multiple Business Owners and many other things create counterproductive dynamics that can reduce an organization’s flexibility, their ability to deliver value and speed of decision making.

These mechanisms address challenges that enterprises may have, but they should be applied with utter caution and avoided if possible. As organizations move further in their agile journey, they will find that these mechanics eventually become impediments to organizational agility and the delivery of value.

The introduction of new concepts should be taken with caution – which it often isn’t. New mechanisms should be implemented only to address a significant, well-understood problem.

Engage middle managers

Managers, traditionally, keep themselves out of operative details lest they be called “micromanagers”. Under the umbrella of “team autonomy”, they disengage even further from the work of the teams. What sounds good is actually SAFe’s biggest problem, because managers don’t learn how the work really works. Even after a prolonged period of time, managers thus often face two key problems: First, they lack the understanding and insight to spot and resolve local optimization. Second, as team autonomy increases and interaction with managers is actively reduced, teams lose trust in management decisions: proximity creates trust!

At a minimum, managers need to start “walking gemba” and experiencing how people work. Even better, they need to get into the trenches and engage deeper and more often with teams, without having their “manager hat” on, so that they can get unfiltered firsthand information of what the new way of working actually is like.

Start thinking agile

Just like there is no pill that turns a couch potato into an athlete, maintaining agility requires constant change and attention. With its undoubtedly huge suggestion catalog and massive training portfolio, SAFe may create an illusion that by following down this road, one becomes agile. In my perspective, by following all the suggestions of SAFe, one does become a SAFe organization – but this organization will not be agile unless people ask tough questions and challenge the assumptions of the framework.

An organization must learn to scrutinize everything it does, regardless of where the idea came from, and rigorously cut down on complexity wherever and whenever possible. This is the only way to avoid accumulating the same kind of “technical debt” in their structure and processes that a piece of un-refactored code would have. Constant, small changes of the structure must be as integral to the work as doing this to the product.

Maybe that topic would be called “Organizational refactoring”, … something to discuss in the future.

 

Finding your place as an SPC

Time to take yet another jab at the SPC. The SPC role is massive, and as I mentioned before - people can't be good at everything the role suggests. That's simply because there are too many different things you might be doing.

DISCLAIMER: Proceed with caution. This model needs refinement.

So, I've created this simple model as a brain dump on what an SPC could spend their time with.
If you're an SPC and/or Agile Coach, you can try checking the boxes and see where that lands you.

How-To-Use

• If you're an organization looking for an SPC, let them make their check marks.
  This gives you an impression of what you're hiring for.
• If you're an SPC as part of a company's SPC community, this gives you a reflection opportunity to see if what you do is what you want to be doing.
• If you meet as an SPC community, you may want to compare your results with your peers - it's a great discussion starter!

Notes

• I would like to say, "There are no rights and no wrongs" - but that wouldn't be entirely true. A few combinations would be pretty insane. If you can't figure out which ones, ... I have bad news.
• Not all combinations are consistent - I hope that's not what you're doing.
• As the dividing line is, "where you spend more than 10% of your time" - there shouldn't be more than 10 checks.
• I would assume that an average SPC shouldn't have more than 5 or 6.
• Being a non-average SPC means you're probably spreading yourself too thin.

Feedback welcome. I would like to improve this so it can be the most useful tool for others.

SPC Competency - what companies can do

In a recent post, I gave my opinion about the condition of the SPC. I have received some pushback, in multiple directions:

1.  I'm being too negative.
2.  The problem isn't limited to SAFe or the SPC.
3.  What's the solution?

Let me address these points quickly before digging in.
First, I made this post because I care. Not to place blame, but to spark a discussion. And I did.
Second, I agree. The growing problem of ersatz agile coaches would still be getting worse even if SAFe didn't exist. But I don't give a hoot about the ever-growing number of pointless certing schemes out there. I would prefer if we could improve the SPC community.
Third, I don't know. But I have ideas based from what I have seen.

So - let's make this article about point three.

Getting out of the dilemma
I base these ideas on personal observations (in italics) made from one client - they know who they are.
This article is a kind of action-item list for things you may want to do in your organization to maximize the likelihood of having "good" SPCs.

The certificate is nothing - what matters is the person who bears it!

Dismiss Ersatz SPCs fast

When you identify Ersatz SPCs in your organization, you should let them go quickly. Preferably, you don't give an external SPC a prolonged contract to begin with - start with monthly contracts that you can simply choose to not prolong.
When you hire SPCs as internal staff, use a probation period to see if they're worth their salt.
The challenge is that you need further mechanisms to determine where prolonging makes sense.

My contracts are often limited to supporting ART launches. Although I believe that this isn't how you build up a sustainable Lean-Agile enterprise, I am currently considering to offer fixed price services like ART ramp-up support with success clause.

Check your metrics

By looking at the wrong metrics, you run a huge risk of ditching the right people and relying on the wrong people. Metrics such as numbers of ARTs launched (fewer is better), amounts of people trained (irrelevant) or teams converted to "Agile" create effort and trouble without value. Success metrics should be business relevant figures, and success should be measured in terms of how your organization creates value.

Transformation metrics like customer satisfaction, time-to-market and product quality are much harder to game and let you know whether your SPC is making show or progress.

Avoid wholesale packages

This one is key - because too often, organizations look to a single large consultancy to take care of the entire staffing question.

When you ask an agency to bring in droves of SPCs to do an Enterprise transformation, you're going to get a few good ones and a lot of bad apples. It's inevitable. Don't hire SPCs by-the-dozen. Create a process where you, as a client, are in control of every single SPC so that you can decide to terminate Ersatz SPCs without getting contractual problems.

I see Business Owners interview every SPC individually, and being from one specific agency can't be a success guarantee to be placed. Steer clear of "bargain bins" here - if Agency A allows you to place a second candidate at a discount, that's probably not to your advantage!

Rely on Expert opinion

Do not rely solely on Business Owner or RTE opinion as to what makes a good SPC, as the art of snake oil selling includes deceiving the Ignorant. You don't want Snake Oil.
When a Business Owner has a bad feeling, they should immediately turn to an SPC for advice.
Create a stream of communication between Business Owners and SPCs who aren't invested in the ART.

I have been invited to observe PIP's and offer feedback to the Business Owners. This approach strengthens well-meaning SPCs and exposes Ersatz SPCs.

Give SPCs a role in strategy

SAFe isn't just about lumping development teams together in ARTs, The key to Enterprise Agility is bringing different parts and layers of the organization together in transparent alignment. Experienced SPCs can help there, if you let them. Especially, don't determine what the SAFe organization should look like and then just delegate it to SPCs. This attracts Ersatz SPCs who will act as willing execution agents for poor strategy.

Include external SPCs in your Transformation team, while avoiding to delegate the Transformation entirely to external SPCs. Offer the SPCs transparency into the Transformation - and figure out ways to let them contribute beyond ART level.

Avoid One Man Shows

It looks tempting to put a single SPC in charge of a single ART launch - which creates two major risks: First, if that single SPC is a washout, you'll discover that after the PIP failed. Second, if that single SPC gets stressed out, you stand empty handed. Try distributing the load.

Involving multiple SPC's with each ART increases transformation quality and decreases risks. It's good to at least have other SPCs check in on a new ART occasionally, to see if the lead SPC requires support. Ideally, don't save on SPC capacity. 1-2 SPC per 50 people isn't too much.

Separate concerns

SAFe is a huge topic. For starters, we have the domains of strategy, training, value streams and technical aptitude.

Consulting isn't coaching isn't counseling. Process change, teaching people new practices and structural reorganization are different pairs of shoes. Managers have other needs than developers than product people. 

Few people can take care of all of that. Most excel in one area, some in two or three. Even if someone could do everything, they'd spread themselves too thin if they would do all of it at once.

Hence, allow people to play out their strengths. Let SPCs determine how they can contribute - and let them do exactly that.

Always involve multiple SPCs to launch an ART. Not everyone needs to be around full-time, as long as you ensure that people do the thing they're good at, not the things that are really not their strength.

Pair and Shadow

Once you have identified some competent SPC's, ensure that they are present at key SAFe events, such as the Value Stream Workshop and the PIP. An hour of observation and a short conversation between them and the other SPC will be very revealing.

I have very much enjoyed the conversations with a senior SPC who critically probed the dysfunctions he observed during my ART launch PIP.

Build an SPC Community

When skilled SPCs talk, discussions get interesting. By having a community of peers, you will quickly see:

1. Who contributes and who doesn't.
2. Whose contribution adds value and who blathers.

The SPC's you want in your organization are those who care to make a difference. Observe those who don't want to join the SPC community as a vehicle to have a bigger impact - they might have something to hide!

I enjoy every session of my client's SPC community, because it's a great way to look at the big picture and avoid local optimization. Personally, what I like most is the ability to draw attention to enterprise-wide issues.

Create a Central SPC Work Backlog

Nobody is Superman. We all have strengths and weaknesses and nobody can do everything. We should focus on the things we're good at. There's a lot of SPC work, starting with awareness sessions, Value Stream Workshops, going over trainings, program backlog workshops, PIP support, Inspect+Adapt events and many more. The SPC community should have a backlog where all known work can be made visible, so that SPCs can pull the items where they're confident to add value.

I have been "One Man Army" Coach before. It's terrible. Being able to access an SPC activity backlog where one can get items covered that one isn't good at and pull items that make the organization successful is a quantum leap.

Identify Organizational Antipatterns

Current Culture has an impact on Agile Transformation. No single SPC sees the big picture, it becomes visible when we put our individual perspectives together. This helps us identify systemic change potential and levers going much beyond the scope of a single ART. Ersatz SPCs might reveal themselves by claiming antipatterns that aren't, or claiming clear antipatterns are fine.

When we had the idea in the SPC community to collect antipatterns, I had a hundred things on my mind. It was fascinating to learn where I was victim of my own bias and where others shared my observations.

Meet. Face to Face.

In large corporations, it's easy to remain anonymous. This creates a hiding place for Ersatz SPCs. When you meet for a day in a setting like Open Space Technology or Liberating Structures Workshops, you can learn about who you're dealing with. Many minds breed new ideas.

The best you can do is create an Open Community Meetup in your company's location. This creates a time and space where you can meet your own peers. It can likewise become a mechanism to learn about one's own organizational bias and be a vehicle for recruiting interested outsiders who could make a valuable contribution.

Fuckup Nights

Talking about where "you dun goofd" isn't easy, but we all do. I do. All the time. Maybe my last article was a goof - I'll let you determine that. Provide a forum where people can talk about their mistakes openly. We can help each other out, and we can learn from others' mistakes as well.

The Agile Academy

I've taken two barrel loads of shots against the Agile Academy - and it might appear as I am totally against this idea. I am not. Indeed, I mentioned before that I believe that a properly set up Agile Academy is an essential instrument in sustaining and nurturing Enterprise Agility. I am against using this approach too early, exclusively or as a false dichotomy.

Use Neutral Trainers

An Agile Academy is very dangerous when it relies on people with local bias as trainers, who in their worst case have built their own curriculum based on their personal understanding and then proliferate this in the organization. Bringing in a mix of reputable external trainers to conduct trainings on Lean/Agile basics irrespective of your local context is more costly, but it provides a balancing instrument in the organization.

The client who is running a quite successful "Agile Academy" has a number of training partners who are not part of their organizational culture. This ensures the trainers get neutral market feedback and do not adapt to cater to your current status quo.

Trainers must be Doers

A very common mistake in Corporate Agile Academies is that you raise fulltime Inhouse Trainers who lose touch with organizational reality. 

My heart jumps when I hear that people who are doing the work in the trenches are giving trainings and feeding back their learnings from the training into their daily work, and vice versa.

Every ART SPC must take a role in training

When the Agile Academy creates a disjoint between trainer and the ART SPCs, that may be efficient from an organizational perspective, but it's terribly inefficient from a learning perspective. The Lead SPC of an ART must be in the training room, ideally as a trainer or at least as co-trainer. This strengthens the bond between them and the people they work with on a day-to-day basis. They can link training content to their daily work - and see from the training questions where further support after the training is required.

Ideally, the Academy relies on SPCs who also work in the trenches and has a standard process where the ART SPC is part of the training process.

My client didn't do this initially, and this created negative feedback swiftly as Agile Academy processes weren't synchronized to ART launch processes.

Choose candidates wisely

SPCs are multiplicators either way. A good SPC spreads a good culture. A bad apple spreads a bad culture. Is it better to err on the side of caution? I don't know. But what do you do if you have an internal SPC with an anti-agile attitude? Do your processes accommodate for that? Maybe they will use their accreditation to wreak havoc elsewhere. Although that may not be your problem - it affects the global SPC community.

Wait before you train inhouse SPCs

Being an SPC is a high responsibility. I believe that training people without agile experience as SPC is setting them up to fail. Especially if you have no Agile history in your organization, you will be challenged to find people who have enough background to succeed as an SPC. Wait before moving the SPC role "in-house". Give people time to collect experience as Scrum Masters or Release Train Enegineers before you move them into an SPC role.

My client went through an Agile Transformation years ago. There are Scrum Masters with vast experience on their back, and they have the battle scars to prove it. Such people make great SPC candidates.

Avoid role poker or favors

Internal SPCs will carry the burden and responsibility of fostering and sustaining Lean-Agile Practice long after the Externals are gone. They need to be the people who care to do this. If you select Internal SPCs by means of favoritism or to appease political demands, that's a signal that you're preserving a status quo where power play beats performance.

I have participated in deep discussions with Business Owners over the implications, pros and cons of nominating SPC candidates for the Agile Academy. As part of my coaching, I also had 1:1 conversations with the candidate to see if this is how they personally felt they could add most benefit to the organization.

Be picky

There should be no guarantee that a candidate nominated as SPC becomes an SPC. Let some time pass between nomination and training. Peer interviews by SPCs and collaboration with SPCs who are outside the line responsibility of the nominating Business Owner are a good way to do this.

The first SPC candidate I mentored for my client was probably at least as capable to meet this responsibility as I am. He shadowed me and asked questions. I coached him for a few months. This was part of his onboarding process before he went for training.

Provide ongoing support

An SPC training is nothing more than basic awareness. It doesn't make an SPC, and it doesn't equip an SPC to bear their responsibility within the organization.

SPC Candidates should ...

1. join the company's SPC Community as early as possible.
2. have a mentor/coach even before their SPC training.
3. be able to rely on their mentor/coach after their SPC training.

I have observed others becoming SPC in a slow process, where seasoned SPCs were always present to support one in growing into the role. Combined with the above items from the community, this keeps weird outcrops under control.

Don't cut ties with external SPCs too quickly

I have mentioned the Dunning-Kruger Effect in the original post: how do you know what you don't know? And how do you know when you're ready to move on alone?

Fading out external support slowly is, in my opinion, imperative. Don't throw out your Externals on the day after PIP launch. Consider a prolonged period before the SPC moves on. I'm talking about months, potentially years before the last External finally moves on.

Why? Otherwise, you reward SPC's who create fire+forget show effects.

Make sure that an external SPC is responsible for a first successful PI with valuable outcomes, and give them the opportunity to make this happen.

I have seen ARTs reduce the involvement of external SPCs to I+A event attendance, PIP coaching, call-on-demand and many other means of slowly breaking dependency without cutting ties.

Plan the future for external SPCs

Some organizations rashly and harshly cut ties with External SPCs after the ramp-up phase. 

Even after the SAFe rollout is over, I strongly suggest to keep some brains close for collecting feedback, new impulses and ideas.

Part of the phase-out process needs to be creating a strategy for sustaining an influx of valuable external knowledge without falling for dependencies. And here, I'm not talking about maintaining external trainers for the Agile Academy - I'm talking about people who stand where the rubber meets the road, that is: in the trenches.

That's it.

I hope this is a more positive outlook on how I envision corporations contributing to a better SPC community in the future.

Why the SPC will destroy SAFe

SAFe is a massively successful Enterprise Agile Framework, and irrespective of how one thinks about SAFe, it's impossible to think away from today's enterprise world. Part of the huge impact SAFe has made was due to its - undoubtedly extremely smart and well calculated - move of quickly training a large number of SPC's and letting them spread SAFe in organizations. 
I believe that the SPC will ultimately become SAFe's downfall - let me explain.

Dwindling Requirements

When I became an SPC in 2016, the requirement was "five years of agile experience at various levels, in various roles, in various organizations." Although at that time, I already saw some SPC's who didn't meet this requirement, I was excited to join a community of very seasoned agilists who were serious of moving beyond team-level agility.

Today, we see no such constraint. The main constraint seems to be who (or whose organization) is willing to invest the training fee - growing hordes of ersatz agilists are competing for an SPC role.

While most early adopter SPCs and SPCTs are massive bundles of competence, today's average SPC  brings only a fraction of the competence of the early adopters.

Organizations hiring such SPC's, unfortunately, lack the discernment to figure out the difference between a washout and true competence. This alone will ultimately undermine trust in SAFe.

Skipped examinations

The SPC exam is undoubtedly hard. Much harder than, for example, the CSM exam and still a tad harder than Scrum.org's PSM-II.  Unfortunately, this doesn't help when it's already fairly common practice to get together in groups with one single experienced person who helps everyone pass their exams - even to the point where some consultants earn some extra bucks by offering taking exams for others. As such, this form of quality assurance isn't worth anything, either.

Ersatz Consulting

The worst development I am currently witnessing are the SPC "premium agile coaches" who ask for four-digit daily rates, even though they lack every single dimension required to succeed in the role. Not only do they have extremely shallow understanding of agility - they have no experience of the makes or breaks of an agile organization and rely solely on the standard slide decks to get by.

One SPC literally told me, "It's too much work, and reinventing the wheel, to figure out what the customer needs. I just copy+paste SAFe by the Book." - talk about even basic understanding. 

This level of expertise nets us ART's with 2 teams, Large Solutions of 40 People and Value Streams that start with a fully budgeted project or even a "Testing ART", and it's no wonder this eventually flies in people's face.

I predict that as more organizations get in touch with such Ersatz SPC's, fewer and fewer will take the gambit, until eventually the entire thing collapses. Give it a few years - if the current trend continues, it will come to pass.

Ersatz Agility

Agility relies on empiricism, a lot of it is situational awareness and context sensitivity. The idea that "SAFe by the book is Industry Best Practice" is contrary to the very idea of agility, and what would you expect as a result when your consultant dumps a number of structures, patterns and practices on your organization? Agility isn't one of the things you should expect.

Ersatz Coaches

The SPC community is also facing an increased membership of people who bear the title "SAFe Coach (SPC)" and lack any form of coaching background.
Also note that an SPC is a SAFe Program CONSULTANT, not a coach. Consultancy has its benefits - not everyone needs to be a coach! And the SPC training program doesn't even claim to make you one, either.

Many "SAFe Coaches" confuse "Coaching" with telling other people what to do or selling them solutions. In a worst case scenario, I have seen an SPC "Coach" complain that they lacked a mandate to impose their own (very poor) understanding of SAFe  on the organization without resistance.

Such Ersatz Coaches are running rampant, to use the words of a friend of mine, "causing a nuclear fallout in their wake" - and their numbers are rising, whereas the number of truly competent agilists who work as SAFe Program Consultants isn't really increasing.

As such, the odds of SAFe-oriented coaching being worth its cost diminish rapidly.

Ersatz Trainers

SAFe allows people to get a sanctioned license to train Scrum Masters, Product Owners, teams and even managers without any relevant trainer qualification .

SAFe Trainings contain a lot of learning objectives and even provide standardized trainings. But these trainings aren't worth even the time of attending if the trainer doesn't understand the learning objectives themselves and has no personal experience to contribute.

I once got a message from a disillusioned member of a corporate LACe who complained that she had just sat through a mind-numbing training with an SPC trainer who responded to a remark, "But that's Waterfall practice!" (after having explained that allegedly SAFe's Product Management requires Big Upfront Planning) with the serious question, "What's wrong with Waterfall?" and who for the heck of it couldn't figure out why Command and Control structures don't help in knowledge work.

 What learnings would you expect from such a training? Significant agility probably won't be one.
The more organizations get exposed to such training, the less likely they will see SAFe delivering any benefits.


But wait, those are just the SPC's on the market - with an ever-growing number of snake oil sellers who are just out for a quick buck. So let's talk about the alternative.

The Inhouse-SPC

Large organizations going the SAFe route quickly shift to raising up inhouse SPC's from the ranks of their own Project Managers and Line Managers. Many of them get sent to an SPC training without ever having experienced agility first-hand, and even if they have, it was only a kind of Scream. They have been in a middle manager role for a long time, oftentimes in the same corporation since they graduated. And now they take responsibility for helping their organization "become Agile". I will grant that they are motivated and keen to make a difference - they just lack experience to compare situations and the depth to predict future outcomes.
Consequently, they often implement things which look like a good idea but will have adverse effects months or even years in the future: How can they know?

Training is not Practice

The Inhouse SPC raised by an Inhouse "Agile Academy" under the tutelage of Inhouse trainers who are also very limited in Agile breadth and depth, although a great cost-saving factor, lack the background to avoid even elementary pitfalls. Even if the organization has the foresight of combining the training with on-the-job experience, we're still talking about people who basically "do organizational surgery after having read a book on the subject".

Agile Incest

The Inhouse SPC and SPCT lead to a phenomenon I would call "Agile Incest" where people from the same company define what is "Agile" based on what the company itself is doing - the benchmark becomes the current reality instead of the true potential.

Proliferating Bad Practice

Combining the two items, that is, extremely limited agile experience as well as no exposure to alternate viewpoints, will make the Inhouse SPC believe that they have reached the culmination of Agile Excellence - which is in reality Dunning-Kruger's Peak of Ignorance.
They then proceed to spread their "excellent" ideas by moving on to better paid roles in other organizations or giving talks on conferences, where the name of their organization has a more impressive sound than the actual achievement.

Just to give one example of where this leads - I was interviewed by one such SPC who had become "Head of Agile Practice" in a corporation, who called on my incompetence for making the claim that a Product Owner actually gets to decide what gets built! They patiently took their time to explain to me in detail the mandatory half-year process across five layers of an "Agile Enterprise" where others will decide on what gets built by whom and when - before the Product Owner ever gets to see a requirement or talk to a stakeholder.

tl;dr:

A massive influx and growing army of SPC's who have no background in agility are spreading dysfunctional practices. Organizations care more for SPC price and quantity than results and quality. Combined, this will eventually lead to the downfall and marginalization of SAFe.

I will leave it up to the reader to determine whether the currently visible acceleration of this process is for better or for worse.