Ding Dong The Witch Is Dead

Sometimes it happens. Sometimes the reviled, evil, pointless, irritating, quasi-undescribable, oily, brown-nosing, self-interested twunt of an excuse for a human being who thinks he's in charge... well... stops. Whether it's a decision to move on, or the scales falling from the eyes of the people who are in charge of him (or should I say "it"), it doesn't matter. One day the news will come "Dickhead no longer works here".

What do you do with news like that? Do you celebrate? Do you sing "Ding Dong The Wicked Witch Is Dead"? Or do you just sigh and move on with your lives. The answer depends on how much of your spirit he knocked out of you. If he's done his job properly (by which I mean his anti-job) then the news will be heralded by a dull acceptance.

Why isn't there dancing in the streets?

It's probably for the same reason that people suspect that his wife may have to put extra make-up on over the black eyes he might have given her.

An organisation can suffer from battered wife syndrome. "Well, yes, he is a bit difficult, but he's really good to us really; he cares about us, he just doesn't know how to show it... and maybe we do stuff wrong sometimes and it annoys him... you know...". This is how the tosser-tyrant manages to keep his position, by sucking the life out of his people.

In time the scales will fall from everyone's eyes and then we can celebrate the new future. Ding dong, the death of tyranny is the start of a new life.

The Knee Jerk Improviser

Sometimes managers need to be reactive. Sometimes they need to be nimble. The Knee Jerk Improviser, with the emphasis on the Jerk, is able to react on the spur of the moment and totally commit to any plan that passes through their brain. The beauty of this approach is that the strategy can be set in a fluid way which only the Improviser can control because it changes so rapidly that nobody else can keep track of it. On top of that, once committed to a bizarre strand of their own imagination, there is no opposing them.

Blocking Opposition
Any opposition to the plans of the Knee Jerk Improviser can be shot down as unreasonable as the opposer cannot possibly have a full and frank opposition to a plan that they don't understand. When opposing a plan of the Improviser, the Improviser is able to add details to their plan, on the fly, that the opposer is unable to have a reasonable argument against, since they have only just heard of them. The plan can be morphed into something which the opposer thinks they partly agree with, while still maintaining the substantive of the Knee Jerk Improviser's original Jerkage.

A team leader or other manager might reasonably object to a sudden change in direction by pointing out that they should be consulted before such decisions are made. However, the Improviser has the perfect argument. "I couldn't possibly have consulted you sooner, I only just thought of the idea". How can you argue against that? Perfect.

Defending Fluidity
The beauty of the fluid argument is twofold. As already mentioned, it's impossible to shoot down a moving target which can immediately morph to incorporate the basis of any argument against it. Secondly, though, it's fair to say that the world is an ever changing landscape; if this is true, then plans must be able to turn at the drop of a hat in order to cope with the change. This appears to those people not charged with executing these ludicrous half-formed pipe-dreams that the fluid planning is the antidote to the intrinsic chaos in the world. Of course, this is not remotely true. The fluid, consultation-free, commitment to any fleeting glimpse of sparkly idea, passing through the head of this moron-turned-leader, is going to cause more chaos than would have existed if the person in question had simply asked around for what their people would like to do.

Wriggling Out Of Anything
Improvisation is a trick which provides a path through any quagmire. If necessary, the terms can be redefined in the middle of a discussion, to avoid any reasonable opposition, and the terms can be partially defined to avoid conflict, as nobody (including the Improviser) really understands what's being suggested, what the next steps are, what the timescales are and who would be responsible for achieving it. In addition, Improvisation, where things are vague anyway, allows the world to be redefined retrospectively, so history can be revised and the Improviser can be painted as the one true voice in a chaotic world of madness - the madness that they created in the first place. Anyone who can see this madness for what it is will be so enraged by it that they will be crippled from opposition by their own sense of impotentence.

Holding the Ear of Management
Upper management won't be able to spot the work of the Improviser as being a slippery nonsense. This is because the Improviser is able to convert the impossible challenges into plans that sound feasible. The Improviser has an answer for everything. If the upper management provide constraints that might make the job harder, the Improviser can simply promise anything, with an apparently reasonable justification. On top of that, the Improviser will revise history on the fly, suggesting evidence that the apparent problems that are being put forward have already been solved by a previous attempt at their just-thought-up hare-brained scheme.

How can management refuse a voice that has the immediate answer to everything that they're making up? It's even harder for them to refuse this voice if they themselves are using the same improvisational techniques to propagate their nonsense strategies down the hierarchy.

Killing Your Team
Insistence in the face of convincing evidence to the contrary of your whimsical plans is hard, but will, ultimately, make people expect that you're going to dig your heels in to make it happen. As a result, the battle-worn losers will stop any form of opposition. When things don't work out, there's always the historical revisionism and the renaming of failures and techniques so that nothing seems to make sense and the Improviser is the only person with a strong enough voice to keep things moving forwards. One demotivated team equals one empowered Jerk.

How to Spot The Knee Jerk Improviser
Here are some key phrases:

• Can't we just
• Hey, let's outsource to...
• It's not outsourcing, it's smart-resourcing
• These constraints aren't easy
• Don't call it that
• I prefer the term...
• The benefits are obvious
• We can't do this without...
• It's just a simple matter of
• We can throw a little bit of money at it...
• I know it sounds impossible, but...
• So, we all agree then

Technical Debit

Running a software company badly is easy. Running it very badly is harder. Generally, you've employed smart people, who can spot the bullshit. To run the company in such a way as failure is guaranteed, you're bound to get noticed. Your smart people, natural-born-problem-solvers, are bound to rock up and tell you what they've noticed - the impossible can't be done, and it's being made impossible by the following factors.

In some ways, the idea that your smart people might prevent you screwing up seems like a good thing. However, what if you've promised someone that you're going to achieve the impossible. To turn around and say you're not even going to try to do it would be very demoralising and would make your promises seem like they were flimsy ill-considered folly. To try very very hard, fail, but get something vaguely pass-off-able, would be better, even though it will make all who touch it shimmer with shame. So, you need to squeeze your development team through the mincer of your decisions, no matter how naive, fallacious or plain reckless they were. This works all the better if you simply refuse to believe that your decisions are anything other than reasonable and achievable. It really helps if you liken your strategy to one which worked in some other situation, under different circumstances, with a different problem, team, technology and desired end-result.

So, how do you stop your team beating you and "pushing back against your decision"? This is where Technical Debt comes in. Technical Debt is where you first push your team to deliver some stuff too quickly to do it properly. You assure them that you'll give them time to tidy up. However, you quickly push them again and again into more dark corners. By the 4th cycle, the work will be a cludgy mass of nonsense. Then you can ask them about Technical Debt. This is the missing tidy-up they were meant to do as they went along. Then, you get them to ask for the time to put it right, as though it's a debt that they owe you.

Then you need to go a step further. From Technical Debt you must achieve a Technical Debit. The idea here is to crush the spirit of your technical team, by pressuring them negatively with demanding schedules for the impossible, a sense of accusation over the technical debt, and, and this is the clever part, no opportunity to research moving technology and move with it. Generally, as technology improves, the ability to make stuff gets easier and your team could get better at their work, which will only improve their ability to focus on the impossible/improbable bits of your strategy. You have to keep them crushed and cornered to avoid them causing you to fail too soon and HAVE to back out of your plan.

So, this is where Technical Debit comes in. A chronic exposure to the impossible and the crushing will cause people's capabilities to reduce, thus debiting their technical proficiency, or, will cause your best people to say "screw this crap, I'm going somewhere better" and leave. You can then get the smaller team to limp along, or even appoint a Problem Absolver to confuse matters further.

Technical Debit is inevitable if you want to keep the team down and, by comparison, yourself up.

Problem Absolving Position

Imagine you have a perennial problem in your company. You have a couple of choices for solving it. You can work on fostering a company culture of group responsibility and empowerment, such that everyone recognises the problem as their own and naturally come to solve it themselves. This, of course, is the most effective and long-term solution to a problem. What's more, the emergent solution probably will create some opportunities for further development of the company's capabilities and the staff involved. However, this approach is very very difficult, because it requires a company culture change, involving the hearts and minds of the employees. Frankly it takes leadership which may well be either too hard, too much effort, or simply beyond the sort of person who blags their way into leadership of a company.

This is where the Agilistamistalentalist consultant first gets an in-road into the company. The management know their a problem, so they just hand the problem on to some other mug. The consultant, who can only continue to work while there's work to do, gets to come along and stir things up, providing illusory and placebo progress results to management, while simultaneously working hard to maintain the core problem in such a way as it's tangible, thus keeping them in work.

There is a further pattern that management may also use. This need not exclude the Agil-sultant. The pattern is to recognise a problem and then create a job description which equates to "suffer this problem on our behalf". The idea is, metaphorically speaking, to appoint a messiah who the company can follow for a while, ultimately nailing them to the cross of the problem and watching them die slowly and horribly. The problem may not go away, but the fact that it has a figurehead gives people the comfort that it's not their problem, and even the chance to point at the person and say that it's all their fault that the problem still exists.

Of course, some job seekers reading this may be worried that they're currently looking at roles that might be of a "problem absolving" nature. Here are some clues to look out for in interviews and job descriptions.

• There's a look of "please help us" in the eyes of the grass-roots staff you meet at interview
• The role has a lot of varied responsibilities, all of which look like management, but are at a low level
• The role has never existed before
• The management ask you how you would solve certain very specific problems at interview, and the examples don't sound like they've been made up
• They ask you how long you might expect to take to restructure something - this is a trick question, always estimate it as 10 cycles
• They ask you to be "flexible" on the job description
• They seem prepared to offer a bit too much money
• They're looking to improve abstract quantities, like "throughput" without quantifying what that means
• There's talk of some possible future, where the role will change, once the initial phase is complete

You can take a problem absolving role if you intend to do it for a few months and leave under a cloud. You can take a problem absolving role if you are, essentially, a lazy person and want to do nothing for a few months; if you can report illusory progress of your own, then nobody will suspect you've really done nothing, since the problem was never going to go away no matter what you did. Don't become a problem absolver if you're looking for an engrossing hands-on satisfying job experience. Life's not like that.

Agilistaist Glossary

A

Abolishing testers

ultimately, testers can prove that Agile processes are just as prone to bugs as any other. The placebo effect is maintained with alternative strategies. See Hexaflexagonal Architecture and Quality is in the toilet and flushing

Agilista

one of us, not one of them. See How To Be An Agilista.

Anger

A way of reacting to someone's views to make their viewpoint seem less desirable. See I Am Not Shouting

Antagonist, The

blind to the benefits of anything that involves change. See Team Membership

B

Believer, The

blind to the failings and committed to the dogma, the bedrock of any Agile-attack on your organisation. See Team Membership

Believing

the central tenet of agile. See Seeing is believing.

Blameless culture

How to apportion blame without looking to be to blame for causing blame. See How to turn your company around

Blitz spirit

a traditional British response to attack, involving improved performance despite and because of the difficulties presented. See Keeping Your Job

Boolean

proof that something is true or false, undesirable for the Agilistalist who is spreading falsehood and placebo. See avoid boolean

Bottlenecking

how to use the deepest fears of a production environment to control them, much like Room 101 See Bottlenecking

C

Carpet Sweeper

A style of management involving a big rug and keeping problems out of sight. See How to turn your company around

Chicken

See pig

Claiming success

attaching any incidental successes to your reports to make you look good. Also attaching any unrelated successes. See Production Simulation

Confusion

A means of making people uncertain of whether they are right or wrong. Ultimately you get your way because you're the only person who isn't confused. See I Am Not Shouting

D

Defender, The

perverts the system by following it and adding all the things which would otherwise be replaced by it. See Team Membership

Distortion

How to make people see things your way without arguing the point, simply distort everything until it fits your viewpoint. See I Am Not Shouting

Documentation

unpleasant evidence of what you said you'd do, or what you actually did. See Avoid Documentation.

Dogma

the sure fire way to stick to your guns. Nobody can argue with dogma or they will look foolish. See Making People Feel Stupid.

Dojo

place of learning martial arts. What this has to do with software is anyone's guess. See The Muda of Muda.

Dou Da

A post failure meeting to redefine success. See Dou Da, the art of the retrospective

E

The Emperor's New Clothes

the story of a child who was so blind he couldn't see.

Extrapolation

If something is good, then it's worth extrapolating. See Extreme Programming, Ringfencing and Avoid Boolean

Extreme Programming

programming is turned from a serious engineering pursuit into a dangerous sport. SICK!

F

Fervour

When dogma meets belief.

First line of irritation

a protective group of Agilists put forward by an Agile-meister to protect him against the immediate threat of violence. See Not Getting A Smack In The Mouth

G

Gaijin

foreigner or other.

Gaming

enjoying your work by pretending it's all a game, even though people's livelihoods are at stake. Gaming is also the process of making yourself look better by improving only specific, measured, strategies.See Information Radiators and Game Theory

H

Haiku

a three line verse in 5, 7, 5 syllables which sums something up neatly. E.g. Agile is going\to destroy your company\if you will let it.

Hexaflexagonal architecture

An apparently impossible approach to testing. See Concave Hexaflexagonal Archictecture

I

Illusory progress

the suggestion of moving forward and gaining momentum without any evidence. Can be simulated by simply using stronger language and better excuses. See Reiterative Development

Iterative development

adding features in small almost imperceptible increments. See Reiterative Development

In-fighting

encourage this to take attention away from your empty promises. See Intangible Mist Mystery

Intangible Mist

a fog through which nobody can see your true purpose. See Intangible Mist Mystery

J

Jonah method

how to convey your own brand of uncommon sense. See Effecting Change.

K

Kasa

An umbrella. See also Poppins, Mary

Kata

another martial arts term relating to some sort of training. See The Muda of Muda.

Knee-Jerk Improviser

how creativeness on the spur of the moment can be a substitute for leadership. See The Knee-Jerk Improviser.

L

Local optimum

having reached the point where everything you can see seems to be working really well. Apparently this is not good enough. See Effecting Change.

M

Muda

a waste of something or other, usually your time. See The Muda of Muda and Ohno Not More Muda.

Mug, The

one of the well-intentioned souls paving the way to hell. See Team Membership

Mythical Man Month

the fallacy that some men can work 90 hour weeks without going insane. See The Mythical Man Month

Mythical Man Moth

the depressingly simple pest who flys into the light. See The Mythical Man Moth

N

Necessary Bullshit

The lamentably small amount of nonsense it takes to confuse the simple majority. See Necessary Bullshit

Non-leader

A style of management that's neither peer led nor dictatorial, but somewhere in between. See How to turn your company around

O

Ostrich, The

lets it all happen, regardless of the obvious consequences. See Team Membership

P

Passive Aggressive

holds everyone back with a string of semi-coherent excuses. Repressing a desire to kill. See Team Membership and The Yakisobi

Pig

What you want to be if you want to get anything done. The pig is committed. Sadly, pigs often die before breakfast. See also chicken and How To Be An Agilista (silly metaphors)

Placebo Effect

allows you to appear to be the best thing since sliced bread while the breadbin disintegrates

Pope, The

spiritual leader of the Agile cult. See Team Membership

Poppins, Mary

Chief Agilistaist and umbrella flyer. See Sugaring The Pill and Game Theory

Possessiveness

He who owns the process, owns everything. See I Am Not Shouting

Problem Absolving Position

Get yourself a company scapegoat. See Problem Absolving Position

Process

the most important thing in the world.

Production Simulation

make believe progress seen against the backdrop of a flimsy analogy with manufacture. See Production Simulation

Protagonist

instigator of trouble/Agile. See Team Membership

Pseudo-ML

a method of conveying no information using confusing, but apparently intelligable diagrams. See Pseudo-ML diagrams

Q

Quality is in the toilet and flushing

swirling away from you, but leaving the shit behind

R

Radiator (Information)

How to make the work of your team seem hot with lots of charts See Information Radiators.

Refactoring reality

reality, when spun correctly, will always be in your favour. See Production Simulation

Reiterative development

the process of repeating the same task in order to fix any problems that would lose you your job, while at the same time guaranteeing a perpetual need for your role. See Reiterative Development

Reporting (optimistic)

maintaining the effect of illusory progress by giving good reports, regardless of actual progress. See Production Simulation

Resistor

silent, virtually useless opposition to Agile, drags everyone down regardless. See Team Membership

Ringfencing

protect your position by placing artificial barriers around everything. See Avoid Boolean

S

Salmon method

Like the waterfall model, but uphill. See Parable Of The Yakisobi

Scapegoat

just follow the pointed fingers. If you look at the other end of the arm pointing the finger, you have the cause. See Team Membership

Shoehorning

How to ensure your unified-theory-of-everything includes anything that it shouldn't. See Shoehorning

Simple Majority

The large number of people in an organisation who are too stupid to see through manipulation See Simple Majority

Standards

that which you claim to be raising while simultaneously eroding and destroying all records of it. See Avoid Documentation.

Start the ball rolling

how to make irreversible decisions seem easy and invisible. See Team Membership, Protagonist and Jumanji

Suit (The Agile)

how incremental builds can ruin a good tailor. See The Agile suit.

Sugaring the pill

make bad news seem like proof of how good you are. See Sugaring the Pill

Sweetistics

how to make pseudo-science seem like it's based on rational evidence. Everything tastes nice with sweetistics. See Sweetistics

T

Theory of constraints

the idea that when you hold engineers back from their job they feel angry and constrained.

Truism

something undeniably true which you can say without any need to justify it. Truisms please people and are, largely, irrelevant. They are a useful tool. See Promising The World.

Toyota

the car in front. Also the model for any engineering ideal. See The Muda of Muda.

U

V

W

Waterfall

a method of software engineering which is like the natural flow of water... off the edge of a cliff and into oblivion. See The Agile suit.

White Book (the)

The mystical bible from which all Agile practices derive. Similar to The Beatles's "White Album".

World (the)

what you must promise. See Promising The World.

X

Y

Yakisobi

Fat woman. Useless, pointless, redundant. See Parable Of The Yakisobi

Z

Working at Concurrent Levels of Abstraction

The problem with fooling some of the people some of the time is that there are some people you are not fooling. In order to fool those people, you have to switch method, but if you switch to a different method, then you will fail to fool the original people, since they will be unable to understand the particular tactic you have chosen to fool the second set of people. As a result, you'll still only be fooling some of the people, although in this case, it will be a different subset of the people. You can change tactics some more, but then you're simply switching subsets. This sounds like an ever moving target. However, there is an easy back-door provided.

Each subset of the people you deal with has a specific set of things that they know. You can only engage them on those things. Yet they also have a set of things that they don't quite know, and if you can somehow engage them at the border between what they know and what they don't know, and speak convincingly about it, then you'll wrong foot them. Of course people who know those things that their colleagues are oblivious of, would immediately step in, but that's okay, because you can speak in truisms, thus avoiding them being able to make any meaningful objection. However, and this is the clever part, you select a superset of these borders to attack simultaneously in the same conversation. In other words, you operate your discussion at multiple levels of abstraction, each of which is conducted with references to truisms that people find it hard to both disagree with and understand because they can kind of see what you're getting at, but individually are not equipped to deal with the entirety of it, because you're elusively leaping from borderline of knowledge to borderline, without engaging anything.

Why would someone do such a thing?
This sort of technique is ideal if you want to create the belief that you are in total control of a project. In fact, what you're doing is forcing people to interact to work out what the hell they can practically do in order to resolve the myriad conflicting things you've brought up, all of which look sensible, since they're based on half-baked truisms. As a result of this collection of buzzwords and misunderstandings, your workforce will actually pull together to make a solution, one which they'll show you in the hope that you'll say it was what you wanted. If you like it, then it looks like you were totally responsible for orchestrating it. If you don't like it, then they have to go back to the drawing board, convinced by their own insecurities that they were the ones who didn't quite get some master plan.

If you're simply a bad boss, unable to delegate or operate at a suitable level of abstraction, then this technique will prevent you being caught out. If you're a consultant, trying to keep yourself in business, by creating a dependency on your continued services, then this will keep you in business.

Remember, you can fool all of the people all of the time, provided you know exactly where their insecurities lie. They concentrate on the software engineering while you focus on the combination of social engineering and pseudo engineering.

Getting A Foot In The Door

A reader asks the following question:

I'd like to become an independent agile consultant, having seen the immense amounts of money available for very little effort. The trouble is that there seems to be a lot of other people with the same idea? How do I go about getting my first contract? Do I present at conferences so that people might think that I'm an expert or do I try to claim expertise in some field that I know nothing about, but no-one else claims expertise in? Will I stand more chance of work if I present a paper on a subject I know nothing about? Can you advise any suitable conferences to attend?

This is a very good question. How does one get start with being an Agile coach? How do you get a foot in the door of the organisation? What does it mean to get a foot in the door? Is it good for the organisation, like getting a free gift in a box of cornflakes? Or is it bad, like getting a Stingray barb in the chest? Here are some key tips for starting out:

• The Humble Gaijin - you must not start preaching the word before inducting yourself into the world of Agile. In much the way that there are six degrees of separation between most people and, on average, two degrees between most actors and Kevin Bacon, so the Agile world has a similar ranking. If you have paired with Ward Cunningham, then you have a ranking of 1. If you have paired with someone who has paired with WC, then you have a ranking of 2, and if you have been in a film with Kevin Bacon, then you're probably not that interested in IT.
• Conference attendance - once you have befriended someone in the Agile community, you need to invest in a conference - you need to get them to agree to let you co-present something, or at least help them with the presentation - perhaps you can hang the wallpaper that they're going to use for their next paper-and-strings exercise to demonstrate how to turn your well-educated team into a bunch of childish Blue Peter viewers.
• Find a disciple - while at such a conference you have to network like hell. You need to find someone who is vaguely interested in Agile and you have to ensure that they know very little about it. Then you can begin the process of apparent reasonableness which suggests to them that the rewards of Agile can be brought to their company in such a way that their management will hear what they want to hear and perhaps promote this poor trusting fool in the process.
• Blog like crazy - this blog is a good example. The more apparent sense you've written, the more people will apparently believe you. You can refer people to your website and even justify spending consultancy time updating the site "because it's for the benefit of the company". The blog will give you a mystique - especially if you register it with various off-blog communities, like ridi.culo.us or upmyown.ar.se
• Presenting a paper - a paper would be bad, but an online white-paper stating the flaming obvious and then relating it to some obscure Japanese martial art (incorrectly) would be useful.

Essentially, this business is about reputation. If you can find someone less famous than you, then they will assume that you have more reputation than you have - they can be the Jenna Elfman to your Kevin Bacon and you're in business. It doesn't matter that there are loads of clones of Agile-consultancy out there. The process is adaptive and while there remain software companies who think that their perfectly sensible processes can be improved on (and they always will) then there are bound to be suckers for your particular brand of self-indulgent common-non-sense. Remember the words of P.T.Barnum.

Oh, and conferences are always a good idea, my advice is XPDay, which is neither a day, nor about XP.

Any More Questions

Following the successful Questions and Answer session back in June, here is another chance to ask questions of the Agilissimo himself. If you want to ask a question, just write it on the front of an index card, and write the expected answer on the back and then stick it to a pinboard.

Alternatively, just post your thoughts in a comment on the back of this post. All questions will be answered... unlesss they're not.

Is AGILE Dogmatic Enough

There are two answers to this. One is "yes". The other answer is more complicated. It amounts to "no", but it would be worth exploring why Agilogma (the dogma of Agile) is not yet at its naturally dogmatic extreme. Surely the principles of Extreme Agile will lead us to a full-on dogma, more resolute than current Agile practice, and worth of the name Agilogmatics. In time, Agilogmatics will be seen as the delivery of the ultimate promise of Agile.

Why Dogma Is Bad
Dogma is bad because sometimes people notice that it's based on unyielding, unflinching blind faith and seems almost irrelevant to their lives, their work and their life's work. Dogma, when spotted, can be easily dismissed as nonsensical dogma. This is, of course, very bad.

Why Dogma Is Good
Alternatively, "love is not love which alters as it alteration finds". In other words, a yielding doctrine isn't worth the paper that it's not written on. So, it's important to be able to sell the Agile process and everything else as an absolute. If it appears to be flexible, then it will appear to be made up, and anyone can make up a series of irrelevant principles, so why should the Agilist be special? So, it must be possible to demonstrate the dogmatic nature of Agile in order for Agile to exist at all.

If you can make it look dogmatically strong, without making it look dogmatically insane, then you'll get away with it.

Why Agile Isn't Dogmatic Enough
In many ways, the problem with Agile is that it intentionally tries to go about anarchically fitting the team and the problem. It does this with dogma, but hooks into the team with the apparent flexibility to fit the existing people and constantly changing problems. This leads to a conflict. Something can be dogmatic and flexible at the same time. Yet Agile is dogmatic in its flexibility and emergent processes... though it can only work with the dogma of pairing, refactoring, annoying people, being smug, disinformation, misinformation, misdirection, misappropriation of consulting time, reading of stuff about Toyota, and constant interruption. The conflict comes from the the flexibility.

Were Agile to specify exactly how everyone should behave and exactly what the problem should be, then it would be so easy to enforce that people would have difficulty arguing with it, even though they'd stil be unable to make it work.

How Agilogmatics Will Be The Golden Bullet
Agilogmatics will not be a silver bullet, because there are no silver bullets. However, it might become a golden bullet because that sounds better. Basically, the Agilogmatist will declare that they are going to force change on an organisation by the forced implementation of a series of counter-intuitive processes. That they're counter-intuitive will be seen as (because it will be shown to be) better than intuitive, because it takes genius (and salmon) to swim upstream. It will even be possible for the Agilogmatist to declare exactly which subset of the personnel and problems of the company they expect to revolutionise in this way. It will be unswaying and relentless and will last as long as the consultant espousing it can continue to draw his consulting fee.