Agile Academy - McKinsey, you get it all wrong!

In a recent Whitepaper (LINK), McKinsey publised an approach for "growing your own Agile Coaches", i.e. creating an "Agile Academy". While I may even agree with the general idea and some major points and ideas proposed in the paper, it fosters and relies on a few massive misunderstandings that could plunge your company into disaster.

Executive Summary

With their whitepaper, McKinsey have proven that they themselves are indeed nowhere near what they claim that you need to become an agile organization - so don't take their advice, they've disqualified themselves!

Since the below article is quite extensive, let me provide an abridged version:
McKinsey demonstrated that they have a low understanding of what agility is, what agile coaches actually do, they argue fallaciously to suggest a solution to a problem that you don't even want to have: the need for masters-of-all-trades.
The suggested solution doesn't match the problem statement: They ignore the temporal dimension of the problem and move it into a different domain to make it look like it addresses the proposed challenge. The approach doesn't yield what they claim you need.

By following the McKinsey approach, you will end up with a lot of people with decent, but limited understanding who won't have what it takes to make a breakthrough change.

What McKinsey gets right

Some of the key points that they get right:

• "Scaling Agile" isn't done by copy+paste. An Agile PMO isn't a solution, either - as agility and PMO are contrary approaches.
• In a VUCA world, we must move away from consultants who "implement best practices". It's more sustainable to use coaching to help people learn and discover.
• Without good coaches, your chances of becoming or sustaining an agile organization diminish rapidly.
• Enterprise agility also requires taking care of processes anchored outside IT, such as budgets or performance reviews.
• You can't ignore current reality - agility isn't a cloud castle.

You don't become a master by attending a course.

I also agree that a 2-days course doesn't make one a "Scrum Master", especially not an "Agile Coach" and that just the prospect of a higher paycheck inspires people without even the remotest form of qualification will appropriate these titles in their profile.
I'll even concede that people who have little to no understanding of agility will rewrite their CV's to make it look like that their project manager Command and Control role in a classic Waterfall project which gloriously went down the drain was actually an "Enterprise Transformation Agile Coaching" project - and that makes it incredibly difficult for classic HR mechanisms to filter out who is indeed a qualified coach.

Where things get fishy

There are many assumptions in the article that I'll just put into question, as they haven't been backed up.

McKinsey clings to a number of beliefs that are questionable and will not help your agile transition.

• For what and how many "Agility Coaches" do you really need? Why even introduce yet another role instead of helping Scrum Masters learn to expand their horizon, when self-organized teams need a supportive environment, not even more complexity?
• How can there be "a clear approach to enterprise agility" when the entire problem is that in the VUCA world, there is no One-Size-Fits-All solution - which is the reason why we need agility to begin with? And if so, how is this approach better than approaches like SAFe or LeSS, which have been around much longer and have been used in a broad spectrum of organizations?
• Why do they believe that "the role of the Scrum Master is limited when it comes to scaling agile" when all they quote as reason for their beliefs are antipatterns on how not to be a proper Scrum Master? Isn't that like saying that you believe ships are unfeasible because you threw a rock into the river, and it sank?
• Why define "the vision and scope of the agile transformation, informed by assessment of the organization today"? Is this how you do strategy? Wouldn't it make a lot more sense to define goals by where the organization needs to be than by where you currently stand?
• How do you define an "Agile Blueprint" if the entire point of agility is that adaptability to circumstance isn't universal, a point they themselves made in the introductory section?
• Why do they talk about "the agile operating model" rather than about being flexible, responding to change - which isn't a model, but an attitude and capability?
• How can you change your reality by operating within current reality? Wouldn't establishing a new reality require going beyond current reality? And isn't "reality", as described in the article, merely a perspective held by people without agile experience?
• If we realize that the problem of Enterprise Agility is that complex system change isn't molecular, but rather molar in nature - how can we succeed by focusing on subsystems within an otherwise static environment? 

Where it gets really problematic

The article creates a false dilemma and then so conveniently proclaims a solution, which isn't even one.

McKinsey sets up a false dilemma to sell their "solution".

Setting unrealistic expectations

A person who can do everything at mastery level won't be interested in a limited role.

The "Agility Coach" as defined in Exhibit 2 has a role complexity that shrinks the amount of people who could meet that responsibility to Zero.
Just ask yourself: How many people do you know in your organizations who have management skills, facilitation skills, developer skills, agile framework skills, technical skills, business skills - and the time to do all of this at a Mastery level? Each of those domains requires focus, otherwise mastery will wane rapidly. Top it off with that person also being creative, innovative thought leader, and you're looking for a Jack-of-all-trades, master-of-all.

Typically, a developer who learns management will lose their technical edge within a few years. The line manager who works strongly to coach and grow their people will not be spending time to learn facilitation techniques. The manager who moves in strategic management will have little time to work on empathy and listening skills, simply because their responsibilities lie elsewhere. The business expert will not be a technology expert - and vice versa. And finally, being innovative and a though leader doesn't combine well with being tied to a single organizational context.

Now imagine that you put up mastery in all of these areas as a mandatory requirement - and answer: Why should such a person work for your organization rather than start their own business?

Basic training

Even a 20 weeks curriculum won't remotely give a person the breadth and depth to be an "Enterprise Agile Coach".

Don't get me wrong. I love the idea of an "Agile Academy" and I have worked with organizations who have one. And I have worked with people who went through Agile Academy curriculums. They're great people to work with, as they do indeed both understand the basic tenets of agility and their specific role within the organization.
But a 12-20 week course (3-6 months, taken generously) in addition to the regular work isn't going to make the cut, either.
A Scrum Master training is just a starter, a teaser, a foretaste. It's nowhere enough to say one has mastered agility. A 12-20-week part-time academy is definitely one step further, but still a far shot from the experience and qualification that professional agile coaches bring.

I have stated in another article that the Scrum Master journey, if taken seriously, over the years, might take a person into the domains of technology, personal and team and systemic coaching, quality, process, general and strategic management, mathematics, psychology, sociology and philosophy. Just two days on each of these subjects, and we haven't covered any business domain yet. There is no way that even a 1-year part-time curriculum will give a person even a remotely viable understanding.

Moving the Goalposts

There is no single curriculum to do what McKinsey claims is required.

Participating in an "Agile Academy" program doesn't produce anything that even remotely resembles the Jack-of-All-Trades proposed by McKinsey's Exhibit 2. An academy program has to set a clear focus and may give teasers on fringe areas. The outcome of participating in an Agile Academy is not a technological mastermind who can innovate, coach teams and management, develop a strategy roadmap and lead enterprises to success. It's simply people who are decently equipped to meet a specific function within an enterprise,
There would be different programs for people who would:

• support one or multiple agile teams ("Scrum Masters"),
• professionally coach individuals ("Coaches"), 
• organize and facilitate larger events ("Facilitators"),
• train organizational units who are yet unfamiliar with agile approaches ("Trainers"),
• accompany agile organizational units with methodology advice ("Consultants"),
• take care of the transition itself ("Organizational Change Managers"),
• lead program and product development from a business perspective ("Product Owners"),
• create and innovate ("Developers" / "Designers"),
• fill day-to-day coordination roles ("Managers"),
• have people responsibility ("Leaders").

And this isn't even talking about the domain of technical mastery yet, where a decent training program outdates before it's completed.

If we would - for argument's sake - say that a person goes through all of the domains listed above, then each domain gets like a day or two: does that qualify for "mastery"? How much trust would you place in a Change Manager who has taken a single course? Would you put anyone on your Board of Directors whose management experience is limited to one day of training and a week of practice?

While it's indeed possible that one individual goes through a series of such academy programs, and while indeed many of us senior agile practitioners on the free market have enhanced capability in multiple of these domains, let's be blunt: You can't have a Master-of-All.
Finally, a person who ran through ten quarter-year programs to gain "mastery" has been in education for a minimum of two and a half years - and that's definitely not something that you will have at the start of a transition.

Limited quality

Part-time focus isn't the same as full-time focus

There's a reason why world thought leaders like Marshall Goldsmith don't excel in all of the domains proposed by McKinsey. To be the best in your field still requires full-time dedication and serious effort. Nobody becomes a thought leader by spending a couple weeks in a training academy. The best people coaches aren't software developers, the best software developers aren't people coaches. Taking the "T-Shape model" - people who have a broad insight into many domains lack depth in at least one of them, worst case - in all.

I like to use the circle illustration. A person has 100% of their time, and it doesn't matter whether we're talking about lifetime, work time or agile coaching time. Let's just talk about 100% of their time. What would you want them to invest this time into - you can choose anything.
You will realize that as you put the items into the circle, each additional item decreases the proportional share available for all the remaining ones. An increase in focus on agility automatically decreases the focus on everything else - and putting four items in there ("Self mastery", "coaching", "agile mastery", "commercial acumen") would mean that at least one gets neglected unless the person spends no more than a quarter of their time on each of these domains.
You will not become a "Master" by spending 25% as much time on a domain as a full-time dedicated expert would - and definitely not a "thought leader!"

McKinsey started with the broad claim that they have a clear solution to the self-created dilemma of finding people who have a large list of qualities, but the solution is setting up a pool of people who, if following their proposed suggestion, will not have any of the qualities on the level they insist are required!

Ignoring the setup

Agility is based on empiricism. You have to start by inspecting and adapting, not by setting up an academy.

Starting your own, internal "Agile Academy" isn't done overnight. To create curriculums that match your need, address your challenges and have a sufficiently high quality of materials is a high-effort process and relies on having the expertise to begin with. This is essential to keep agility flourishing over the years, but if this is your first step, you're not going anywhere in the next couple of years.

As agility is based on empiricism, you need people who can bring both the theoretical and practical experience of empirical ways of working into the organization. These are the people who typically get hired as "Agile Coaches". There is no way to eliminate this step, and you can't copy+paste another organization's curriculum to circumvene it.

You have to run agile development within your organization to learn what works - and what doesn't. After you did this, you can roll this out in whatever way you choose - for example, by seeding multiple teams, pulling in additional units, doing a strategic rollout, setting up an academy or whatever (I have opinions on these approaches, but that would be too big for this article). But the first step of bringing in seasoned practitioners who can shine some light into how agility practically works within your specific organization is inevitable.

The big lie about agile practitioners

"outsourcing these key roles will often lead to an influx of agility coaches who are disconnected from a company’s culture and want to dogmatically apply agile the way they know it rather than the way it needs to be molded to a particular organization" - McKinsey

Basing a core statement of the paper on a lie about agile coaches doesn't further your cause.

Let me call it for what it is: a lie, as if McKinsey had any experience in the field (which I will take for granted, otherwise the entire whitepaper is moot), they would know that the last attribute that can be used to describe proper agile coaches - is dogmatism.
I would therefore disagree with the sweeping statement that agile coaches who do not come from your specific organization are often dogmatic and will insist on pushing their pet framework rather than understanding and working with your current reality.

The first big part of the lie is that a person who pushes a specific agenda isn't a coach to begin with. 

The second part of the lie is that anyone who has experience with agile enterprises will know that enterprise transition is a long, strenuous process that requires deep understanding of systemic interactions, specific attenuation and oftentimes, compromise. 

There's even a community of so-called "Agnostic Agile" practitioners, which I would highly recommend looking into, who reject framework dogmatism, because dogmatism isn't agile. 

Not addressing the real problem

If you don't know what qualified external people are, why would you do a better job in selecting internals?

McKinsey proclaims that companies often find themselves hiring external coaches who are, in short, utterly unqualified. I agree. This happens. Organizations who aren't agile often have trouble selecting for the right people and qualified agile coaches are not dime-a-dozen.
They then proceed on the very flawed assumption that organizations who find themselves incapable of identifying who the right externals are would do a significantly better job at identifying the right people internally.

What we see here is a classic bait-and-switch: "You have no way of figuring out who the right external coaches are" [Reason: You don't know what the right mindset is and your HR mechanisms often make it impossible to onboard the right people] "so just identify people internally and grow them" . This doesn't answer the question how to identify what this right mindset is that you couldn't identify when selecting for external agile coaches. It also doesn't answer how to fix the broken HR processes which prevented getting qualified people on board. And to draw a full circle, if you can't even spot the right mindset when recruiting - how are you supposed to teach it?

If you can't find the right people externally (where a few fairly talented people exist) - what makes you think you're better at doing it internally (where definitely nobody with all the requirements from Exhibit 2 exist)?

Closing Remarks

Every company has employee churn, just by statistics. Some people leave, others come in.
Everyone in the company should be familiar with the company's specific ways of working. Agile principles and practices should be understood by everyone.
An Agile Academy, which sets up both starter curriculums and ongoing education in which interested employees can choose to participate is a feasible way of achieving this. Formulating your own curriculums to bring people with overarching responsibility "into the know" is an effective way of moving forward.
I do indeed support agile academies as an ongoing mechanism of sustaining enterprise agility.

However
An agile academy is not strategically viable to start an agile transition - and it is not a replacement for onboarding external expertise in the early phases.
Finding the right external agile coaches in the beginning is essential to get your initial seeds of agility to flourish, and it's important to ensure the curriculums aren't imprinting the Peak of Ignorance as per Dunning-Kruger-Effect, because that would kill enterprise agility before it could ever start. By just following the ideas proposed in the initial whitepaper, this is exactly what would most likely happen.

Even when an "Agile Academy" is set up, there are a number of immense dangers:

• Curriculums focus too much on specific methods and practices, thereby being limited in usefulness and outdating rapidly
• Standardization" or "blueprinting" is anti-agile, any curriculum aiming in this direction doesn't go in the right direction
• Forcing or coercing employees to participate in the Academy invalidates the entire idea
• Senior managers and HR need to lead by example and go through the curriculums lest the Agile Academy becomes a mockery of itself.

What every Scrum Master needs to understand about Development

Not every Scrum Master is technical. Indeed, some of the best Scrum Masters I know have a sociology or psychology focus - so it's all fair and square to say that they're don't know how to develop code. This may (or may not) pose a problem depending on how advanced the team's engineering practices are: you can't get the team to deliver sustainable value when they don't know how to do that.

At a minimum, the Scrum Master should to realize whether the team is aware of what they're doing - and if they aren't, bring in a technical coach or senior developer who can teach the team the ropes. There are many nuances, and a non-technical person will not see everything. Once developers are on the right track, they can very well figure out where they need further help.


tl;dr: of all the categories below:
Absence of the practice causes delay, incurs cost, reduces stakeholder satisfaction and may kill the product (and in smaller organizations, the business!)

Here's what to look out for:

Automation

Phrased positively: If we do indeed automate everything that can be automated, we gain a much better understanding of what's actually needed to get something to work. Automated activity also frees developer's heads for doing new work rather than repeat activity. Everything automated can be tested, so we can test not only the software but also the meta-processes, bringing quality to another level. We create repeatability, reliability and confidence in the processes.
Plus, we eventually save time.

Dead giveaway? Team members have paper (or electronic) documents for standard activities they do all day.

Constant Refactoring

Refactoring should be a day-to-day activity as part of regular work. Every line of code should be refactored as soon as it becomes necessary.
Deferring refactoring will eventually put product development to a screeching halt, which can be fatal for smaller companies. I have seen products die entirely because one day, developers discovered that new features couldn't be integrated any more without breaking something else.

Dead giveaway? Developers complaining about code quality.

Unit Testing

Over the months/years, code will become more and more difficult to maintain unless there's a decent amount of unit tests. The time it takes to make even minor changes will explode in the absence of good unit tests: What might take seconds with unit test coverage could take weeks in untested code.

Dead giveaway? The "tests" folder in the repository doesn't get updates with every new version.

Continuous Integration

Problems in the codebase are often not visible until the latest version of the build (which must be subject to automated tests) has been validated. In highly complex environments, changes to one part of the code base may break other code, which will become visible only when those pieces play together. The risk of this happening increases with every change made. As developers do multiple things sequentially, the effort of locating the root cause of an issue becomes increasingly difficult to uncover with passing time, and every change ("fix") to an unstable codebase will amplify the problem.

Dead giveaway? Developers call things "Done", and there's no Working Build for it yet.

Code Smells

You don't need to be a developer to discover "code smells" which will eventually become a problem.

 Some of the most obvious code smells are:

• "Mountain Ranges": The code, rotated 90 degrees left, looks a whole lot like a mountain range. Such code is too complex to be feasibly testable
• "Copy+Paste": Code that looks eerily similar multiple times over or developers who outright say that they develop by copy+pasting existing code segments, then modifying them, produce code that eventually becomes unsustainable.
• "The Gigabyte Class": A class that is unusually large will eventually become a problem. As a rule of thumb, a class with more than 5000 Lines of Code is probably fishy. YMMV.
• "Treasure Hunt": When you see developers moving across myriads of classes all the time to understand what's going on, there's probably a code structure issue.

There's tons more of code smells, but these are the most common to see when developers don't know how to create Clean Code.

Dead giveaway? Developers don't understand code produced by other team members.

All Unknowns aren't equal

The Stacey Matrix has invited many agile teams to use the term, "Unknown" as a reason for using an "Agile Approach", i.e. winging it and finding out what's happening.
In some cases, that's the most economical or even the only option. But Unknown isn't unknown, and it makes sense to classify the term a little bit further.

The types of Unknown

Folly

Some things are just common knowledge. For example, everyone who has a smartphone knows that you need a secure password for everything that's on the Internet. To claim that "we didn't know that 'root' doesn't make a good root password for our web server." is just plain foolish. It's not Unknown, and there is no sensible reason to treat it as one.

Unqualified

If you work in a field, for example, software development, a few things can be assumed as standard knowledge. It doesn't take much except reading a few blog articles, a beginner's book or attending a really basic class to know these things. People who don't put the effort to know the very basics of what they're dealing with are sloppy and therefore unqualified. Absence of basic knowledge means you hired the wrong people, not that people should learn by trial and error.

Silly Excuses

Things wouldn't be common knowledge unless they were understood by a majority of the population. Claiming that it's not possible to research what happens when you disconnect a router is just a silly excuse. These also don't qualify as Unknowns for anyone who intends to keep their job - as a company that accepts such unknowns is very unlikely to survive for long.

Knowledge gaps

As soon as we get to field specific knowledge, not everyone can know everything. For example, you might have hired a music PhD for your development team who contributes a lot when it comes to synergizing ideas - but they may be unaware of how to write proper tests. That's an acceptable Unknown, which can be readily covered with available information. Throw in a bit of practice and you're set.
These Unknowns are fairly predictable and can be planned quite well.

Unfeasible

You may encounter areas where nobody on your team has any knowledge, and only a few people on the planet know what they're talking about. Maybe the thing you need to know hasn't even been explored yet or it's just uneconomical to acquire enough information upfront.

Such Unknowns are quite typical when doing innovation work, and are often hard to plan, as nobody knows exactly what the result will be and which steps will lead there.
This is the domain of experimentation, adaptation, trial and error.

Unknowable

The most difficult realm for prediction is knowledge which can't possibly exist, such as information about the future. While we can either research or explore by trial and error how customers use our product, we have no way of knowing whether a policy change in a country somewhere half across the globe will plunge our business into an economic crisis tomorrow.

The Unknowable warrants an entirely different approach. Usually, deliberately ignoring unknowable circumstances until they occur is the best strategy (as trying to know the Unknowable can consume an infinite amount of energy with no return on invest). When something Unknowable pops up, we need to deal with it - and that's being agile.

Dealing with Unknowns

If your development team claims that something is Unknown, first classify why the thing is unknown.

• Folly, unqualified action and silly excuses should not be tolerated. If it's a people thing, address the behaviour openly.
• Knowledge gaps should be brought up as early as they become known, so they can be filled effectively.
• In software development, - acquiring all the knowledge is unfeasible: either too complex, too slow or too expensive. "Experiment, Inspect and Adapt" is the most economical, pro-active strategy.
• Everything related to the future is unknowable. Accept it. The further you look into the future, the larger the Unknowable becomes. The impact of the Unknowable on your work determines how flexible you'll need to be. 

A plan far into the future should be very crude  ("a roadmap") lest it breaks when all the Unknowns unravel: The further you plan into the future, the more unfeasible knowledge becomes part of the plan and the larger the big ugly blob of the Unknowable becomes.

The SMF Guide: The world's simplest Agile Framework

Let me introduce to you to an agile framework that's much easier to learn, has a much lower hurdle of adoption, and much higher chances of actually making a impact than Scrum. It's leaner and more flexible and if you start using it today, you'll see results right away!

SMF: The Sense-Making-Framework

By doing this relentlessly and rigorously, you can make things work!

Sense-making theory

Every day, we do a whole lot of things of which we don't understand why, or we even know that the outcome is not optimal. That doesn't make any sense. When we realize that something doesn't make any sense, why do we continue doing it?  And still, that's one of the biggest scourges of companies worldwide: people do things that don't make any sense, and nobody questions this.
The SMF is intended to stop this nonsense.

People act in the most sensible way, given the information they have and the circumstances they are in. When people have the right information and communicate properly, they can quickly realize whether something makes sense. The minute you realize something doesn't make sense, talk with those around you and if others agree that it's nonsense, don't do it.

Sense-Making is incredibly easy to understand, yet incredibly difficult to master. Even with this simple five-step process, it can take years of practice, superhuman patience and strong perseverance to create an environment where everything makes sense.

Making Sense

Sense-Making is concerned with different categories of sense, fully well realizing that this is both a spectrum and shifts over time, both as the system changes and as you gain more understanding of what is going on.

Good Sense

When something makes good sense, just keep doing it. You may occasionally want to reflect whether something else makes more sense, but that's probably not your main problem - so direct your attention elsewhere.

Common Sense

When something contradicts common sense, discuss why this is so.

Be aware that common sense can lead us awry, because it depends on our biases and the culture we're exposed to. When you spot contradictions between what would make the most sense and what common sense dictates, you may want to discuss why this is so.

Nonsense

There's outright nonsense, where everyone knows that this is nonsense, yet you keep seeing and/or doing it. Just stop it and see what happens. Then, replace it with something that does make sense.

No sense

"No sense" is different from "nonsense": there's an information and/or understanding gap and you don't know how and/or why would make sense. This requires further transparency and communication before classifying whether it makes good sense or is nonsense.
When you can't collect information that would help make further classification possible, stop doing things that make no sense and figure out what happens: If nothing happens, it made no sense to do it. If something happens, you have further transparency.

Sense-Making mechanisms

There are a few key mechanisms in making sense. There are no roles, artifacts or special events to sense-making, as that doesn't make any sense. Just do what makes sense.

Communication

When you don't know if something makes sense or are certain that something else makes more sense, communicate. Your environment is usually more complex than you understand, so openly involving others is key to making choices that make sense.

Stopping things

Stop doing whatever is nonsense, and stop doing things that make no sense.
When trying to do something that makes more sense, don't just add it on top, you also need to stop doing the thing you currently do so that you make more sense instead.

Experimentation

When you think something makes more sense than what you do, experiment - try it, and see what happens. Then, you have information to see whether it makes sense. In some cases, you learn that things made more sense before the experiment, and you may want to go back.

Implementing Sense-Making

If you have the courage to start making sense in your organization, start with this simple process:

1. Get together and ask yourself, "What's the biggest nonsense we're currently doing?"
2. Stop the nonsense.
3. Try out something that makes more sense.
4. Communicate the outcome.
5. Repeat at infinitum.

The problem with Agile Transformation Programs

Many organizations want to "become Agile", then browse through the catalog of common frameworks, pick their favorite - and run a Transformation Program. While all of these are officially communicated as a massive success, I'd like to cast a bit of light on what is actually going on.

Transformation Input

There are some "givens" that affect a framework-based Agile Transformation program before it has even been conceptualized: expectations, reality and the determined future state as described by the framework.
These are the constraints to the success of the transformation, and depending on how well they overlap, this success can be bigger or smaller. Worst case, this intersect is empty from the beginning - in which case, the transformation program is doomed.

Management Expectation

Typical management expectations from an Agile Transformation include, without being limited to:

• Faster time-to-market
• Lower development costs
• Higher Quality (fewer defects)
• Improved customer satisfaction
• Happier employees

The choice of framework often falls to that which promises most of these benefits.

"Good" transformation programs then set targets based on improvment seen on these metrics. 

Unfortunately, to scope a proper project and/or program, the real work is oftentimes measured in amount of departments/projects/employees using the chosen Agile Framework "successfully" (whatever that means).

Real Problems

Usually less visible to management is the entire quagmire of problems the organization has accumulated over the years. Benefits don't appear from thin air - they are generated by getting rid of problems.

The more problems are known and the greater the pain to solve them, the easier it will be to actually get benefits out of a transformation. 

Cultures averse to admitting or taking responsibility for problems will be struggling to gain actual benefits from any "Transformation Program," regardless of whether it's agile or not.

Framework Scope

Frameworks themselves have a very clear scope, mostly concerned with structure - roles and process, events and some artifacts. We can easily determine how much of this structure has been implemented, and that's how success is often measured.

What's significantly more challenging: determining how compatible people's mindset and behaviour is with the intent of the framework, and how significantly the "new ways of working" get impacted by "old ways of thinking and doing".

Transformation Output

To keep this article simple, let's not argue about how well any of the inputs was understood or change was actually realized, and keep to reality - "we are where we are, and we go where we go."

This reality is:

• some expectations will be met, others don't.
• some aspects of the framework will be implemented perfectly, other won't.
• some problems will be solved, others won't.

Another reality is that at the point in time when the program is conceptualized:

• some expectations are based on known problems, others on unknown problems.
• some expectations are based on understanding the framework correctly, others on understanding them incorrectly.
• some program activity will be planned to do things that solve meaningful problems, others will focus on something that's not a root cause.
• some framework components will lead to beneficial change, others won't.

... and we can't know which is which, until we have done some experimentation. 

For argument's sake, let's just assume that the program is sufficiently flexible to allow such experiments, and that everyone contributes to the best of their understanding and ability.

Programs are still time-bound, and it doesn't matter whether that timespan in 1 month or 5 years. Within this period, a finite amount of activity will happen, and this activity will lead us to wherever it does, and "not everything" will be perfect. And this is what the future reality will look like:

Outright failure

Some aspects of transformation will lead to success, others will fail to provide any improvement - or even make things worse. Let's call things by their name: When you scope a transformation program and don't get something you planned to get, that's failure.

In this section, I want to highlight the failures your program will have.

Unmet expectations

There will be a number of management expectations that haven't been met (blue area outside intersects). Some may have been unrealistic from the outset, others "could have ... should have". Regardless, someone will be disappointed. Managers familiar with diplomacy and negotiation will stomach the ordeal, knowing they got something at least.

Just be careful that the higher your expectations are and the less aligned they are with the framework's actual capability, your organizational reality and the flexibility of the transformation program, the bigger the disappointment will be.

Wasted Investment

Frameworks are frameworks, and when shown an overview of everything that the framework has to offer, managers often decide that "we need all of that". Truth be told, you don't, because a lot of it provides a solution to problems you don't have (yellow area outside intersects). But you can't know what you need until you are in a situation where you do need it.

By deciding upfront to go full-scale into implementing everything a framework has to offer, you're going to load a massive amount of waste into your transformation program - and this waste costs time, money and opportunity.

Unsolved problems

Many of the problems in your organization won't get addressed at all (red area outside intersects) - because they're unkown, too complicated to resolve or simply not relevant enough.

The intent of an agile framework isn't to solve your problems, but to provide you the means of solving them - you still need the heart, the will and the power to actually do this. 

Great transformations focus on tackling meaningful problems, thereby showing by action that resolution is possible and valuable - bad transformations avoid the mess of problem solving and focus on just covering the existing heap of problems under the blanket of a framework.

Unresolved pain points

Managers would prefer to have the perfect organization where everything is smooth and problems don't exist. But we don't live in cockaigne (purple intersect between blue and red on the left), and "Agile" won't create one, either. Problems are still real - and frameworks don't address them directly, they just provide means for addressing them.

The list of pain points is (near) endless, and seems to grow with increasing transparency. and we only have a finite amount of time. There will be un-addressed pain points. Even if the Agile Framework is perfectly implemented, many of the pain points will remain - most likely, more than imagined.

When a transformation program scopes more framework implementation than problem solving, don't be amazed if the outcome is more structural change than solved problems!

Partial Benefits

Transformation programs can and do provide benefits, in different categories:

What you see and feel, what you see but can't feel, what you feel but don't see - and what you neither see nor feel, although the latter is a difficult topic in and of itself.

Illusory benefits

Informed managers will expect the transformation program to implement certain framework elements that will indeed be implemented (full intersect between blue and yellow circle). This is great when these elements actually solve a problem the organization has - but there's no guarantee (greenish intersect between blue and yellow on the right). 

Oftentimes, we create "change for change sake" without getting any better results, because we changed something that's not a problem.

In some cases, the new status quo is even worse than the former state, but it looks better ... because it's new, and compatible with the Agile Framework.

These benefits are not real, they have cost money and kept people from doing the right thing!

Let me warn you right here: Unethical coaches/consultants will focus their efforts on the illusory benefits, to build management rapport and milk the cash cow as long as possible. 

AVOID generating benefits in this category!

Hidden benefits

The framework may actually solve some problems that management isn't even aware of (orange intersect between red and yellow on the bottom), either because the benefits take a long time to become visible or because they do not affect anything of management relevance.

A typical example is the implementation of XP engineering practices - it may actually look like teams are getting slower when they write unit tests and create deployment automation, but the benefits will become visible in the future, as defect rates and stress levels decline. Example: Developers who have worked on Clean Code microservices with Continuous Deployment never want to go back to legacy processes or code, because it's so much easier and faster to work this way - but getting there could take years (and possibly be entirely unfeasible) on legacy systems.

Let me dive in with another note of caution: Ethical coaches/consultants will focus their efforts on solving real problems, many of which managers don't see. Managers must be curious to learn from their teams whether such hidden benefits are being generated, or whether the consultant is just trying to please management.

The success story

Every organization that has invested lots of effort and money on an agile transformation program will eventually produce a success story (brown intersect area of all circles in the center) based on what management expected, how the organization actually benefitted and how the Agile Framework has brought them there.

People are smart enough to not reveal publicly how many of their initial expectations weren't met, how much activity didn't lead the organization in a better direction and how big their problems still are. But depending on how well the Agile Transformation Program was defined and executed, this could easily be some 90% (or more) of the program.

Simply put, it's insane to start an Agile Transformation Program because you read someone else's success story, because the story doesn't tell you what went wrong, how much disappointment and frustration has accrued, how much time and money was wasted - and oftentimes, you don't even see the pointers of what actually made it a success.

Real success happens where the three items intersect, and the size of this intersect is determined by:

• How well do you focus on solving real problems?
• How flexible are your expectations?
• Are you using frameworks where they benefit, rather than making your organization framework-compliant?

Summary

An agile framework transformation program, conceptualized, planned and executed by people who do not exhibit an agile mindset and who do not practice agile organizational development - is going to produce a politically motivated, insignificant success story. 

Stop thinking frameworks, stop thinking programs.
Start thinking agile, and embark the agile journey in an agile way.

Five Principles of Organizational Agility

Do we need frameworks to be agile or not? 
Maybe. If we have a problem that frameworks solve. And if they are an appropriate solution.
Here are my five principles for change, which are paramount to the question of frameworks.

If you adhere to these five principles, my question would be: "What do you expect from an organizational framework?"

1 - Frame your problem properly

Learn to understand your problem before implementing a solution.
A poorly framed problem's solution may be worse than the current state.

Go beyond both the symptom and the Obvious and frame the problem correctly. And when you learn that you framed the problem in the wrong way, refine your problem statement rather than "working harder" to make the solution work.

There are great tools, like Ishikawa Diagrams, 5-Why-Analysis and many others which can assist you in getting closer to what your real problem is, in a very short time.

2 - Limit change

Only reduce the bottleneck constraint that causes the problem.
Large-scale changes will have uncontrollable, large-scale impact.

Figure out what the bottleneck is, why things aren't moving smoother.
When you know where the bottleneck is, be uncompromizing on making a change. By accepting the bottleneck and making a change elsewhere, you destroy the change process overall.

Tools like Process Mapping, Flow Diagrams, Lead Time Analysis and many others that will help you discover the single point where a change will be effective.

3 - Simplify change

Do the simplest possible thing to reduce constraints on the current bottleneck.
Change should be so simple that it's effortless - if our idea doesn't work, we just try the next one until we find something that does work, and that's a lot easier when we make small, simple changes rather than implementing grandiose master plans.

Simplicity is an art - "anyone can make things complicated, it takes a genius to come up with something simple". When geniuses are hard to come by, it helps to involve the people who actually face the problem, as they often have a pretty good idea why something doesn't work, and they may just need the permission to do the right thing instead.

4 - Subtract before you add

Eliminate structures, processes or tools that cause problems.
The "simplest possible thing" we can do is usually getting rid of a blockage, not adding something.
Problems don't get solved by adding something on top.

Additions to an existing problem are like band-aids on a cracked pavement: They won't really help, won't last and won't make much of a difference. The existing problem needs to be addressed and removed. Often, this is already enough.

I like to use tools like Marshall Goldsmith's "Wheel of Change" to model the change, and tend to remind people that "For each thing you add, you have to remove one thing", because otherwise we create more problems (oftentimes elsewhere) instead of solving them.

5 - Verify outcomes

Verify your outcomes before calling something a success.
Change is successful when the problem is gone.

Many organizations call change successful when the change is implemented - which often leads to "change for the sake of change", and people getting rewarded for doing things that don't help the company.

We can use methods like OKR to define which outcome we want to see, and if we didn't achieve this outcome, that should at least trigger the question of what the change has done instead.



Closing remarks
These five principles stand together and should be applied together.

A well-defined problem allows us to run a minimal change experiment in the right place, which allows us to verify fast and cheaply whether we're making an impact. And we need to get rid of at least one root cause of the problem to make such an impact.

Sustainability - not just for software

The eight principle of the Manifesto for Agile Software Development encourages sustainability - working in a way that we could "maintain a constant pace indefinitely". Although this blog post is generally about agility, I want to take a detour here: What we do with our planet is definitely not sustainable. We can't continue at this pace for long!


I am currently visiting Ha Long Bay, one of the most beautiful places on earth - if you haven't been here, you will surely enjoy the trip.


The boat tour through the islands is exciting - this is just one of the beautiful tropical islands you can look at. Some can even be explored:

A beautiful tropical island - in danger!

Okay, enough advertising. The beauty of this paradise is already fading - because of things happening somewhere else on this planet: And you and me have a share in this.

The pictures I took from this place look very similar to the picture people a generation ago would have taken - except for one small, almost invisible thing. Almost!

Let me zoom in on this shoreline for you:

The light freckles in the water - everything plastic garbage!

What you see floating in the water here is plastic garbage, brought here from all across the globe: be it America, Europe - or wherever.

The cost of our action reaches far across the globe and into the future.

Every coffee we might enjoy on our way to the office, every instant meal we consume, every snack we grab at the corner of a street, even groceries wrapped in disposable plastic. They all contribute to the problem.

The consequences of our choices are so distant and elusive that we fail to remember that they exist. Our actions create a problem somewhere else on the world, and we do have a responsibility both towards the environment we live in, the people elsewhere who have to put up with the trash we create for them to deal with, and towards our children who may never know the beauty that had been there just a single generation ago.

Here is the suggestion - it's not new, but still a good reminder:

• Think twice before using disposables. 
• Use paper or jute bags instead of plastic bags. 
• Use paper cups instead of plastic cups.
• Leave that plastic straw where it is - drink from the cup! 
• If you're in a position of making or calling for choices what your company should use, opt for bio-degradable (e.g., paper, wood) or reusable material.
• Make your office kitchen and your homes plastic-free.

The bag hanging in that tree - it could be yours!

We can easily work and live at a much more sustainable pace, even without sacrificing comfort.
It just requires some thought.

Let's live at a sustainable pace!