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.