SAFe: Setting up the Value Stream level

After various discussions about the alleged massive management overhead introduced by SAFe 4.0, let me clarify what's really brought in with the additional level called "Value Stream". The Value Stream Level combines multiple Agile Release Trains. As a matter of fact, you don't even want to go there unless you have significantly more than a hundred developers working on the same product. This level is only necessary in massively scaled product development, something you want to avoid in the first place. 
But when you can't - you need to find a way to deal with the problems introduced by an organization sized equally to multiple enterprises collaborating in (near) real time. And SAFe has a proposal how to get you started on that one, too.

Defining the value stream

What's a value stream? Simply put, it's all stuff happening "from customer (demand) to customer (satisfaction)". In some enterprises, that's obvious - while in others, it may be hard to grasp.

An example value stream
Let us take an example, "What is the value stream of a smartphone?" - That depends. When you are talking about a telco carrier, you as a customer sign a contract, get a SIM card and a device, register it - and start calling. You then get monthly invoices and that's it. From customer side.

But what is going on in the background:
To get a contract, you select a package typically considering of tariffs, prices, products, options and bundles that will be assigned to your customer account. All of this stuff handled in so-called "business support systems" (BSS). As customer, you don't care much how they do that, but BSS platforms are often provided by specialized organizations due to their complexity. It might even be fair to call this an independent product.  It may be adequate to label BSS platforms a "product" in it's own right, required not by you, the customer - but by the Telco carrier in order to serve their customers. Depending on the carrier, in this line alone you might find 500+ people working.

Next, of course, you want to make a call. But for that, your device must be activated in the telco network. That requires some interaction between the BSS and the network stations. For simplicity sake, let's just say that the physical network is yet another sub-product required to provide service for you, but ordered by the carrier.
There's also a product line called "Operations Support Systems" (OSS) taking care of that. There's major corporations doing only the Network base stations stuff, and there's major corporations doing only OSS stuff. The things going on here are highly technical and interest nobody except operators, but otherwise you couldn't make a simple phone call.

This means our example value stream actually consists of three product lines, only two of which are exposed to you as a customer. In each of these product lines, some magic happens so that you get to make your call.

So, here's what the value stream would look like:

A value stream perspective for a mobile network operator

As noted already, BSS, OSS and Network may be completely independently organized "technical value streams", for example when they are outsourced. SAFe would not advocate to start by insourcing all activities, especially where it does not make sense from a revenue perspective.

Continuing with our example, let's just assume we are dealing with a so-called "Virtual Network Operator" (MVNO) who does not have their own network. In this case, the "Network" and even the OSS would be a purchased service, provided as closed black box. Our own development would be using the output of these value streams, but would not be directly interacting with them in the process, so our SAFe organization would embed, but not directly touch them.

But we still have a problem: There's the BSS teams providing value to end customers by setting up new product lines and also those who provide value to our own business with stuff like accounting, tax records, audit reporting and yada (plus our black box technical value streams providing OSS and Network services for end customer value) - but they're too many to organize in a single Agile Release Train (ART). Now what?

Splitting up the value stream into multiple ARTs

An Agile Release Train can accomodate anywhere from 50-150 developers. Once we get beyond that, stuff like the Dunbar number and regular organizational complexity get into our way. So we need to keep the ART at a sensible size, while still being able to deliver useful products to our customers.

Here are some splitting strategies. Please note that while the terms "Bad", "Better", "Best" are definitely judgmental, there may still be pressing reasons to follow a specific approach.
A "bad" choice is still better than paralysis.

Bad: Component split

Probably the most obvious form of splitting is a technical component split, allowing developers to focus on a specific subset of technical systems. While that is possible, it's a great way of maximizing dependencies and coordination overhead while minimizing productivity and customer value. We don't want to go there.

Better: Feature category split

In our example, we might consider splitting the value stream around categories such as tariffs, campaigns and infrastructure. These kind of feature areas would be a good starting point to form a feature team organization that can deliver end-to-end customer value. Of course, there will still be dependencies - but far less than a component setup.

Best: Customer segment split

Probably the most common form of splitting may be "private customers", "business customers", "VIP" and "internal customers", having feature teams serve each customer segment independently. With this approach, strategic management can easily decive to boost/reduce the growth of a customer segment based on how many people would be working in the respective segment. Of course, there's also interaction between the segments, but with a robust product, these should never be game breakers.

Setting up multiple ARTs

So, after identifying how we want to split up our value stream, keeping in mind that each split should be between 50 and 150 developers in size, we'll end up with multile independent Agile Release Trains, together forming a Value Stream.

After reaching clarity which developer is assigned to which ART (just for clarity sake: every developer works on one ART, every agile team is part of one ART) there are multiple ART's to launch and coordinate.

Here is the proposed SAFe structure for setting up multiple ART within a single value stream:

The Value Stream Level - a team of ART's

This one should cerate a deja vu, as it looks exactly the same way an Agile Release Train is set up - and this similarity is intentional.

In another article, we will describe in more detail how the roles and responsibilities change in comparison to a single ART when this form of split occurs.

Summary

Coordination at Value Stream Level becomes an issue when more than 150 developers collaborate on the same product - and even then, the complexity of what you do depends highly on how your organization is set up. On Value Stream Level, you may have multiple ART's sliced in different setups, you may have black boxes of consumed services etc. 

Going into this level of complexity is only necessary for the largest product groups. SAFe provides a way for them to get started in a structured way even there are too many people to coordinate within a single ART.

Do not set up the added complexity Value Stream level coordination unless inevitable.

Disclaimer: Opinions expressed in this article are the author's own and do not necessarily coincide with those of Scaled Agile Inc.

SAFe: The structure of an Agile Release Train

I have heard many different views of what an Agile Release Train (ART) actually is, ranging from a predetermined release schedule all the way down to nothing other than a renamed line organization. None of these are appropriate. Let us clarify it's basic intention. As Dean Leffingwell puts it, an ART is no more or less than a "team of teams". But what does that look like?

One Team Scrum

Basically everyone is familiar with the constellation of a Scrum team, but for brevity's sake, let me include a small summary: Every Scrum team has a Product Owner, a Scrum Master - and the developers. This same constellation is more or less applicable for other agile teams - even if they don't actually use Scrum.

A Scrum tean

Multi Team Scrum

But since a Scrum team is limited to 3-9 developers, how does that look like when your organization is, say, 50, or 80, or 150 developers? Do you put the PO outside the team? Yes and no. The Scrum Master? Maybe, maybe not. How do developers interact?
In fact, Scrum does not answer any of these questions, as the scope of Scrum is a single team. Consequently, larger organizations adopting agility struggle to find their answers. Their Scrum organization sooner lor later looks like this:

A Multi-Team Scrum adoption

This model actually works, but it leaves some questions un-answered, such as: "How do we make sure we're all working on the most valuable stuff?" - "How do we make sure we're not impeding each other?", or, for business: "Whom do I talk to with my request?" - "Who could take this feature?" - "What's Priority 1?" - "Is there a way to get this out of the door earlier?" - "When will the next major release be ready?"

The need for coordination

While this may still be resolved for 3-4 teams, this scenario might become a nightmare for business when there are 10 or more teams: Transparency, the key to any decent agile development, is lost in the mud. The more focus development teams have, the more likely they will not work on the highest priority.

The first obvious level of coordination is: The Product Owners need to be aware of what other PO's are working on and what the overall Backlog looks like and where their own priorities are within the bigger system.

Typically, in large organizations, impediments are endemic to the overall organization. As such, even independent Scrum teams will all be struggling with the same or similar problems caused by the bigger system. Likewise, each team itself will be powerless to change the entire system.

As such, the second obvious level of coordination is: The Scrum Masters should be aware of what's going on in the other teams around them, and how their team affects other teams.

Another problem arising in this scenario is that teams may suggest or implement local optimizations which may be fine for their own team, but detrimental for the other teams! For example, think of one team deciding to switch to an exotic programming language like Whitespace, because they're all Whitespace geeks: How can other teams still work on that code?

As such, the third level of coordination is: The Developers should be aware of what's going on in the other teams around them, and how their team affects other teams and the product.

The SAFe approach

What SAFe® does here, is basically nothing more and nothing less than consider a "Scrum team" like a developer in a larger organization and create the same structure on a higher level:

An ART - a team of agile teams

Looks an awful lot like a Scrum team - and that's intentional.

New Roles

Before we get into "Whoa, three new roles - more overhead!", let us clarify a few things: First, huge organizations do require more overhead. Don't go huge unless inevitable. Second, while SAFe® suggests these roles, it does not mandate them to be full time roles. It's entirely possible that these are merely additional responsibilities of existing people. However, experience indicates that in huge organizations - these things tend to become full time jobs.

The Product Manager (PM)
The PM relieves each invidivual PO of aligning the overall big picture with the different stakeholders.
The big differences between a PM and a PO is basically that while the PO is working with teams and individual customers, the PM is working with PO's and the strategic organization. Their main responsibility is making sure that there is only one overall "Product Backlog" from which all the teams pull work - so that at any given time, there is only one Priority 1 in the entire organization.

The Release Train Engineer (RTE)

You could say that the RTE is a "super Scrum Master", but that's not quite the point. While their responsibility is definitely similar, they don't work as much with a team as they work with the organization and management: For the teams, we already have Scrum Masters. 

The RTE, on the other hand, paves the way to corporate agility. The main concern of the RTE will be the legacy structure around the teams, to create a positive learning and innovation environment to nurture the agile teams.

The System Architect (SA)

That's the only really new thing on the ART is the System Architect. To clear up the common misconception about agile architecture right from the start, their responsibility is not to draw funny diagrams of cloud castles and force the teams to implement them. Much rather, their role is to guide and coach architecture, so that we don't end up with uncontrollable wild growth. Likewise, when individual team members have questions about the architecture, this SA would be the first person to come to. 

Changes to existing roles

The Product Owner (PO)

A Product Owner may be in charge of more than one team. Practice indicates that 1-4 teams tend to work out, otherwise the risk of losing focus increases. 

At scale PO's tend to become specialized in areas of the product (such as: Product Catalog or Customer Services) and need to synchronize the overall big picture with each other. Most of all, they need to synchronize with the PM, who feeds back into corporate strategy.

The Scrum Master (SM)

A Scrum Master may also be working with more than one team. Practice indicates that 2 is already the limit.

Facing the team, the main difference for the SM is that they need to point the team to interact with people from different teams, rather than being a bubble for themselves. 

Facing the organization, the SM has to have a much deeper understanding of "Spheres of control", and communicate the impact of outbound impediments. They may need to hand over large blockers to the RTE, and may likewise receive input from the RTE when their team needs to budge in order to move a larger block out of the way.

Summary

I hope that this article explains how SAFe®'s structure of the ART is not "relabelling the same old thing", but simply putting Scrum on a bigger level.
To repeat again, "don't go into scaling unless inevitable". But when you need to, the ART model minimizes the deviation from good Scrum practices.

Be careful of so-called "agile coaches"!

An agile coach is supposed to help agility "stick" within an organization. But that is not always the case. Unfortunately, the label "agile coach" is not a protected trademark. Anyone can wear that title. As such, there is a huge risk that the so-called "coach" will do more harm than good. Caveat emptor!
Here are a few stories of what "agile coaching" I have experienced so that you can actually avoid it. As a disclaimer: I do not consider all agile coaches to be quacks. There are a few whom I highly respect. But there's a lot of quackery giving them a bad name - and not many talk about it.

Purposefully unhelpful 

Probably the most idiotic phrase in the arsenal of an "agile coach" is "You need to find this out by yourself". Of course, that is supposed to inspire self-learning. But honestly. Not everyone wants to learn everything by themselves. Here's my story:

I just came into a new enterprise as a consultant. I asked the team coach "What's the wifi password?" - "You need to find that out by yourself"

This guy was serious that I should rather learn the WiFi password by myself than have someone "tell" me. Dude. I can paint a picture of a stick-man, label it "agile coach" and it'll be more useful than such a coach. Why do people even hire coaches who can't even discriminate when self-learning makes sense?

One trick pony

They say that for a coach, moderation, conflict management, coaching and mediation are key skills. This has the unfortunate side effect that we see "agile coaches" popping up who are domain experts in these exact subjects - and nothing else! Meaning: They are sociology or psychology majors who have never written a single line of code and are now trying to teach developers how to work better. Here is my story:

I was working with a team that faced numerous difficulties. One of these was the lack of a coach. So, they hired one who was really good at talking and creating a positive mood: Actually, too good. Unfortunately, this person had only ever attended a 2-day Certified Scrum Master course and NEVER worked with a software development team.
They had zero knowledge of things like technical debt, Continuous Integration, software testing or other engineering practices - not even PO stuff like backlog management, value prioritization or right-sizing the work!

The team was going in full circles, continuously struggling to figure out stuff "everyone knows" and caught management attention eventually because of high defect rates and unusually low throughput. It was blamed on the developers. The team got disbanded and forcefully rearranged. The "coach" never realized anything was wrong - because hey, the team was always happy and learning!

Feigned expertise

How can you coach something you're actually clueless about? It seems that for some "agile coaches", agile experience is truly optional. They think that having a couple certifications qualifies you and give themselves a label of expertise they do not actually possess. Here is my story:

I am occasionally meeting with an "agile enterprise coach" (CSP) to discuss about the various problems they face. Based on their CV, they've got a decade of "agile experience". At first I was befuddled when they started asking me trivial questions about stuff like backlog prioritization or why people limit WIP. I realized that this person had never really worked in an agile way: They had no idea what the real purpose of Continuous Integration was, they had never even attended, much less moderated a Retrospective - and they haven't actually seen what a workable Product Backlog looks like!

Oddly enough, this person is seriously working in enterprise agile transformations, introducing Scrum to teams, even coaching/educating internal Scrum Masters and managers. Looking behind the scenes revealed that things could have been done within weeks that their clients are still struggling with after years.
Seems like the old conmen statement "There's a sucker born every minute" still holds true.

Hiding incompetence

A coach can always conveniently hide between "stimulating self-learning". I'd call it more fair to say "Some things I know. These I will help you with. Other things, we'll learn together". Especially in the latter category, I personally call it un-ethical to climb on a pedestal and profess to guide others' learning journey. But here's my story. I heard it over a cup of coffee with an upper manager:

A large product group tried to adopt Scrum for the development of an important product a good decade ago. Long story short, 500-people Scrum is not the same as one team. So, they had, "challenges". And since they couldn't figure out any way of getting past a specific one, they spent major bucks and flew in a highly reputable "Scrum coach" to make progress. For two hours the coach answered every question with a counter-question or reframed it. But the client felt there was no substance. Finally, the manager's collar popped and he bursted out: "Now tell me, ONLY with a Yes or No: Do you know how to solve this problem?" Pushed into the corner, the answer was "No". At which point, the manager exploded: "Then this meeting was 100% waste." Not only did they never try to approximate a solution or give helpful pointers, they simply left the client stuck with an unresolved problem. Even years after, to that manager - and their peers - "Scrum coaching" is associated with that specific name and has a very sour aftertaste. 

It should be fairly easy to state what your competencies are and what aren't. It's fair game to state that you don't know everything. But when others rely on your help, it's unfair to leave them hanging.
Note how "problem solving" is not mentioned by coaches as a coaching skill.


Getting away from the stuff that I would actually call fraudulent, where the client's ignorance of one's own incompetence is used to make a quick buck, let us now turn to the softer area of mindset.

Unable to see the big picture

Good coaches should be unbiased, because bias prevents us from seeing the big picture. Reflection and self-awareness help us to overcome bias to serve others better. Or: So is the theory. Some of the most biased people I have met in my life bear the title of "agile coach". Their bias is so incredible that they try to convince me of silver-bullet solutions that simply won't work in context. Here's my story:

I was once working with a company that had a HUGE quality issue: Their legacy product was a technical garbage heap: Developers literally had nightmares about the code base. Some threatened to quit were they forced to dig into that mess any deeper. Customers were rioting, Customer support was desparate. Customer problems (such as: lost orders, missing payments, wrong products shipped) never got fixed. I like to name things the way they are. When a customer spends money for A and then gets B, that's a DEFECT. A failure that the customer does not want. Period. So, I was fighting tooth and nails with management to limit WIP and value-prioritize defects so that we could actually drive down defect rates. The results were splendid: Customer Service actually started giving names to developers that were no longer synonymous with "monkey". Anyhow. Comes along this veteran "agile coach" who suggested "You shouldn't call them defects. Wherever I go, the first thing I do is to remove that label. This will cause an important mindset change!"

I spent over an hour mostly listening to why it's important for the team that the PO treats all the work equally. They didn't even account for the fact that "defect", in that case, was not merely a label but a metric to draw attention to the horrible technical mess, so that we could have sufficient power to weigh the need for a long-term technology change against the need for short-term business evolution (i.e. new features).
I did get their point, but I saw they didn't get mine. And they didn't care to.

Misunderstanding assumptions

As I stated elsewhere, people can and do make assumptions all the time. We navigate in what we perceive as "reality" by making and deriving assumptions. And some of them are inconsistent with each other or with evidence presented. As such, we should always be ready to anabdon our assumptions in favour of better ones. "Five Why" analysis can help us explore our assumptions. But some people just don't get it. Here's my story:

A team gathered for their retro. Within a few minutes, they simply decided "We need to write more unit tests". So, the team dug out their Five-Why tool: "Why?" - "Beacuse we have too many defects" - "Why?" - "Because we don't have enough unit tests." - "Why?" - "Because we didn't think they were that important." - "Why?" - "Because we didn't know." - "Why?" ... - "Dude, shut up your food hole!"

This team had already learned their lesson, but the coach made it look like there was more to it - down to the point where they really just got nauseating. "Five Why" is one of many ways to uncover false or misleading assumptions, but there's a point where it's fairly safe to simply let it go. A coach should not dig out all assumptions. They should be aware which assumptions are reasonable and which are unreasonable.

Wrong focus

Agile coaches might focus on the wrong things when they miss the big picture. Especially when their understanding is limited, they will quickly optimize in the wrong direction. Here's my story:

I was working with an organization where a certain middle manager always tried to impose their specific ideas (such as: separated test team, using HPQC rather than spock etc.) on teams. As i was doing my best to rally management support for the teams' ideas, I got into the line of fire from that manager. Basically, he was undermining the techical quality measures built by the teams with an email to ALL the PO's and coaches. So, I replied to ALL, because I wanted ALL to take a stand. What happened? This "agile coach" suggested introducing business email etiquette rules, because they felt bothered by a Reply-All on a matter they considered personal between me and the manager. So, we had etiquette rules enforced. Great! Problem solved! ... About half a year after I left, the manager won - now they have a Test Department reporting test results in HP-ALM. But hey, at least they have formal email etiquette rules!

It's actually quite funny how often agile coaches propose a solution without engaging in direct dialog with the concerned parties - and without trying to understand the problem they are solving. There was no mediation sesssion held to uncover why the conflict actually existed. The real problem never got solved. Neither any of the many coaches nor any PO bothered to understand the fundamental problem.

Conclusion

Am I perfect and pointing fingers elsewhere? No. I undoubtedly have some communication issues and maybe many of the situations I encountered would have turned out different if I had known how to better communicate. But I learn.
However, I would also expect "agile coaches" to bring honour to their profession.

When the solution isn't known, approximate. But be straight about it. Never claim to help others with things you don't understand: That's fraud.

Especially from a coach, I would expect the following: Be fast to learn, but slow to judge. Engage in dialog. Never decide before verifying your own assumptions. Be ready to discard your preformed assumptions. Don't draw biased conclusions. Let people know when you don't know.

It's called PDCA for a reason: Never act before checking. And, from a coach, I'd expect that to be a double check.

Don't play games: a coach is not a mad scientist!


Final disclaimer: I do not consider all agile coaches to be quacks. There are a few whom I highly respect.

Agile learning for starters

I have previously discussed the "cost of learning" and it's impact on the learning strategy. After establishing that we should always keep this cost of learning below the Point of No Return, let us consider the differences in learning. The dogmatic statement "A coach should not prescribe a solution, but foster self-learning", presumes that self-learning is universally the best approach. But is it?

Let us consider which companies/teams typically call for help, based on this simple model:

Do you know why you don't know what you don't know?

There's a hidden relationship to the Cynefin Framework hidden: Software development is a socio-technological problem, and the issues of communication, understanding and skill are just a few factors affecting the team's performance. We work in the complex domain, where any model has an inherent error.
Usually, when a company requests external help, they tend to be basically aware that they don't really know what their problem is and that they assume someone else can help them make progress. In terms of our model, uncertainty is high and people admit that their specific knowledge and understanding of the problem domain is shallow. That's good. It's a basis for learning.

Initiaing problem solving

We have a wicked problem here: How do we know we're doing the right thing - and how do we know we're getting better at it?
A consultant has no choice other than first gaining clarity whether the problem is comparable to a problem where a solution is known, so would first try to drive down uncertainty - by asking questions and experimenting with the process.

If the problem is in a domain where deep expertise is available, the problem solving process is reduced to tapping into available expertise.

If the attempt to reduce the problem to a domain where a solution is known fails, this indicates that we're working in the domain of the Unknown.
This one splits down again:Either, we know that all known solutions fail, in which case we need to innovate - or all attempts to reduce uncertainty failed, which indicates our problem is ill-defined and we need to clarify the problem until we have a workable problem.

Innovative problem solving

If there is need to innovate, we're pretty much clear that we'll be using empirical data, feedback loops, inspect+adapt and experimentation to iteratively anneal the situation. The best thing a consultant can do in this situation is to provide support based on their own experience to discern which experiments make sense and what the available data implies.

There are tons of techniques for innovative problem solving, starting with Kaizen Events, Design Thinking, TRIZ ... potentially even a full blown Design For Six Sigma (not advised). Determining the suitable problem solving technique may also at the discretion of the consultant.

Introducing known solutions

When expertise is available, the consultant must factor in the impact and urgency of getting the problem solved.
Impact is high when there is a risk of crossing the Point of No Return, i.e. destroying the company / team, or have individuals lose life, health or their job.
Urgency is high when you only get one shot.

• If both impact and urgency are high, a dogmatic solution will save time at the expense that the inherent understanding remains low. Autonomous learning is purposefully replaced with prescriptive approach for a greater good.
• If impact is high, yet urgency is low, the consultant may choose to underline the solution process with moments of learning to deepen understanding. This will reduce long-term dependency and the risk for misunderstood assumptions around the solution.
• If the impact is low, yet there is a sense of urgency, the consultant might actually provoke "learning from failure" to create deep understanding for the next time.
• If both impact and urgency are low, the consultant should not invest further time. Providing a pointer on how the team could learn solving the problem can be sufficient. If they learn - good. Otherwise - no harm done.

Summary

In this article, I described only the consultant's approach when the team is lacking knowledge and ability that is available to the consultant. A different approach is required the team's knowledge already exceeds that of the consultant.

A good consultant weighs the costs of learning against the benefits of learning and chooses the optimal approach, carefully considering the tradeoff between short-term results and long-term results.

Innovative problem solving should generally not be used for known solutions, since that approach is inherently inefficient. Although it facilitates learning, it also maximizes the cost of learning.

Peoples who dogmatically insist on facilitating innovative problem to maximize learning solving might force the team to reinvent the wheel when a firetruck is sorely needed. That's not helpful. It's snake oil.
There are times for learning and times for just doing. Know the difference.

Coach, Trainer or Consultant - a false dichotomy

There are a lot of opinions going around on the Internet concerning "coaching vs. consulting". Especially coaches who like to discern their position will pose this question and suggest that consulting is somehow inferior to coaching. Let's leave the emotional aspect out of this and reduce this to assumptions. In this article, I will include "training" as well, because of the significant overlap. 

The model

For all three services (coaching, consulting, training), there's two sides involved: Service provider and service taker (client). Both make assumptions about themselves and about the corresponding other party. For simplification purposes, we will not list all assumptions, but focus on the essentials that are related to learning.

Underlying assumptions for each role

Interpretation of the model

The first thing we should be clear about is that these are all just assumptions.
Since they are assumptions, it's good to clarify that both client and service provider have the same understanding of these assumptions beforehand, since they define expectations.
These assumptions are not axioms, since each variable can be verified objectively by asking questions and observation. Neither client nor service provider should turn any of these assumptions into dogma and insist they be true regardless of reality. You must accept that any of them may turn out invalid at any time.

Provider responsibility

For each of the three roles, the service provider is expected to have a clearer understanding of the big picture than the client. As such, regardless of whether you are coach, trainer or consultant - you need to be actively on the lookout whether the above assumptions are valid. One skill you need to bring to the table is the ability to realize when they are invalid, because it breaks the model of your role. When they are invalid, you must take steps beyond dogmatic insistence on the definition of your role in order to move into the direction of success.

Client responsibility

The main reason for getting help is that you don't really know what you may need to know. Your initial assumptions may be invalid because of what you did not know. Given better information, you need to adjust your course of action accordingly.

Application

Roles are really just transient. 

It's probably easiest for the trainer who provides a specific training service to stick to the agenda and simply leave. Worst case, the training did not help and the very limited few days of training are wasted. However, even trainers often add coaching techniques and modules to their trainings where they actively generate learning with their clients. In rare cases, that may turn into consulting sessions. When a trainer leaves, the client should have an appetite to try out the training knowledge and learn more.

The line is significantly more blurry for coaches and consultants.

The best thing a consultant can do is enable the client to solve the specific problem and related problems individually by producing learning within the organization. This may include domain-specific trainings in skills the consultant provides and coaching key players in doing the right thing. When a consultant walks out, the client should be able to say "From here, we can move forward by ourselves." - which is the best thing a coach would also hope to achieve.

For a coach, the main difference to a consultant is that there is no specifically defined problem initially and that the coach is not expected to come up with a solution. However, a good coach should understand that there are situations where simply giving a directed pointer to existing solution in order to instill an appetite for learning and experimentation is a good way forward. That's a training situation. Also, sometimes, the coach needs to take carefully considered shortcuts in the learning process to prevent irrecoverable damage: That's consulting. Depending on where on the learning curve the team is, that can be quite a big part of the job.

Summary

Assume that coaching and consulting are two distinct roles and that you are either-or is a false dichotomy. In the same breath, it's an even worse misinterpretation to consider one of them"superior" to the other, because both simply rely on different assumptions. A good consultant will use significant coaching techniques in context, and a good coach will use significant consultative techniques in context as well. "Context" depends on observation and interpretation and is usually very mixed. Be ready to accept this mix. Your actions then also need to reflect this mix.

Being dogmatic on one specific role and insisting on the above assumptions as axioms is done only by people who are unable or unwilling to consider the systemic implications of their own actions. That's snake oil. Caveat emptor.

The Cost of Learning

Time and again, I read stuff like: "The role of the coach is to guide a client in solving their problems, rather than providing a solution". Well - Reducing complexity is a talent, and this statement is a strong simplification. Here's why I personally think this isn't always the best choice.

Cost of Change

One basic premise of agility is "Responding to change over following a plan".This value is made real by constantly reducing the cost of change, to the point where you'll never need to follow an invalid plan simply because it costs less to continue doing the wrong thing. A low CoC is a premise for "being agile".

Correlation between agility and Cost of Change

Let's look closer: Change does have a cost associated, and you can't simply declare that cost to be Zero, in disregard of every evidence to the contrary. You must understand what the cost of change for a given change at a given time actually is.

This is where the coach/consultant comes into play. Both have the responsibility of inducing change. The coach would work on getting the responsible people, for example the teams, to embark the change process by learning by themselves. They need to be cautious, as especially in the initial stages of agility, the cost of change may be extremely high.

Cost of Failure

There's a problem in the learning process: Learning, obviously, means that you haven't done it yet. And that can pose a problem: You might fail. Well, failure is not inherently bad. We might argue that failure is an essential part of the learning process. That may be true, but you need to be aware of the failure costs.

Expected Cost of Failure

The danger that a person/team/organization is exposed to is a correlation of likelihood and incurred damage. For example, it's low danger to "learn" that putting salt into a cup of coffee is bad and therefore, you should use different containers for salt and sugar next time.
It's a completely different thing to "learn" that it's a bad idea to first pull the pin from a hand grenade, then put the grenade into your pocket: There won't be a next time.

In both cases, we assume that failure may occur. In the first case, we will assume that we can safely let people find out what happens, because the cost of failure is low. In the second case, however, it would be highly immoral to know the cost of failure and still let people figure out what happens.

Impact on the approach

We should always consider the cost of failure for any potential course of action. Low-risk topics that pose little danger to organizational health are not typical scenarios for requiring external support. Hence you wouldn't hire a consultant for that. People are more likely to ask for help the closer they feel to being to the Point of No Return.

Self-learning is a better course of action only when two conditions are met: 1) We will not cross the point of No Return and 2) It's a positive long-term business case.
Even though, I do admit that 1) automatically invalidates 2), the latter might still be easier to figure.
If those conditions are not met, a prescriptive course of action is more appropriate.

A feasible learning model

Depending on the consequences, we a different strategy is required:

When the cost of failure is low and people are likely to come up with a good solution, there is no need for outside involvement. Where the consequences are bearable while time is precious, guided learning can speed up the process and we can avoid reinventing the wheel. 

When there's a high risk of incurring an irrevocable, negative outcome by not doing things in a specific way, then "Do this, think about it later" is an appropriate course of action.

The highlighted boxes in the model are the most economic situational approach - the green, blue and red horizontal areas with lighter color should be considered depending on the predicted outcome.

Summary

There is no one answer to how learning should take place.
While it's very convenient to simply lean back and "encourage self-learning", that's not always appropriate.
Just like a parent would not encourage their two-year old kid to "discover the miracles of 220V AC", a coach might need to become quite prescriptive.

The directive is basic human ethics: "minimize overall harm". We can both do harm by neglect (damage to team's credibility, business etc.) and intervention (damage to understanding and desire to explore). There's a tradeoff, so choose wisely.

Which type of agile leader are you?

Agility relies on self-organization. Leadership is considered situational in most agile approaches. Most agilists agree that the role of an agile leader is to bring the team forward, but remain vague what actually characterizes a leader. This leadership characteristic model is based on the Stacey model and is intended to create an understanding of what kind of leadership to look for in which situation. It also explains why having a single person designated as leader is suboptimal.

Where is your team - and where are you going?

Let us explain the model basis briefly.
"Understanding" is how well the team understands their goal and the way to reach it. "Ability" is how experienced the team is in achieving this type of goal. A leader serves the team to reach this goal.

The Protector

When the team is playing on home ground, they mainly need to keep focus. The protector wards off distractions and maintains the discipline. Protectors are not concerned with the "how" and "what".

The Optimizer

When the team has good understanding and ability concerning the challenge, they may just want to do the same thing a little better or reach the goal slightly easier. Optimizers look for the small things with high attention to detail. They experiment with different ways of working, keeping their overall goal in mind.

The Trailblazer

Let us resort to a Wild West metaphor. Trailblazers were masters in scouting and survival. They could rely on their skills, but never on a specific plan. They constantly struggled with unexpected challenges, so that others could reach their goal easier and safer.

The Navigator

Imagine the Seven Seas during the time of colonization. Sailing was never a safe endeavour, not even in charted territory. Navigator helped the crew steer towards the goal on the best possible route. They were constantly cautious of unexpected circumstances that might mandate a change in direction.

The Doer

When you're obese and the doctor told you to exercise, you pretty much know what to do and where your goal is. But you haven't done it - otherwise, you wouldn't have that problem. It can really help to have a non-judgmental, diligent person to do it with you. This will keep you motivated until you get the hang of it.

The Daredevil

A real adventure happens when you have no idea where you're going or what it takes to get there. This is not for the faint of heart! Your next action may end in disaster, and you have no way of knowing that until it happened. Some people enjoy this thrill. Being positive, with more of a "can-do attitude" than reliance on "have-done experience", the daredevil is never afraid to catch a bloody nose. If the endeavour fails - at least, we learned what we should not do again!

Summary

None of the leadership traits examined in this article require a position of authority or a job title. Such leadership is situational. It occurs subliminally during day-to-day work and is very fluent. Everyone exhibits some form of leadership traits and everyone's leadership is appreciated. Some people lead well in more than one type of situation. Few people can appropriately in all situations. It takes wisdom to understand when to lead and when to follow.
The challenge is building up positive leadership traits in all team members and aligning them to a common purpose.

Assumptions, assumptions everywhere ...

The difficulty with any attempt to change an organization is that we're full of assumptions. Both as consultant looking into the organization, as well as member of the organization looking out, we filter our perception of reality through a mesh of underlying assumptions. These assumptions will dictate our thoughts and actions. This wouldn't be a big issue if assumptions were either irrelevant or consistent. It becomes an issue when our assumptions are in conflict. But what kind of assumptions do we make?

Axioms ("Base assumptions")

Axioms are fundamental assumptions which we can neither prove nor disprove, so we simply assume they are true. One scientist I respect a lot says that he reduces his axiom system to the following set:

1. Reality exists
2. We can learn something about reality, from which we can form our own model of reality
3. Models with predictive capabilities are better than models without

People may rely on more - or other - axioms.
The principle of Occam's Razor basically states that models requiring fewer assumptions tend to be more accurate.
The problem with relying on a different set of axioms is that basically, we are talking about a different model of reality without even realizing. If you see discussions going in circles, it might be good to establish a common set of axioms and check them for consistency.

Theory ("Scientific Assumptions")

We can to learn something about reality using the Scientific Method. Typically, these are also merely assumptions, because we often rely on tacit knowledge, but we still try to find better explanations with fewer underlying assumptions. The big difference between a scientific theory and an axiom is that a theory can be reinforced by repeating the experiment of the theory. Everyone is encouraged to find an experiment that could disprove the theory and form a more accurate theory. When there is overwhelming evidence for a theory and no valid counter-evidence, the theory is considered proven.
Our theories rely on our axiom system and must be consistent not only with these axioms, but also with one another.

Derivation ("Logical Assumptions")

Often, we derive knowledge rather than proving it with experiment. We often rely such derivate assumptions, such as "Tim is grumpy, therefore it is not a good idea to tease him". The derivation of new assumptions usually relies of further axioms, such as the rule of inference. Logical assumptions are typically considered valid as long as they rely exclusively other assumptions that are considered "valid" and were derived without resorting to a logic fallacy. A derivate assumption is automatically invalid if any underlying assumption turns out to be invalid.

Bullshit ("Made-Up Assumptions")

Sometimes, we just make up an assumption to justify a certain behaviour, in concrete disregard of the reality around us. In many cases, people refer to some form of evidence, ignoring the scientific method. Scrutiny will expose this, and the idea should be rejected. If these assumptions plainly contradict available evidence, there's only one name for that: Bullshit. There's probably not much need to describe what we should do with that.

Dogma ("Religious Assumptions")

One of the worst problems plaguing the world of science, management and news are dogmatic assumptions. But what's a dogma? Dogmas arise whenever a concept is assumed to be valid "because someone said it" (or wrote it) without a tracible line of inference or evidence. Dogmas become problematic in two circumstances. First, if the original idea was already bullshit. In that case, we can also refer to the idea as a hoax. Second, when we need to trace back to the origin in order to discover a potential lever for adjustment. Quite often, tracing back the root busts the assumption: During backtracking, we might discover that we relied on an idea that was not valid to start with. Dogma is not inherently invalid, but whoever adopts dogma runs a risk - Caveat Emptor!

Take-away

Everyone makes assumptions. It is not bad to have assumptions.
However, inconsistent assumptions cause miscommunication and result in poor decisions. 5-Why-Analysis is a method to expose invalid or inconsistent assumptions. Tracing back a thought system to it's underlying assumptions can reveal crucial points of uncertainty.
Exposing the key assumptions in your models can be a powerful mechanism to uncover ways for significant innovations through experimentation, validation and rejection.

So, I'm not an agile coach, after all ...

I recently applied for a Certified Enterprise Coach - and got rejected. It took me a while to get over the rejection, and I had some good discussion with one of the application reviewers. What I learned: My understanding of "Coach" is not the same as others. Then I found this post on LinkedIn about what a coach is, and decided: I'm not a coach. I consider that what others promote as "coaching" to be snake oil selling and therefore, unethical. As such, I will gladly refer to myself as "enterprise consultant helping others be more successful by becoming more agile" (short: agile consultant) instead.

So, what are my reasons for stating "I'm not a coach", then?

For now, I'll just sum this as a response to the "Top 5 Criteria of an Agile Coach" delined in the quoted article.

1. An Agile Coach must not own the delivery or the outcome expected from the team.

Would you hire a football coach who openly states that "I'm not responsible for how the team performs!"? Where would you get the idea from that a coach has no outcome responsibility?
There is a difference between short term, mid-term and long-term performance and one must definitely understand the concept of special cause variation. But when I see that my coaching engagement makes no significant difference in the team's performance, then I am not doing my job! Convincing my client that this is how it's supposed to be and that I deserve my paycheck even when my coaching makes no difference at all - is purest snake oil!
My take: An agile consultant keeps an eye on short-term, mid-term and long term capability of the organization and understands the systemic impact of specific choices. They understand that there is often an anticorrelation between short-term and long-term performance and understands when tradeoffs between the two make sense. They are aware that taking a short-term hit in performance might yield long-term learning and growth. Likewise, they understand which short-term performance boosts will lead to long-term disaster. They help agilists make informed decisions to understand the consequences of their actions.

2. An Agile Coach must not try to be a great coach or expect to be loved by the team.

Well ... this is dubious. Your job isn't to be everyone's best buddies, but if you don't want to invest into building a trust relationship, you shouldn't even start. Likewise, it's not about who you are as a coach, but about what you want to achieve with your client. If you put focus on your person instead of on the change you're guiding, you're the wrong person in the wrong place!
My take: An agile consultant is a trusted partner of everyone in the organization, and their greatness is the impact they make, not who they are or what they do. If your footprint isn't felt even years after you left, you're not worth the money. And if people don't reminiscence about your work admirably or positively, you're probably in the wrong business.

3. An Agile Coach must not solve the team’s problems.

I just can't get this image out of my head:
A child fell off the bridge and is drowning. A coach passes by, sees the frantically screaming child and helpfully states "Well, now would be a good time to learn swimming." - and walks off.
There is a time for everything! People who don't understand that and deny help in time of need are not just not coaches, they are inhuman bastards! Now, it's important to understand when is the right time for help in order to not fall into the trap of helper syndrome.
My take: An agile consultant is aware when is the right time for what. They understand that, just like you can't let a 4-year-old child figure out how to drive an SUV in the city center, there are situations which are beyond the teams' current level of expertise. They will take control to prevent irrecoverable damage, they will guide to steer away from disaster, but just like a parent, they will let teams take a few hits here and there in order to be more self-reliant later. In the same way, they might even create challenging situations for people to grow. And they understand when is the time for which approach.

4. An Agile Coach must not stay too long with the same team.

This was stated as maximum 3-6 months. In that time, you can hardly achieve meaningful, sustainable change. I am not even concerned whether that is sufficient to get the team to trust you, think a bit, run a few experiments and make a few changes. However, in challenging environments, this is hardly enough to drive out old habits. Hidden opposition to new ways of working can easily keep low profile for that timespan, especially when they know they just need to outwait you. What I see too often is that once coaches leave, within a few iterations, people are back to the former status quo.
My take: An agile consultant should focus on making an impact that lasts even long after they leave. They are not keen on leaving before the cookie crumbles. They want to contribute something meaningful, and they take as much time as it takes. Understanding Kotter's model of organizational change, they see the entire process of change through before they leave. They help in institutionalizing change, rather than taking off before sustainability is reached.

5. An Agile Coach must not make prior assumptions about the team.

We all make assumptions - all the time - and we can't even think without making assumptions! To assume that we can make no assumptions is ignorant! An agile coach who does not understand the nature of assumptions will not be able to make suitable assumptions and may not catch invalid assumptions in time. This plays right in line with point (4) above - be aware of the dangers that your own model of reality imposes on your work!
My take: An agile consultant must purposefully make critical assumptions and invest time into verifying them without bias using the Scientific method - preferably by finding evidence to discard them in favour of a better model of reality. It's actually good to have a certain set of assumptions and a clear plan how to reject them!
For example, "The people here are lazy" is a useful assumption in the sense that you now have to find a way to disprove it. Evidence-based rejection of this idea will become both the basis of your trust relationship (see 2) abnd the first small victory on your road to excellence. The art of the agile consultant is to find a effective experiments to disprove false assumptions quickly, completely and without a spark of doubt.

Conclusion

I've witnessed too much snake oil selling in the agile community and am pretty much fed up with it. When people try to define the term "coach" as someone who seeks absolution for their inability to make a difference even before engaging a client relationship, I can only advise: Don't hold your breath. Find someone who has the guts to take a stand for what they believe in!
I gladly reject the idea of being an "agile coach" when the idea of coaching is to not help people who need help, not make an impact and spending as much time as possible staying vague and undecided before taking a quick exit and not taking responsibility for their own work.
I do not want to be such a person. If there's nothing I can do for you, I will tell you. When I won't make a difference, I'm wasting your time. I'll jump into the river to save you from drowning, but only until you're out of danger. When you can swim by yourself, I've achieved my personal goal. But I'll be looking for evidence to see that you don't need me.

I am a consultant, supporting your agile journey. My job is done when you're more successful.
Sorry. I don't have snake oil for sale.

Guide: LeSS or SAFe - which direction?

As an enterprise choosing an agile framework, you may be stuck with the choice: Which one is better? Having expertise in both of them, I have provided a small decision making guideline to help in your decision. There is no "good" or "bad", "better" or "worse" framework, but a list of factors based on your organization's reality that make either of them more or less suitable in context. Here is the checklist including a small explanation:

Current state

Which traits strongly describe your organization at this moment? Only make a check where you think "Yes, that's definitely a driving factor". The factors are split into "constraints" and "enablers". A Constraint reduces your potential level of agility, while enablers foster higher agility.
Many enablers would support a LeSS adoption, but the constraints need to be dealt with prior to introducing LeSS. SAFe, on the other hand, has been tailored to accomodate existing constraints and can be adopted even if there are few enablers present initially.

Optimization goals

Which benefits do you hope to gain from adopting an agile framework in your organization? The goals are weighted against each other, so you need to choose whether you want to balance them or tend into a specific direction. Tendency to the right will be more in line with a LeSS adoption. A tendency to the left will be more in line with the SAFe framework.

Tendency

Completing the checklist does not provide a prescriptive direction for implementation, rather a tendency on which framework you should research first. It may still be useful to look into the other framework, but odds are that at the current moment, you will find more value in researching the indicated framework.

Change over time

Regardless of the outcome you get from this simple guide, you may want to revisit this guide after a few months or years. If the indicators show a different trend, it might be useful to consider taking a closer look at the other framework.

How SAFe deals with cost accounting

I was asked the question "How does SAFe handle money?" - well, in a complex organization, this is a complex topic. Here is a non-comprehensive list of answers:

• SAFe discourages "project accounting", but acknowledges that an ART may be forced to do that because especially in a cross-company value stream, contracts may be hard to change on a short notice. We spent a good half hour discussing the detrimental effect of cost centers (i.e. resource utilization) on flow (i.e. value delivery). An SPC would accept the current cost structure when launching an ART and then collaborte with Executives on a Portfolio level to move to a value stream centered budget structure.
• On a Portfolio level, SAFe suggests that budgeting be done per Value Stream, on a (no finer granularity than) per Program Increment basis, so the Enterprise should assign for each Value Stream (= each ART) budget based on the expected outcome of the Value Stream.
• Cost transparency is provided on the highest level of abstraction that the organization has, i.e. you'd measure on a portfolio level the "cost per epic" [i.e. "The new iphone"]. While it would theoretically be possible to drill this down to Value Stream and even team level, SAFe favours TCO (Total Cost of Ownership) with a systemic "Optimize the Whole" view.
• SAFe standardizes Story Points across teams and then uses Story Points as a "hard currency" in the sense that stakeholders and finance understand where the money goes ("expensive" and "cheap" feature requests). Dean indicates that a workable PBI (i.e something you'd put in a Sprint) should be no bigger than 8 Story Points, while a Program level Epic might be 5k SP's, while another might be 1k (also providing a dimension for "fairly cheap" and "fairly expensive"), then counting on the Law of Large Numbers to make this "sufficiently accurate" for value based prioritization.
• Dean gave examples of a single SP ranging to a cost between 800 and 1800€ depending on the value stream: This gives a fairly accurate price tag for a portfolio topic.
  Again, this resorts to using the Law of Large Numbers, and it will (based on the distribution) be off more often than not when drilled down to a User Story level. Again, it's about optimizing a system, not a component of the work.
• In PI Planning (i.e. the big, quarterly Planning Event), each overarching PI Objective ("Sprint Goal") is assigned with a "business value" ranging from 1 to 10, where 10 is the most valuable and 1 the least valuable. Teams will then collaborate during the PI to deliver the WSJF (weighted shortest job first), i.e. deliver maximum measurable business value from a customer perspective, keeping in mind thatthe focus is the delivery of a valuable product increment as an ART, not the completion of individual team objectives.
• ROI tracking is then done in a simple, yet sophisticated process of having Business Owners ("real PO's") account the value delivery per PI objective (i.e. Iteration Goal) with anything between 0 (done, but no value) and 10 points (done, EXTREMELY valuable) to give feedback how well the plan (i.e. PI investment) worked out.
• Teams receive transparency whether they delivered on their owned team objectives, and also whether the value stream delivered. Points of inaccuracy in the value forecast become the subject of retrospectives within the team(s).
• From a management perspective, the goal of PI planning is to move delivery value forecasting accuracy (i.e. how much the ART will deliver in the PI) as close to 100% as possible, which equals a corresponding reliability in cost estimates (i.e. SAFe comes with a promise of catching potential budget overruns early - a HUGE thing for large enterprises!)
• One of Dean's personal pet peeves is MBO (Management by Objectives) with monetary incentives, because that not only doesn't work in Knowledge work, but it also causes dysfunction. As a current WIP, he is creating educational material for middle management on why and how to move away from MBO. SAFe encourages a salary structure without any performance bonuses beyond enterprise-wide profit shares.

Summary

SAFe discourages utilization-based accounting. SAFe favours value delivery based accounting. Executive management retains full transparency and control over cost.

Fiduciary accountability is realized through the several feedback mechanisms induced in SAFe to ensure the ART operates to continuously maximize ROI based on assigned funding. Failure to deliver the presumed value are revealed early and continuously. 

SAFe encourages optimizing the system as a whole, which requires moving (the impact of) CapEx and OpEx decisions to Portfolio level and away from components of the ART. This prevents local cost optimization which could be very expensive for the organization as a whole.

SAFe impressions from a LeSS Practitioner

I'm just now sitting through a 4-day SAFe 4.0 SPC course with Dean Leffingwell.
While I would not dare call myself a SAFe expert, I can at least say that I'm no longer making baseless assumptions about SAFe, but based on firsthand information from the source. Of course, being a CLP and aspiring CLT, I see SAFe through the biased goggles of a LeSS Practitioner. That does not mean I came to the course to bash it or nitpick, but to learn new/better ways of developing software and helping others to do so, from others who are doing that.

Here are some observations I made:

What I like

• There's a big level of overlap with LeSS. Examples? Systems Thinking, Optimize the Whole, Get Rid of Queues (where possible), Focus on Customer Value, Lean Thinking, Transparency. 
• SAFe emphasizes "U-Curve optimization", i.e. it suggests doing the best possible thing, which may be a compromize when the cost of further flexible outweighs the benefits thereof. That doesn't absolve you of actively seeking ways to reduce the costs caused by your inflexibility!
• SAFe suggests Co-Located Feature teams. It concedes that major structural impediments often can't be resolved on a short notice, so it offers a way to start with such maladies still in place.
• The "Dependency Map" on the Program Board (that scary red spider web) is NOT intended to actually help track and manage dependencies (though it can be used for that if you're masochistic) The primary goal is to create visibility so that people start thinking about resolving that mess.
• The "Coordination" part of SAFe are functions, not roles: No denying that a big picture and delivery capability are needed, and SAFe is not prescriptive about how exactly that's getting done.
• SAFe does not actually suggest having a separate System Team, but won't stop you from doing that if you can't do otherwise, 
• SAFe isn't really as concerned with what the teams do and how they work, as long as that's agile and follows a reliable cadence. But SAFe is concerned that everyone understands the impact of their actions on the overall (huge) system.
• SAFe addresses the entire Middle Management Layer in a huge corporation and provides them with a perspective, rather than stating "From now on, you're optional" (which reads to many as: disposable).
• One main concern of SAFe is reliable mid-term and long-term oganizational predictability, where "mid-term" is a Program Increment of 3 month, and long-term 2 or more thereof. Of course, non-development activities at a large scale need to have some reliability. Preparing a primetime TV campaign also takes effort.
• SAFe does actively address the issues of Enterprise Budgeting rather than taking the easy way out by descoping it.
• There is no "Big Batch Delivery": SAFe suggests "Release anytime", but concedes that for companies who previously could hardly release twice a year, release at Sprint's End is already a lofty goal. Again, it's about compromizing based on reality.
• A Program Increment is 5 Sprints, one of which is an IP Sprint (Innovation + Planning). The main purpose of this "non-development" Sprint is to engage mid-term forecasting and systematizing innovation. It's NOT a "hardening Sprint" or anything coming out of not really working agile.

Neutral

• You can boil down Essential SAFe to the Agile Release Train ("ART"). Not much magic there. We see the same in LeSS, although we call it the Product Group.
• SAFe is about as prescriptive as Scrum, in the sense that "you can customize it, but that's not SAFe". No need to get religious about calling it anyhow "un-agile" because of that.
• SAFe is actually not for everyone - it targets huge organizations who have trouble delivering, and for those companies it will be a way out of the quagmire.
• The "Value Stream" level of SAFe is not even interesting for Product Groups are less than 100 people. A Value Stream level synchronization actually only occurs when multiple E2E value streams, each bigger than 50 developers, coincide in 1 product. In LeSS, that's Requirement Areas.

Scrum Masters

• SAFe interprets the Scrum Master as facilitator and nanny of the team: the guy who has to get running when someone needs something - an HPQC (yuck!) license, for example.
• SAFe suggests using a "Scrum of Scrums" where Scrum Masters communicate impediments to each other, in the absence of teams. That's not so Gemba.
• SAFe actually suggests to try making Project Managers into Scrum Masters if at all possible. Some Scrum practitioners may have some animosities with that.
• Dean actually stated "Scrum Masters aren't really masters of Scrum after a 2-day course", so SAFe provides an environment that doesn't expect them to be, although it encourages them to learn more.

Product Owner

• SAFe' Product Owners are simply fakes. They are the bottom level in a 3-4 player hierarchy of Portfolio Managers, Solution Managers, Product Managers and finally Product Owners. They all do the bidding of so-called "business owners" who make the real shots. This is actually in conflict with the Scrum Guide!
• SAFe actually suggests making Business Analysts into PO's (not people from the business!). Some Scrum practitioners may have some animosities with that, as well.
• Dean actually stated "Product Owners don't own the Product, but it's a specific term that's widely used in the industry, so we stick with it for simplicity sake".

Teams:

• SAFe gives teams a lot of leeway as long as they keep the System (i.e. the Release train) rolling and actually keeps the organization out of their way as long as they are on board. SAFe might occasionally feel highly constraining when teams are unaware of their position as a cog in a much larger gear.
• SAFe emphasizes something called "subtle control", i.e. managers stay in charge, teams are NOT empowered or self-organized beyond where management lets them go. That actually does make sense until teams (who have never worked autonomously before) have learned to bear their responsibility. It takes a good coach to understand when this control is due and when it's undue.
• The first implementation of SAFe might not change the basic line structure of the organization, but rather "virtualize" the ART on top with team members still reporting into their original line. What this means for team autonomy, and therefore, decisive capability, depends on the organization.

Extra Roles:

• The Product Manager is not an "extra". They exist for exactly the same reason why APO's exist in LeSS - because you can't manage hundreds of PBI's in real time.
• Dean meets the idea of whether we need an RTE (i.e. Super-Scrum-Master) and Architect with an empirical statement of "Experience has shown that it's a good idea" rather than a religious "It's mandatory". 

Comparing SAFe with LeSS

SAFe doesn't really compare to LeSS: LeSS implies a Product Group below 72 people (no more than 8 teams, 6+/-3 people per team) while SAFe doesn't even have much of a case for less than 50 people. The comparison is, if anything, with LeSS Huge, which would be more concerned with Product Groups of hundreds or thousands of people.

SAFe concedes that Scrum isn't for everyone and that some teams may be better off running Kanban with synchronization points. In that aspect, it is more flexible than LeSS, which is Scrum.
On the other hand, Less does not have certain elements of the ART such as the "Architectural Runway", making it more flexible in those aspects.

Organizations who don't even understand why they should invest time into a Nemawashi will be better off trying SAFe. During this process of making an informed decision (which LeSS strongly advises), they might or might not discover LeSS to be more suitable.

In either case, the organization must take care that their optimization goals are compatible with the adjustments and outcomes suggested.

In my opinion, any discussion "SAFe vs. LeSS" is not a question about the frameworks, but about the current and intended future state of an organization considering an agile transition. There is no "better" or "worse" without having a specific company as the basis for a comparison.

My personal, biased take on SAFe

• SAFe definitely has merit for improving organizations who just can't understand agility yet. It's a good incubator for agile practices and mindset.
• It surely looks fairly easy to sell, because they've invested a lot into streamlining the sales process (i.e. convincing managers to give it a shot). Every SPC has had a basic Sales training. I find that valuable, even for other purposes.
• SAFe comes bundled with mutual adoption support - an SPC never has to fear of being left alone. Dean emphasized that you should always work together with other SPC's as a team during a SAFe Enterprise Transformation. I love the idea. It increases reliability and creates a meta-feedback loop.
• I pity the "Product Owners" and "Scrum Masters" in a SAFe environment. One thing is certain: if an organization would offer me a SM/PO position, I'd now be very, very keen to discover whether they are using SAFe, and if so, what they made of it ...

Summary

SAFe is a quantum leap ahead for companies who are still stuck in the Stone Age of Waterfall Project Organization, reporting Watermelons year after year.

On the other hand, it is probably unnecessary weight for companies that have mastered agile delivery on an organizational level already. But even then, it may be good looking into SAFe just to get a different perspective and maybe learn something new.

Unlike Scrum, which pretty much suggests "We'll train your CSM, then have fun learning through Inspect and Adapt", SAFe clearly suggests taking calculated risks while having continued SPC support until the Train runs smoothly. That does boost management confidence in the framework.

Guide: Achieving Self-Organization

Based on our former model of self-organization, autonomy and trust, we have a question: "How do we achieve self-organization when we are currently organized in a Command and Control structure?" The big pitfall is that neither autonomy nor trust can be decreed: They must be earned, given and received. As such, the switch to self-organization is not simple. 

Increasing autonomy

Moving from a Command and Control structure to increase autonomy results in a problem: People are able to make their own decisions, but they are not being trusted on those decisions. Rather than being able to use this autonomy, people will be wasting their time justifying why they want to do things the way they chose: The system moves into the state of anarchy. Productivity drops as managementtries to retain control. As management sees a productivity drop without having trust in the outcome, the "obvious" solution is to reduce autonomy again in order to increase productivity. The consequence is a rebound back to the former C+C structure.

Increasing trust

Moving from a Command and Control structure to increase trust also results in a problem: In an environment where adherence to plan was always strictly monitored, simply removing the reports and controls does not automatically remove the behaviours induced by the control structure. People may already have learned that accountability must be checked. They might consider that "doing work" is only necessary when it is being checked upon: Productivity will decline with no benefit. Management will learn that controls are necessary to get results - a rebound back to the former C+C structure.

Increasing both trust and autonomy

A good way is to increase both trust and autonomy simultaneously. However, it is not enough to say "Do what you need to, I trust you." This is actually dangerous.

The first issue is that autonomy is the result of teams taking ownership: Ownership can be taken, but it can not be given. There is no guarantee that teams will take ownership. Important products may become "no man's land", where nobody feels responsible: the team might land in the apathic square - even worse.

The second issue is that trust is difficult to build: Spontaneously extending unconditional, unwarranted trust from one minute to the next may be greeted with reservation and suspicion. As mentioned above, this may result in an unproductive, apathic situation.

Completely loosing the reigns in an instant will have an unpredictable outcome, but will most likely not lead to self-organization.

Incremental, coinciding increase

Rather than attempting to move erratically across this matrix, we must consider the matrix as a gradient rather than binary.
Trust can be grown, bit by bit in small increments. Trust can only grow well by giving people something you trust them with. Replace rigid control processes with a collaborative feedback cycle.
Consider giving the team a little bit more autonomy in one area where they can and want to take ownership. Replace rigid control processes there with a collaborative feedback cycle.

Handing over ownership

Handing over ownership is difficult, especially when this is unfamiliar both to management and workers.
Here is a non-comprehensive list of actions you need in the process:

1. Explain what will be different and why. You can use the GROUPER acronym: Goals, Roles, Overview, yoU-View, Perspectives, Expectations, Responsibilities. 
2. Learn to ask different questions. For example, exchange the questions "What did you do?" with "Everything fine?" and "Why is this not done?" with "Where do you need help?".
3. Extend information. Instead of demanding information for reports, provide information that will help the team decide in the same way you would.
4. Suggest options. Early on, people might not feel comfortable with deciding atonomous. Moving away from "You must do X" to "Now, you might do X or Y, or even something completely different." helps people re-learn that they have a choice.
5. Probe understanding. Instead of controlling how well people bear their newfound autonomy, try understanding their point of view. Fill the gaps that help them bear it better.

Accept that newly acquired ownership is a learning curve - people might fail to bear this responsibility well. When a setback occurs, do not re-institute control, and most specifically, refrain from issuing commands. Use feedback mechanisms to find out why the setback occured and guide the team in moving forward again.

Managing the transition

There are basically four major pitfalls in the transition:

1. The increments towards self-organization may be too small or too large to bear. In this, observe the basic rule "Go slow to go fast". Start with relatively small changes. Increase the amount of autonomy/trust increase per increment until the team is self-organized.
2. The team may not be able to handle self-organization. Education is key. Make sure that the team has all the knowledge and skills to bear their new responsibilities. In a strong C+C organization, that may well mean sending a developer to a Project Management seminary just to understand the surrouding ecosystem.
3. The managers may not be able to handle self-organization. Trusting others is a leap of faith for everyone, and leaders are expected to lead. When the job of commanding and controlling others becomes obsolete, the organization needs a strategy for retaining talented transition managers.
4. The environment may be hostile to self-organization. In this case, managers gain the additional responsibility of becoming "culture catalysts", creating a self-organization friendly ecosystem in their sphere of influence by creating a bubble of autonomy and trust around their teams.

Summary

There is no silver-bullet recipe and no straightforward roadmap for achieving self-organization, either. Like any other organizational change process, communication and leadership are essential. Depending on the current limits restraining autonomy and trust, a long, difficult - and occasionally painful - journey begins. The deregulation phase should be kept as short as possible, yet as long as necessary for real learning to kick in.

Never forget Kotter's Change Model in the process. 

The relationship between self-organization, autonomy and trust

Agility encourages self-organization. Self-organization is the only way to fully harness the maximum thinking potential of everyone on the team(s), but you can't just tell the team "Ok, now you're self-organized" and expect things to work out. In this guide, we will discuss how management attitude and practice affects self-organization.

Autonomy and Trust

Self-organization has two basic requirements: The team must be able to work autonomously, and there must be a high level of trust.
Let us examine how the levels of autonomy and trust affect the team:

Command + Control

When autonomy and trust are low, we speak of a "Command and Control" structure. In this setting, management tells people what to do and checks that they do it. When people do not do as told, additional controls are instituted, because that gives management more confidence that the desired result is obtained: Trust is not necessary. Most traditional organizations are built this way - that actually works to get things done in the way management wants. The only drawback is: The innovation power is limited to management brains. The rest of the team are just busybees.
C+C Structures are stable and sustainable.

Self-Organization

When autonomy and trust are high, we have a "Self-Organization" structure. In this setting, management enables people to do what they think is right. Managers admit that they are not the experts and when the experts are stuck, managers will support. This requires trust on both sides: Management must trust the team to do the right things, the team must trust managers to be a reliable source of help.
This is a massive paradigm shift - and this frees everyone to fully focus on moving forward rather than on the status quo: New solutions emerge that management could never have imagined.
Self-Organizing Structures are stable and sustainable.

Anarchy

High autonomy coupled with mutual distrust will be anarchic: Everyone will try to protect themselves first, even when this is detrimental to others. Managers want to control people, but people do not want to be controlled. Teams will consider other teams as impediments and constantly try to force their own view on others. This reinforces mutual distrust.
Anarchic organizations are inherently counterproductive, as people will invest the majority of their effort on protecting their own turf and conquering others' turf.
Anarchic Structures are unstable, and typically unsustainable.

Apathy

Giving people trust, without letting them decide what to do will result in apathy. Managers will constantly restrict people in doing what they think is right, but then let people run free on what they think is not. People learn through reinforcement that their ideas, expertise and skill are actually perceived as irrelevant.
Apathic organizations are inherently unproductive, as people realize that their potential is discounted and unvaluable.
Anarchic Structures are unstable. As apathic workers tend to leave, they are unsustainable.

Summary

Based on this model, managers have only two choices: Provide high autonomy and trust - or remove both. Other states are undesirable. Self-Organization only happens when a high level of autonomy and trust exist. This does not happen merely by decree, but must be reinforced by actions.