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.

The six-step agile transition coaching model

What does a coach do - and how does a typical agile coaching engagement look like? 

This is my personal model - it may also serve as a discussion basis for others.

"What does an agile coach do?" - this model is an attempt at answering the question.

Stage 1 - Engage 

(with the as-is-system)

Judge not, that ye be not judged.
For with what judgment ye judge, ye shall be judged: and with what measure ye mete, it shall be measured to you again.

- The Bible, Matthew 7:1-2

In the first stage of a new client engagement, I engage with teams, management and business stakeholders. Even though I may have (deep) industry expertise already, I start with a blank slate. I look around, I listen, I ask. Regardless of what I encounter, I remind myself that people have reasons for doing what they do, for thinking what they think - for saying what they say.

I have no opinion in this stage. I am like a dry sponge, absorbing information.
In the Engage stage, my notebook fills rapidly, maybe 10-20 pages a day and not much precipitates, because nothing of what I write would be new for anyone who has been within the organization for a while.

The outcome of the Engage Stage is nothing more than a book of notes which nobody except me gets to touch.

How long does the Engage stage take? Depending on the complexity of the organization and intended change, anywhere from a few days to several weeks.

Stage 2 - Prepare

(the as-is-system for change)

Grace to accept with serenity the things that cannot be changed,
Courage to change the things which should be changed,
and the Wisdom to distinguish the one from the other.

- Reinhold Niebuhr, "The Serenity Prayer"

Every organization has to deal with certain circumstances. Some are mutable, others immutable. And even some of the mutable things may not be ready yet. Change strategy and communication is a very unique process, different for every single organization.

In this stage, I make proposals and verify them for feasibility. I still don't seem to be "doing" much -  the approach needs to be tempered by the current reality of my client. Bringing my client to a different reality doesn't depend on me - it depends on them: what they can see, what they are ready for and what they are willing to do.

The outcome of the Prepare stage is a transition strategy picture - I prefer to have a single page showing the Vision, main Objectives and a transition backlog with prioritized, sorted Key Results.
(it would be preposterous to say that the picture doesn't change - that's what being agile is all about!)

Depending on how available and open clients are for providing input and feedback on the strategy, this, too, can take anywhere from a few hours to several weeks - it becomes a drag in organizations where people are continuously "too busy to improve" and really fast if I can get people into a Workshop.

Stage 3 - Build Up

(something new with the people)

I'm focusing on the issues that bring people together and build broad majorities.

-Doug Ducey

In this stage, I work with the transition backlog to establish agile processes, practices, structures and mindset. The backlog allows me to focus and not overburden the client with too many parallel changes. What gets built up how in this stage depends on where the client stands and what they are ready for. It's not a linear process, it depends on continuous, deep feedback.

People can be built up in various ways: Formal training in frameworks such as Scrum or Kanban or methods such as BDD can open new horizons. Practical guidance, such as support in setting up the Backlog or offering insights into how to hold effective Reviews, boosts capability. When the a process gets reworked, I may propose unknown alternate approaches and then encourage independent experimentation with the process. 

This stage is the main stage where my own understanding of agile practices matters most, as the client usually simply doesn't know what they don't know or why the things they do won't get them where they want to go.

The outcome of the Build-Up stage are people - teams, managers and stakeholders - who have gained a new understanding and are equipped and ready to try out something new.

Since there is no universal definition of what it means to be "Built Up" and no objective standard for "feeling ready", this stage also depends strongly on the client's people and culture. The coaching process starts to become diffuse here, as some people might be in the "Strengthen" or "Support" stage already while others are still in need of building up.

Stage 4 - Strengthen

(new beliefs and practices)

Difficulties strengthen the mind, as labour does the body.

-Seneca

During the Strengthen phase, I help people to familiarize themselves with the new practices and ideas in their daily work. That could be anything like taking a look at the Kanban board and asking about queues or WIP limits, helping teams increase the effectiveness of their meetings, moderating Retrospectives to bring forth significant change and also individual coaching on the job - such as pair programming with developers, developing value propositions with Product Owners or walking Gemba with management.

The outcome of the Strengthen stage are people who feel confident in using new practices and who are willing to think in new directions.

It depends too much on the individual to answer how long it takes to continue through the Strengthening stage, as this is really a highly individual matter.

Stage 5 - Support

(others as they go their own way)

Believe that anything is possible when you have the right people there to support you.

-Misty Copeland

In the Support stage, my coachees anchor a new mindset. I work mostly to build up a self-sustained habit of feedback and growth while the show belongs entirely to the client (both teams and managers), who often habitually fall back into old behaviours and thoughts.
I coach by reminding people of their positive achievements, helping them discover and take the next step on their own, while also holding them accountable when they resort to behaviours they had decided to abandon.

The outcome of the Support stage are people who have made feedback and reflection a habit, who have no need of myself in their daily business.

The Support stage can be stable with a low amount of engagement over a prolonged period of time, but may be optional when the client has established internal mechanisms to create closed feedback loops.

Stage 6 - Journey onwards

(to new horizons)

Every day is a new day, and you'll never be able to find happiness if you don't move on.

-Carrie Underwood

Every journey comes to an end as the destination is achieved, and a new journey with a new destination starts. The end of my journey with a client is the beginning of their journey without me.

When bidding farewell, I like to part ways knowing that my client knows where they are heading and which are the next steps they will take, so we best close with a Retrospective to create a clear vision for the future of my client.

The "Journey Onwards" stage ends with the order - although I may still retain informal touchpoints  irrespective of budgets or commercial gain. After all, we're human beings whose relationships shouldn't depend solely on money.

Closing words

Sadly, most clients only plan budgets until Stage 3 - "Build Up", which oftentimes results in organizations reverting to old habits and practices, lacking understanding how they are damaging their own progress.
Although this is the normal case, I prefer to work with clients who take care to complete what they have begun.

Equally saddening is to see coaches/consultants who purposely create dependencies upon themselves, never enabling the client to take autonomous control because doing so would dry up their revenue stream.

I feel it fair to inform my clients that "A Transformation isn't done with 1-2 months coaching", and that my engagement will quickly diminish once I am confident that they can do it, which neither means that I am suddenly disinterested nor that it's already a good time to stop.

Goal Setting in an agile organization

Is your agile team is on track? Are you making progress? How do you know? Here are some tips to keep in mind.

You will notice in this article that nothing has anything to do with a specific agile framework or even with "agile" in general. Indeed, the remainder of the article will avoid the term "agile" completely. The suggestions are still fundamental to agile transition, because without these things, you're in for a trip to Wonderland!

Take your time and define, step by step, in the order presented in this article, the following items:

Mission

Where do you want to go, as an organization? Why does the organization exist, and what will be different because of the work that people do?
"To earn money" or "To pay the bills" won't cut the cake, although that's obviously something a company wants to be able to do. Your mission should discriminate you from the broad mass, giving guidance on things which the company would do and wouldn't do while being simple to remember.

Here are some guidelines when setting up a mission statement:

1. Length: People need to remember it. Five words - maximum!
2. Clarity: Provide meaningful guidance and direction.
3. Breadth: Include everything you really want to - or are already - doing as a company.
4. Focus: Must allow people to align activity.
5. Avoid slogans: Must be useful as a yardstick in everyday work - and not just for marketing!

Examples:

• "Improving work" is a legitimate mission for a consultancy,
• "Delivered." would be a feasible choice for a logistics company,
• "Everything covered" might be appropriate for an insurance.

These statements are broad, yet focused - short and clear and can be used as a discussion point when discerning whether an activity is in line with the company's goals or not.

A mission statement isn't immediately actionable. It's guiding in nature and should rarely change.

Strategy

From the mission, a small set of strategies should be derived - how do we plan to make this happen?
A strategy is a mid- to long-term plan for moving into a certain direction and should lead to some relevant outcome that is aligned with the mission.

As odd as it seems, this step is often skipped or neglected. Since a strategy is a clear statement of a direction into which we develop the organization, the presence of a strategy is necessary to determine whether you're still on track.
It isn't even necessary for management to define strategy - in many cases, employees have a good idea what strategies they would pursue, but they don't have any means or transparency to communicate this.

Taking one of our above examples, if we have "Delivered" as our logistics company mission, the following strategies might all be valid options:

• Enter grocery delivery market.
• Partner with company X and employ their delivery network.
• Pivot Drone Delivery.
• Build a Delivery Hotspot Discovery service to monitor and optimize efficiency.

Some strategies might require just a few months, others many years.
A strategy is good when we can tell clearly which set of activities is part of the strategy, when these activities are achieving the strategy - and how the strategy relates to our mission. Ideally, we can also fathom who could be involced and how long it might approximately take.

Strategies still aren't actionable, but they help people deciding for action determine what to do.
Keep the amount of strategies small, as too many dilutes your resource pool and impairs focus. Also, try having more than one strategy as putting all your eggs in one basket is a significant business risk. Two to five strategies are a decent bundle.

Revisit them about quarterly, abandoning those which are obsolete, reinforcing those which are worthwhile and adding one when needed.
Keep in mind: For every strategy you add, you should axe another, lest you lose focus and mess things up.

Goals

Strategies aren't equal, and the things we actually want to achieve might differ as well. This is where we get into the realm of setting SMART Goals: Specific, Measurable, Ambitious, Realistic, Time-bound.
We must be able to figure out how much of what we want to achieve by when - and that should  likewise be challenging and possible.

Many companies have trouble with this step because the wrong people do it. Ideally, goals are uttered by the people who will be working to achieve them and verified for priority, plausibility and strategic alignment by management, rather than enforced top-down. Only when management realizes that the workforce isn't able to set meaningful and important goals, should they feel the need to intervene by providing more clarity and context.

All goals are not equal.
Strategic goals might take years to achieve in a stepwise process, operative goals may be met fairly quickly and tactical goals could be succeeding each other in rapid succession.

The importance is that depending on their nature, they're frequently revisited and constantly verified against their alignment both with the strategy and mission - as well as with other goals the organization might be pursuing.

Transparency of goals is important to prevent the accidental pursuit of competing goals as well as enabling collaboration between people pursuing synergetic or overlapping goals.

When goals conflict with each other or strategy, everyone should feel free to have a voice and raise their concerns, as working on such goals would result in a loss of time, money and opportunity.

A problem with goal-setting is that when undergoing change, goal-setting isn't a straightforward action. Larger goals need to be achieved incrementally with intermediate checkpoints and feedback loops - another thing many organizations get wrong. Either they forget to feed subgoals back towards overarching goals, or to act upon information that a goal no longer makes sense.

Goal-setting on different levels should be a frequent exercise, but when a goal hasn't been pursued or seen progress in months, then that goal can be considered obsolete for all practical purposes. Don't bother with these - axe them. The shorter the time between goal-setting and seeing their achievement, the faster the organization can act.

Actions

Goals need to be met somehow, so some action must be initiated. Regardless of whether this action is an initiative, a program, a project or even just a small task - it needs to be clear who is responsible for the action and how we can know whether it was successful.

As one action could contribute to more than one goal, or one goal could require more than one action, creating clarity between the relationship of goal and action is essential, although the only people who can do this in a meaningful way are those who set the goal and who will be executing the action. If these people don't know - nobody will!

Since actions are only required to achieve goals, depending on the complexity of the work, it may or may not be important to make these actions transparent. When people's actions could block each other, these people need to communicate. Other than that, actions and their tracking are irrelevant.

Results

Every action should have an outcome - and that outcome can be as intended, or otherwise. It's a good idea to define the intended outcome right alongside the result, in order to assist the execution of the action.

It's essential for those who complete an action to know the intended results and correlating goals, as this is the yardstick for progress. Performance should move away from amounts of action conducted towards results achieved.

Results are the compass for action:

• When results are moving away from the intended goal,s the action needs to be revisited immediately. 
• When results are moving towards the intended goals, the action is on track.
• If an action proves to be ineffective, it needs to be changed.
• And when the intended goal is met, it may be time to either complete the action - or set another, maybe more ambitious goal.

Results should be revisited frequently and feed into their goals on at least a weekly basis. While "no result because no action" is an acceptable explanation, this is a clear indicator that something should be done in this context:

• If the result is important, it needs to be prioritized for action
• If the result has become obsolete, no further action needs to be taken.

Conclusion

Let's return to Alice and the Cheshire Cat for a minute.
If you don't know where you want to go or why you would want to go there, or how you would know whether you have arrived - it doesn't matter which way you take.

You need to have your mission defined ("where you want to go"), so you can state which strategy you want to pursue ("which way you go") and by defining goals with verifiable results, you can even discover whether you've gotten somewhere.

If you lack these three components, you will still get somewhere, eventually - but whether that "somewhere" is where you'd like to be, is a completely different story.

Just like Alice didn't know Wonderland and she had to explore, we often define goals without knowing the way and discover midway that both the goal and our action was maybe not the best choice. Still, we are where we are and have to move from there, so our process of locating ourselves, and determining the next step are essential.

The more frequent and painlessly we can go through the feedback process of Goal-Intention-Action-Result, the better we become at getting where we want to be.

And to close with the Cheshire Cat:
"You sure do that, if only you walk long enough".

Agility- a matter of survival

Why would we even want to "be agile"? 
Claims of being faster, cheaper, getting more software done are all based on anecdotal evidence and may not be true for an agile organization. 
Here is a different take.


Before we dig into the key questions, let's start with a few statements that I'm not going to back up here for brevity sake.

Digital Disruption

Digitalization means a lot more than just having a corporate website, having IT systems to support your business or even taking advantage of hyperconnectivity to access business information anywhere.
It means that analogous business models are getting disrupted - and if you don't do it, someone else will do it.

There are two types of disruption which can occur:

1. Business disruption: A player invades your market with faster, cheaper and more reliable processes. By the time you caught on, customers have made their move. The good news: You still have a chance to hang on to some of your business if you're fast enough.
2. Market disruption: A player learns about your business model, then creates a service which renders that model obsolete. Since your business is centered around your current market, the business will die with the market. The bad news: Any attempt at returning to former status quo is futile.

Disruption is inevitable. Just to give a few examples:

• Amazon sends retailers packing (pun intended)
• Digital photography threw Polaroids off the market - and the market for digital cameras caved in to smartphones
• The Internet has removed the need for Pneumatic tubes in offices
• Outlook has eliminated office mail delivery
• How many postcards do you still receive in the age of Instagram, Facebook and Twitter?

Your business model is in danger. If you're not the disruptor, you are going to be disrupted - and when you're not up to speed, you have already lost the game.

Being agile is not about fancy stuff IT is doing. It's about remainng relevant on the market. In terms of the Kano Model, agility isn't an Excitement factor: It's a hygiene requirement. You don't win because you're agile. You will lose because you aren't agile enough.

Here are four questions you can answer yourself to see whether you are sufficiently agile:

How effectively do we meet market needs?

Digital organizations cut out every possible manual activity from the value stream and focus on creating scalable business models. A no-touch automated process can serve a billion users at (pretty much) the same cost as it would serve ten users. Likewise, any activity not helpful in meeting the goal of satisfying customers on the market is up for scrutiny: if it can be eliminated, it will be eliminated.
A digital organization would think twice about having non-essential functions as part of their business operations. Any activity which can be outsourced, automated or purchased as a service with a benefit to the core business model, will be.


Questions:

• Do you spend more time meeting business needs or customer needs?
• How closely are you aligned with the needs of your customers?
• Are you improving existing SOP's or are they creating new capability?
• How intertwined are software services with your way of meeting customer demand?
• Which touchpoints between you and the customer could be digital - and how many are?
• Which means are you using to recognize how in touch you are with your customer's needs?

What are we doing to learn about our market?

Digital organizations don't give tasks to IT after others have discovered what is going on. They mine for information and creates business opportunities in the way a journalist hunts for the next story. Sometimes successful, sometimes unsuccessful, but always in an attempt to be the first and best. Agility is but the necessary means of jumping in early and pulling out fast.

Questions:

• Who in your organization understands how the market is doing? 
• When the market shifts, do you realize this early, when the symptoms arise - or too late?
• Do people understand where to look and what for? How do you cover blind spots?
• What role does IT have in generating and analyzing market knowledge?
• How do the information flows in your organization look like?

How do we sense shifts in markets?

Digital organizations create markets, divert existing markets and take the profit out of current business models. As new options for customers arise, old options become unwanted or obsolete. Consumer needs change with digitalization. Can we be the first to offer options to meet the changing needs, are we trying to get a slice of the cake before it's too late - or are watching the ship leave?

Questions:

• Is your market growing, shrinking, stagnating?
• How do you learn about market shifts?
• How do you know that your information about market shifts is reliable?
• How do you decide where to dig in and where to withdraw?
• What are incumbent players in the same market doing?
• What new players have appeared recently, and how are they operating differently?
• In which ways are you actively working to create market shifts?
• How would you shift the market in your favour?

How much does it cost to change direction?

Digital organizations are aware that markets change. They realize that changing direction early, fast and often is the most effective way of meeting customer demand. Instead of investing heavily into retention programs to keep customers bound to a dying business model, they reshape their business model to be what customer want it to be. They constantly run experiments to find new opportunities and cut off lost opportunies as soon as a ship starts sinking.

Questions:

• What happens when your activity is out of sync with real market needs?
• How much time are you spending on things you could simply buy as a service?
• What happens between the discovery of an opportunity until it is captalized?
• Which factors prevent the immediate removal of an unprofitable capability?
• How much opportunity cost do you tolerate because of late change?

Conclusion

None of the above has any specific relationship with "an agile framework" and the questions aren't even specifically linked to IT. Digital organizations are driven by technology and are inherently agile because of low cost of change and fast response times.

Do not confuse means and ends: Agility isn't a tool to get better at doing what you currently do - you can move, evade and explore new threats and opportunities better when you're agile.

Becoming agile is the active, relentless and uncompromising quest for new and better ways of meeting customer needs.

Agile in the Value Stream

Many organizations claim to be agile without ever having understood what makes a company agile. They bought an "Agile Transformation" - and think that afterwards, agility is achieved. What does this look like, why is it fake - and what is the difference?

Fake Agile

Let's take a look at a typical organization value stream for software delivery:

Being agile without customer contact never worked!

In the beginning, there's Marketing, Presales and Sales, all talking with the customer, discovering what the customer needs and is willing to pay for. Once a contract is signed, the project is planned, requirements are formulated, some code is written, tested and then deployed.  All straightforward.

When the organization realizes that customers aren't getting what they want and/or are getting it too late or expensive, managers are looking for a way out. Enter: "Agile", most notably: Scrum. Scrum uses terminology like "Development team", and since most people equate "Coding" and "Development", Scrum is being introduced as the miracle pill in the Coding stage of the value stream and the organization expects all problems to be solved.

Developers are still not in touch with customers, work off specifications and hand off bulk increments into testing, where then defects are discovered, reworked, launch is delayed - and nothing has improved.
Even though this form of "Agile" might improve the amount of work done by developers and slightly reduce the overhead of getting code finished, in the big picture, even a 100% effort reduction in Coding would still only reduce the overall effort of getting a project to "Done" by a mere 12%.
Since a 100% capacity increase in coding - which is a massive stretch for most organizations - performance is merely a 50% reduction in duration, it's almost impossible to achieve a statistically significant (thereby, visible) improvement in organizational performance across the value stream.

This kind of organization tends to be trimmed for efficiency, where each department tries to both maximize utilization and minimize their own cost.

Even if coders were absolutely perfect, worked in zero time and for free, the overall approach would still be staggeringly slow, ineffective and not satisfying to the customer. This is why such an approach to agility is fake.

Genuine agile delivery

An agile organization is most notably different in one aspect: The customer is at the heart of each activity. Not "fake customers" like sales who, although demanding something, are not those who actually will be using the product - but the real customers who are interested in using the product themselves:

Customer Centricity in everything we do

What makes things slow, unreliable and expensive are the handovers, where delay is introduced and information is lost. We need to drop organizational barriers and let everyone talk with the customer as needed. Departmental priorities need to be replaced by product priorities. Everyone needs to collaborate with each other and the customer in achieving one common goal: maximizing the value delivered while minimizing overall effort.

Coding is no longer the focus of being agile - not even IT as a whole. Indeed, the focus shifts away from activity to outcome. What matters to business success isn't that IT can get their job done, but that the customer gets what they need! Everything else will fall into place accordingly.

In this kind of organization, some things don't appear to be efficient. The same discussion may happen multiple times (which is still better than working against unfounded assumptions) and cost is fixed, irrespective of workload.
Agile organizations optimize for effectiveness, i.e., getting things Done in a way that pleases the customer.
This only makes sense from a system's perspective, not from a departmental perspective. Hence, it's important to include everyone in such a process. Any function not included will end up a bottleneck and could block the flow.

Fully agile enterprises

I omitted "Operation / Maintenance / Customer Service" functions in the above model, even though these are equally (and potentially more) important. This breaks down the final barriers beyond "Done", integrating practical experiences with the product into the feedback loop as well.
In the ultimate stage, every action is aligned with customer needs and every piece of learning harnessed for competitive advantage.

Conclusion

Contrary to popular belief, "being agile" isn't something limited to software development. It's a way of running an enterprise that revolutionizes how we think about value streams and value generation.

While the first hurdle in an agile transition is often rewiring the brains of developers to move away from meeting requirements to understanding customers, it by far isn't the biggest. The biggest hurdle is breaking out of a limited IT setting - and opening the doors for the collaboration of all departments for one common goal: business success.

The system: People

To successfully change the culture within an organization, we need to understand the system we are operating in and how people within that system interact. This isn't as simple as it looks, so here is a standard map ...

People and Interactions over Processes and Tools ...

The above is a proximity model, where people who are more likely to interact are drawn in close vicinity. YMMV.

Your team

The first circle is your team. In case of Scrum, that would be the developers, the Product Owner and the Scrum Master.
Who interacts with whom, and how should these interactions look like? The Scrum Guide has a few things to say on mandatory Scrum interactions - for example, Planning, Refinement, Review or Retrospectives. Those are the objective, process-driven interactions.
What the Scrum Guide can't help you with: Who likes whom, who can work well together - and: which factors bring people closer together or further apart?
Detractors could be obvious stuff like different work ethics, fandom (Star Wars vs. Trekkies, for example), skill animosities (e.g, tester vs. coder) but also hidden things like subtle bigotry, not liking another person's choice of diet (e.g., garlic/onions) etc.
All of these will affect how well your team can interact. The good news? All of this is within your team's sphere of control - as long as you can talk about it, you can find a way to knit together.

Your organization

The second circle is your organization. Most traditional enterprises have roles such as team leads, middle managers, senior managers, finance, HR, marketing, sales, customer service etc.
All of these people will affect your team one way or another and the potential interaction points are already too many to count.
While the Scrum Guide states that the Scrum Master should protect the team from outside interference, it's hardly practical to create a complete bubble of isolation around the team. Especially in the early phases of an agile transition, the direct and indirect effects of managerial roles may still be very strong, oftentimes in detrimental ways. The solution can't be digging trenches - you'll need to provide education on the effects of any influence taken upon your team.
As management finds their new role within the changing organization, the interactions with classic business departments also change: the team gets closer to functions like sales, CSR or marketing - and these people, too, will need to learn which functions are better maintained within your team and which information needs to be communicated straight between the team and them.

I have heard many Scrum masters talk about "drawing boundaries" - while I personally would favour "blurring boundaries", i.e. integrating the different business people in ways that remove indirection and delay, right to the point where information is freely available and collaboration happens without structural limitation.

Immediate surrounding

Your company doesn't operate in a vacuum. There are many second-order interactions going on, the most important being between the customer and your organization. Depending on whether your team is working as business support or in marketable product development, it's a great idea to move the team as close as possible to (in the best case: directly into contact with) the customer.

In traditional organizations, you will see that sales people and marketing try to bond with the customer - which can be both a blessing and a curse for your team. These people, too, need to learn which second-degree interactions are helpful and which aren't. For example, making promises to the customer without consulting the team is oftentimes a recipe for disaster.

Then, there are suppliers and competitors. Suppliers may or may not have the flexibility to support your team's newfound ways of working, which can become a massive problem unless addressed. In many cases, vendors find themselves in an uncomfortable situation when their client(you) is asking for more flexibility, in terms of both contracts and speed.
Your competitors will strive to be more agile than you, so keep an eye on what they are doing at all times. As long as you can learn something from them, you have homework to do. In complex environments, your suppliers will also be working closely with your competitors - which can create extremely interesting dynamics that can become very dangerous for your organization unless properly managed.

And then there's all of those other second-degree interactions: Friends and family, (social) media. You can't possibly hope to change these people and we're quickly talking about thousands of possible interaction points for a single team, yet these do affect your team as well.

Never forget that these interactions are highly intertwined with all the other interactions previously mentioned: a single press release by Markting can cause hell to break loose within your team, while a careless blog post created by your developers could void a year's work of sales currying favour with a potential client.

At least the good news is that up to this point, the interactions are either directly under your team's sphere of control - or at least, they can be influenced one way or another. That means you need to be finding ways to make those interactions favorable for your team.

The world

Life would be simple if everything could be brought under control - but it's just not that simple: Imagine that you did everything right, and along comes a new law that makes your product illegal: What would you do? It's not as easy as having a chat with lawmakers and undoing the law.
There are so many forces far beyond your control which can devastate everything your team is doing. Thought leaders coming up with new ideas which might imply that you've been working in the wrong way, industry leaders disrupting your market segment, political leaders interfering with your entire industry - and you might have no way to deal with it other than to cope with it!

The impact of "world level" interactions can also be both harmful and helpful - for example, a new invention may boost your team (if management lets you take advantage of it) or favorable changes in the market may boost your sales, thereby your financial resources. There are also cases where new laws or political changes might work in your favour and drive customers straight to your company.
These same effects could be positive or negative - in some cases, both. For example, that new helpful invention might boost your team - but also force you to invest heavily into it, draining resources elsewhere. Or that new political situation might drive flocks of customers right to your company - while the necessary customization changes overburden your team!

The world is beyond influence and control. In the Cynefin Framework, it would correlate with the "Chaotic Domain". You can't shield your team from the world's influence on your organization (and therefore, your team). Unless you're in a highly lobbying segment with massive public influence,  you can't tell the people of the world how they should behave, and you can't educate the world, either.

When it comes to interactions between the world and your organization, your only strategy is - adapt. That's what "being agile" is all about.

Summary

None of these interactions can be completely neglected - yet which of these interactions are crucial for whom, and when, constantly changes, so you're shooting at moving targets.

I hope you liked this small introduction into "People of the System" and what their interactions mean for your team. If you are an agile coach, understand that you can't always work on all of these, so you will need to observe the most important interaction points and work directly to make them favorable for your team.

"Being agile" means making the interactions within your sphere of influence more favorable - and learning to get along better with the interactions that influence you.

Not Scrum - not a problem

We have been warned in our CSM training: "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum." - any deviation from Scrum leads to a dangerous "Scrum-But" - or worse ... so, you should stick to Scrum as per Guide!

Is that even a problem? Forget it!

Why would we even care if "the result is not Scrum"?

Here are a few examples of "results that aren't Scrum" ...

Unless you are in the business of producing and selling Scrum - why would it even be a problem if "the result is not Scrum"!

Scrum is but one of many means of achieving better business outcomes. It is neither a desirable outcome, nor the focus of your attention - again, unless you're making your money from Scrum.

As agnostic agile practitioners, we aren't forced to sell Scrum. We're trying to help our clients achieve better relevant business outcomes - more sales, more revenue, new markets, happier customers. If Scrum helps us get there, we're happy with Scrum as far as it helps. When Scrum becomes a distraction or an impediment - we'll gladly throw Scrum as per Guide overboard and do something else that works.

 "If you deviate, the result is not Scrum!" is a kind of fearmongering that only works on those who don't know that there are other, equally valid approaches. There's plenty of them around.

Five signs you've got the wrong agile coach

You've set out to begin your organization's "Agile Transformation" and, lacking the expertise, you've brought in external consultants and/or coaches to make the endeavour successful. But since you're not agile yet, how do you know whether you have the right people on board?
Here are a few pointers that will help you identify rotten eggs - i.e. you can be almost certain that after the consultants leave, the show will be over, and best case you've only wasted money for nothing.

#1 - Lack of Battle Scars

Having the seniority to assist another organization in their agile transformation, the coach should have a lot of war stories to tell. Stories of experiments, pitfalls, troubles, joyful moments and cheerful victories. Stories of what they have experienced firsthand (not hearsay!).
What people tried, what they set out and where they landed - the differences between intent and destination, the obstacles and dangers on the journey - the small nudges that made the difference and so on.

If you see that the coach either has little to say from personal experience or is only quoting others ("double-hearsay"), beware!

#2 - A shelf full of solutions

It doesn't matter what your problem is, they already have the bottled solution ready! Just follow their advice, and you will become Agile. NOT!

Especially when they promote solutions as a silver bullet, i.e. universally applicable without concerns for context - you're in for trouble.

#3 - Change without change

Following pre-concocted agendas, outlining the change on fancy slide decks without ever talking to the people doing the actual work or knowing the real struggles they have isn't going to work.
The first three questions I would expect to ask: "Why would you want to become Agile?", "What will be different in a year?" and "What have you tried so far?".
If there are no comprehensible answers to these three questions: what exactly do you expect as a result?

#4 - Not rocking the boat

Many experienced consultants have learned to avoid challenging status quo and messing with people in positions of power. This is a great approach to maximize the amount of billable hours and to please those who decide whether their contract will be renewed.
As attributed to Einstein, "Problems can not be solved with the same mindset that created them.", it's essential to rock the boat - to identify and tell people about the root cause assumptions which lead to the problems that an agile transformation is supposed to solve. And if key decision makers aren't aware how they are contributing to the problem - how would they know what they must change to solve it?

Consultants who only compliments senior management aren't going to make an impact.

#5 - We've got this!

Probably the killer criterion for spotting fake coaches: They can do it by themselves! They have so much experience and expertise that whatever is brought to them, they have the right answer. Senior management doesn't need to involve at all, because the coach knows how to handle everything. Teams don't need to worry, because the coach will teach them everything they need to know.

The coach who offers the solution without teaching you how to find your own solution - doesn't help you learn, and if you don't become a learning organization, you're not going to be agile.

Conclusion

I would like to conclude with my favorite TheraminTrees quote, "People who don't want you to think are never your friends!"

A "coach" who doesn't make you think and challenge how you think - is the wrong coach.


Sour aftertaste? 
Let's fix this: Here are ten signs you might just have found the right coach!

Thought Reform and Mind Control in the Agile Community

How do we know we're making progress towards a meaningful goal? Are we following a carrot on a stick - or even worse: are we being led astray in our attempts to become more agile?
Has the agile community gone too far in their attempts of making agility a lifestyle?

I feel the need to write this post because I recognized some patterns in the agile community which I know all too well from the years of my life I spent studying and discerning the phenomena of psychological abuse. 


But let me start from the beginning.

DISCLAIMER

This article isn't singling out anyone or pointing fingers.
It's not about calling, labelling or stigmatizing anyone.

 Instead, it is an invitation for each of us to think where we ourselves are heading with "Agile".
Are we shaping an aspirable future with our words and actions?

If you feel that this article is talking about you or anyone you know, ask yourself: "Why?"
Why are we seeing those behaviours in the agile community?

Dangerous Behaviour

In this section, I will examine a list of behaviours based on the four common domains of "Mind Control" - neither with a claim that some specific persons would do all of these nor with a claim that some of the can't also be found elsewhere, just with a note that these behaviours raise a red flag. For brevity's sake, I am going to limit this to central points that are most notable.

I. Mind Control

Behaviour Control

a) Major commitment

of time and/or money for indoctrination purposes.This is talking about stuff like requiring attendance at group events and the trainings required to climb up the pre-defined hierarchy.

b) Group Think

instead of individual expression of thought. Society grows by bringing completely new ideas to the marketplace of ideas, then examining these based on their merit, instead of their point of origin. Group think means that ideas contradicting the group's doctrine will be rejected even if they are true and useful.

c) Obedience and Punishment

to enforce compliance. Obedience to the group's rules is paramount to keep order, even if said order is detrimential to growth and learning. Punishment and the threat thereof is used to keep members obedient.

Information Control

a) Deception

taking many forms, from outright lying over hiding facts all the way to distorting unpleasantries in order to make them acceptable. It's pretty much the opposite of transparency.

b) Discourage dialogue

with people who are critical towards the organization and its goals, including outsiders, ex-members and dissenting current members.

c) Compartmentalization

of sources. Information provided by "members in good standing" is good, information provided by "others" is bad, especially when in conflict with the organization's goals.

Thought Control

a) Axiomatic Truth

of any statement proclaimed by the group. There must be no doubt that the official doctrine is true by definition.

a) Black vs. White

thinking. There is no ambiguity and no alternatives. If it isn't A, it is B. This provides the basis for simple explanations to life's complex problems.

c) Us vs. them

mentality: There is no sane reason not to be on "our" side: Everyone else isn't enlightened enough or has a problem.

d) Loaded Language

reducing complex topics to contrite buzzwords. This inhibits, rather than growing, a deeper understanding.

e) Forced positivism

where people may be branded or shunned for "negative thinking".

f) Thought stopping

techniques are applied to suppress the need for analysis, critical thinking or constructive criticism of the group's doctrine.

Emotional Control

a) Manipulating feelings

of people for or against people or ideas by using psychological or linguistic triggers.

b) Blame shifting

towards those expressing ideas inconsistent with the group. Nothing can ever be the group's fault, it must be those who see the problem. Also manifests as: "Shooting the messenger".

c) Use of fear

tactics to keep people silent and in line. This is also combines with:

d) Phobia induction

in current members. Something bad will happen if you follow other ideas, or, God forbid, decide to leave the group. And remember: there are no legitimate reasons to quit - ever!

II. Apologetics

Apologetics is a huge chapter in and of itself. Talented apologists have a massive arsenal at their disposal, with the main goal of silencing dissent. Apologists tactics range anywhere from "working the issue" towards character assassination. Again, for brevity's sake, I will reduce this to an examination to the three core tactics employed by apologists.

Logical fallacy

The largest category of weapons in the apologist's arsenal is the employment of logical fallacies. There are too many to discuss - it's really worth exploring this domain of philosophy to be less prone to manipulation, so we will limit this to the most notable ones.

a) "Misunderstood"

When caught on a contradiction, the first line of defense will be "Ah, you misunderstood". Can be well combined with Loaded Terminology ("join us to learn what we mean") and blame shifting ("YOU get it wrong!") Note that the apologist will do their best to avoid clarifying the real meaning, as this would put the burden of proof on them.

b) Moving the Goalpost

Another powerful bait is to move the topic away from items which can be scientifically examined and scrutinized by changing the meaning of things mid-discussion. Combines very well with Loaded Language ("It means something else") and axiomatic truth ("If it were wrong, we wouldn't say it").

c) Appeal to Authority

or to Popular Opinion. Instead of tangible evidence, names and titles ("Doctor X") or sweeping generalizations ("Everyone knows ...") are offered as "proof".

Making it personal

Instead of arguing or providing evidence about the matter, the person of the critic becomes the topic of discussion in an attempt to "shoot the messenger" to avoid that the message itself needs to be examined. This can range anywhere from:

a) Who are you?

It looks easy to discredit a person who doesn't have the combined experience of those one the other side of the argument by simply stating, "We have industry leaders, professors and scientists - and you are?" If this doesn't end the discussion, they will move on to:

b) Mud slinging

and shifting the dicussion towards personal shortcomings of the dissenter, either in tangible aspects ("You failed at ...") or even their alleged emotions ("Why do you have such anger/hate towards ...?")

c) Character assassination

by providing unsubstantiated reasons why listening to the person speaking the different idea is a bad idea, such as "The person is a fraud, a criminal, psychologically defective and you'll be damaged if you listen"

Shifting the burden of proof

What's more convenient than turning the entire discussion around - instead of "Why should I do X?", let the dissenter explain "Why do you not want to do it?", which allows the apologist to lean back while the critic has to waste time and energy, exposing their thinking and providing additional places of attack for the apologist.

Instead of digging deeper here, let me refer back to Hitchen's Razor: "That which is assumed without evidence may be dismissed without evidence." What this means: If someone claims that a certain thing works, you don't need to disprove that. They must prove that it does.

I also want to combine this with Sagan's Standard, "extraordinary claims require extraordinary evidence" - so the next time someone says that "this always works" or "it can be used in any context", remember: that's an extraordinary claim which still needs to be proven!

III. Change of character

Thought reform modifies people's character in ways that are detrimental to society as a whole. In order to avoid getting too personal to anyone, I will keep this section at short, commented headlines.

Situational ethics

Things which a normal person wouldn't do in normal circumstances are okay when it's required to protect the group's special interests or to further the group's declared mission. For example, being deceptive, outright lying or slandering outsiders.

Need for conversion

Once you believe your group has "The Truth", you want to do everyone a favour by converting them to your group. Rejection isn't taken lightly, as this attacks the very thing you believe in. "They" must be evil if "they" don't take your gracious offer.

Following leaders

The group's charismatic leader(s) offer "The Truth", so what comes out of their mouth must be good. Critical thinking is shut down when words are spoken by a leader. Members of thought reform movements just can't understand why other people wouldn't have the same level of veneration for their leader as they do.

Preoccupation

You don't have time to waste on things such as thinking or interacting with outsiders, as you need to do things which further the agenda of your group. After all, you have an important mission - and it can only be achieved if you're fully dedicated.

Mental shutters

You are no longer open to ideas that conflict with the group's ideology. Instead, you invest time into ideas that are "in party line".

Limited social interaction

You reject people who propose ideas that don't fit with the group - and break "dangerous" relationships, warning others about such "poisonous/toxic" people as well.

Sobriety

You don't understand a joke at the expense of your "truth". NOBODY is allowed to joke about the truth, and you will make sure that those who dare do so get put into place.

Concluding words

Thank you for continuing to this point. It is sad to see that even in the agile community, we see many people who are affected by such symptoms without even realizing. It's even sadder to see when people entrench themselves further in such limiting beliefs and behaviours day by day. Such behaviour is often the consequence of having too much vested interest in this entire Agile/Scrum thing and taking it a bit too far or too seriously.

I would leave you with a few open questions, that you may reflect for both you and those around you:

• Do you see positive growth in character caused by following an Agile career?
• Is there a willingness to discuss the option that there might be the slightest chance that all of it could be wrong?
• Are sound, factual reasons brought forth when contradicting ideas are raised?
• Is there respect and positive openness even towards those who hold conflicting beliefs?
• Are any detrimental behaviours developing, and what is being done about them? 

The Agile / DevOps ecosystem

The question, "How does an organization, especially one that is already using an agile framework, benefit from DevOps?" is very common. In this article, I provide a succinct answer to this question by examining the benefits provided by some standard frameworks.

The development lifecycle

Irrespective of which approach a company is using, it all starts with a customer need:

This need must be understood, so we need to invest some effort into understanding.

In Scrum, we call this "Refinement". It could also be called an Ideation or Prototyping process. Regardless of how you call it - it's essential to build the right product!

Once understood, our next job is to build something. Any kind of iterative approach encourages us to build just a little, then learn from that. We want to minimize our upfront planning efforts and jump right into doing delivery work. In Scrum, that's our timeboxed "Sprint".

The objective of delivery is to get something shipped right to the customer, we want to make the product available. This is often called "Minimum Viable Product", in Scrum we call it the "Product Increment".

When we got the product out of the door, we want to learn how customers respond to it. This is where most agile implementations disconnect: Scrum has a "Review" - although the Review still happens disjoint of both the problems and opportunities arising when our product hits the shelves!
What happens in the "Real World" becomes the job of Support, Customer Service or Marketing.

This final piece of the puzzle is vital to build an even better product in the future. We want to iterate a full cycle in increments as small as possible:

The business opportunities when integrating this cycle are immense: Anything that is of value can be turned into revenue, anything that wastes effort can be turned into saving. To harness this potential, it's essential that a single team has the ability to recognize and create these benefits.

Now, it's time to take a closer look at some agile frameworks:

Standard frameworks

Scrum

Scrum is the most common framework. It excels as a delivery framework. Based on the Scrum Guide, it neither cares for what happens in order to get the right items into the Product Backlog nor what happens after the product increment has been delivered.
A small fly in the ointment is that Scrum scopes the timebox: it doesn't bode well for a Scrum team to deal with unplanned work. Yet, everything that happens with customers in real time is hardly planned, much less does it make sense to plan it upfront.

Kanban

Like it's cousin Scrum, Kanban focuses strongly on optimizing the delivery process. Kanban provides less emphasis on getting a planned shipment through the door, offering higher flexibility in dealing with unplanned work. Teams that have productive maintenance responsibility often fly well with Kanban.

Side note: Scaling Frameworks

Scrum scaling solutions, such as Nexus, Scrum At Scale (S@S), LeSS focus on doing the same thing with more people - getting better at delivery. Combining these frameworks with Enterprise Kanban practices, like suggested in SAFe, is still limited to the delivery portion.
While SAFe strongly encourages integrating DevOps, the suggested use of DevOps is still restricted to getting the product through the door in the most reliable fashion.

Design Thinking

It's often adertised that Design Thinking combines well with Scrum, and indeed it does. Design Thinking addresses understanding the customer need through systematic exploration before delving into a more costly delivery process.

Lean / Six Sigma 

Regardless of whether you're thinking Lean, Six Sigma, or the standard combination "Lean Six Sigma" - these frameworks address optimizing our existing product through better insight:

Extreme Programming

Returning to the agile hemisphere, Extreme Programming and some of its derivates, such as Programmer Anarchy, add more emphasis on understanding the customer and providing the right solution for the customer's needs.

DevOps

DevOps is concerned with two things: Getting the product to the customer with minimal overhead and delay - and understanding how the product is being used.
The first, and well-known, portion of DevOps is providing an automated delivery Infrastructure - Continuous Delivery, Infrastructure as Code, Containerization, Logging, Authentication and many other things come to mind.

In addition, DevOps, done well, provide a myriad of analytical insights into the product: which features are being used, how new features are being received, where unexpected things occur, how to solve customer issues etc. This requires more than technical insight - it requires harnessing business insight as well!

The big picture

DevOps is an essential piece of the puzzle towards hyperperformant teams. The full power of an agile team requires a smart combination of discovery and delivery methods. It's your choice whether your team sails under the Scrum, Kanban, XP, none or any other banner - just make sure you cover all of the blocks:

Design Thinking shines for the "Understanding customer needs". Scrum is great to cover the "Doing work on customer needs" section. Combine these two with DevOps to optimize your "Working on the available product - both before and after delivery" approach.
For best results, you might want to add a touch of Lean, an ounce of XP and a pinch of Kanban,

Closing the loop

Let's forget frameworks for a minute. What's important is that you got everything covered. Use Design Thinking where it helps you build a better product. Apply XP where it helps you build the product better. Try Scrum elements that improve your delivery process. Utilize DevOps tools and practices to ensure you're doing the right thing when the rubber hits the road. And never forget - Lean/Six Sigma has really powerful tools that help you do the right thing better!

If you look closely, you will discover that this cycle is an implied "Build-Measure-Learn" cycle, which is the core premise of Lean Startup, yet another framework from the agile bucket.

Closing remarks

No single framework, approach or method is sufficient to deal with the complexity of creating and maintaining a successful product. All frameworks have useful and important elements to offer. Combining them for best results is a core practice of agnostic agile practitioners.