Alignment & Management

Alignment is an essential piece in the puzzle of an organization to be successful. There are vastly significant approaches of establishing alignment. Let us ponder two diametrically opposed philosophies of alignment. Rather than providing answers, I present you with two images and will ask some questions for your own reflection.

Scenario A

Managers create alignment by allocating assignments to teams

Let us ponder a few points:

• How likely will our Manager (M) get the Widget that is needed?
• How efficiently will the team (T) work on the Widget?
• How will S contribute to the organization – in the short term and long term?
• What is required to keep everyone aligned? Who needs to invest this effort?

Scenario B

Managers keep their hands off as long as the strategic direction is suitable

Let us ponder a few points:

• How likely will the Widget be exactly as needed?
• What happens to effectiveness when S joins?
• Which are the likely effects of having S join T? Consider side effects.
• What is required to keep everyone aligned? Who needs to invest this effort?

Comparison

Finally, let us compare the outcome of the two scenarios:

• Which approach will deliver the more valuable Widget?
• Which approach has lower total cost of ownership? Consider the costs of:
• Management
• Waste
• Delay
• Knowledge
• Recruiting
• Opportunity (for getting other things done)
• Which approach will result in a more stable company? Consider:
• Keeping alignment
• Profitability
• Risk of failure

Conclusion

Is active management intervention the best way to align an organization?
Draw your own conclusions.

Six simple ways to understand Scrum team maturity

When you're a Scrum Master, working an a new environment - with a new team, it's imperative to have a good understanding of the team's agile maturity. Why? Teams with low maturity need more  guidance - teams with high maturity need more opportunities to reflect. To not be the Elephant in the Glasshouse and spoil your relationship with the team early on, you need to understand how mature your team is before you act.

The Scrum Master's leadership style is based on the team's level of maturity

With this fairly self-explanatory model, here are a few pointers to help you determine how mature your new team is. Note that this is not a binary scale - it's more a gradient that can be anywhere and vary for different topics.

Problem solving

Mature teams have a working way of solving problems. Problems are not shoved under the rug, they are openly discussed and actively resolved. In all but the most special cases, the Scrum Master is not required as part of the solution.
Teams with a low level of maturity may choose to ignore known problems or require active intervention from the Scrum Master in the resolution process. In extreme cases, the Scrum Master needs to solve the problem for the team.

Collaboration

Mature teams are mostly focused on the shared team objectives. They arrange their activity and collaboration around delivering value to the customer. 

Immature teams tend to focus on the work of each team member. There are many handovers in the delivery process. People think in personal functions rather than business outcomes.

Getting things Done

Mature teams don't like to stack up undone work. They like to work on as few items as possible and get these done as fast as possible. They won't touch a new backlog item until their last one is Done.
Teams with a low level of maturity might shy back from "tough" work and put it on hold until more information becomes available or until the problem "disappears".

An easy assessment of the team's maturity is a quick glance at the Scrum board throughout the Sprint: Is WIP limited, how fast are items moving from "In Progress" to "Done"?

Process change

Mature teams constantly modify their ways of working. They continuously use controlled experiments to break their process in order to discover new, better ways of developing software. It's impossible to formally define their process, because by the time you'd jot it down, the documentation would be outdated.
Immature teams either meddle with their process without deeply understanding the impact of their action - or they are too scared to experiment without having formally approved the change in a Retrospective. They might even prefer a clearly defined process to follow and would rather master this process than make a disruptive change.

Ceremony behaviour

Mature teams run their own ceremonies and they get the necessary outcomes to continue working effectively. Immature teams need active facilitation and moderation - in some cases, even content guidance to reach the intended outcomes. Extremely immature teams will skip the meeting unless the Scrum Master actively invites them.

In general, ceremony conduction follows a bell curve: Learners spend less time, because they don't see the need, advanced practitioners invest a fair amount of time to maximize the effectiveness of the ceremony - while mature teams obtain the same outcome with significantly less effort, following the 10th Agile Principle of Simplicity.

Ceremony effort curve:

The Ceremony Effort curve needs to be clearly understood: For an outsider, there is little difference between a "Shu" learner and a "Ri" Grandmaster. Observing the team mechanics in detail and understanding the intended outcome very thoroughly is essential in determining whether you're encountering a mature team or not. Oftentimes, immature teams consider themselves mature.


Daily Scrum
Immature teams "report status" and "track progress". They are more focused on their portion than on the team objectives.
Mature teams use the Daily to sync each other and come up with the most sensible team plan for the next 24 hours.
Really mature teams don't need much of a Daily, because they are continuously planning and continuously syncing.

Refinement
Immature teams don't refine or delegate refinement responsible to the Product Owner: The Sprint Planning is often an unpleasant surprise for all those involved.
Mature teams refine in mutual interaction between stakeholders/customers, PO and team. They meet as often as necessary to guarantee enough "Ready" backlog for the next Sprint Planning.
Really mature teams don't need to refine, because they have mastered the art of delaying decision making to the latest possible moment. They are comfortable with lacking clarity until they actually start developing. The need to acquire information does not affect their development speed.

Planning

Immature teams are often befuddled at the intention of Planning. The typical beginner's planning looks like this: PO introduces Product Backlog items and asks "Do you have any questions?" (no). Then, the team decides what to work on, occasionally doing estimation and task breakdown. (Usually, the plan doesn't work out because significant items were missed.)

Mature teams use the Planning as an opportunity to explore intentions behind each item and come up with hard questions to challenge their own understanding of the request and how it should be implemented. They might argue over the solution, as there is not "one best way" to do things.

Really mature teams use the Planning ceremony to get a quick glance, as they are comfortable with delaying detailed decision making until they actually work on the item. They are clear on the intention and approach because of deep, shared understanding.

Review
Immature teams fail to hold Reviews or do so ineffectively. It's more of a Demo and approval session. In extreme cases, it becomes a blame session where stakeholders accuse developers of misunderstanding or developers accuse stakeholders of miscommunicating.
Mature teams use the Review as a tremendous mutual learning opportunity, gaining deeper insights into the customers' minds and enabling the Product Owner to add more value to the backlog.
Really mature teams don't invest much into the Review, because they continuously gather information about customer needs and satisfaction in real time.

Retrospective
Immature teams use the Retrospective as a small break from "real work". The outcome of a beginner's Retrospective is often an obvious change with marginal impact on the delivery capability. The question, "Why are we even doing this?" is quite common.
Mature teams dig deeply into their process to unearth hidden pitfalls and treasures. They take the chance to discover significant improvement potential in their ways of working.
Really mature teams use Retrospectives as a reflection space to find different ways of achieving a better outcome with less effort.

Interaction

This topic follows the same kind of bell-curve progression as the ceremonies.
Immature teams shy away from communicating with each other or the Product Owner. Developers somehow try to progress individually. Especially the Product Owner has very little touchpoints with the team - except for Planning and Review.
Mature teams communicate constantly with each other and the Product Owner. No question is too trivial or too difficult to ask - what counts is building up a common understanding. The team probably wouldn't even miss the PO during Review, as they already know the PO's shot at their results.
Really mature teams have a high degree of common understanding. Discussions start to center around  synchronization and innovation. The overall need for discussion might decrease when work is easy to modularize.

Summary

Look at these six patterns: Problem solving, Collaboration, Getting things Done, Process change, Ceremony Behaviour and Interaction. This will give you a fast and thorough understanding of how mature your team really is. You can adjust your own behaviour as a Scrum Master to accommodate the needs of the team.

What does a Scrum Master do during ceremonies?

I was recently asked the question, "What does the SM actually do in Scrum meetings, apart from facilitating" - so here is my view. It coincides with what I do, not with an absolute stance of "This has to be like this".


As Scrum Master, there are different modes I take during a ceremony. My "mode of operation" depends on the team's condition. My indicator of choice is maturity, which I consider a mix of ability, autonomy and motivation.

Teams of low maturity

Understanding of ceremonies is low. I'm lucky when the team even understands why we have the meeting, much less what is an effective way to get the necessary outcome.
Maybe I even need to start with a detour, explaining the purpose of the meeting, the approach and intended outcome. As facilitator, I dig into my stash of facilitation tools to keep the audience both focused and engaged.
Engaged groups don't need to be whipped into action, so my most important job becomes timekeeping. I like to give strict timeboxes on each activity, furthering the mindset "It's not about coming up with a perfect plan - it's about doing the best thing we can do within the available time."

For really immature teams, I will facilitate everything. I "give the voice" to people who want to say something, I sum up the outcome, provide a photo protocol and ensure that someone takes accountability of decided follow-ups.

In cases, where teams even have less subject matter expertise than I have (indicating that they are "stone age"), I might even involve in discussions by providing potential alternatives they can explore and cutting off rabbit trails.

From a leadership perspective, I will provide clear direction on the ceremony form and necessary guidance on content.

Slightly advanced teams

When teams already have a basic understanding of the ceremonies, I don't need to state the obvious. I might use a Refocussing Question, "Why are we doing this ceremony?" as an opener to start the ceremony and raise awareness within the team.
At this level, I don't facilitate as much as I moderate - providing a proper environment for the ceremony to take place and ensuring that the team has the necessary means to reach their goal.

I still take control over keeping the agenda by applying moderation techniques that help the team to reach the next point autonomously. I will hardly intervene. My main intervention will be an occasional thought provoking question to open up different alternatives.

From a leadership perspective, I will provide guidance on the form and support on content.

Matured teams

A matured team doesn't need me to do things for them anyways, so why would I? They own the meeting.
Of course, they might ask me to actively facilitate - for example - hot topics they can not reach consensus on. In these cases, I will support based on pull-principle. Other than that, I will sit back during their session, reflecting on the meta-situation.

I will mostly be looking for things happening that those who discuss are not aware of - such as people suddenly withdrawing, someone taking control over the meeting, elephants in the room and things. The insights I gain may or may not be necessary to help the team grow. It depends. When I observe a severe dysfunction, I might intervene with a question like, "Is there a specific reason you've abandoned Tim's idea?" and otherwise leave the field to the team.

After the meeting, my insights provide the basis for reflection among the team, either on an individual or collective basis.

From a leadership perspective, the meeting is fully delegated to the team - I provide vital support on demand or when inevitable.



Side note on leadership

The underlying model is direction-guidance-support-delegation, moving further with increasing autonomy/ability/motivation.

Summary

What I do depends on need. I spend time not only to conduct the meetings with the teams - I also invest into transferring understanding and ownership towards the team. The team themselves needs the outcome and when they have learned effective ways to obtain that outcome without assistance, there is no need for the Scrum Master to impose anything. Over time, the Scrum Master becomes more of a reflection beacon than an actor.

Getting to that point can take a long time. In an "orange" organization, this is definitely much harder to attain than in a "Teal" Organization.

Is SAFe just another name for Waterfall?

A strong accusation against SAFe is that it's only a different name for "Waterfall", i.e. while the structure and names are different - the underlying process (and corresponding problems) remain unchanged - so let's clarify how SAFe really changes your development process.

The Waterfall

Does SAFe permit you to continue running a dysfunctional Waterfall? The classic "Water-Scrum-Fall", a widely spread phenomenon:

The Water-Scrum-Fall: "Agile" is something else.

 Can you do that with SAFe? Yes. Then again, you'll be hard-pressed to find any type of statement that SAFe is actually encouraging this. So - why do people think SAFe is just Waterfall reloaded?

1. The PI Planning

As described in another article, the reason why there is a "PI Planning" is not to maintain the Plan->Build->Run cycle (aka. "Waterfall"), it is to create common understanding. PI Planning does not separate "planners" and "doers": Given a prioritized list of abstract, high-level stories ("features"), they decide autonomously what to do while exploring the "Why" together with others. The detailed "What" and "How" is deferred to the latest possible time where it makes sense - i.e. the Iteration (Sprint) Planning of the iteration when teams actually get around to the topic.

Highly empowered, autonomous teams make their own decisions regarding "What", "When" and "How". Managers serve as facilitators, not as authors. Teams propose the most feasible ideas. Teams agree with each other on the objectives. The output is a prioritized, value-based list of objectives for the overall PI - and an intitial short-term backlog for each team. Everyone knows full well that the backlogs can and will change, both in content - and in order. The teams commit to work towards common goals, not to complete specific activities.

PI Planning can not be compared at all with classic project planning.

2. Three-month increment

One of the biggest gripes with Waterfall is Three-Month (or slower) release cycles, inherent to the system: Typically, a stressful analysis phase is followed by a painful development phase, culminating in an excruciatingly painful test phase, where developers are fixing the problems of the current release while already working on the next release.

SAFe operates in small, integrated cycles and suggests applying Test-First implementation. As discussed in an article about releasing, SAFe builds on "Deliver Anytime", taking advantage of fast, integrated learning cycles. Creating batches of work, then sending them through a development process pipeline is not part of the SAFe model. In each Iteration (Sprint), teams refine, plan, build and deliver individual stories and small portions of value. There are no separate "Analysis / Development / Test" phases in SAFe.

A SAFe team should preferrably be arranged to be cross-functional, allowing a single team to ideate, design, implement and verify customer value autonomously. This reduces Work in Process (WIP), handovers and delay.

The PI Increment can not be compared with a Quarterly Release as the underlying process is not the same. 

3. Systems Team

A specific team deploying and operating the built product ("Operations") is a common pattern in Waterfall organizations. The consequence is a "throw over the fence" attitude ("works on my machine") and animosity between developers and operations.

SAFe strongly encourages DevOps practices, bringing the responsibility for operations directly into the teams. The buzzphrase "You build it, you run it" is also applicable in SAFe. Throwing stuff over the fence is not encouraged, as this creates communication gaps and a desync between work in progress among teams.

Then - what is the purose of the Systems Team?

Infrastructure
Teams are potentially challenged to provide a well-working delivery infrastructure, such as deployment pipeline and operating environment.
Especially early on in a transition, it makes more sense to have specific experts deal with infrastructure so that development teams can get around to deliver value and not constantly be distracted by working on base technology. As the Agile Release Train (ART) matures, the infrastructure stabilizes and the amount of maintenance work should decrease to a point where teams can handle it.

Solution Testing
Although this should not happen, occasionally developers or large systems are so focused on their work that they lose sight of the overall process. The question "Who maintains the Big Picture?" sometimes remains un-answered. In cases where developers work on individual microservices and lose sight of the end to end customer facing processes, there needs to be someone to ensure that the customer can actually use the new increment. This may require both exploring the product and automating standard test scenarios. Similar to the point above, as the ART matures, the amount of necessary manual oversight and undone test coverage should approach zero.

Long story short: The Systems Team is not doing work in a different phase. They do work that is outside the other teams' Definition of Done.

Summary

SAFe requires dramatic changes to the way developers work. While not everything is different from how things were done in the past, an ART works radically different from Waterfall. How massive those differences are - depends on how agile the teams are. Maturity and autonomy are the keys to success.

The idea behind SAFe's PI Planning

One of the key ceremonies in SAFe is the "PI Planning", where teams come up with an aligned plan for the next 6 iterations. Why do we have this special ceremony?


Let's start with the reason why SAFe's PI Planning has been designed, and what happens during PI Planning:

1. We don't plan for others. The teams create their own plan. Handovers are discouraged.
2. We don't plan activity. We plan objectives. This provides enough transparency for everyone. 
3. We don't schedule the details. We sort the objectives in descending value order, then put the most valuable thing first.
4. We don't focus on having a plan. We focus on achieving a common understanding. Unexpected things happen and our estimates are usually misleading. That shouldn't stop us from having a thorough discussion about what, why and when.

Objectives over Stories

More important than defining the individual backlog items (i.e. user stories) is the definition of mutually agreed upon objectives, i.e. what the teams desire to accomplish - and why their work contributes to the enterprise goals. 

While stories are created for features during PI planning, the main purpose of stories is to discover the scope, range and purpose of the feature in collaboration within the teams, with Product Management - and Business Stakeholders!

The Stories that are created are then summed up in terms of objectives, i.e. outcomes that the teams want to obtain. The value of these objectives is discussed in business terms, with the intention that developers have a clear understanding of why certain goals are more valuable than others.

This shared understanding of common goals is probably the most important output of the PI Planning, because it keeps expectations closely aligned in the following months.

Catch inconsistencies

When teams place their objectives on the Program Board, this forces them to consider whether their objectives are consistent: within themselves, with each other, with those of other teams, with time available, with extrinsic factors (such as: market constraints, vendor delivery etc.). With simple red strings, the Program Board shows dependencies - which themselves are pointers to a high risk of becoming inconsistent.

The visualization of planning inconsistencies helps teams to steer clear the pitfall of inconsistent delivery later on. 

While a part of the purpose created by the program board is indeed to get a clear understanding of what will be done roughly when - the biggest value is to have a consistent big picture, shared by everyone on the Release Train!

Planning horizon

A big question for many agilists is: "Why do you plan 3 months ahead?" - This has mostly to do with U-Curve optimization. 

We don't do this because we consider it's a good idea, it's more likely the most feasible thing to do, especially in environments with distributed teams. Our goal is to minimize batch size. 

For an organization that is currently transitioning from a legacy development model that has a more-or-less expressed backlog for the next couple years, moving from a "We just do what we feel needs to be done" towards "We know exactly why this thing is Priority 1 and how we can contribute" is a massive leap forward.

Think ahead

The 3-month planning horizon creates a slowly depleting team-levelbacklog for each team. Based on the one central product backlog, every team backlog has been clearly optimized to maximize the value this team delivers. When a team fails to meet their objectives, they have a clear understanding of the value gap - and can use this to communicate with other teams to maximize overall value delivery in a delivery Inspect+Adapt.

The team backlogs are not exhaustive. They contain value-ordered lists of those stories that are known upfront. The teams still refine their backlog continuously throughout the PI. Items from the backlog may be added or removed as new information becomes available. 

The defined PI Objectives help the teams place new items into an appropriate position in the backlog and provide a useful guideline for value delivery. Within the scope of the defined objectives, the teams gain full autonomy on how to build things without the need for frequent synchronization and coordination meetings.

Optimizing PI Planning

There are two questions we should ask about the PI Planning horizon:

1. How can we reduce the overhead associated with planning - so that we can plan together more often?
2. How much value do we lose by having to resort to mid-term planning - and what can we do to decrease the value decay?

If you can get all the teams to plan together every month or even every Sprint, then by all means - do that! The planning periods will be shorter, product value will be higher and mutual understanding will be better.

Summary

SAFe's PI Planning is the first step in an evolution away from Big Upfront Planning, with the intention that teams gain full control over their work, while providing the required stability for effective, valuable collaboration. 

As your organization becomes more agile, PI's might become more fluent and iterations shorter. As mutual understanding grows, the need for clarification will decrease. Plannings become smoother and faster over time. 

As you learn how you can maximize the value of planning, the nature of your PI Planning will adapt accordingly.

What will remain is the need to have a common understanding by planning together frequently.

Why project organizations are doomed

We talk a lot about why we should shift from organizing around projects to stable teams. In Scrum trainings, we use the Stacey Diagram and explain the need for agility with the inevitable Unknown that we encounter. From that we conclude that Waterfall projects with pre-planned structure and approach are doomed to fail. The basic assumption can remain intact that if we had more certainty, projects would work out. And so, we basically still assume that project work is fine - as long as it's done in an agile way. In this article, we will discuss that a project organization is doomed - agile or not. You have no choice except to change how you organize.

Prelude

The Want-Need-Matrix

Let's start out with a simple matrix I borrowed from Marshall Goldsmith. Well, I took the liberty of simplifying it even forther than described in his book, "Triggers", because it's enough to serve our purpose for this article:

The Need-Want Matrix

On the vertical axis are Wants, on the horizontal the Needs.
In the top right we see: We need and want success. To not open up a barrel, I am not defining "success" in detail. It can mean different things to different people. Whether that is recognition, money, gratitude or whatever - we long to have those things, and we need them for our own well-being.
On the upper left, we have what we want, but don't need: distraction. In this case, anything that distracts us from success. The worst kind of distraction is instant gratification, ignoring long-term success to have a temporary High right now. Arguments are another distraction: Fault-finding without problem solving distracts us from proceeding.
On the lower left, we have what we neither want nor need: trouble. Trouble is the opposite of success - distress, losing money, being shamed, ostracized or whatever.
Nobody really wants rules. We just need them to prevent trouble. And they help us keep on track, so that we can achieve success.

The Vicious Circle 

The vicious circle: Distraction, trouble, distraction ... it never ends!

Distraction wouldn't matter nearly as much if it had no impact. This is rarely the case. Typically, the result of distraction is that something slips. And when something slips, that means some kind of trouble. At the minimum, we need to catch up. Or we start making excuses - which only end up causing further trouble. Once we're in trouble, we typically try to get out of the troubling situation. The easiest route is displacement activity - yet another distraction. And so, we end up "fixing" the problems caused by distraction with distraction. Now, how do we get out of that?

The virtuous circle

Moving to success requires rules

Once we're in trouble, we can deflect - or we can improve. We typically set rules to avoid the distraction that caused the trouble.
It hardly makes sense to create rules for every possible distraction, so rules are typically reactive. We see the virtuous circle: We got distracted, we took the hit, set a rule and move forward. Like this, we constantly improve.

Don't take success for granted

What got you here won't get you there!

Be alert: Just because you're successful, doesn't mean you remain so. At any point in time, even currently successful people can run afoul of falling into distraction. There are many reasons why this may happen. One of them being that your environment changes constantly - and that means that today's success may be tomorrow's failure. By continuing to do what you did previously, you might actually be distracting yourself from succeeding in the future!

Keep your rules updated

Sticking to helpful rules keeps you on track

By keenly observing our rules and updating them as necessary, we remain in the success dimension and avoid distractions, consequently - trouble.

Adverse Rules are devastating!

Adverse rules that prevent success!

Sometimes, we set up rules that not only don't prevent trouble - they prevent success and cause the trouble we're trying to prevent!
Once we have adverse rules in place that we can not simply break, our only way of avoiding trouble is to remain in the "Distraction" quadrant.

The problem of projects

A project is usually defined as a specific endeavour to be accomplished within a specific time at a specific cost. Companies do their best to align project objectives with business goals, and therefore, overall success. Then, they task a Project Manager to meet the project objectives - deliver the defined result in TQB.

Same goal, different goals

While the project's stated goal is part of the corporate goals, the goals of the project are not the same. The goal of the project is not to succeed as a company - it is to meet the predefined objective in TQB. The so-called "Iron Triangle" is usually a bit softer in one or two corners, and a Project Manager will optimize to meet the Primary Objective (i.e. deliver on a specific date - or prevent budget overrun) at all costs.
Suddenly, the presumed goal (the Business Objective) is replaced with a different goal - meeting the Project Objectives.
We call this a "distraction", and now our project organization is directed towards a distraction.

Favorable rules, adverse effects

A Project Manager is always expected to do their job properly, i.e. deliver the stated objective in TQB. As their success is based on their Primary Objective, they will create a set of rules to ensure their Primary Objective.
When a developer within the project has the option of working towards the business goal, in conflict with a Project Rule, the developer will be constrained by the project rule. The rule becomes an adverse rule from a systemic perspective.

Perverse incentives

Project rules typically include things like status reports, status meetings, timesheets and many other things. Breaking any project rule will trigger a project investigation, putting the developer's behaviour under scrutiny. This means that the developer will have even less time to work towards the business objective - which means they are in trouble. To avoid breaking adverse project rules and ending up in trouble, developers can only follow project regulations which are a distraction from business success. 

Staying out of trouble by causing trouble

As we discussed in the Virtuous circle, when a distraction is encountered, the only way forward is to accept the trouble and improve the rules. When adverse rules are cast in stone, moving into trouble is no progress. A developer has no option of getting out of the trouble domain, except by staying out of the trouble domain in the first place. Being in the distraction domain, the only way of not getting into trouble - is by staying distracted!

The consequence of distraction is trouble, and so people are shoving a whole bunch of trouble under the rug, hoping it will never surface. Business success is far out of reach.

Summary

Project organizations suffer the malady that a project has it's own goals, which distract from business goals. The rules that create a project structure result in a condition where distraction, i.e. avoiding business success, is the only desirable state that can be attained - even when the project runs perfectly!

A company can not succeed until they break this vicious circle. This means they need to abolish the rules required to run a project organization. This means that the project organization will no longer function.

Failing with a project organization is not the fault of project managers or those initiating the projects. It is an involuntary side effect of running projects.

You need to move away from project oriented structures towards product oriented structures as soon as you can.

How SAFe approaches releasing

While a Program Increment spans 3 months, While at the end of these 3 months, there is a "Solution Demo" where all Release Trains demonstrate a Working Product, SAFe suggests "Release Any Time". This is not to be confused with "Release at the end of every increment". Let's clear up what the intention is.

Developer perspective

One of the biggest plagues of Waterfall software development is the "Integration phase", where developers bring together the different pieces of work and try to patchwork it into a shippable product. Martin Fowler described "Integration hell" and the corresponding solution, Continuous Integration, a long time ago. SAFe suggests applying Continuous Integration, combined with scrutinous test automation, on a developer level.

Every developer should aspire to keep the product shippable at any time. After every commit, the product should be "done" in regards to the work invested up to this point. There is no place for "loose ends".

Team perspective

Every team works on their specific stories and objectives. Whenever developers feel that they are ready to deliver a specific piece of work, maybe even just a fragment of a user story, it's up to the team what to do with the result. SAFe encourages delegating Micro-Decisions, such as whether to release the new "Search" function for our Website, directly to the teams doing the work. 

In the same breath, teams should have both the authority and technical capability of delivering their value when they feel is the right time. Continous Deployment is a wonderful way of accomplishing this wherever possible.

Release Train perspective

The Release Train, a "team of teams", builds Features - major blocks of customer value. In some cases, these features do require a lot of upfront work and big-batch releasing. For example, "The new iPhone" requires "a new iOS", "a new battery" and "a new chassis": You can't just deliver the new battery whenever you want. It's just a new feature that has no market value until it can be integrated into a shippable product. And this "integration" is not just software level. It includes setting up a physical production chain - and potentially tons of legal paperwork that could take months to complete: That's just not what you do 27 times a day.

The decision to insert a completed major feature into the current product is beyond a single team's sphere of control. The Release Train must be ready and overall willing to deliver the product with this new feature. This does not mean that the date is either preplanned in complete disregard of development reality - or that the feature sits as inventory until a PI end date is reached.

This is where PI planning is a major boon: When teams need to collaborate on big batches, it does make sense to put the product milestones onto a common plan, so that everyone knows what needs to be done by when.

Value Stream perspective

In some cases, the product development is so massive that multiple Release Trains need to collaborate. Resorting to the example that Mike Cohn also uses, of developing an Office Suite, the Train in charge of the Word Processor can't simply decide to release "The New Office". They can deliver features into Word, they can deliver bugfixes - but they can't control the entire campaign surrounding Your Office.

Decisions to bring new Capabilities to the market are made on the level where the different trains in the same value stream come together. While product releases are made completely independent of cadence, the Solution Demo is a good way to give and receive feedback regarding whether it makes sense to proceed with releasing.

Portfolio perspective

In exceptional situations, even a completed product needs to be kept off the market for maximum effect. There may be strategic appointments defining when a product needs to hit the market - no sooner, and no later. In these cases, even the Value Stream has no influence on releasing. An example could be a government contract to deliver a new Public Security Monitoring application. While demos, piloting or potentially even localized initial trial runs of individual features and capabilities are well within the ability of the teams, trains or value streams - releasing a major milestone into the market comes with a lot of media buzz and the potential for devastating repercussions. 

In such extreme scenarios, Epic batches may need to withheld from official release despite internal agreement that go-to-market is possible.

Summary

Releasing in SAFe follows the 9th Lean-Agile principle, "delegating decisions to the lowest possible level" - encouraging the release of value at the earliest possible date where it makes sense, reaping value as soon as possible and maximizing opportunities for feedback learning. SAFe does not  encourage big batching, yet it provides a clear approach to dealing with situations where batching is inevitable.

Common misunderstandings of SAFe

SAFe is becoming increasingly popular - and with it's popularity, we encounter the issue that people with a superficial understanding harbour inaccurate concepts about what SAFe is or does. Here, we want to debunk a few of the most common misunderstandings. There are also others, which we will discuss at a later time. 

#1 - SAFe is too ...

A common issue around SAFe is that allegedl, people consider that it is ...

• Heavy
• Complicated
• Complex
• Restricted
• Restrictive

Regardless of which of these are bothering you, first consider the following: SAFe is a framework intended to aid you on the journey of developing highly complex systems in a dynamic marketplace. If you can do that with a single team, then - by all means, do that. SAFe is not a way of making simple things complicated.
When you are dealing with a complex, adaptive system, then any simple solutions will be snake oil - based on wishful thinking. SAFe does not claim to dissolve the inherent complexity. On the other hand, it reduces the unnecessary complexity induced by legacy organizational structure.
SAFe does become restrictive and constraining when it comes to structure in the same sense that Scrum does. SAFe discourages bloated, inefficient structures without customer value. In SAFe, there is no place for complex reporting processes, time-squandering status meetings or wasteful accounting structures.
SAFe encourages optimizing structure and processes constantly, applying Lean and Agile principles. Many people say that SAFe, at it's core, is really just plain common sense, even "too obvious to be special". Except that too many organizations don't apply common sense - and don't see the obvious.

#2 It’s just another name for Waterfall

Common arguments include:

• Each PI is a Waterfall
• SAFe is just another PMBOK style waterfall.
• It’s just RUP Reloaded

The basic premise of the Waterfall is a phase-based model, where analysis is succeeded by design, by development, by test, by releasing. While SAFe considers all of these activities as useful, it neither prescribes doing any of them in a specific fashion - nor does it suggest these be done sequentially with an implied handover process.

SAFe supports the continuous delivery of Working Products, within each PI - within each Sprint - and within each team. SAFe's delivery model is highly inconsistent with a phased model.

The PI is an abstraction layer of an iteration. Unlike a traditional program, there are no phases assigned to Increments. Every Increment results in a Working Product Increment, and at the end of each increment, the "Proceed/Stop" decision is based on inspection of valuable deliverables. Artifacts like documentation or un-integrated code are not considered value.

While SAFe has so-called "Programs", a SAFe Program is not a classic large-scale Waterfall project. A SAFe program is, first and foremost, a larger group of people working together towards a common vision. It does not imply sequential phases or separations of concerns.
SAFe has specific suggestions how to get started and be successful in a very short period of time, the key idea behind SAFe's program structure is this: As organization size increases, non-value added coordination also increases (i.e. anti-scaling). Therefore, SAFe suggests an organization both in terms of structure and process which significantly reduces non value adding coordination.

SAFe does permit you to integrate with a Waterfall organization either on lower or higher levels of abstraction, yet this type of integration suffers from the same maladies as a Scrum team would suffer when being forced into a Waterfall mode of delivery. SAFe intergration with Waterfall is possible, albeit wasteful and extremely risky. Both the waste and risk are endemic to the Waterfall and transferred onto SAFe.
SAFe encourages abolishing Waterfall structures as fast as possible and suggests converting the entire Value Stream towards SAFe in order to minimize the impact of Waterfall practices.

#3 - SAFe doesn't fit

People are quick to dismiss SAFe before understanding how to fit it into their organization, for example:

• We are too big / too small for SAFe 
• SAFe has to be tailored to fit
• We have to modify SAFe so that it works
• SAFe processes do not fit into our organization

Let's start by stating the obvious: SAFe is a scaling framework. When you can avoid scaling, please do that!
Even when you aren't really scaling, the SAFe values, SAFe principles and SAFe mindset are useful. Of course, you won't be using SAFe structures and processes to solve a non-existant problem. SAFe is a way to approach the problems you already have and it's excruciatingly good at highlighting where they are.

When it comes to "too big", SAFe is probably the framework that has proven to work with the largest organizations of all scaling frameworks. The Value Stream layer, introduced in SAFe4.0, basically allows you to organize thousands of developers working on the same product. If you think you go beyond that, it is more likely that you only think you need so many people because your organization is so ineffective - not because your development challenge is so big.

There is significant danger in modifying/tailoring SAFe: SAFe follows the Shu-Ha-Ri learning principle. At first, do the motions until you understand - then you adjust the practice to get better results - finally, you transcend everything to obtain the same outcome without the initial motion.
For companies new to agile, it is highly recommended to first learn the basics before jumping into modifications. Just like in Karate, you don't go into a Dojo and tell the Sensei "Well, I like this Karate thing - but we need to modify it a bit so it suits my needs" - you need to get a grip on SAFe before meddling with it. The odds that you are modifying something that is actually essential to success increase with lack of understanding.
An expert agilist would definitely approach SAFe differently from a beginner, yet it is often self-proclaimed "experts" that do the darndest things.

SAFe has been proven to work in thousands of companies across the globe, spanning all kinds of industries. While it is possible that your company is such a special case that you just can't make use of SAFe, chances are that in these cases, neither is any other agile framework, including Scrum or Kanban.
Most likely this means that your optimization goals are not compatible with the following common optimization goals: Value, Time-To-Market, Customer Satisfaction, Effectiveness, Learning. In that case, SAFe has nothing to offer.

Some organizations are already so agile that SAFe is a step backwards. Congratulations! You're already in the top 0.1% of your industry! Keep it up. We'd like to learn from you. You may still refer to the vast experiences collected by SAFe to get some ideas and simply grow and improve on what you're doing.

#4 - SAFe isn't real Scrum!

Here's some common statements:

• SAFe does not include Kanban/Scrum
• SAFe dilutes Scrum/Kanban
• SAFe doesn't support Continuous Delivery

Let's start with the simple things first: SAFe encourages using Scrum or Kanban on team level. Unlike Scrum itself, it's not prescriptive in stating "You MUST do Scrum or you're doing it wrong!!!!11oneoneeleven". When teams are more comfortable with one or the other, they have options. SAFe is equally compatible with either. SAFe's main constraint here is that the teams need to be able to integrate continuously and should be cross-functional.
While this implies that it's possible that you have a SAFe implementation without Scrum at the team level, SAFe actively encourages at least trying out Scrum first.

A little more challenging is the topic of "diluting Scrum". There are modifications to Scrum, based on the idea that a team is not fully autonomous when they are merely a component within a complex system. Pure Scrum has nothing to say about the interaction of teams when interests are in conflict. SAFe redefines the Scrum Master as focusing more on the team, accepting that issues within the organization at large might overburden the Scrum Master.
Scrum equally has no suggestions when the product itself is so big that one PO can not both maintain the entire product and be sufficiently available for all teams. SAFe attempts to provide a meaningful way forward, stating that final product decisions are - just like in Scrum - single person (not committee) decisions, effectively de-valuing the PO role as product/value focussed person within the team - putting a PM in charge of what we'd typically call a "real Product Owner".
The principles and values of Scrum are retained. Similar statements would apply when a team chooses to apply Kanban, except that SAFe purposefully considers the roles of Scrum Master/PO vital to team success - so SAFe suggests having PO/SM even when teams use Kanban.

Continuous Delivery is clearly supported by SAFe, as are other XP practices. While SAFe accepts that for some organizations, Continuous Delivery is still a huge stretch, SAFe encourages these companies to set "Be able to deliver any time" as a key goal for value creation.

#5 - SAFe isn't Agile

Some people claim that SAFe does not manifest agility. The arguments are these:

SAFe equals Big Bang releasing

SAFe is Non-Agile and doesn't support the Agile Manifesto.

The "But it's not agile" guns are quickly pulled and fired, in classic Western Style "Shoot first, ask later".

SAFe acknowledges that large products, such as "The new iPhone" are typically released as major updates, including big and costly upfront marketing and sales activity. At the same time, SAFe encourages the continuous, fast delivery of value both for commercial and innovation reasons.
Regardless of which approach to releasing is suitable for your specific product, SAFe is fine with that. While frameworks like Scrum are completely neutral regarding large-scale effects such as "Super Bowl", SAFe suggests putting major commercial events on a calendar, then planning potential scope around these events to leverage maximum business value. This idea is not conflicting with the continuous and early delivery of value.

In regards to the Agile Manifesto, SAFe emphasizes the Agile Manifesto equally - or even more - than frameworks like Scrum or Kanban. While agility at scale is significantly more complex than team-level agility, SAFe acknowledges that both the values and principles of the Agile Manifesto are valid. A thorough understanding of - and support for - agility is a prerequisite to succeed with SAFe.
A culture that does not support the Agile Values will not succeed with SAFe. Let's just be brutally honest here: That kind of culture will not succeed with agility regardless of framework or approach.

Conclusion

Well, that was round 1 of SAFe misunderstandings. There are more to discuss later.

SAFe does not claim to have all the answers. SAFe is a good way to get started on your journey to Enterprise Scaled Agility, and "Here's something you can try" is better than "Well, you have to find out ..." for many people. After introducing SAFe, you will constantly inspect+adapt to discover better organizational processes and structure.

Think about why you hold specific reservations about SAFe. Maybe the problems are caused by your perception of SAFe, not by SAFe?

Denying requests without saying "No"

My recent post about why saying "No" or "But" might be avoided spawned the question: "A Product Owner should better say NO quite frequently". Based on my experience, here are some tips for a Product Owner to deny a request without actually resorting to "No". I've been using these kinds of statements for years, so this is a small collection of keeping your product in shape while staying positive.

How exactly does this idea fit into our long term strategy?

Any request which is not yet in the backlog is not worth considering in the light of the current strategy. The burden of proof to the contrary rests on the stakeholder rquesting something new.

The Product Owner should be very clear about the product strategy. Requests that either conflict with this strategy or are irrelevant to the strategy have tremendous impact. While the PO can explain the current strategy to the requester, it is the responsibility of the requester to convince the PO that this item will actually support reaching significant strategic goals faster. Tools like "Impact Mapping" are great ways of doing this visually.

You just need to convince the other stakeholders. 

"Can you ask the others to approve your request before I do something that conflicts with theirs?"

Especially in corporations, there are often many stakeholders with conflicting interests. As soon as the PO puts an item into the backlog at a certain priority, they need to justify to all of these parties why this item has been placed there - especially since it means that all stakeholder requests of a lower priority will be either deferred or descoped. Why would you want to be in that position? Just let the requester go into the line of fire. Tools like "Buy-a-feature" may be invaluable to do this effectively.

This is probably going to cost you about 10x as much as you'd want it to.

"I just asked the team, this is much bigger and more expensive than you thought".

Random ideas can quickly congest the path on your journey to maximum value. Often, stakeholders have little or no understanding how much work a "small favour" actually causes. Since the PO also doesn't have all of the information, it is very risky to commit anything behind the team's back. I have experienced "just a few days" items become severely impactful on strategic milestones, and that's not something you want. The most effective way to avoid cost/effort/timeline traps is applying the very simple tool "Ask the team".

We have limited WIP.

"Which of your requests should I scrap in order to put this into the backlog?"

People are good at coming up with ideas to keep others busy. Many people are just very bad at understanding that WIP Limits are pretty much essential to keep getting things done and delivering a valuable product. You need to exercise caution to avoid becoming a "request manager" tracking endless lists of things that have no chance of ever getting done. You don't want become responsible for reporting status of items that aren't being worked on - and you also don't want to justify why you're not getting more things done than the team can do. Make it the responsibility of the stakeholder themselves to get gray hairs over figuring out which things they really need.
A very simple tool is to have a Visual Dashboard with strict WIP limits. If that doesn't help enough yet, assign specific WIP limits to each stakeholder - for example, 3: Requests are only accepted once something got done.

Our backlog is a prioritized list.

"Do you have any data that warrants putting it into a position where it has a chance to be done in the next half year?"

Why should you, as Product Owner, waste your precious time to figure out whether something is worth doing when even the person making the request can't be bothered to do that? You are a bottleneck. Delegate as much work as possible. Avoid feeling pressured to put something at Priority 1 just because the Group CEO just had another great idea. Arrange your backlog items so that they make sense from an economic perspective. You can keep items off the list that aren't healthy for the company with the tool "WSJF" (Weighted shortest Job First).

Based on the current state of the backlog, this has no chance be done anytime soon.

"It won't be done within the next half year. I suggest you come back in about 5-6 months, if it's still important."

Why would you even bother to track things so far into the future that it's more likely your product won't fit to the idea any more than seeing these things actually get done? If the idea is good, it will come back later. If it isn't - well, why is it important to keep?
Once a request is not sufficiently valuable to get done anytime soon, it is very likely that this is the actual value of the idea. As our product grows, our ideas should actually get more valuable over time - so ideas that already aren't valuable enough now will probably never be. By keeping a rough idea how much work is currently in your backlog, you get a rough idea when the item at position 20/30/50 will be done. Any item moving to the bottom of the backlog, being beyond a predictable horizon, wastes your capacity as you need to think about it all the time.
You make your life as PO significantly easier by capping the backlog size to contain roughly 1/2 year of work.

We discuss things when they become important.

"We will consider your suggestion at an appropriate time. Thanks."

And 'now' is not that time. This means nothing short of 'This item is wasting my time', it's just phrased a little more polite. 

At any time, the Product Owner should maintain focus on the top few priorities in the backlog. Anything that is not there reduces the odds of success - who would want that? 

Avoid getting dragged into meeting madness for things that may never happen. If others want to discuss these things - fine. Let them. Once they have overwhelming evidence that you should invest time, go ahead. Until then, feel free to assume that your product is doing perfectly fine without adding the request.

Resort to Backlog Weeding. Treat all ideas that aren't worth doing anytime soon as weeds.

Summary

Being a Product Owner and staying positive towards all requests is always a tightrope walk. 

Use the approaches and tools described in this article as stepping stone towards respectful product ownership in challenging environments.

Three words that poison every conversation

Nearly a decade ago, my Change Leadership trainer already taught me a valuable lesson: How a few simple words can destroy meaningful communication: "You're right, but ...", "Yes, but ..." "But you need to see ...", - the memo stuck: "Get your But(t) out of my face". Not until I read Marshall Goldsmith's "What Got You Here Won't Get You There" did I start to become conscious of how often this phrase and others are used.

A small dose is enough to poison the conversation.

But, No, However

Marshall pointed out all three terms as ways to turn any conversation into some sort of war. When I first read this, I remembered the good advice I received so long ago - and started to monitor these terms and how they are being used.
They are toxic because all three of these terms have the same meaning: "I know something you don't - I am better than you." The healthy exchange of ideas on face level becomes blocked as soon as one person starts elevating themselves above the other. What follows is often a toxic vindication of standpoints.

Why do we say these words?

Few people actually mean to poison a conversation. When I first started looking at myself, I became conscious of what I was doing. Maybe you want to re-read my blog articles with this in mind. You can pinpoint fairly exactly when I started reading Marshall's book. Before that, I was simply unaware of my own use of language. I never meant bad. I was simply un-aware. So, when you realize you're but-ted out of a conversation, the next thing you should realize that this is most likely happening because the other person is unaware of what they are doing.

What to do about it?

For me, it became a tedious exercise of monitoring every single sentence I wrote. Whether it was a blog post, a LinkedIn reply or even a simple mail response, I started double-checkeing. I re-phrased every sentence I had poisoned. I am still doing this today. Do I still use these words? Yes. What I do try is to use them consciously, when needed. Does it make sense to avoid answering a binary question directly? No. See. You got me. I did it on purpose. I know what I did - and why I did it. I had a chance to reflect on my own words to improve my own communication.

How about spoken language?

Written language is significantly easier to monitor than spoken language. When I first started observing my own speech behaviour, I was all full of the first and second, resorting to the third in a feeble attempt of evasion when I caught myself. Learn to think twice before speaking. Form your answer in your head. Be a bit more constricted on the words you let out of your mouth. Change is hard. You will fail. More than once. Getting better requires being conscious of what you do - and not being too hard on yourself. Just sufficiently hard to avoid falling back into old habits.

Conclusion

Do your conversation partners a favor. Eliminate the toxins of "No", "But" and "However" from your vocabulary. Start becoming a more amicable communicator today!

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.