Pair Programming - what makes it hard?

Recently, after quite a long while, I had a Pair Programming Session again. I think it's been a good year since I last wrote JS. Let me share some valuable lessons I learned.

What we did

I found a nice little visualization tool on the Web, 100% JavaScript that we wanted to do something with. So, we forked the OpenSource Repo and got going.
The code was ... like ... nested functions within functions, if-else mountains, and our first thought was "Omg, we gotta refactor everything". Well, we just wanted to add some User Interface and customize a few things. It was a constant trial+error, and because the Repo came without a single Unit Test, we broke the app countless times. Well, we accomplished our goal and the app now does what we wanted.

Our approach

We had a vision and some ideas and just "nerded it". No upfront planning, no upfront design - we simply decided to pair up and do something spiffy. I started navigating, trying to get my ideas across of "how to do it". I don't consider myself much of a developer, so Navigator was totally fine.

Setting out

The first couple minutes were fine. "Let's do this ... ok, the code where we need to work is here. Now, all we got to do is add a function ... and a function call ..." I started to get tense. For a Clean Code fanatic, the code looked like a nightmare. About 700 LoC in the outer function, duplicate code, overridden variables - it could make you nauseous. 

Having created that kind of code before (cough), I didn't find it all too difficult to locate exactly where we had to work and which portions of existing code helped. For my driver, who was more used to Clean Code and had no JS experience, it was an entirely different story. He got lost in that code: Structure, syntax, purpose ... all a mystery. It was even more mysterious that it somehow worked.

What happened next

I started telling him specifically which line of code to go to. That helped. A bit. Next, I started telling him which variables to use. And which code to write. He became my secretary while I was dictating the code.

Soon, I grabbed the keyboard right across his lap, had my arms crossed with his - and started typing. That was a clear violation of my Navigator role.
I had lost my temper.

What I did about it

I realized I did the wrong thing. I withdrew. We quickly discussed what we wanted to do, then I turned to my own computer, minding my own business. We always came together when he made some progress. At least like that, he was free to work out his own solution, do his own experiments and gather his own learnings.

Within the same day, he could work the code completely free of my interference.

What I learned

Pair Programming isn't always the best approach to learn - especially when you're short on temper and lack the rules to keep you at bay. 

Rules that might have helped:

• Define clearly what a Navigator is allowed to do and what not
• Define clearly what the Driver does
• Hold each other accountable to staying in role
• Define driver-switch intervals. Don't let the Navigator get all jittery over a prolonged time

Meta-Learning: I have tremendous respect for navigators working with learning developers on messy legacy code. I didn't even last half an hour before I lost my patience.

I now consider Navigator a significantly more difficult role than Driver. Kudos to all who navigate well.

Three strikes and you're out

A recent blog article I read about how people should deal with SAFe spawned me to reconsider what we should do when people disagree. This is not limited to SAFe, it's applicable to any major change initiative. How should we deal with resistance?

I suggest a "Three Strikes" approach when commencing the agile transition.
This approach should be applied equally to those who insist on retaining the current status quo as to those who adamantly insist Agile be done "my way or the highway".

1 - Educate.

Chances are people resist the change because they do not understand the implications of the change. As in the article above, the author applies their prejudices and current understanding to a future state. Training is a good way to dissolve prejudices and enhance understanding.

2 - Coach.

People naturally resist when taken out of their comfort zone. Especially those who insist on a specific direction with religious zeal are often simply afraid to adjust. This may be because they do not understand how the new ways will benefit them - or how they fit into the new picture. Coaching will enable them to align what they want to do with what they actually do.

3 - Out.

When people start to form guerilla resistance and backstab the change program, they damage your organization. Keeping them in check will require setting up anti-agile controls, making their cause a self-fulfilling prophesy. More than that, they unwillingly become saboteurs of the very thing they fight for. When people start to follow the advice provided in the linked article, please listen to the wise words of John Kotter, one of the world's leaders on successful change management:

Summary

Your agilists deserve a chance to do the right thing. Training is a very cheap measure of bringing people on track. Getting a good coach is money well spent if the main issue is personal comfort.
Should both of these things be ineffective, don't hold your breath.

Be consequent. Invest well into education and and coaching. Should that be ineffective, cut the ties.

The three core aspects of SAFe

I get into quite lively discussions about "What is SAFe?". So, I want to boil down SAFe to three core aspects. When you have these things in place, you're set out in the right direction.

Team of Teams

At the root of SAFe is a team of teams. Like a developer is a vital component of a Scrum team, in the bigger picture, an agile team is a vital component of an agile organization.
The most important aspects of a Team of Team are the same as those of a single Scrum team:

• Uniting Vision
• Shared Goals
• Collaboration

The Team of Teams will be much more powerful than a group of individual teams. A Team gains power and effectiveness by contributing as a valuable member in this Team of Teams.

Systemic View

A Scrum team self-organizes to effectively meet the Sprint Objectives. In a large organization, the most pressing impediments are either at the touchpoints between teams - or even completely outside the team scope.
The following systems need to be considered:

• The Product 
• The Value Stream
• The Enterprise

A team is a component that both affects these systems - and is affected by these. Teams need to understand how changes to their way of working affects the system - and management needs to understand how modifying the system affects the teams.

Inspect and Adapt

Agility implies doing the right thing as we learn what this right thing is. Inspect and Adapt requires taking a systemic view to do properly - and a Team of Teams to be effective. The following items need to be inspected+adapted scrutinously:

• The Product
• The Process
• The Structure

The motor of agility is a functioning I+A mechanism. Ceremonies like System Demos (Reviews) and Retrospectives both at Team and System level are essential. A mindset of Experimentation and Feedback is necessary to be successful with I+A.

Summary

People who look at the "SAFe Big Picture" feel compelled to note that it's quite complex and has an overwhelming amount of prescriptive structure. Be at ease.
If you are concerned about the numerous roles, artifacts, the suggested practices or even the Big Picture itself - that's okay. They are not what you should focus on. They are provided as guidance to help you with the most common problems encountered when dealing with large product development.

Build a Team of Teams. Think in Systems. Inspect and Adapt.

Do these things and you will succeed.

The biggest question when Scaling Agile

Pretty much every large company states, "We need an agile scaling framework". 
I do agree that when 50+ developers need to collaborate, then a scaling framework provides massive benefits. There is one question left unanswered. One unspoken, unchallenged assumption looms like a specter over every scaling approach. Before asking this question, I will list out the reasons why it needs to be answered.

Are you asking the right question?

Creating complex products

A complex system has, by definition, a fairly high complexity. A common assumption is that Divide+Conquer (D+C) is a good way to approach complex problems: Split one big problem into many smaller problems, distribute these and bring the solution back together. Sounds promising. 

A Scaling framework can then be used to maximize the effectiveness of the D+C approach.

Question 1: How do you define the problem?

When you're starting the development of a large product, you typically have a need - and want some product to meet that need. Due to the very nature of product development, the solution doesn't exist yet. Have you thought about these:

Is your problem even properly defined yet? Is it sufficiently clear where the efforts will really be? Do you know enough about the challenge domain to divide and conquer it?

Question 2: What is really the problem?

When you're setting up a product development organization, you simply assume that the need is clearly defined, and then it's "just work". 

What happens if even the question wasn't the one you should have asked during planning? What happens when the plan turns sour and you're giving the wrong answer to the right question? Does it help you when more people work on the wrong things? 

Question 3: Where is the problem really?

In scaling agile development, you assume that the main problem is that "there is too much work to do"for a limited amount of people. As I wrote elsewhere, the problem with lots of work is that it causes lots of work. And with that, I mean non-value added work like coordination, task switching, meetings etc. 

Have you considered the proportion of value-added work focused on the product versus the amount of non-value added work focused on your own process? Are you aware how much time your developers coordinate thanks to your organizational structure? Is your organization product-focused or process-focused? What happens to coordination overhead when you add complexity to your processes? What happens to development time?

Question 4: Is the problem really that big?

You simply assume that you need a lot of people to create the product you need, then you wonder what is the best way to organize these people. Have you considered that Google was basically developed by two people in the first few years? And Facebook by one?

Is your product really so great that it blows Google and Facebook out of proportion? Why aren't you making trillions yet? Are your understanding and approach optimal?

Question 5: Does much really help much?

The book "The mythical man-month", written a good 40 years ago by Frederick P- Brooks, has long since discredited the idea that "throwing additional people at a product speeds up delivery proportionally". To this day, corporations consider "scaling development" a solution to "The mythical man-month". As mentioned before, great products were built by a handful of people - and more people just add work without value.

Could fewer people doing less work deliver a better solution? Would it really be slower if fewer people participated?

After asking so many questions around the key issue, here is the real question:

Do you really need "scaling up"?

• Do developers have the 100% best possible knowledge to find a solution? 
• Are they using the 100% best possible technology to solve the problem? 
• Is everyone 100% focused on doing the most valuable thing? 
• Is every work item done 100% value-added?
• Is the work done 100% effective?

Remember, when adding additional people, the percentage does not go up. It typically goes down.

If you multiply the real percentages you have, they are often abysmally low. Maybe 10 people work at 20% potential - so 3 people working at 80% potential might make more progress than these!

If you have 100 people working at 5% potential, then a single team might be more effective than they!

Have you exhausted all possible means to do the same thing with fewer people?

Only if the answer to all the questions in this section is "Yes" - then the answer to "The Big Question" is "Yes". Before that: You will be scaling up your organizational problems - not your problem solving.

Clearing our own mental model

In the wise words of Marshall Goldsmith, "For everything you start, you need to stop something." - when we are embarking a new journey, we need to throw out some old ballast. One of the biggest burdens we carry around are our own mental models, shaping our perception of reality and therefore, our thoughts, behaviours and actions. When was the last time you did some housecleaning for your own mental model?

How our mental model affects us

Everyone builds a mental model based on at least three assumptions:

1. Reality exists
2. We form a model of reality through interaction and observation
3. Models with predictive capability are better than those without

From that starting point, we are building everything we consider "real". Probably the most noteworthy assumption is #2. It indicates that during every single second of consciousness, we are shaping our model of reality.
Our mental model of reality has assumed it's current shape from the second we were born until today. Each aspect and angle of this model is based on observations, interaction and deduction.
Our choice of action is then determined by the outcome we predict based on our own model.


The problem with our mental model

"All models are wrong, some are more useful than others" - another quote I picked up somewhere.
We do not know reality. We can't. We only can form a "pretty likely model of reality" - and that model only exists in our mind! The shape of our mental model is determined by the interactions we had - and the observations we made. Since we are neither omniscient nor omnipotent, we didn't have some important interactions and haven't made some important observations - or have misinterpreted some observations.
This means our mental model of reality usually suffers from three key drawbacks:

1. Incompleteness
2. Inconsistency
3. Incongruence

Incompleteness means that there are events beyond our comprehension.
For example: I don't understand why there are black swans in Australia. I have never bothered to learn how this came to be, so I couldn't explain why Swans can be white or black, but not green.

Inconsistence means that if we scrutinously considered everything we know, we would realize that multiple things we assume as "true" individually can't be "true" together.
For example: I consider Tim to be a nice person, and I am aware that Tim is not nice to Alice - so what is it then? Is Tim nice - or not?

Incongruence means that different people models of reality may either fail to overlap (I know what you don't) or mismatch (I think this is true, you think it's false).
For example: The UKIP supporters think it's good to leave the EU, while the EU proponents think that's a terrible idea. Either party drew their conclusion based on a number of assumptions and facts that may either be unknown, weighted differently or dismissed by the other party.


Mental model housekeeping

To do some proper housekeeping, we need to be aware of the following:
1. Our mental models are just that - models.
2. We benefit from having a more accurate model.
3. Incongruent models can be aligned through open interaction with other people.

Now, let us discuss some methods for doing this housekeeping:

Aligning concepts

We have so many inconsistent concepts, just like the one above.
Once we become aware where these inconsistencies lie,
we can uncover the reason why we have these concepts.
Next, we formulate a hypothesis for the conflict, then design an experiment to disprove at least one of the concepts.

It could be that we failed to disprove any of them - in which case, we probably haven't dug deeply enough and need a better hypothesis.
It could be that we managed to disprove all of them - in which case, we may need to forget everything leading us to either conclusion.

If we disproved all but one of them, the best way forward is to discard the ideas that no longer hold true. Especially in this case, it could be that even what we believe now is still wrong: We just don't know until we have more information.

How do I align concepts - in practice?
It's quite simple. When I discover that I have conflicting ideas, I mentally rephrase "Tim hates me." and "Tim is a friendly person" into "I assume Tim hates me". Then, I ask myself, "Why would Tim hate me?" - then I may go to Tim, and be quite upfront: "I feel we don't get along very well.". Tim might meet that with an unexpectedly friendly: "What can I do so you feel more comfortable?" - my first assumption is already invalidated. My model is more consistent now.

Pruning loose ends

We are bound by so many concepts that arise seemingly without reason. 

For example, Tim said something bad to me yesterday - and now I have the concept "Tim doesn't like me". My concept is not founded on a sufficient amount of evidence.
This concept now binds my interactions with Tim, even though it is merely a loose end in my mental model. The more loose ends I carry around, the less freedom I have in my interactions with my environment.

Through introspection, we might drill into the "Why" of picking up this loose end and tying it to our model. In our attempts to do this, we complicate our model by adding numerous assumptions without any foundational evidence.
We need to become aware of what our "loose ends" are - and consciously discard such concepts.
This helps us form a more consistent model of reality.

This approach is based on Occam's Razor, the suggestion that "The model relying on the fewest assumptions is often the best"


How do I prune loose ends - in practice?

Tim might actually have said to me "Dude, you messed that one up." I can now integrate that sentence into my model right away, filling the missing gaps with unspoken assumptions, one of which may be "Tim doesn't like me". I can also choose to simply say "Yup", and regardless of whether I agree with Tim or not, I simply don't attribute these words to my understanding of Tim's relationship with me.

In retrospect, I may need to be aware that "Tim hates me" and question myself, "How much evidence does support this concept?" - unless the evidence is already overwhelming, the easiest thing may be to simply go to Tim and say, "Want to have a chat?", seeing if that chat generates evidence to the contrary. 

Probably the hardest way of pruning loose ends is to drop the concept as it pops up. Since our concepts are hardwired in our brain, pruning like this becomes a difficult exercise of psychological intervention: becoming aware of the dubious concept, then redirecting thoughts into a different direction when the concept manifest. This method does not resolve the underlying inconsistency and is therefore unhelpful.

Resolving dissonance

My concepts often don't match your concepts, because neither my experience nor my reasoning process is the same as yours.
The "easy way" to resolve dissonance is war - just get rid the person who doesn't agree with you. Unfortunately, that doesn't mean that your model of reality got any better.
When our own strive is to obtain the best possible model, we need to attune our model based on others' ideas and reasoning.

First, we need to expose ourselves to others' thoughts.
Then, we need to discover where our thoughts mismatch those of others.
Next, we try to uncover which assumptions lead to the mismatch.
Together, we can then form a hypothesis of which assumptions are more likely.
Then, we can begin aligning concepts together, coming up with a shared model that is more congruent.

Resolving dissonance requires two additional key assumptions:
1. It could be that my model is wrong.
2. I can find out enough about other models to integrate a portion into my own model.


How do I resolve dissonance - in practice?
Nothing easier - and nothing nothing harder than this. Just talk. Unbiased.
Have an open conversation without predetermined outcome.

Punching holes

We typically assume that what we know and observe is true. Then, we build new assumptions on that. Very rarely do we spend time trying to disprove what we know.
The Scientific Method is based on the idea that we can't prove anything to be true, but we can prove something to be not true. We consider as "probably a good explanation" by exclusion, i.e. when every experiment to prove that the opposite failed. So, our goal should be to come up with an experiment to prove us wrong.

We can improve our mental model by using this approach to try and punch holes into our model.
If we succeed - our model is bad and we can discard the assumptions we just invalidated.
If we don't succeed - it still doesn't mean our model is "right", it only means that it's the best we have for the time being.


How do I punch holes - in practice?
When my model assumes "Tim is unfriendly", the most effective way to punch holes is creating situations where I am exposed to Tim in settings which minimize the likelihood for him to be unfriendly.

Summary

Frequent clearing our mental model is very helpful in improving our understanding of the world around us - and our interactions with others.

The exercise of cleaning always requires the following:
1. Being consciously aware of our assumptions.
2. Doing something about it.
3. Never being content with our current understanding.

Simply starting is the best way.

Five Pitfalls when scaling Agile

Especially large corporations are looking for quick and easy ways to transition from classic development to agile development practices. The faster a transition is intended, the more likely dangerous pitfalls are overlooked. As Agile Development is intended as a sustainable practice rather than a way to get a project done, management has a tremendous share of responsibility in success.

Here are five pitfalls that you will need to deal with when you desire to scale agility:

1. Fundamental agility

Transitioning the processes towards agile is very easy. Basically, you're deregulating and training - then people can "do Scrum" or another agile approach: In the big picture, you have accomplished maybe 1% - and 99% are still "toDo". There is still a long journey.

At the core of agile development is the Inspect+Adapt process. This requires a mindset of scrutinously examining whatever is happening - and making changes when something is going in the wrong direction. To get proper Inpect+Adapt into your organization, you need to do two things:

First: detoxify the current way of working. Remove any element in your company culture that makes engineers unwilling or scared to own their process. This requires breaking tons of command+control processes and fundamentally changing how engineers are managed. Change only happens when you let it happen!

Second: Create a healthy way of working. You need to implement a management system that encourages engineers to own their decisions, changes, mistakes and successes. This requires setting up both structures and processes that honestly treasure individual contributions, even when they are not going in the direction you like. People will only contribute when you let them!

Unless you have first established fundamental agility, your agility will be brickwalled. 

Teams without fundamental agility will neither benefit nor contribute to scaled agility.

2. Craftsmanship

Instituting the ceremonies of Scrum can be done in a single day, including training and making the decisions. They give you the basics to "work agile". Short-term planning and frequent updates on the plan, feedback on the product and incremental improvements to the process are essential. Like this, developers can come up with the optimal way of working over time. You just may need to calculate a lot of time if Engineering Practices are not in place yet.

Your engineers need to be familiar with concepts like Version Control, Continuous Integration, Test Automation, Emergent Design, TDD, BDD, Pairing, Code Conventions - and many others from the XP book. They need to be able to consciously decide which of these practices are helpful in their current context and select the appplicable items in context.

 If your developers are still unaware of these practices, they well be doing the motions of "agile" without practicing agility.

Teams working without proper Craftsmanship can actually decrease the implementation speed of scaled agility.

3. Team Spirit

Often considered esoterical, team spirit is paramount to scaled system improvement. Many managers still think that individual objectives (and potentially even Stack Ranking) help developing high performing staff. As scaled agility is mostly about implementing a complex adaptive system with many contributors, the need for contribution to the Whole far outweighs the contribution of the individual to their own good. Team Spirit, in this context, means that individuals are willing to subordinate their personal interests to accomplish the overall company mission. 

Team Spirit is not as much about "doing fun stuff with others" (rafting, go-kart, paintball etc.) as in finding satisfaction in doing stuff that help everyone and advance the company mission. For this, every engineer needs two things:

First, they need to know how they can contribute. As this depends totally on the individual's current situation, it needs to arise from self-organization and intrinsic motivation.

Second, they need to have assurance that virtuosity has it's own reward. Any organizational impediment that creates a personal disadvantage in achieving overall goals needs to be removed.

A classic example of "team spirit" is soccer or football: History has proven that the game is not won by the best players. It is won by the best team. Engineering is the same: Competing aces do not win the game in the market. You win by joining forces, synergizing ideas and going in the same direction.

Groups of engineers without Team Spirit will actually spend disproportionate amounts of energy on "being busy". A scaled group will only invest an insignificant portion on achieving the shared mission!

4. Transparency

Many organizational transformatios run afoul by lacking sufficient insight into the overall system to enable global optimization.

Classic impediments to transparency occur on all levels: From developers being unaware of the impact of another developer's work on theirs - all the way up to managers being unclear what the Absolute Priority 1 of the organization currently is. 

The lack of transparency results in a myriad of other problems, ranging from engineers unknowingly sabotaging each other all the way to entire teams doing the wrong work. None of these is a desirable condition, and the amount in which these things are happening denotes the criticality and priority at which transparency should be increased. Sometimes, an organization spends nearly 100% of their capacity on problems caused by lack of transparency. In those situations, "scaling" is probably not a lesss accurate depiction of the work than "struggling".

There are many ways to increase transparency to enable proper scaling. These include, but are not limited to:

• Setting up a Kanban - visible to everyone!
• One Central Backlog from which all teams pull work
• Collective Code Ownership, providing a basis for "communication in code"
• Use of Andon: Build Monitoring and "Stop the Line", relying on test automation 
• Joint Planning and Joint Reviews, showing the Integrated Product

Transparency is antiproportional to coordination overhead and impediments. Because of that, transparency at scale is directly proportional to ROI.

5. Focus

Probably the biggest issue in organizations is a focus on utilization: bringing work to people, assuming that when everyone is "busy", we create a lot of value. An agile organization is pretty much the opposite: We bring people to the work that needs doing, understanding that value is not correlated to activity. We focus on delivery, getting things done. A classic problem of many organizations is that in their attempts to maximize utilization, many different items are "work in progress", requiring task switching and coordination. Already in trivial settings, the lack of focus quickly diminishes ROI and significantly increases throughput time: We spend too much time figuring out why nothing gets done and too little time actually getting things done.

The main idea behind focus is: It costs less to do the wrong thing first, then the right thing - than to do two things at once. 

Focus sounds trivial, yet it is incredibly hard to implement: The entire organization must have a clearly ordered list of objectives where every objective is uniquely prioritized. There may only be one priority 1. Next, focus requires strictly limiting Work in Progress.

Focus is mostly a mindset change for managers: You need to accept that idle time actually costs less than overload. You must accept that you can't have everything at the same time. 

Unfocused teams will be fully utilized, yet completely ineffective. The less clear the focus, the longer it takes to produce value.

Summary

"Scaling agile" that does not pay close attention to the aforementioned pitfalls will most likely result in a cargo cult. Outwardly, your transition may be successful - while inwardly, you will be missing the benefits of the adoption. 

To ensure that your agile transition is successful, a common approach is temporarily bringing in experts who have been in the trenches and know these pitfalls.

To avoid these pitfalls in a scaled environment, I suggest the following:

• Get Management support for the change. You will turn your organization upside-down in closing the pitfalls. That requires unconditional management support.
• Set up an Agile Transition Team (ATT) consisting of managers and developers alike. The ATT commits to a clear change backlog.
• Bring in executive coaches for key people in the transitions. This includes line managers, Product Owners and the new Scrum Masters alike. The external coach must have experience at scaled agility.
• Use technical coaches to enable teams adopt suitable engineering practices much faster: This pays off in delivering a much better product!
• Hire a consultant to lead the transition. This person must know what they are doing and must be absolutely no-nonsense. They need to be empowered to make even unpopular changes.
• Train everyone in agility. Use a safe classroom setting to demonstrate the impact of the change.

I hate SAFe ...

".. because it focuses too much on management, and too little on teams." - this is what I hear many times from agile coaches who have very strong opinions regarding SAFe.

Let me just ask you a few questions about your own experience, before getting into SAFe:

• Whom do you find more difficult to convince of agility: developers - or managers?
• Where do more organizational impediments arise: development - or management?
• Who will have more effect by changing something they can control: developers - or managers?
• Who is less likely to change their ways of working during an agile transformation: developers - or managers?
• Who needs an answer to the question "What will I do in an agile organization?" more urgently: developers - or managers?
• Who do we spend more time with during an agile transformation: developers - or managers?
  

Where agilists failed

Agility has a sad history of neglecting, ignoring and even badmouthing managers. Statements ranging from "Management is optional" to "You don't need managers in an agile organization" all the way down to "Impediments tend to have a job title ending with 'manager' or starting with 'head of ...'" alienate management.

People fail to see that every existing company has a management structure - and that managers are all highly skilled individuals who got into their position for what they can bring to the company. Structure has rendered many of these people ineffective or counterproductive. You have bright heads with brilliant ideas doing nothing except filling powerpoint slides and spreadsheet reports, attending a gazillion of meetings. I don't think that many who hold a managerial role consider that "This is what I went to university for!"

The SAFe answer

SAFe is a framework that does not go out on a limb with a "Let's fire all the managers!" declaration of war. 

Instead, SAFe does what agilists have neglected over decades: Finding an appropriate answer to the question "What is the role of a manager in an agile organization?"

The answers provided in SAFe are not surprising at all. They are based on what the reality of agile transformations in the past has already taught us.

Managers are still valuable in an agile organization, with two important constraints that need to be clearly understood:

1. Engineers aren't "resources". You can't manage people like resources. We respect people.
2. Engineers don't work on an assembly line. Tayloristic management doesn't transfer into knowledge work. We assume variability and preserve options.

 As a consequence of these two, the role of the agile manager undergoes a radical transformation. A traditional manager must un-learn many behaviours and adopt new behaviours to adequately serve an agile organization. 

How can a manager know which behaviours are detrimential and which are desparately needed? 

Well - you don't learn that in a Scrum Master class. 

Managers desparately need clear answers to the questions I asked initially. The Scaled Agile Framework takes a shot at the question "What is the role of a manager in a large, agile organization" by first digging into the question what an agile organization looks like - and from there explaining which changes management role need to live through - and why these changes in roles are essential.

Summary

I don't hate SAFe because it has so much to say on management. I love it for what it has to say regarding management. It provides a perspective for some of the most skilled and crucial knowledge workers a company has. 

A manager in a SAFe organization will finally be what they always longed to be: valuable. And SAFe gives managers a solid set of "baby steps" to outgrow their past.