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.

Effective agile leadership patterns

Many organizations struggle with the notion that "leadership" equals position on the Org Chart. That is, the C-Levels lead everyone, division heads lead their division, team leaders lead their team etc. This concept may have been valid at a time when people were not sufficiently educated to discover the best way forward autonomously. But this is questionable in a world where managers don't even understand the work done by their teams. We have discussed previously that leadership is situational based on the situation of the team. Let us take a look at three different leadership patterns.

The Forerunner

The most straightforward way of leading agile is "to boldly go where no man has gone before",
A forerunner experiments, takes new ways, and learns by Inspect+Adapt, taking others along on their journey.

A forerunner is effective when others continue the journey they started.
It's very difficult to be a forerunner when the things you're doing are not the same things others are doing.

The Enabler

Another way of leading agile is by enabling others "to boldly go where no man has gone before".
An enabler considers the roadblocks which prevent others from experimenting, taking new ways and learning by Inspect+Adapt.
To enable, "walking gemba" is essential, i.e. seeing the reality of the problems causing others to not move forward.  Scrum typically sees the Scrum Master as the team's enabler, although the PO can also go a great length in clearing road blocks as well.

An enabler is effective when others can move beyond the path they cleared.
The further a person moves away from the team, the less effective they are at enabling. Likewise, decreasing proximity increases misunderstandings and "doing the wrong thing".

The Thought Leader

A thought leader does not lead by doing, but by providing impulses.
It is completely up to others to start experimenting, taking new ways or learning based on the impulses provided by a thought leader.

A thought leader is effective when others are inspired to try out the things the thought leader suggested.
Thought leaders can be completely disconnected from the team's situation, because they are just offering inspiration. They might even be completely disconnected from the team's organizational context, making their inspiration useful nonetheless.

What this means

None of the proposed three leadership patterns relies on a position on an org chart. Except for the Enabler, who can be effective by dissolving impediments caused by the org chart itself, agile leadership works best without positions or titles on an org chart.
Titles may even be counterproductive. Leading agile is something that you either do or don't. It is entirely possible that a regular developer in a team is a more effective leader than all the managers in the company together.

The most plausible way for a line manager to be an effective agile leader is in an enabler.
Forerunning is only possible by forsaking the position in the Org Chart and joining an agile team.
Thought leadership takes extremely deep understanding and many years of expertise and is difficult to attain for managers.

Conclusion

The harsh truth about "agile leadership" is that organizations have a problem with middle management.
When lots of middle managers find value by acting as enablers, we probably have so many organizational impediments that the organization is pretty much doomed. However, when they can't function as enablers, they can't be considered "leaders" any more than any other person on the development teams.

Sprint 0? Good? Bad?

I recently joined a discussion where people advocated against "Sprint 0".
The arguments delivered are along the lines of "Sprint 0 is only necessary when you consider Scrum a process", "It involves people that don't need to be involved", "It overloads the terms", "Waste", "BUFD", etc.


So, let me create a bit of transparency, regarding what I consider as "Sprint 0":

The following side conditions are in place:

• It's not necessarily the same time box as the delivery Sprints, but we're working time boxed
• There is a Backlog for things we need
• The Deliverables are: 
• A clear Product Vision
• A team that can deliver, including a capable PO and SM
• A technical environment which permits the team to deliver
• Management supports Scrum
• Stakeholders are aware of how Scrum changes the game
• Assured Funding
• Dedicated availability of developers on the team
• The team (i.e. the transition team) is delivering using an Inspect+Adapt approach.

There is no doubt that such a phase is necessary, so that the Scrum team has a chance to succeed.

To me, discussing about how to name that phase is just a game of po-tay-to, po-tah-to.

Maybe we can end the religious discussion around Sprint 0 by just calling it the "Potato"?

Iterative development?

There's an image that's going around on the Internet after a talk from Spotify as an explanation for iterative development, and it's being picked up by trainers, coaches and consultants from around the world - but it's wrong.

Here it is:

"Iterative development" analogy abused from another blog

Do not use this analogy!
Here's why.

The problem
I will ask these questions to help you draw your own conclusions.

What is the bottom row claiming to be a display of "how to do it right" actually implying?

• Is the purpose of a skateboard and a car the same?
• Are the people buying a skateboard, motorcycle and a car the same people?
• How likely will a person who just bought a skateboard upgrade to a car?
• Can you recycle your marketing campaigns?
• Will a great skateboard designer know how to build good cars?
• How many learnings from the last success/failure will help you do better in the next iteration?
• What % of the last iteration's product is "waste" in the new iteration, how much can be reused?

Pretty much every increment would require restarting the entire business from scratch: New customer segment, new experts, new design, new product. There is no constancy of purpose at all.
How likely will you succeed with that if you're doing that in a 2-week rhythm?

Fixing it
If you really want to do iterative development, here's how you should approach the increments:

• First, get some tires (not deliverable, but already a lot of work)
• Then an axis to connect them (can already carry something)
• Then an engine (automated propulsion)
• Then a chassis (safer to ride)
• Then windows (water/dirt proof)
• Then, paint the whole thing

Most likely, you'll continuously find improvement potential in one of the above areas before ever finishing, but if you can't get these things done, you're not going to sell cars.

But how many companies have ever successfully produced streetworthy cars based on their skateboard expertise?

So, the upper row actually makes more sense than the lower row (even though it's also wrong).

Trash this analogy. Get it out of your head. It's misleading.

Visualization tip: The "i" people

Visualization can help a lot in communication. While technical people can easily draw some UML or ER-Diagram, they quickly feel challenged when having to draw people interacting in different ways. But drawing people isn't hard. Here, I'll show you a way to draw people based on the letter "i". These "i-people" can be doing all kinds of things. 
There is absolutely no magic in there and it's a good way to lose the shyness of drawing people.


1 - draw a handwritten "i" base.

2 - draw the head. It's just the dot on the "i", but you use a circle:

3 - Use the arms to make the person do something. To stand still, just draw a straight line from left to right on the tip of the base:

Now, that really wasn't hard.
Next, you just use different line shapes for the arm, and your i-people can do quite a lot of things:

For this exercise, I've exactly copy+pasted the "i" and added different arms.
It's really not hard.

Just try it!

Agile Leadership - Buzzword Bingo

One of the newest buzzwords appearing in the agile community is the "Agile Leader". Didn't we spend decades preaching situational leadership and how every team member can be a leader?
Well, it seems like Larman's law #2 is taking effect and soon, every middle manager in line-oriented companies "doing agile" will be a "certified agile leader".
In the process, the term "leadership" and many others will be overloaded to be so devoid of their intended meaning that you'll wonder what they are actually supposed to mean.
Be prepared that your division manager agile leader will have a whole repertoire of terms to drive your agility.

So I just had some fun, created a Buzzword Bingo game for "Agile Leadership":

Enjoy!

Are you an organizational catalyst?

The newest buzzword in the agile community is "Catalyst". The Scrum Alliance considers being a "Catalyst" an essential part of being a coach and an agile leader. It's actually taken from the book "Leadership agility" by Bill Joiner.
It's always funny to hear coaches talk about the need to ask questions and reflect on your own behaviour, then doing exactly the opposite by unquestioningly adopting buzzwords. They have picked up something that seems to sell well and are now following in herd mentality. Since "agile coaches" are promoting something they don't even understand themselves, let me take some time to explain what a "catalyst" actually is!


The myth: "A catalyst speeds up a transition into a new state".
That's actually true, but you need to understand how a catalyst does that.
Catalysis is a highly complex chemical process with lots of constraints that one should be aware of when using the term.

No Philosopher's stone

A universal catalyst ("Philosopher's stone") that can make any kind of change happen does not exist.
Every catalyst is a "one trick pony" that can do only one thing in a very restricted context. In a different context, a catalyst will be useless or even an inhibitor. Do you really want to be good for one thing, and only that one thing?

Energy parity

The definition of a catalyst states, "In the presence of a catalyst, less free energy is required to reach the transition state, but the total free energy from reactants to products does not change"

This may be understood as "less energy is required". No: It means less energy is required to reach the transition state, but the total amount of energy to reach the goal does not change!

Let's translate what this means: The catalyst destabilizes the system in an otherwise stable state. Then, it channels the energy difference throughout the change process. All consumed energy is lost, and all the remaining energy must be invested before the catalyst is out of the system. The catalyst actually binds energy until the process ends.
The catalyst takes a massive active role in the change process. Typically, not much would happen without the catalyst. Every single aspect is being modified by the catalyst on more than one occasion.
The catalyst is an extrinsic change funnel, which in an agile context is equivalent to stating that the change is imposed on the target. A catalyst completely destroys autonomy.

Irreducible complexity

Catalytic reactions are highly complex. Scientifically, a catalytic reaction looks like this:

1. X + C → XC
2. Y + XC → XYC
3. XYC → CZ
4. CZ → C + Z

The same process, without a catalyst, would look like this:

1. Y + X → Z

The catalyst is an essential component in every stage of a catalytic process, and there is no direct relationship between start and end of the process, although the catalyst is not necessary for the process to take place. Not only is the catalytic process significantly more complex than necessary, it may be impossible to figure out the natural relationship between X,Y and Z if one has never observed the reaction without presence of the catalyst.
The catalyst becomes "irreducible complexity" and hides the simplest way to reach a goal.

Bottleneck

A catalyst "participates in the slowest step of a reaction, and rates are limited by amount of catalyst and its activity."

This simply translates into "The catalyst is the bottleneck of change."

Potentially unsustainable

A catalyst "does not change the energy difference between starting materials and products."

This also means that the energy difference between the starting point of the change and the endpoint thereof is independent of the catalyst. Catalysts can induce highly unsustainable change that would not have happened without them. Catalysts might even be the cause for creating an unstable system.

Value neutral

Catalysts also "do not change the extent of a reaction".

This is basically stating that the same result could have been achieved without the catalyst by investing more energy. Effectively, this means that the presence of the catalyst really only reduces the energy investment, but it does not add any extra value.

Change exempt

Let's close this discussion with the final straw: A catalyst, by very definition of the word, "remains unchanged after the reaction."

What this means: While the catalyst did put a lot of effort into the change, the catalyst ultimately was not changed. For the catalyst, the change was just a temporary thing that is completely brushed off, left without a trace.

Should you be a catalyst?

Let's sum this up: An organizational catalyst is someone who:

• Is a one trick pony potentially causing damage with their involvement
• Does something that could happen in different ways without them
• Starts processes that can't be terminated until all energy has been spent (i.e., removes agility)
• Interferes dramatically with others' autonomy
• Adds significant complexity which can no longer be taken out of the system
• Becomes a massive bottleneck and Single Point of Failure
• Hides the real change going on from those who are involved
• Does not learn anything from what they are doing

Decide for yourself.

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.