Where to put the Business Analysts?

A common question that needs to be answered during agile transitions is, "Where do we put the Business Analysts?"

In a traditional project organization, it's quite common that they receive orders from Product / Project Management, create solution designs and hand these over to development teams, this is a poor approach for agile organizations.

Avoid: BA working for PM

We often see that the BA is a go-between for users and Agile Teams, or even for Product Management and Agile Team, both of which are done in the name of efficiency at the expense of quality.

There are numerous highly dysfunctional antipatterns associated with this approach, i.e. things that cause more problems than they solve, including, without limitation:

Antipattern

Problem

Works as Requested

When users ask for something suboptimal, that's what they'll get, because developers are unaware of the user's real need, and the Product Owner also lacks the necessary information to acknowledge alternate solution proposals.

Works as Designed

When Business Analysts make invalid assumptions about the technical solution, developers will strugge to implement based on their design, since developers are not in a position to challenge the underlying assumptions.

Dysfunctional PO

When a PO gets prioritized, "must-do", fully analyzed designs that need to be implemented, their role becomes dysfunctional. All they can do is "push tickets" and fill in templates of work. The PO's main function is invalidated. 
Product Owners struggle to find purpose and meaning in their work, and in such a setup, it's no loss to eliminate them entirely.

Telephone Game

The amount of information lost when users talk to analysts who talk to product owners who talk to developers is staggering. The amount of communication overhead and productivity loss caused by this setup potentially outweighs the benefits of doing business analysis outside the team.

Bottleneck

Separating the BA out as a special function typically makes them a bottleneck. When push comes to shove, incomplete designs are handed to development in a hurry, which often causes more trouble later than the amount of work the BA wasn't able to complete.

Try: BA is part of the Agile Team

An alternative, significantly more agile, approach is to make the BA part of the agile team they're doing analysis for. 
In this setup, the BA is a dedicated member of the Agile Team they're working with - figuring out both the customer needs in the solution, and the developer needs in the design. Their accountability is being a member of the Development Team, contributing towards the Team Goals. 

In this setup, their job isn't "Done" when a design document is written, but when the user's need is successfully met.

From this position, the Business Analyst supports the refinement and elaboration of business value, interacting with users, not as a go-between, but as a facilitator for developers and users.

Business Analysts also support the decisions of the Product Owner, ensuring that backlog items are "Ready" both quantitatively and qualitatively when there is development capacity to pull these items.

This approach to Business Analysis in an agile setup makes BA expertise equally, and potentially even more, important to the success of development as in a traditional setup, without creating any of the above-mentioned antipatterns.

The HR issue

The main challenge that has to be addressed when talking about the new role of the BA is an HR issue:
From a practical perspective, the BA gets "degraded" from being pretty high in the hierarchy of the organization all the way "down to" team member. This often causes resistance, making it look like the way of least resistance is to opt for the prior choice, which creates irreconcilable conflict within the development organization.

As such, there are multiple items to clarify before we can make the BA as valuable as possible in an agile setting:

Focus area

Problem

HR

Address potential HR impediments that make it within a BA's own best interests to not be part of an agile team, but rather outside. Such impediments include salary, career progession and other incentives set by the organization.

Line Organization

In organizations where BA itself is a separate silo, work with the BA's manager to ascertain them that making the BA's part of the Agile Team does not diminish their importance or influence. The main thing that needs to change is that BA's now receive their work from the team.

BA Individuals

Work with the BA's themselves to ascertain them that being part of an Agile Team is, in fact, not a degradation and to discover and resolve the personal issues they have with the new, different ways of working.

How to resolve the Planning Conflict

There's a seeming conflict that might become apparent: On the one hand, "delivering early and often" is an Agile principle - and on the other hand, "deferred commitment"  is a Lean principle. This might create a planning conflict. How do you resolve it?

Planning purpose

First, we must realize that there are different reasons for planning. 

Within the team / development organization, the purpose of planning is to make sure that we have a realistic goal and we all understand what we need to do.

Towards our customers, the purpose of planning is different. They don't care who does what, and when. They care when they'll get what.

Towards other stakeholders in our organization, the purpose of planning is again different. They need to know when they're expected to contribute, and when they can get a contribution from us.

Defer commitment?

First thing to realize here is: "Who are we committing towards?" Are we committing inside the teams to maximize value - or are we committing a certain date or scope to our customers or stakeholders?

Customers and stakeholders plan their actions based on our commitment, so in this regard, we shouldn't commit anything that we can't keep, because otherwise, we may be creating significant, non-value-adding re-planning and organizational overhead. Broken customer commitments will damage our trust, If you can deliver without having to give a commitment, that's better, and even when you need to commit so that others can plan, try to commit as late as possible.

The trust issue

"Deferred commitment" requires trust. 

• Trust in the team, that they do the best they possibly can. 
• Trust in the organization, that they enable the team to succeed.
• Trust in the customers and stakeholders, that they want the team to succeed.

Asking for early commitment hints at a lack of trust. The solution is not to enforce strict commitment, but to build trust. In a trustful relationship, deferred commitment shouldn't be an issue for anyone.

Deliver early?

Inside our team, we plan to deliver as much value as early as possible, because "you got what you got". To minimize risk and to avoid falling for Parkinson's Law, we should avoid keeping activity buffers that allow us to "do extra work", and we should remember that early delivery is our feedback and learning trigger.

Resolving the conflict

There is no conflict.

We work towards two separate events: 

The team's first point of feedback, and the point of business completion.

• The first date is the earliest point in time when we can get feedback. It allows us to validate our assumptions and to verify our product. There is no guarantee of completion or finality. For internal planning, we look for earliest possible dates, so that we can reduce risk and deliver value quickly.
• The second date is the latest point in time when we can complete a topic. We communicate this date as late as possible and try to avoid having to lock it in if we can. This minimizes the danger of expectation mismatch. For external communication, we look for latest feasible dates, so that other people's decisions don't rely on our unvalidated assumptions.

Addendum

Based on the feedback that "deferred commitment" in a Lean context is referring to decisions:

The statement "Scope X will be completed at date Y" consists of two decisions made today: a decision about what, as well as a decision about when. If there is no need to decide this today, we should not.

We try to avoid locking in a decision that has a significant risk of being wrong.

That is not the same as "we won't deliver any value until some undefined date in the future." It means, "we can't guarantee you the value until we know more."

Why you shouldn't set Predictability targets

While predictability is pretty important for management, and having an agile team/organization deliver in a predictable manner is certainly aspirable, setting targets for predictability is a terrible idea. And here's why:

Blue lines are reinforcing, red lines negative reinforcement, orange items are under the teams' control.

As soon as we set Predictability as a target, we create a reinforcement loop that rewards teams for spending more time planning and less time actually developing. The same reinforcement loop also destroys the very thing called "agility", i.e. the flexibility of "responding to change over following a plan."

As a consequence of both reinforcement loops initiated by setting a predictability target, we reduce the ability to actually deliver business value. As such:

Developers who work towards a Predictability objective do so at the expense of Business Objectives.

If that's not yet clear enough, let me put it bluntly:

Predictability targets hurt your company's bottom line.

 

Hence, I will strongly advise to resist the urge of using predictability as a KPI and setting predictability targets on software development.

Dependencies aren't created equal

We often hear the proposal that dependencies are bad, and we should work to remove them.
Is that true? Well - it ... depends. Pun intended.

First and foremost, "dependency" can mean many things, and some of these are good, others bad, and some conditionally good or bad - and yet others, simultaneously good and bad.

Before I get into that, let me define what I mean with "good" and bad:

Economic perspective

(You can skip this section if you can simply live with the terms "Net Benefit", "Returns" and "TCO".)

Looking from an economic perspective, anything we do or decide results in an outcome.
This outcome has a benefit - the economic Returns.
The way to reach this outcome, its maintenance and failures on the way all have a cost - the Total Cost of Ownership (TCO).

From that, we can determin the Net Benefit: Returns - TCO.

Whether we measure that in Currency (Dollars/Euros) or in whatever unit we see fit (e.g. time, opportunities, satisfaction etc.) is irrelevant. Every outcome we get has such a net benefit.

As such, we can always compare two alternatives based on their net benefit. The outcome with the "better" net benefit is the preferable option.

For example:

Either we can:

1. do the yard work this Saturday, and have a clean yard.
   Net benefit = clean yard.
   
   
2. hire a gardener at $500 to do the yard work, and go to see the Playoffs.
   Net benefit = clean yard + seen playoffs - $500. 

Now, whether you prefer option 1 or 2 depends on whether you value attending the playoffs more than the $500, so often, the Net Benefit may have some subjective component that's hard to quantify in money. Regardless, a rational mind would choose whatever option has the highest subjective net benefit.

Why do I bring up this example?
Because option 1 has no dependencies, and option 2 has a hard dependency on the gardener and on the money. If you prefer option 2, you deliberately choose to have a dependency in order to increase your benefit.

Good and bad dependencies

With the concept of net benefit on our hand, let us opt for two generic alternatives:
Option A, which has dependencies and Net Benefit A as "Returns A" - "TCO A".
Option B, which no dependencies and Net Benefit B as "Returns B" - "TCO B".
To at least keep it somewhat simple, we'll assume "risk" (of whatever type) is part of the TCO.
This gives us a proper basis for discussion.

Type

What

Example

Bad dependency

Net Benefit A < Net Benefit B,
TCO A > TCO B and
Returns A < Returns B.

Being unable to meet market demands
because a component vendor can't keep up.

Good dependency

Net Benefit A > Net Benefit B and
TCO A < TCO B.

Software company buying servers
instead of building chipsets from raw silicone.

Potentially good dependency

Net Benefit A > Net Benefit B but
Returns A  < Returns B.

Letting a business partner serve a market segment
you're not an expert in.

Potentially bad dependency

TCO A < TCO B but
Net Benefit A < Net Benefit.

Preferred Supplier process that simplifies procurement
but means you can't get everything you need.

Mixed dependency

Net Benefit A > Net Benefit B and
TCO A > TCO B.

Outsourcing sales to an agency
that takes a commission.

That clarified, we definitely want to avoid or eliminate "bad dependencies", but we may actively look for "good dependencies".

What happens in practice, though, is bias: we inflate ROI and discount TCO to make dependencies look more rosy than they are. We do this by making overly optimistic assumptions about potential payoffs (ROI) and dismissing negative factors that don't meet our concept. Of course, that is a trap we easily fall victim of and we should make sure we draw a realistic image on both ROI and TCO, preferrably erring on the side of caution.

Now, let's take a look and interpret those dependencies:

Bad Dependencies

A bad dependency is definitely something you want to eliminate. You win by removing it, hands down.

Good Dependencies

Don't be fooled, good dependencies are both everywhere and at the same time rarer than you think!

Our specialized service society is full of them. They help you make the best value of your own scarce resources, first and foremost, time. We could hardly live if we wanted to have no such good dependencies. You depend on a farmer to produce food, you depend on cars or public transportation which you haven't built, and so on. The modern world wouldn't be able to exist without them.

To eliminate such good dependencies would throw us back into the Stone Age.

After this, let's take off the rosy glasses and face reality: willfully induced good dependencies can turn sour any time. To use an illustrative example, let's say you're a non-tech company who decided to outsource their IT to an IT Service provider. Then, the market turns and your most profitable segment becomes online sales - all of a sudden, your ability to meet market demands depends on an external agent who now dictates the rate at which you're earning money!

Potentially Good Dependencies

The world isn't simply black and white, and TANSTAAFL. Partnerships are a great example of a potentially, though not universally, good dependency. In our above example, the dependency is good if you partner with someone who relieves you of some burden to allow you to achieve more. The dependency is bad if you partner with someone who allows you to achieve more, but at a price you can't really afford.

(An extreme example here might be a model who becomes rich and famous through a casting show, but is forced into a contract that ultimately makes them sacrifice family relationships and health.)

Potentially Bad Dependencies

When you can have something simple cheaper than something better, that's good if you are content with the outcome. It's bad if you aren't. Since most of the time, people want the best possible outcome, these types of dependency are usually bad.

Mixed Dependencies

These increase your business risk, and are a gambit. The bet is that by taking the dependency, you will get a better outcome. If the bet wins, this dependency is good. On the other hand, if the bet loses, this dependency is bad. Sometimes, it's both good and bad at the same time.

Taking our example of a sales outsourcing, you earn less money from your core business that is now running via agency, and you earn more money from business you otherwise couldn't have acquired. So, it's a good dependency as long as you have more extra business than the commissions, and a bad dependency otherwise.

How does all of that map to "Agile"?

Great question. All of these are business decisions. Oftentimes, it's business people who bring dependencies into a process in an attempt to optimize something. Take, for example, customer service introducing ZenDesk, or Marketing deciding to run Salesforce. Or a manager who decides to offshore the development for some of the systems integrated into a complex IT landscape.

In any of these scenarios, all of a sudden, you end up with dependencies outside your sphere of control. The question, "how do we best create the business outcome" becomes "how do we deal with the technical dependencies?"

If we leave the local optimization goggles of pure Software Development, there may be tangible business benefits which make the induction of these dependencies not just plausible, but a genuine, positive business case. 

For argument's sake, let's ignore the fact that most business cases look better than reality and deal with the fact that all of a sudden, there's a dependency.

While certain Agile framework proponents religiously advocate the removal of dependencies, the case isn't as clear-cut as it may seem.

Simply exposing a dependency doesn't mean we can, or even should, remove it.

We have to make a clear case that a discovered dependency is bad.

When we can provide transparent evidence of a bad dependency, removal should be the only logical conclusion.

If, in our investigations, we discover that from a systemic perspective, that a dependency is actually good, we would be optimizing locally in an attempt to remove it. Managing it becomes inevitable.

And that's where tools like SAFe's dependency map are more helpful than the Agile dogma of "dependencies are bad."

Tool Tip - The Change Compass

 If you're looking for a simple, yet efficient tool to help you create transparency on how your team is developing and growing, you may want to try the "Change Compass" in one of your Retrospectives:

The x-dimension is labelled "Calm" vs "Stormy", and the y-dimension "Improving" vs. "Worsening". Like this, it becomes a 2D mood-meter on where your team thinks they're heading.

How to use

Give people one minute to put a marker on the compass in whatever place they feel is most appropriate. Any place on the compass is fine, because we're mostly interested in a direction.

• "Calm" would mean "Nothing is really happening, there's no speed."
• "Stormy" would mean "We're in for a rough ride, faster than we can control."
• "Improving" would mean "Things are getting better"
• "Worsening" would mean "Things are getting worse"

Directional Patterns

When looking at the results, you don't need to interpret every single note. Instead, try to look for some key patterns.

The list of patterns here are the most common ones you can spot, although there may be others.

Making Progress

Our "True North" is positive change at a sustainable pace.

A healthy team undergoing healthy change would place their markers on the top third of the compass, preferably close to the center.

Too far on the left means we're not moving as fast as we could, while too far on the right means we may be overburdening the team, potentially making change an impediment in and of itself.

Comfort zone

When everyone feel that we're neither getting worse nor better, and there's no motion, people operate in their comfort zone.

This is good after a long, bumpy ride, but shouldn't be a permanent condition: There's no change without change, so this might trigger a discussion about where we can improve.

Change Fatigue

Sometimes, people have the impression that we're moving fast, but nowhere.

In this case, it's pretty important to have a conversation about what we're trying to accomplish.

We're losing 'em

When you see this, the team is torn. Some people feel the change is moving too slow, others feel things are moving too fast and/or in the wrong direction.

This would be a great time to have a conversation about what causes the different perceptions. Maybe the people who are uncomfortable see something the others don't - or vice versa?

No clear direction

With this pattern, it's almost irrelevant whether the points are on the left, center or right of the compass.

The key realization here is that people are disoriented - they don't know where they're headed, or what the outcome will be.

Maybe we lack transparency of what's going on?

Business as usual

People are in motion, at a comfortable pace, but nothing is really getting better.

Are we not even trying to change, or are we trying and see nothing coming out?
What do we need to change, so that things actually improve?

Change Theater

We're moving, but not where we want to go.

The further people move their markers to the bottom, the more likely you should stop and entirely reconsider whatever you're doing.

Dealing with the results

As long as you're "making progress", there's not much to discuss, and the exercise could be over within minutes.

In any other case, you need to start an conversation about what the results mean for your team.

The outcome of a Change Compass session should be that you:

• pick up speed when you're in a calm
• slow down when you're in stormy conditions
• Correct course when you're worsening
• Reconsider when you're not improving

In any case, it creates transparency on how your team thinks about your improvement efforts.

Alternative uses

The Change Compass can also be used in stakeholder environments, i.e.:

• to conclude a Sprint Review (to see how customers think about the team's progress)
• in management sessions, to see how the "outside-in" perspective on the team is
• to provide management feedback when the team feels things are blocked or going wrong

 "How do we manage risks in an agile setting?" - Agile risk management differs widely from classic project risk management, because we have a different sphere of concerns. Whereas classical projects are mostly concerned with risks related to delivering within TQB (Time, Quality, Budget), an agile environment forces us to consider a much broader sphere of risks:

Agile risk management

There are some general notes on agile risk management that may be unfamiliar or in contrast to the expectations of classic project organizations:

Risk overview

Teams (and in SAFe, ARTs) should be able to have an insight into their most relevant unresolved risks at any time. The assumption is that "if there is no risk overview, there are no relevant risks." Scrum Masters ensure that both of these statements are true.

At a minimum, risks are identified as such to be visible. Some organizations prefer to add additional information, such as severity, occurrence, detection (the FMEA process) and countermeasures, which is only relevant if you have no means of addressing them swiftly.

Risks are treated like regular work items, and move into the backlog as "potential work to do". The teams decide whether new risks are added to the Sprint Backlog or to the Product Backlog - or to the Program Backlog, in a SAFe context.

Live updates

Agile risk management is a constant exercise of evaluating available information and anticipating probable events that should be avoided, then inspecting and adapting the determined course of action. Risk management in an agile setting happens during every event (and during daily work, as well) -

• Lean-Agile Budgets identify financial risks
• Refinement identifies product risks
• Planning and Dailies identify process, delivery and organizational risks
• Reviews and Demos identify delivery and product risks
• Retrospectives and I+A workshops identify all kinds of risks
• PMPO Sync identifies product and delivery risks
• Scrum-of-Scrums (SOS) identifies organizational and process risks

As such, the risk overview is a more volatile and shifting artifact than even the teams' plan, and potentially more ephemeral than the product backlog itself.

Avoid Single Points of Failure

Organizations are most resilient if there is no single points of failure, hence risk management becomes a collaborative exercise. It's better to work with focal areas than rely on a clearly delineated role-responsibility mapping. It is expected that everyone contributes to naming and resolving relevant risks, from the most junior developer to the most senior manager.

Scrum Masters facilitate team risk resolution and create transparency in the surrounding organization on those outside the team's control. Ideally, the team would be able to deal with their own risks even without requiring the Scrum Master to take action.

Risk resolution

Just as every day is an opportunity to identify risks, we should deal with them before they materialize, ideally right when it is exposed. It's the team's decision on how they will prioritize risks against other work.

Risks outside the teams' sphere of control should be adressed via proper channels. In a SAFe setting, the first channel for a team is usually from PO to PM or from SM to RTE who would involve management if required.

Focus Areas

Teams succeed by collaborating and helping each other out, so let's not go into the "sorry not my desk" antipattern. Still, people do different things, and so pay more attention to different aspects. In this context, let us examine the different focal areas of the common agile roles.

Product People risk focus

First and foremost, product people must take care that we build the right thing, and have the resources (both time and money) to do so. Hence, they must be aware of and deal with:

Financial risks

Financial risks are cash flow related. We must secure an initial investment that allows us to develop something, and in order to continue, we need ongoing funding. Within an enterprise, that's typically budget. On the free market, that's revenue, which is usually generated through sales or subscriptions. So the Product people need both the means to understand the current financial situation and to forecast the future, and thereby extrapolate wherein the risks lie.

Common financial risks include exploding license fees, stakeholders withdrawing their support, customers leaving or price wars on the market, but also pretty mundane stuff like equipment breaking down or the need for a bigger office as the team grows.

To manage financial risks, the product owner must understand their cash flow.

Since financial risks are entirely out of scope for classic Kanban, XP and Scrum, there tend to be no standard team-level mechanisms for dealing with them.

Lean-Agile Budgets are one of many SAFe mechanisms to keep the predictable financial risks away from the team.

Product risks

Product risks are related to success of the entire endeavour. We need to build the right thing right at the right time, and ensure we adopt to changing circumstances as rapidly as possible. Hence, "release fast, release often" is essential to minimize product risk. 

Common product risks range from building the wrong product over building it in a way people don't like all the way to the product becoming obsolete or unmaintainable. Hence, product risks can be located in the past, with consequences ranging far into the future. This requires constant attention both to the inner dealings of the team and the outside environment.

To manage product risks, it's essential to look beyond the backlog, into the product itself and the product's market. Metrics can serve both as lagging and leading indicators to discover and track their manifestation.

Refinement workshops, Reviews (System Demos) and Planning events should reveal product risks, both within the team and at scale.

Team risk focus

Autonomous teams have control over both their process and their delivery. Hence, the risks associated to these must be born by them:

Delivery risks

Delivery risks range from not delivering anything all the way to delivering the wrong thing or something that doesn't work, hence they include the huge topic of quality-related risks. Since delivery risks have a price tag attached, called the "cost of failure", these risks consist of more than pure impact - they also have a huge element of choice: we take calculated delivery risks when the benefit outweighs the cost.

Common delivery risks include defects, incidents and problems (in ITIL terms), not being in control over the product's technical quality, not testing right or enough as well as releasing something immature, but also failure to gather fast and reliable feedback that could expose and thereby prevent other risks.

Delivery risks must be managed, but often become visible in real time. They are hard to pre-plan.
If we see any delivery risk in the future, we should devise a strategy to start minimizing it today. Retrospectives address how we dealt with past delivery risks. Team dailies should reveal current delivery risks, and teams should actively collaborate to deal with them.
If they can't be dealt with immediately, they should be made transparent on the Team Board.

Process risks

Usually, a process risk manifests as an impediment towards doing the right thing swiftly. In larger organizations with strict regulations and massive dependencies, process risks are often outside the teams' sphere of control, which, in the worst case, may lead the idea of self-organization and team-level agility ad absurdum. 

Common process risks include handovers, bottlenecks, delays, but also technical aptitude.

Teams are expected to manage process risks within their own sphere of control. Where they lack this control, the Scrum Master must often intervene to drive risk resolution. 

Team Dailies often reveal immediate process risks.
Retrospectives are often the best point in time to deal with long-term risks.

In SAFe, we use the Scrum-of-Scrums and the I+A workshop to address cross-cutting process risks. Additionally, we can resort to Communities of Practice to deal with practice-related risks.

Scrum Master risk focus

One of the Scrum Master's core responsibilities is revealing the things nobody else sees - and that includes risks of all form and types. Sometimes, the Scrum Master actively has to examine risks from the other roles' focus to identify need for change. Additionally, there's a group of risks that will oftentimes require action on behalf of the Scrum Master:

Organizational risks

Organizational risks, in this context, are risks induced by the way the team and its environment is organized. Such risks occur within the team, at the interaction points between the teams and the surrounding enterprise, as well as imposed from outside the teams' immediate horizon. Most of them occur at friction points, that is, where incompatible parts of an organization collide.

Typical organizational risks include asynchronity, miscommunication, bottlenecks, communication gaps or inavailability of individuals as well as mismatching goals or priority conflicts. There is usually a positive correlation between organization size and organizational risks.

Two core activities where organizational risks are identified are Planning and Retrospectives. In SAFe, that would include PI-Planning and I+A workshops where the SM should feed in both input and track relevant action items.

The Magic of Agile

One problem with "Agile" is that it often gets used as an excuse to avoid addressing the real problems in a straightforward matter. People resort to "magical thinking" - hoping that "Agile" somehow does some magic that will make the problem go away. And here's what's happening:

Clarity

In anything we do, we tend to look for predictability: what are we supposed to do, and what will happen as a consequence of what we do?

The coin toss

Let's start with something really simple: tossing a coin. 

You toss it into the air, let it spin, and call "heads" or "tails", and 50% of the time, you're right, 50% you're wrong. Straightforward enough.

Would you believe me if I told you that "if you throw the coin properly, it will turn into a helicopter and fly away?" Probably not. You won't believe me, because you know exactly what a coin and what a helicopter is, and how to toss a coin. There are no Unknowns here, and as such, you wouldn't accept my claim.

But now, let me change the topic:

The Project

Your company has started a project: to toss coins and turn them into helicopters. "Insane", you say. "No," your consultant responds: "we are in the Complex domain - a problem that we don't understand requires an approach you are not yet aware of. Since you can't rely on a familiar approach, you need to use an Agile approach."

Whereas formerly, we would have said "This won't work", now we have "Agile", and the plausibility of success immediately increases!

We have done nothing, absolutely nothing, that would lead to a helicopter as a result, and likewise have done absolutely nothing that would actually help you create a helicopter. All we did was introduce "magic" into the process by reframing the Unknown: "we have no idea how that's supposed to work!" becomes: "Agile will create the result!"

Comfort

Since we know very well that we're not getting a helicopter with a coin toss, we are quite comfortable to state, "That doesn't work." Now, if someone showed us how a coin turns into a helicopter mid-air, we would say, "I see the helicopter, but don't know how that works," (we increased the certainty of the outcome, but not in the approach) - and those of us with a growth mindset would likely say, "I want to learn how to do that!"

If your manager has given you 2 weeks to do it, your nerves would tingle. 

And now your manager tells you that unless you do it, you will be fired? Most likely, you'd be quite willing to try any advice on turning coins into helicopters.

What has happened here?

The further you leave your comfort zone, your willingness to accept magic as part of your mental model increases. When facing an existential threat, you'll more than happily try things you'd call nonsense under normal conditions: the plausibility of the proposal hasn't increased at all, only your perception thereof!

And this quite frequently happens with "Agile Transformations":

Magical Agility

Of course, turning "coins into helicopters" is a joke. Nobody would take that seriously. But what if our challenge was to turn:

• Dissatisfied Customers into Happy Customers
• Poor Time-To-Market into Fast Delivery
• Cost Pressure into Huge Savings
• Tons of Defects into High Quality
• Unhappy Developers into a Highly Motivated Workforce

Someone says, "when you're Agile, you can achieve all these". and now you're all - "Okay, bring on the Pigs in Pokes, let's get this going!" - especially when your job is at stake!

And that's where you get into the realm of Agile Magic. And that's when you need to stop and think.

Let's not get into the nitty-gritty that even if you're agile, you'll still have these problems, just that you will be able to deal with them better, and let's focus on the big hitter:

When your organization has no experience with achieving these, then "Agile" isn't going to change a thing about that unless you start doing your homework!

De-mystifying "Agile"

There is no unknown component that can't be explained. Everything is transparent. We know very well how to relate cause and effect. And where we don't know, we can explore until we do.

Problem -> Approach -> Action -> Outcome. Preferably highly repeatable and reproducible. No silver bullets, no miracle pills.

Where we can't copy+paste a solution from one place to another, succeeding with agility becomes harder, not simpler: we require experimentation and a willingness to fail - and a pretty good understanding on whether failure will lead to growth or be fatal.

There's no Agile ceremony, ritual or incantation that will grant you a magical Great Leap Forward.
You must get to work and clean up the mess you're in. 

Learn what causes you to get the outcomes you currently get, and what you need to do in order to get the outcomes you want. As you learn, you'll catch a bloody nose quite frequently, so bring plenty band-aid. (figuratively speaking)

Mundane agility

Find your own way forward:

Experiment. Fail. Learn. Repeat.

That's all there is.

The only shortcut I can offer: You are probably not the first person who has encountered a problem. Thus, you can often skip or at least reduce the "Fail" part by learning from others before you move ahead.

There are many bodies of knowledge that allow you to accelerate your journey: Engineering Practice. Process Management. Product Management. Quality Management. Supply Chain Management. Team Building. Just to name a few. Make use of whatever knowledge you can get a hold of.

Inspect and adapt until you're clear why you are where you are, and where and how you want to go next. When you don't know, you'll need to figure it out. 

The more you practice this, the more comfortable you become doing it.

The desire to seek magical solutions evaporates.

There is no magic in "Agile.".

Stories that aren't

 Let's take a look at the "User Story Template" (also known as: Connextra Template, by origin) - "As a ... I want ... so that ..." - straightforward enough. It's common in the "Agile" space, and many inexperienced Scrum Masters and coaches learn that teams should formulate their work like this.

The result?

Formally it's correct. It's a "user story" based on the template. 

Now, what's wrong with it? About everything.

Let's leave aside for a minute the fact that this story is as much of an antipattern for "INVEST" as it could be, and focus instead on the use of the template:

1. The "user" isn't a "user". 

If we start calling developers "user", then next thing we know, testers, analysts, and project managers are also "users". It becomes a hollow, meaningless term.

A "user" is someone who actually uses the end product. 

Like ... a Candy Crush user is, for example: the "mother of a small kid who only has 5 minutes before the kids will cry again."

(Of course, developers can be users as well. But that would require them to actually use the product, in which case they wouldn't be a developer, but ... for example, a "mother-of two who sits in front of computer screens all day ..." - if that's your demographic!)

2. The want is a means, not an end

"Wants" should be something that this specific user wants to have and would be willing to use our product for, like "simple and easy fun". No user ever wants a Customer_ref_ID. Maybe they need it to identify themselves, but ... can you name anyone who wants to use a product because it has a Customer_ref_ID? 

Could you imagine running a marketing campaign with the slogan, "We have a Customer_ref_ID" - if not, then you're probably not addressing anything someone wants. 

Take it as a lithmus test for formulating "wants":

If you would feel weird to see it on a billboard on the way to work - it's probably not a proper "want".

 

3. The reason is self-serving and circular.

In more abstract terms, the reason is "so that I have it." - it doesn't explain which problems it solves.  It adds no information. It doesn't help us verify whether we're adding value to the product, and it doesn't help us verify whether we actually need it. It's a fake reason.

Let's, for argument's sake, assume that both the user and the want were valid: we still don't know why you want to refer to the customer by ID, and how that is better than what you're currently doing.

A good reason statement shouldn't repeat the "want", but explain why the "want" is relevant, which problem we're solving, how the world is better after the need is met.

Good reasons invite developers to understand why the user has an unmet need.

The Investment into Quality

If you're setting out to "become Agile", or "more Agile", I would like to say something in words as simple as I can:

Unless you're willing to invest heavily into quality, forget about "Agile".

Now, what I mean with "invest in quality" is not "throwing huge amounts of money into testing", because the investment you will make is actually free, and it doesn't involve hiring additional staff, either: If you're doing it right, you will spend a lot less money to get better results. What you need to invest is attitude, thinking, brainpower, capacity:

Now, let me elaborate:

The commitment to quality

I think that no sane person would say that "we like to produce garbage products." I have never met a  developer who would state on their CV, "I was producing crappy software." Likewise, I have never met a manager who would introduce their line of service as, "We deliver crappy software."

If nobody would say that - then why is it even something to talk about?

Most commitments to quality are just lip service.
You must act upon your commitment.

When I say, "commitment to quality", I mean that everyone, and that is, everyone, must continuously ask, "How do my decisions and actions contribute towards quality, both in a positive and a negative sense?" Any decision that leads to poor outcomes should be reverted, and any action that leads to poor outcomes should be stopped.

Nobody needs to justify themselves for not doing the wrong thing, or not doing something in the wrong way. It should go without saying that "if you see that it's going to end badly, don't do it."

Managers must commit to creating an environment where team members have the freedom to do the right thing. Reciprocally, developers must commit to resolving any problems within their own sphere of control and naming any organizational barrier towards high quality, even if that barrier has been set up by the CEO in person. This must be unpartisan, free from personal preferences or fear (and these three things are already massive barriers to overcome!)

Everyone, and that means absolutely everyone involved, from managers over developers all the way to side stakeholders, must commit to do their best to enable high quality.

Quality thinking

You must turn a commitment into action, and for that, you must understand how to achieve quality. Quality isn't a local thing happening somewhere between a finished product and its users. Quality begins as early as in the ideation, and it never ends as long as the product exists. Quality is everything. It concerns everyone of us, and each of our actions.

Let's start simple, with the choice to add a certain feature to our product: Will it make the product better, or worse? For whom? How? In what way? How does the very decision of adding it affect both the process and the outcome?

The new feature could be a boon for some, and a put-off for others. It could make the product inconsistent with its purpose. It could make it clunky. It could put stress on development. It could have effects that are difficult to discover until it's too late. Could ... now I don't want you to over-think. At least, I want you to ask the questions that need to be asked, instead of simply shoving another piece of work into the pipeline: Oftentimes, the product could be better by removing a feature instead of adding another!

So, who has to think about the quality?

Designers, in design. Developers, as they develop. Testers, as they test (of course). Operators, as they operate. And that's the simple part: "I must be mindful of quality in my work."

Developers have to collaborate with designers. Testers have to do that, too. And Ops. Logically, testers also need to collaborate with developers and Ops. And everyone with the customer. And with management: "We must be mindful of quality in our interactions."

All the time, everyone of us must constantly ask:

"What can I do, both in my own work, and to the work of others, to achieve higher quality outcomes?"

Quality practice

Move beyond words. Learn how to create quality: Design thinking. Behaviour-driven development. Test-Driven design. Clean Code. Stop the line. Data-driven decisions. Measure everything. Quality and Process management. Go-See. Standardization. Simplification. Candid feedback. 

Just to name a few.

If you want to be agile, quality isn't just for testers: It concerns everyone, even the most junior developer and the most senior manager. Even those outside IT. While, obviously, I'm not going to ask a VP of Sales to write Clean Code, I would daresay that if anyone within the organization makes a choice that results in someone else breaking with an essential quality practice, this is going to hurt the company's bottom line. Hence, everyone must have a sufficient grasp on quality practices to maximize the overall outcomes of the company.

Everyone must understand enough about quality practices to do what it takes to get best results.

Capacity for Quality

I'm not going to sugar-coat this: If you don't have processes, infrastructure and code that are designed for quality, you're not going anywhere unless you put some effort into that.

You must allocate a certain amount of capacity for improving and preserving quality.

If your company has been spending $100k on shoddy stuff and could live with it, what's so wrong with spending the same $100k on something of higher quality? Nothing! Never accept shoddy outcomes: "Do more" has lower priority than "do well." Capacity invested into low quality is lost. Capacity invested into high quality is gained.

"But," - I hear you murmur - "We will be slower, and the business / customer can't wait!" - not really. 

Stop thinking about what you deliver in a day or two. Set yourself a horizon of a month, half a year and then a year. Ponder how much effort you invest during that time into fixing bugs, into rework, into unused stuff and into rote work.

Set yourself a target to generate the same business results, without doing any of that wasted work. Then, ask yourself what you would need to get rid of this pointless work. If you manage to cut down on 10% of your current workload, you have gained 10% capacity for improvement. This capacity is now not "free for more poor quality work": It's free for improvement, so that you can do higher quality work that makes people more happy. 

True Story.

Is all of the above a figment of imagination, wishful thinking, idealism?

No. I'm talking about measurable, tangible business outcomes. 

Helping my clients engineer quality, we have significantly reduced defects, non-value adding activity and rework to cut down new feature development lead times by over 50% and expenses by as much as 30%, while reducing cost of failures on business end by seven-digit figures.

The "invest" we needed was about 50% of people's time initially - to change on their thinking, their practice and their environment, and 30% of their time subsequently.

If it was your money: Would you be willing to let people spend more of their time on quality, if the outcome was that you have to spend less money to get more things faster, while earning more money from happier customers, working with happier staff?

Yes, this question is purely rhethorical: "Time spent" is irrelevant if the outcome is "better business"!

Do it.

The case for trainings

 When coaching, especially in large organizations, I very often encounter teams and individuals who have basically been "pushed" into Scrum, SAFe, Kanban or LeSS without ever having attended a training course. While on the one hand, I advocate that "the real deal is what happens in the workplace", I want to make a case why training is absolutely mandatory for new agile organizations and even for those who are just going through a major change. In doing so, I would like to debunk the common "arguments" given by organizations against professional training.

Why not just learn on the job?

It's entirely feasible to successfully adopt a different way of working while doing it. That's how people who devised "Agile" also did it. But it's extremely slow and error-prone. And we re-invent the Wheel. And we may not spot our obvious problems until we hit a brick wall.

A classroom setting allows the trainer to create an environment specifically focused on a certain learning objective, and drive home the point. Encountering a similar scenario "on the job" without any a priori experience will make things appear more complex, which means that it will take significantly more brain power to comprehend.

Of course, an experienced coach will guide their coachees through this situation and the learning process as well, and they will do it in a practical working environment, connected to the real workplace environment. The time factor could easily be twenty-fold, though, because a lot more guidance, explanation and time for reflection is required when the basis just isn't there yet.

What happens in agile training

After this brief introduction, I would like to explore quickly what you get out of a good agile training:

Conveying knowledge

Teaching the roles, artifacts and events of (Large-Scale) Scrum or SAFe doesn't take long.

The formal rules of these frameworks are extremely easy, and it can be done in a few hours. Hence, the issue isn't in standing in front of a class and rattling down the material - the issue is in getting people to find an answer to their own question of, "what should I do?"

Aligning on Roles

It's important that people understand their own role is and that of the people they work with. For untrained people, that's one of the major sources of conflict, because there are unspoken assumptions and conflicts until we had an open conversation. A classroom environment allows people to bring three things together smoothly:

• Objective standards
• Their own personal understanding of their own role
• Others' understanding of their own role, especially interactions

Understanding events

There are numerous events in each framework. As a coach, most of the dysfunctions in practice I observe are related to people not having a proper understanding of the intent beind these events. A training environment allows the trainer to let people consider for all of these events:

• Scope
• Participants
• Agenda
• Intended outcome

With people who already practice a framework, trainers will often let participants explain how they conduct these events, then provide corrections and advice in order to help people get more value out of what they've been doing so far.

Constructing artifacts

Regardless of whether you're using an agile approach already or are transitioning from classic project organization to dealing with agile artifacts, the journey is extremely difficult for people who have no understanding on the purpose and contribution of these artifacts. A classroom setting will give people time to learn or reflect upon:

• Intent of each artifact
• Setting up the artifact
• Maximizing effectiveness
• Minimizing handling efforts
• Dealing with typical challenges

People are often amazed when they compare how they're currently working with the ease and seeming effortlessness with which a trainer uses artifacts in a classroom setting to achieve their purpose.

Experience Anchoring

As already mentioned above, the "knowledge" part is the simple part of an agile training. A proper agile training will spend a major portion of its time on creating an "anchor" - letting people try out the approach in a safe environment, so they can draw their own conclusions in comparing this with their own workplace environment.

Living the framework

Small simulations will allow people to try out their framework, and gain some experience with both the ups and downs of the new ways of working. Depending on what participants want to get out of it, they may either use the simulated environment to explore their own role and receive instant feedback, or they can try out a different role and build some empathy.

Communicating and learning

In a training environment, it's expected that people use each exercise and share with the group what they learned, what they would like others to be aware of, and what they would like to keep for the future. This is an extremely good habit for adaptive ways of working, which oftentimes doesn't happen on the job, because people feel it's out of place or don't have time.

Subtle learning

When people don't understand an instruction in a training environment, they will typically just ask the trainer. In the working world, they would often lack the courage to speak up and just try to get through somehow, the problem will only become obvious in retrospect. A training allows people naturally adopt the benefits of the Scrum Values, such as Openness and Courage, and a good trainer will drive home the point that they're already doing it!

Team Formation

Probably the most underestimated aspect of an agile training, and also the reason why I advocate bringing in a trainer rather than sending out people to role-specifics training, is team formation. There's a huge difference in performance between a group of individuals working on the same project (product) and a team (or: team of teams).

Over the course of the training, a trainer can form groups of trainees as teams who will have had ample time to discover and work out the important aspects of their future collaboration: who can expect what from whom, how they will organize themselves - and what is important when. After such a training, people will be pumped and ready to rumble without delay.

Just the benefit of having had people spend a few days to sort out all of their misunderstandings and find a common way forward can pay for a good training with ease: The formal knowledge gained is just the icing on the cake.

Flawed arguments against training

I would like to dissect the most common arguments given against bringing in a trainer and having people attend a formal training, because I believe that there are very, very few solid reasons against kicking off a new agile unit with a good training:

Common reasons

I hear all of these arguments commonly, and none of them hold water when you think about it a little closer:

The cost argument

"People know the price of everything and the value of nothing." - Oscar Wilde

The training costs too much

You will pay for the training one way or another: If you would "save" on the training, you'd have to do it with coaching, parallel to work, and therefore, over a prolonged period of time. The time lost due to friction until people are settled as a team and have found their way to collaborate and contribute will typically exceed a month ... and now think: how much will you spend on coaching during that period?

Effectively, you've got to do the same thing, with the only difference being whether you do it in a classroom or in parallel. The cost will be the same.

We don't have budget

A common problem, specifically in large corporations' IT department. It comes from a cost accounting structure. You may have budget to "do work" (CapEx), but not budget to "set up doing the work more efficiently" (OpEx). It's a dilemma. The solution rests in TCO - total cost of ownership. 

Going the right direction after a training will be faster and cheaper than figuring things out first. Even if you save just 1 Sprint on whatever you intended to do by setting up a training - the gains are X salaries for 1 Sprint, which should be part of your overall budget. 

Start thinking in terms of throughput accounting: if you spend $100k to build something, or you spend $80k to build something, the second option is cheaper. Except that "under the hood", option 2 used training, whereas option 1 burnt the budget on "doing": Does it even matter?

You have the money. You just don't see how you should be allocating it.

People are too busy

Of course they are. Because of your current ways of working. Which is what you want to improve.

If things don't work, why would you want to keep continuing doing the wrong thing, rather than making a full stop, resetting - and starting off with full speed in the right direction?

Other Priorities

This tells me that your organization has a priority issue: If "other things" are more important than coming together to introduce a more effective way of working - then your organization doesn't understand or appreciate effectiveness. We can use the training to set the baseline for fixing this issue, but we won't fix it by continuing to do what we always did!

We can't withdraw X people for 2 full days!

Imagine someone gave you an axe that allowed you to cut trees twice as fast, but it would take Monday and Tuesday to get used to. At the end of the week, you'd already have cut more trees. It's the same with your team(s). The only reason why you can't train them: because you feel the short-term cost is bigger than the long-term benefit. I call this "The tyranny of the Urgent." If you don't break free from that now - why would get better when your team has invested even more time working suboptimally?

As the proverb goes, "The best time to plant a tree is 20 years ago. The second best time is today."

We don't need it!

What do you say to a salesperson when you don't want to take the offer? "No." It's entirely acceptable. At the same time, would you say "no" to yourself when someone was literally offering you free money with no strings attached? 

To not spend money for something that costs you less than it earns you - is economic nonsense.

We'll figure it out by ourselves

That's entirely legitimate. I had the same attitude. And I did. It took me years. If you have those years ... great! Unfortunately, I don't think your comeptitors will wait for you to learn stuff that's well known while they start dominating the market.

People already know Agile

As mentioned above, a good trainer will not focus exclusively on objective knowledge. Instead, the training will form a team (of teams) of people who agree on a common, more effective way of working: If you already had this, why would you need a new way of working?

The flawed underlying assumption

Behind all arguments given against training is a single, unspoken common assumption: "We believe that training doesn't make much of a difference."

I would like to take a jab at this assumption like this: "If you believe your current ways of working are already (almost) as effective as what the trainer would teach you, why do you even want to adopt new ways of working?"

If you believe, however, that the new ways of working will make a significant difference, then I would suggest to figure out the value proposition of a training. Drop the fallacious arguments, talk purely about your needs and expectations.

If you need help building a business case for investing into training, we can do that:

The value of training

Before you think about "training or no training", ponder these questions:

• What's the biggest challenge we have, that we want to solve within our current way of working?
• How would the new way of working deal with this challenge?
• How much does this challenge currently cost us - ever day, every month, per year?
• How much would setting the groundwork with a brief training course help us shave off the current challenge?

The answer to these should help you formulate the business case for a training, and help the trainer manage expectations as well. If like this, you end up with a negative business case for the training, then I would - most likely - not suggest adopting a new way of working at all. The friction of switching ways of working would probably outweigh the expected benefits.

Once we've learned that training is a positive case, look for the following aspects in agile training:

• Will the training address the challenge(s) we want to improve upon?
• Will the trainer be able to relate our situation with the training content?
• Will trainees get specific impulses for things they could start doing differently tomorrow?
• Will the training equip people to apply their learnings outside the classroom?
• Will the training connect people on the work they will be doing? 

If the answer to any of them is "no", either talk again to the trainer or find a different trainer.

Once you are convinced that the answer to all questions is, "yes", then it should be a no-brainer to do whatever it takes to free everyone for a few days to get some proper training. 

Training vs. coaching

What I say in this paragraph is bad business for me - because I'm a coach: I have sufficient experience to claim that the needed duration for coaching - and thus the coaching expenses - will be significantly lower after people had training.

The reason why I say it regardless of the financial impact: the probability of change success goes up dramatically. This, in turn, means that the likelihood that you will discover the value in coaching will go up. And thus, the probability that you will speak favorably of my coaching will also go up.

An expericenced coach would be fully capable of compensating the absence of classroom training and formal education in the coaching work. From an expectation management perspective, I would still advocate for starting with training before coaching, because it's not an either-or situation.

Good training enables better coaching. "No training" means extra money for the coach, and more trouble. The best case scenario is great training followed by great coaching. It produces a win-win-win scenario: you learn more, you save money, and the coach will be more effective faster.

Factors to disregard

A lot could be said on bad decisions when choosing a training. I would just want to highlight a few factors you should simply disregard when deciding on training, because I see many people look for these factors, only to later complain they didn't get their money's worth.

Certification

I have some beef with certs, because - especially for introductory classes, which we're talking about - they do not certify competence. They certify attendance, and you don't need (virtual) pieces of paper. You need people to do work. If your training helps you to do work better, that's great. Certification is a gimmick. It adds no value to a course.

Multipliers

Many organizations are trying to save money by sending a few people to a 2-day course, who are then expected to act as "internal multipliers". One of the key benefits of training is to form teams who can immediately and effectively start working in a new way, You lose this benefit by dispersing people and introduce propagation layers. Those people who will work together should receive training together. And don't limit it to "managers" or "leads" - train everyone!

Standards

A canned and bottled curriculum is a double-edged sword. You need something that people can relate to, something that's actionable in your organization. As such, the trainer must at least be able to pick up your people where they are instead of merely playing off a script. If the script is flexible enough, it's not a disadvantage. Otherwise, the standard creates a problem.

Fun!!!

Training can have fun moments, but I'm highly suspicious of trainings that people unanimously call "fun": If you want fun, send people to Disneyland. Ignore the fun factor.

When a trainer actually breaks with your current paradigms, it will throw you into mental disarray. Anger, sadness and frustration can accompany a great training that really shook your beliefs about work. In some cases, it takes weeks or months until people realize what they learned. During that time, you might see people give both thumbs down on the training, which only shifts once the learning sinks in. Don't let high fun scores attract you to a training, and don't let lower fun scores detract you from it.

Conclusion

A good training will pay for itself - even when you're too busy, even when you think you already "know Agile". And even when you have no money. If the training isn't worth it, then whatever change initiative you're running probably isn't worth it, either. Hence, training can be a great lithmus test to see whether you should proceed.

You will save time, you will gain productivity, and you will also have a better bottom line when you achieve the same (or better) results after a training.

Continuous Problem Solving

"What do you even do as a Agile Coach?" - well, that's easy: I help you on your journey towards better, more effective ways of working. And how do I do that? 

Well, I will start using this simple 4-step process:

The problem solving process

Step 1: The Biggest Problem

When I come in, you will have many problems. One, or just a few, will be the biggest. Let's forget the others for now. Why? Because it's better to get one problem solved than to have no problem solved, and by its very nature, solving the biggest problem will make the biggest difference.

How do we identify the biggest problem in the presence of a myriad of issues?

It's not quite as simple as "brainstorming and dot-voting": sometimes, we need both loads of data and the perspectives of many people who may not be in the room. And sometimes, nobody sees or addresses the elephant in the room. When facilitiation isn't enough, I may gather and/or analyze data, interview different stakeholders or simply connect some bits and pieces to form an image to get a conversation going. And if that still isn't enough, I'll propose to you a shortlist of problems that you can pick from.

Step 2: Root Cause

If you had a simple solution, you probably would already have fixed it. So there's a deeper cause to your problem, and we need to address it to make some relevant progress. At times, we must move your process to an entirely different level, because we can't solve the root cause - we must avoid it!

How do we find the root cause?

Simple tools include 5-Whys or, again, brainstorming and dot-voting. These are often insufficient, because once again, if we knew the cause, we would probably already have addressed it.

I'm not a big fan of "Five Why" analysis for organizational issues, because the technique usually suggests a point-based root cause, whereas the root cause may be hidden in a web of causes, and even then, it could be a network effect leading to the problem we observe. And sometimes, identifying the cause is easier for an outsider who isn't stuck in a presumed "inevitability". If that's the case, I will give you my opinion. (Although I could be wrong. Everyone can always be wrong.)

And sometimes, I frankly don't know. If, for example, the root cause is part of your internal accounting processes, I can at best tell you it's there, but what exactly - I'm not an expert on that. we'll need to call the experts in.

Step 3: Action Plan

How do we deal with the root cause, how do we get better? You may have ideas, and I also have ideas. You may lack the experience and/or expertise, and I may have it. Let's bring all of that to the table, and turn that into an action plan. 

I could propose an action plan, although you need to accept it. If you have counter-suggestions or alternatives that you consider better, go for it. I'm indifferent to whether you go with my proposal or your own: what matters is that you get some traction and start moving the big bricks.

What's most important about the action plan: it's your action plan. You own it, and you execute upon it. I will support you with whatever I can contribute that you need: facilitation, tracking, communication, workshops and sessions. Depending on how much support you need, I may also compile the outcome of all of this for inspection.

Again, like in step 2, there are problems where I can propose an approach based on my experience, and some where I'll have to pass. For example, if your biggest issue is a proprietary compiler for a proprietary programming language, I can only suggest you get an expert from the vendor to help you on the issue.

Step 4: Reflection

So you did something, or we did something. If it was a good plan, something should be visibly better now, otherwise - what did we miss, what should we do about it?

Is our problem still as big as before, or has it become smaller? How much? Did we create other problems?

I'll support you with methods, structure and facilitation in this process. And, like mentioned before, with compilations of results and outcomes. As needed, I will add my insights and opinions.

But ... how about "Agile"?

"How does that help us introduce Scrum, Kanban, LeSS or SAFe", you may ask? It may not. Or it may. For certain, it will make you more agile, i.e. improve your ability to "change direction at a high speed." 

Agile frameworks are entirely in the solution space, i.e. step 3. 

If Scrum helps you solve your biggest problem, and you need someone to teach you how to Scrum, that's what I'll do.

If User Story Mapping solves your biggest problem, that's what we'll do.

If Pair Programming solves your biggest problem and you don't know how to do it, I'll grab the keyboard with you.

If your biggest problem is the lack of an overarching structure and you decide to go with SAFe, I'll set up SAFe with you. Or LeSS, if you consider that the better alternative.

What I won't do, however, is to just dump "X" onto you when that wouldn't deal with your biggest problem. I won't do it, is because people will not see the value of "X", and there's even a high probability that "X" will be blocked by whatever your biggest problem is.

The abuse of Cynefin

Scrum has been the tact giver for "Agile" for a long time. And Scrum is all about empiricism. And this "empiricism" has become a problem in recent years: Self-proclaimed, unqualified "coaches and trainers" proclaim that current organizational processes don't help, and hordes of incompetent "Agilists" swarm the market, only to wreak havoc on unsuspecting organizations.

Based on a mis-representation of Cynefin, people abuse Scrum and ditch available knowledge wholesale, because ... "In the Complex Domain, you don't know until you tried."

Now, is Scrum or the Cynefin framework really the cause of this problem? Not really - they are merely the door-opener for the snake oil sellers. And given Cynefin's and Scrum's easy appearance, people don't spot the trap until they fell for it. These frameworks are so popular and so easy to abuse, and it's really difficult for someone who sees them for the first time to discern what's correct and what is a mis-application.

Cynefin Framework by Dave Snowden

Now, let me describe the chain of "Cynefin Reasoning" that leads us down the wrong path:

"Knowledge Work (e.g. Development) isn't simple. It happens in the Complex domain. In the Complex domain, we have unorder where the relationship between cause and effect can only be perceived in retrospect and the results are unpredictable. Complex systems are dispositional and not causal. Hence, we cannot rely on good or best practices. Instead, we need to create safe to fail experiments and not attempt to create fail safe design."

It's a flawed understanding of Cynefin, combined with a false dichotomy that becomes a toxic soup. Here's why:

1. Just because something isn't simple doesn't mean it's automatically "complex". There's the entire domain of Complicated problems that's blissfully ignored, and even "Complex" is a category of varying degrees of complexity.
2. The idea that existing knowledge is entirely inapplicable doesn't describe the "Complex" domain - that would be the "Chaotic" domain: We can predict the outcome of a software development process pretty well. What we can't predict quite so accurately are customer reception and market conditions, but even there, we have quite elaborate mechanisms.
3. A shallow "dip into chaos" doesn't mean we should engulf, immerse or drown ourselves in chaos. Whenever we can prevent chaos, we're well advised to do so.
4. A scientific approach would rely on so-called "experimental conditions" where we fix all but the one variable under examination. If we let go of all control variables, we really won't be able to predict anything any more ("Chaos"). The latter is pretty pointless, and it can be avoided in knowledge work.
5. Just because something is "complex" doesn't mean we have no reliable process and are fully reliant on empiricism. To retain control, we need to minimize the impact of uncontrolled factors. For example, we would never have a smartphone if we didn't know exactly how to build computers, exactly how to build mobile networks, exactly how to mass-produce microtechnology, and those things would be a nightmare to use if we didn't know exactly how to build software that doesn't crash. It's complex, but it relies on a lot of things we precisely understand, and operating in this domain without high degrees of knowledge would be economic suicide.

And that's where we get into the mess today often called "Agile":

People don't understand what they're doing, because it's not a requirement to get into an "Agile" role. Fake "Trainers" without development experience make it look like that's not required - because, "hey, we got Empiricism". We encounter so-called "Agile Coaches" who don't know the building blocks of a functional company, we have to put up with 2-day "Scrum Masters" who don't know how to build a team, and see misplaced "Product Owners" who don't know what makes a product successful. And that's just scraping the surface.

Does this sound familiar?
"We don't need market research, probabilistic forecasting or demand control: Let's just write a User Story and put it into the backlog!" - "There's an entire science around Demand Management" - "Who needs that? Let's just incrementally Inspect and Adapt!"
Product Management, Quality Management, Process Management, Delivery Management, Operations Management, People Management, Finance Management, Sales Management ... we know a lot about these things! In the "Agile" community, however, there's a growing number of people who meet these with resentment, ideology and opinion: "managers are worthless anyways, so let's shoot all of that to the moon and apply empiricism!" 

The knowledge is discarded wholesale under the pretext of Cynefin - complexity and empiricism become the arguments against existing knowledge. "Inspect and Adapt" trumps science. Hence, "Agile" gets a free pass for obliterating functioning organizations: people with zero understanding of a domain "coach" long-term experts who have academically studied a subject, read the books, and gotten their share of field experience - and some even have the galls to claim that "coaching in the absence of knowledge works better, because it allows the coach to be unbiased!"

Thus, we set the playing field for quacks who will dismiss all scientific achievements and progress we have made in software engineering, bringing on the mumbojumbo, kumbayah, post-its and canned bikablo doodles: those professionals who did put in the hard work become indiscernable from quacks, organizations and individuals decline, order descends into chaos.

"Agile" has become a habitat for the same kind of science denialism as Anti-Vaxxers or Flat-Earthers: Except it's more subtle to spot, because the bodies of knowledge these people despise are the invisible fields in knowledge work. And Cynefin has been their door-opener.

Let me conclude with a question: "How will you approach complexity?"