Burberry and Broccoli

Ding Dong The Witch Is Dead

2010-05-07T13:06:00.001Z

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

2009-11-27T22:55:00.000Z

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

2007-07-06T10:58:00.000Z

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

2007-07-06T09:42:00.001Z

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

2007-06-07T09:12:00.001Z

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

2007-02-22T15:57:00.001Z

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

2006-11-08T13:49:00.000Z

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

2006-11-08T11:45:00.000Z

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

2006-11-06T11:15:00.000Z

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.

Telling People What They Don't Want To Hear

2006-11-01T10:45:00.000Z

Nobody Said it was Easy
Nobody said management was easy. If it were easy, then people wouldn't pay managers very much and they wouldn't be able to spend money on all the non-essential essentials like a sat-nav for the BMW which takes them at high speed from their cushy homes to their cushy offices every day. The very thing which makes management difficult is the fact that it's so easy, yet its status is based on the fact that it's difficult. So, the pretense must be maintained or order will dissolve into chaos, governments and bank balances will fall, and managers will have to stop watching their expanding waistlines and do some real work for a change.

There are exceptions to this rule. Usually in the early days of management, the manager will realise that the only way to get results is:

Treat all the people with respect
Don't ask someone to do something that you couldn't do yourself with that same degree of instruction and empowerment
Don't dodge problems
Don't tackle problems too heavy handedly
Keep your temper and keep objective about what's going on
Don't use status to force outcomes
Don't forget status and confuse people

As a result of these early-days managers, some people form expectations that management are a jolly nice bunch who are interested in everyone having a nice life and making a living. This is not where managers end up. In some ways this is a shame. However, if you're the sort of person who intends to make their money from being a manager, or being a consultant that managers rely on, then you're going to have to learn some hard lessons.

The Isolation of Management
Being a manager is never having to say you're sorry. If you did that, then that would be a sign of weakness, right? Well, probably not, but let's assume that your illusion of power is all that's keeping you in employment and that you're no longer able to do any of the actual work that the people on the ground are doing. What you have to do is wield this power through will alone. Sure you can sack people, but that won't get their work done - it might get the work of other people done, if they then come to fear you, but that's not necessarily a good thing, as you'll have to recruit someone to fill the shoes, desk, cubicle, or Audi of the person you sacked. The recruitment process takes effort and you're going to have to put that effort in. Since the person you fired is probably someone you recruited in the first place, you can't go through too many of them before people start to remark that perhaps you wouldn't have had to sack this now-vilified waster if you hadn't hired them in the first place. This logic is impenetrable and self-reinforcing (being that it is, basically, correct) and will give you more problems then if you somehow were able to avoid taking any action over anything.

The threat of an unspecified penalty is always greater than the reality of your semi-impotence.

This is where management starts to isolate you. There are reports up to higher management/shareholders/board/your god. There are demands back down to you and you have to convey those demands to your underlings in a way which somehow causes something to be delivered. The problem is that you don't necessarily know what, how, or when. This increasingly starts to isolate you. The more isolated you become, the harder it is to get anything done, and the more you have to work to keep your role as manager - a role which requires only the maintenance of the illusion that you're doing something. Ironically, the longer this goes on, the more you have to do to make it possible for you to hold a role in which you do nothing.

Dealing With Other Managers
The worst part of being a manager is that you have to have managers around you most of the time. Since they're all doing the same sort of thing as you, they're harder to fool. They're also harder to work with than your underlings' colleagues. Those managers above you are more extreme examples of what you're trying to do, and so they're either going to bully you, or act in such a conniving way that you feel physically sick, partly with fear and partly with jealousy that they appear to be getting away with it and being paid even more unjustly than you are.

To win in this game, you have to be good.

It's All About Image
Again, the aim of being a manager is to maintain the pretence that you're managing. You could try actually doing the managing, of course, but that simply involves going round explaining things to people and asking them if they're okay to do things which they're most definitely capable of doing and that soon gets a) boring, and b) obviously not worth paying a manager to do.

So, you have to project the managerial aura which makes people treat you as a manager. The way to do this is to use psychology. The way to do this well is to use testing, constant maintenance and short cycles:

Testing - you have to try people out - they may not react as you expect, so be prepared to push a little way here, a little way there and see what happens. Sometimes someone is easier to fool than you expected, or has triggers in a different area than you expected. Rather than waste your effort pushing the wrong buttons, probe this and spike that and you'll soon find out what you're dealing with. Once you've established a particular behaviour which they find testy, be sure to keep redoing it, just to be sure that their personality hasn't changed. If things have changed, either change your behaviour, change your test, or give them the apparent support they need to return them to the state they were in.
Constant maintenance - this is a sort of refactoring for management. The idea is that you keep on top of problems in your image as you go along - keep the effort involved in management at a constant, rather than sit back and let imperative-debt grow. Imperative-debt is a residual resentment that builds in your employees making them less and less likely to respect you enough to do as you say. This can be replaced by reflexive-resentment, the process of making your employees believe that the only people to blame for their terrible lives is themselves. While they're busy hating themselves, they won't have time to build proper resentment of you and you'll find it consistently easy to managerise them.
Short cycles - the key to good management is to move the goal posts as your underlings are getting close. If you do this too often then they'll never have any aims, but if you do this after too long, then it will look more obviously like you're making it impossible for anyone to achieve anything, as you snatch a defeat from the jaws of each and every victory. So, by short cycles of imperative, you create a near-term target which looks hard to hit and then change direction once people have grasped how they might just be able to hit it. This creates a sense of despondency and reflexive-resentment, as the peons feel that their efforts are being rewarded with tolerance, but that they're regularly missing what seems to be presented as realistic goal-setting. Genius!

This sort of Agile-management is exactly what you need to keep things ticking over balanced between doing so little that you're bored and doing so much that you feel stressed and cross and likely to be one of the first to get fired when the inevitable shit hits the fated fan of destiny.

Breaking the Cycle by Confidently Delivering Bad News
With a self-hating workforce, held together by your apparent tolerance of their failure, all you have to do now, is report this to upper management with confidence. With a bit of luck, they're using the same techniques on you and so are expecting bad news. However, if you compromise your image as a manager than you are nothing, so there needs to be a way to report failure positively. In addition, you have to report failure positively to the underlings in order to continue to foster their believe of your boundless tolerance. This is where the confident delivery of bad news pattern comes in. Essentially, you need to smile and say what nobody wants to hear in a way which tells them that they need to hear it. You have to be unrelenting, uncomplaining, positive and measured with your delivery. Ask questions. Of underlings you're asking them to answer that they accept their failure. Of upper management you're asking them to redefine their bounds of success for you then and their - this should tie in anyway with their regular re-goal-posting and so meets their own requirements.

In addition to delivering bad news, you need to present a story of a similar occurrence in another company and why none of the bad news is a surprise or indeed anyone's fault except those few people, who know who they are, who have failed themselves. You have to find the positives in the bad news and describe them as a lesson to be learned for the future.

As someone once wrote:

If you can keep your job when all around are losing theirs and blaming it on you.
If you can keep trust when you doubt yourself and are acting in an untrustworthy manner.
If you can keep your salary when all you do is lie and hate.
If you have no wisdom, dreams, thoughts of your own, triumps or tools.
If you can win when all around you are losing.
If you can talk with anyone and keep your smugness.
Then yours is the company and everything in it.
And what's more, you'll be a manager.

Pseudo-ML Diagrams

2006-10-31T12:02:00.000Z

Language conveys meaning
The purpose of an agreed language and set of conventions is to be able to convey meaning effectively between people. In a team of a few members, it is quite quick to form a consensus with very little explanation required. The more people there are on the team, the more effort is required to get everyone to understand the exact same vision, the exact same approach and any details thereof.

Of course, with Agile, the key aim is to generate a placebo effect where everyone believes that they're on message, working hard towards a goal, without any actual progress (except illusory progress) and without anyone managing to stop the regular process change which keeps the Agile consultant in work, and the company so in need of even more process change to correct the previous process changes and the apparent halt in production even though the illusory progress suggests that things have never been so good.

At times like this, a common language would actually be a big problem. If people really understood what was going on, they'd soon realise that nothing was going on except the regular payments into your bank account. So, we need a language which appears to convey meaning and which creates the illusion of a common understanding. This allows the following euphemistic-cliches to be used:

The team is pulling in the same direction
We're all on the same page
We have a shared vision
We've identified the goal and we're working towards it
We're singing from the same songsheet
We're all aligned
We have a group conscience
We are embalmed with glee
We're forming the success pyramid
We're all on message
We're out of the rough, on the green and sailing down the success-piste

And any others you can think of or make up.

So, how do we express this group delusion in a way which seems technical enough for the technical people to get, but is blunt and simple enough for not technical people to think they understand. The answer is Pseudo-ML.

Peudo-ML

This is a markup language that has its roots in UML in much the same way that cress has its roots in a tissue if you're growing it at primary school. Just as the cress has a short lifespan, so the sense of the Pseudo-ML diagram has a lifespan of the critical understanding time. This is defined as the entire duration of your explanation of the diagram plus the time it takes for you to leave the building. As soon as you've left, the understanding of the diagram and, indeed, any copies of it, will evaporate into an intangible mist, requiring you to come back and explain it all again, with the aid of surprisingly more (or less) complex diagrams, which will, themselves, have the same mystical powers.

Pseudo-ML uses many of the symbols from UML. In particular, there will be boxes, lines and pictures of documents and databases. However, the diagram will simultaneously be a class, state, object and use-case scenario. It will express everything and nothing about the problem, solution and goal of the project. In some cases, it may even express truisms about software engineering, like the fact that things should be tested, or that software should be good.

There are a few flavours of Pseudo-ML, but no two diagrams should be the same and you MUST make up your own notation, lest someone sees a similar diagram from someone else and starts to notice the inconsistencies. Some Pseudo-ML patterns:

Marke-tecture - an architecture expressed in such a way that marketing people understand it - this is clearly meaningless
Static dynamics - a diagram representing the momentary state of a changing system with the changes drawn all over it and indistinct information about what changes to what, from what, or how
Collaborative-elaboration - a high level diagram showing collaborators, covered in low-level detail about something completely unrelated - an equation can really set this off
Abstract ephemera - something which expresses a pattern incorrectly, without any substantial purpose and enough information to relate it to the subject in hand
Anti-pattern - something which claims to express the current system, why it's wrong and why it needs to be changed, without being accurate, meaningful or in any way useful

The possibilities are endless. Remembe a picture paints a 1000 words, so if you're paid by the word, you should definitely consider drawing more of them.

Bottlenecking

2006-10-23T13:45:00.000Z

Everyone knows that bottle necks are bad, right? Well, technically, that's wrong, as without bottlenecks, beer would come in cylinders that would be impossible to drink from.

Anyway, the point is that we all know that a bottleneck in a process is something which constricts the process. However, if one is to engender a sense of the appropriate placebo effect, and keep the more perceptive people around you from spotting the necessary bullshit, then it's imperative to find some means of bottlenecking.

Bottlenecking is a defensive move that takes one or both of the following forms:

Disablement - you put the person you wish to bottleneck into such a constrained project that their constant failure is guaranteed. This makes them feel like they're trapped in the jaws of something made of glass and full of a liquid that will quickly drown them.
Declaration - you point to someone and declare that their method of working is the bottleneck. This will so wrong foot them that all their attempts to explain the efficiency of what they're doing will distract them from the inefficiency of what you're doing. This is akin to scapegoating.

Sweetistics

2006-10-23T12:02:00.000Z

People like glib phrases like "It'll be alright on the night" or "We are going to be 110% in on this one". However, the problem with just saying stuff is that it doesn't give the bean counters any sense of proportion. Moreover, people trust numbers, even though they don't truly understand them, and even though a number is an abstract entity.

For example, if we said that crossing the street, according to a survey of 1000 people, proved to be 99.9% safe, people would be thrilled. That's brilliant. That's a great statistic, unless you happen to be the parents of the child who got killed in order to make the 0.1% of the group. Those parents would feel like the road probably needed the zebra crossing after all, and that the 999 other people were just lucky. In truth numbers mean little.

However, some statistics are researched and do genuinely reflect something of value. Those statistics are seldom much use to us unless they happen to agree with what we wanted to prove in the first place, whether they're directly relevant to us or not. However, there is a discipline called sweetistics. This is, essentially, putting a numeric quantity on things which we've not researched in order to allow us to form convenient aphorisms, related to those numbers, which look like absolute science BECAUSE they have numbers in them.

Examples:

The 80-20 rule - 80% of the something is bigger than the 20% of that same thing which would otherwise cause 80% of another thing to be spent, even though it's not worth it for 20%.
Pairing - with double the people doing half the work, then half the people can achieve more than twice as much as they would otherwise have done.
Refactoring - the extra effort spent on the redoing of the work, as a constant - C - can avoid the extra effort required at some later stage - S - rising exponetially (which we all know is bad)

Sweetistics always feel nice when you taste them, but like real sweets, they cloud the mind and the effect soon wears off. Use liberally.

Simple Majority

2006-10-23T11:49:00.000Z

People are, for the most part, very stupid. It's through being stupid that they flock to buy the latest iPod, HD TV and high-fat, low-tasting, poor nutritious products, relentlessly marketed to them. It's through the general desire to be successful that they'll do pretty much whatever looks most fashionable, provided they're given the opportunity to believe that it has some basis in rational thought, even if they themselves, don't quite understand what that basis is.

Better still, those people who think that they truly understand something, will assume that they're being very clever for following it through. If they believe and they think that they're believing in something which is based on logic, rather than blind faith, then they're even blinder to the blindness of their faith than otherwise they would be. Who needs religion when pseudo-science can go that one stage further?

There will always be smarter people in any organisation - the sort of people who raise their hands at the end of a long outpouring of necessary bullshit and say something beginning with "Excuse me...". However, the majority of the people in the organisation will swallow your output hook, line and, sinker. This majority of simpletons, or simple majority is what you need to find when you inveigle your way into the running of the place. They're useful because they're the majority and because they can be turned into an in-group, to which the smarter people neither belong, nor wish to be associated with.

Necessary Bullshit

2006-10-23T11:46:00.000Z

Bullshit is bad. It smells bad. It tastes bad. It's the unpleasant outpourings of an overfed digestive system. However, just as a farmer uses just the right amount of manure to grow his pleasant crop, so must the Agilistamalismalist feed just the right amount of necessary bullshit to his field in order to grow his reputation. Such bullshit is designed to win the hearts and minds of the simple majority.

Unlike the weighty and pungent bullshit from the bovine world, necessary bullshit is largely devoid of substance. Any graph with no axes will help, as indeed will pseudo-ML diagrams and sweetistics. The aim of the exercise is to provide a rich fecund environment in which your bogus claims, that the desirable is possible through you, can take root and grow.

Culting

2006-06-27T17:00:00.000Z

The term Cargo Cult refers to a practice which involved natives copying the behaviour of troops on remote aircraft bases in a misguided attempt to get the cargo which the aeroplanes dropped for those troops. The natives assumed that the aircraft were bringing gifts from the gods, and that the perfectly rational behaviour of the people at the base was, in fact, a mystical process, that if copied, would yield great reward.

Despite the fact that management know about cargo cults, and may even explain what they are, all management are susceptible to culting. This is because of the following:

Management want the world
Agilismics can promise the world, via a series of practices
Agilismics can prove the placebo-effect with those practices and suggest that the world is being delivered, on a plate
Management hypothetically reason that the practice is bringing the world and, thus, roll it out across the organisation
All of this is done in an atmosphere of shallow optimism which engenders the culting behaviour

How do you spot whether your organisation is worshipping the false gods of the cult? There are some obvious signs to spot:

A few people are doing a lot of shouting about how things should be done and nobody can see why
Some sort of bible is being brandished as a must-read for everyone
Despite every initiative going, nothing seems to be happening
You seriously doubt the sanity of the leadership
People are rewarded based on their willingness to believe, rather their results
There's a line of rats deserting the sinking ship
The counter-intuitive is being rolled out based on the flimiest evidence of success

You get the idea.

Development Obstruction Layer Examples

2006-06-27T13:27:00.000Z

The key to a development obstruction layer is to make it increasingly difficult for your techies to do their jobs, thus giving them less time to work out where the blame lies for the failure that's virtually omnipresent in the organisation. When an organisation reaches the mistrust point, the size where nobody can truly trust anybody else (and where untrustworthy people are sucking some parts of the company dry), the obstruction layer can be set up without anybody actually noticing. All that they will notice is that life is no longer as simple as once it was.

Ironically, the obstruction layer is often obfuscated by a style of guerrilla management which claims to cut through the bullshit and get the job done when, in fact, managers simply step in occasionally to make a series of outrageous statements on small matters, and then disappear before anything happens. Part of this style of management involves culting, where consultants are drafted in, books are bought, big meetings happen for a day or two, and the entire organisation's hopes are pinned on a fad, which rapidly escalates from an interesting idea to a disciplinary matter for non-believers. Culting is discussed elsewhere on this site.

To illustrate the development obstruction layer, we need some simple scenarios. Each of these is infuriating and necessary to create the correct environment for breaking the spirit.

Organising Transport
This should be simple. You should just tell someone where you want to go and how, and they should organise it for you. You should be able to specify the specific method if you need a specific method, or you should leave it up to the organiser to do it for you, if you haven't the time to look into the specific methods. Here's how the obstruction layer changes that:

You: I would like to hire a car to go to a meeting on Friday morning at 10.
Organiser: Can't you take the train? We don't like people hiring cars.
You: Not really, the meeting is in the middle of nowhere, a train would be followed by a taxi ride and I would have to get up exceedingly early and go to the station by taxi too. I could go the night before and stay if you want?
Organiser: No. We've heard of your sort, they stay in hotels and spend a fortune on room service.
You: I wouldn't.
Organiser: Anyway, you might be able to have the hire car, but could you pick it up at 5pm on Thursday and get it back for 5pm Friday. Then it would only be a day's hire?
You: The meeting is at 10am, some 300 miles away. If we finish at 2pm, then I might expect to be back after 5pm.
Organiser: Do you have to go to the meeting?
You: I could take my own car if you want and you could just pay petrol. I used to do that when I first joined. In fact, I used to get a per-mile expenses.
Organiser: No way. You're just trying to get a freebie from us. Get us to pay for you to jaunt around the place.
You: I just need to go to the meeting.
Organiser: Fine, you can have the hire car and return it on Saturday morning before 9am, but you will have to get your fuel receipts signed off by your manager. I will also have to put the requisition of the hire car through two directors. This should take about a week.
You: But the meeting is this Friday.
Organiser: Well, you should have thought of that.
You: I think somebody should be thinking about something...

Getting A New Hard Drive
This is not the simplest of things. You need extra storage space on your computer and the minimum of downtime. You also want help from the IT guys to fit it and sort it out for you. Ideally, they'll just add an additional drive.

You: Hey IT dude, please can I have an extra hard drive.
IT: Yes and no.
You: Meh?
IT: I'd happily fit one for you if I had one, but all the drives are currently in use.
You: Can you buy one for me?
IT: I would like to, but I'm on a spending limit at the moment. I can only buy things if they're urgent. I can buy small things, but I have to wait until I have an order worth £250 before I can amass small things together. This is because the delivery charge of £25 from our one preferred supplier is too large to accept for small orders.
You: But a hard drive is only...
IT: ... I know, only £50 from a mail order supplier who would charge £4 delivery. Or we could even go to Maplins at lunchtime and just get one but we're not allowed, without special permission.
You: Ah. Special permission. Shall I try to get that.
IT: You could try, but you'll have to go through The Snake and he's going to suggest stuff.
You: Like what?
IT: Like why you can't use less storage space, or compress your drive.
You: But he knows sod all about computers and that compressing would...
IT: ... I know, destroy system performance and not guarantee any more data with the sort of things we store. Try telling him that, he's too busy ordering himself new sat-nav toys.
You: Can't you put a hard drive on the back of one of his orders for the Yoda voices for his TomTom?
IT: Last time I tried that I nearly got the sack.
You: What for?
IT: Misappropriation of company resources.
You: Meh?
IT: It was a smokescreen to cover up the fact that he was spending more on personal toys which he broke than I'm allowed to spend fixing the servers. Do you know what he did to his laptop?
You: What?
IT: It was running slowly, so he kicked it. In the screen.
You: Expensive?
IT: A new laptop.
You: So I'm not getting my new hard drive?
IT: A lot of people just buy their own...

Buying a Book
This should be as easy as forwarding a link to the book on Amazon to someone, or even just buying the book and claiming the expenses back.

You: Here is a book I'd like to read.
Admin: Do we not already have a copy.
You: I don't think so. I've had a look around. Anyway, don't you already know from the asset register or something?
Admin: No, because people wouldn't hand all their books in when we told them to.
You: Perhaps they were reading some or needed to reference them.
Admin: Well, it's very inconvenient. How are we supposed to know which books we have?
You: Didn't all the purchase receipts go through your office? Anyway... we're getting off topic. I don't think we have this book. It's new and I'd like to read it. It will really help me do my job.
Admin: I can't just buy it for you? Not until I know we don't already have a copy.
You: If we already have a copy, it's so useful that someone is using it, because I can't find it. I've asked around and nobody has seen a copy. I need the book, how do I get it? Shall I just buy one and claim?
Admin: No.
You: Then.
Admin: Fill out the book requisition form. You need to state the title of the book, the author's name, the ISBN number, the price of the book, two quotes for how much it would cost to buy. If the book costs more than £13, then you need to provide a business case for why you need the book and what use it will be to you. The business case should be a minimum of 250 words and should be countersigned by your manager.
You: Ok, I can do that. When will I get the book. Amazon has stock and could deliver it tomorrow if we order before 2pm today.
Admin: I'll have to put the paperwork through my manager and then through a director. That'll only take a couple of days.
You: Then you order it?
Admin: No, Sue does, but she's off until next month.
You: Could you do it in her place.
Admin: I'm far too busy.
You: You know, you'd be less busy if you didn't have all these ringfences around what would otherwise be a 5 minute job. Do you realise that this conversation has probably cost the company more money than the book would have cost if you'd just bought it when I first emailed you the link.
Admin: I don't make the rules.
You: Who designed this form?
Admin: I'm leaving the room now. Let me know when you're ready to fill out my form and do things properly.

Getting More Staples
You ran out of staples. In the ideal world you go to a cupboard or shelf somewhere and get some more. Not with the obstruction layer running.

You: Where are the staples?
Admin: Why do you want them?
You: I ran out.
Admin: You're not doing a stapling job.
You: I have a stapler and I ran out of staples. I occasionally staple printouts together.
Admin: You aren't on the staples list.
You: Is this really happening?
Admin: Give me your stapler.
You: Why?
Admin: I'm confiscating it?
You: Where are the staples?
Admin: I locked them away. People were stealing them.
You: I'll just bring in some of my own - this is ludicrous.
Admin: You're not qualified to use a stapler - it's a health and safety.
You: You're a loony.

We've Run Out Of Milk
A deceptively simple situation. More milk is needed.

You: Hi there, is there any milk in this side of the office, we've run out of milk in the development kitchen.
Milk monitor: How much coffee have you been drinking?
You: Personally, I've had a couple of cups today, but I take mine black.
Milk monitor: I've seen you drinking frothy coffees in Starbucks.
You: Yes, but Starbucks coffee is nice, rather than the crap we get here.
Milk monitor: You can have a splash of milk for your coffee from our kitchen if you bring your cup.
You: It's not for me. As I said, I take it black.
Milk monitor: Then you don't need any.
You: I'm making a round for the team, can't I just take a spare bottle across to our kitchen?
Milk monitor: No, we might need it.
You: Then can I buy some more?
Milk monitor: I can't give you the money for that. It's not been approved.
You: What can we do?
Milk monitor: I know. Leave it to me. [Prints a misspelled laminated sign explaining that people have been abusing the milk and firmly but impolitely insisting that people stop being so greedy] There, that should have the desired effect.

Locking Up At Night
You're given a key and you use it to lock the door behind you on the occasions when you've stayed late to work when you're not surrounded by the jobsworth idiots.

Key sergeant: Someone didn't lock the door properly. It was you.
You: I did. I turned the key in the lock and walked away.
Key sergeant: How many times?
You: What?
Key sergeant: How many times did you turn it?
You: Until it locked.
Key sergeant: Double locked?
You: Double locked?
Key sergeant: Yes, it locks twice.
You: You're joking, right?
Key sergeant: No.
You: What's the point. If it's not locked properly with a turn of the key, can't we get a lock that works normally? What's the point of a mechanism which allows you to half-lock the door? Can we get a normal door please?
Key sergeant: No.
You: Why didn't anyone tell me that I had to deal with a spastic door?
Key sergeant: You should have just known.
You: Why do I feel like hitting someone?

Clocking In And Out
In an ideal world you would come and go as you please, filling out a time sheet to make sure that you've done your hours and reported them as necessary for the bean counters.

H&S freak: I brought in a fire safety and obstruction officer, who thinks we should keep a register of who is in the building at all times.
You: There are 5 rooms in this office. People know pretty much who is where at any point.
H&S freak: It's the law. We'd be illegal not to have an IN/OUT clocking-in system.
You: I know countless places, bigger companies, who seem to manage well without it.
H&S freak: It's THE LAW. We've been round with the officer and he's pointed out that we have to comply with the blindingly ludicrous ringfencing that keeps him in business.
You: So what do I have to do?
H&S freak: Whenever you enter the office, you must turn your card from OUT to IN, sign in and wander past a fire warden. When you leave the office, you must do this in reverse.
You: What about going to the toilet?
H&S freak: For a wee, then don't worry. If it's a poo, then you must follow the procedure too.
You: What do you do with the board in the event of a fire?
H&S freak: I beat through the flames to the doorway where the board is, rip it off the wall, hurry out of the fire exit and compare the board to whoever has met me down there.
You: Allow me to provide the petrol for this fire.

Pairing On Everything
Pairing can be a useful tool for sharing knowledge and experience on complicated technical tasks. However, when applied to every case it can be soul destroying and obstructive.

Coach: I see you're currently working out some estimates using Excel.
You: Yeah. It's quick and easy.
Coach: Alone?
You: Yes. It's a simple task that any idiot could do.
Coach: What about someone who doesn't know how to use Excel?
You: Such a moron should not be in a software engineering job... or should use their own time to learn how to use Excel.
Coach: That's very negative.
You: Why spend 3 times as long pairing on the most simple of tasks to accommodate someone who can't use a simple tool.
Coach: Training.
You: Good point... but also a bad point. There's only so much on the job training, at the expense of the more skilled worker, you can do without the costs outweighing the benefits. People can learn for themselves and if they really are clueless, then they should either sort themselves out or sod off.
Coach: I don't like your attitude.
You: We have something in common then.
Coach: You must pair on your spreadsheet.
You: Fine.
Coach: And produce an estimate for it.
You: it's the estimates spreadsheet - you've just created an infinite loop.
Coach: Then you're too busy to continue this conversation. Off you go.
You: Aaaaaaaaaaagh. Where's that employment consultant?

Obstruction
As you can see from all of the above examples, the apparently simple becomes increasingly frustrating, which fosters a feeling that anything simple will always been frustrating. People will start increasingly defending their own ground, which will widen the gulf between everyone, making it less likely for people to ever want to work together.

Thus, management can hide their inadequacy, which would otherwise be plain for all to see. Perfect.

Motivational Slogans

2006-06-27T11:38:00.000Z

All management need motivational slogans. Here are some examples:

If you're not with us, you're against us
Let's smash the opposition
Look at these people [the opposition] they want your jobs
We're gonna be the best, better than all the rest, no really, we are, oh yeah
Some projects are so bad that the people on them should be ashamed to draw their salaries
Look at this example of good engineering, good isn't it, we should be like that
Dinosaurs died out, don't be a dinosaur
Imagine a biscuit...
Discipline in everything
Life's not fair
False promises lead to false hope, so I'm promising nothing and everything
Let's keep things moving forward
Let's get out there and bang the drum
We're going to think outside of the box, push the envelope and drive things forwards, over the edge
We have the best products, even though our sales are not the best
We've cut the dross now, so we're raring to go
When we expand and go on the stock market, we'll all be rich... one day...

Maybe you'd like to suggest some of your own?

Not Getting A Smack In The Mouth

2006-06-25T12:32:00.001Z

Your presence in a company can cause a great deal of resentment or misagilisma. In some companies, this could lead to increased levels of anxiety, resentment, feelings of depression and, in some extreme cases, violence. It is vital, then, that you choose the company you join wisely in order to avoid a physical incident breaking out. Although you might claim to be good in a scrum and even be a black belt, these terms have absolutely nothing to do with real martial arts, and will quickly feel as shallow as they truly are if someone actually squares up to you and intends on really hurting you.

Choosing the right approach
Here are the tips:

Try to avoid a company with large or violent people in it - software engineers are often a meek bunch, so this shouldn't be too difficult
If you do find yourself in a company with people who could do you damage, suggest a pilot scheme which has you working with a team which doesn't include these people. Incidentally, this idea of working with only one team and yet still driving the entire company into the dust, is the best approach. The special treatment of one team and the idea that everyone else should cargo-cult on things which that team claim to find useful (though actually that team is failing too and it's just illusory progress) can quickly break the spirit of the whole company, without it necessarily appearing to be your fault alone.
Ensure that you are not seen as the major implementer of all change - instead wind other people up to do your dirty work. Those people will provide the first line of irritation to the violent.
Try to avoid winding people up by slagging them off in public.
Slag them off indirectly instead.

Simple and you'll probably find that, after this, the company is too busy tearing itself apart to find the time to start on you.

The Development Obstruction Layer

2006-06-25T12:32:00.000Z

Once upon a time some talented developers join a small company. The company is doing well and can afford to take on more people to make more of the right software in order to make more money to keep everyone in business. It's a happy time for everyone. As the company prospers, so the upper management have two problems. The increased responsibility of a larger company is harder work, and they're no longer sure whether they're up to managing, yet they have to remain as management, lest they admit the need to rely on other people to help. So, they grow the company without paying attention to middle management, expecting the more senior members of staff to pitch in and help things along.

After a time, some of the upper management are considered to be nay-sayers and so they are removed, replaced by the sort of yes-men who do not say no, even when no is the correct answer, and so the company's grip on the real world is replaced by a layer of optimism that does not actually relate to the facts. Furthermore, as the different people who used to do specific jobs, alongside the other people who did different jobs, gain further help in the form of more staff, so departments and divisions (with a capital D) form. No longer is it permissible to ask someone to help you, you must go through the system which that particular group has formed in order to make their internal operation much easier for them.

As the company grows beyond breaking point, it suddenly breaks slightly, requiring some downward expansion, and blame management in order to maintain its position just far enough above the flames of the fire it's now thrust itself into. Both of these strategies create an effect known as rear coverage where the behaviour of each department and managerial unit is intended to protect the department more than increase the prosperity of the company. This is where the development obstruction layer first forms.

Developers will soon find themselves at the sharp end of the productivity quandary. This is where the company realises that its income depends on its sales, its sales depend on its product, its products depend on the developers and the developers depend on the strategy. The strategy should also be dependent on potential sales and the results of market research, but owing to the process of rear coverage, the strategy has been laid over until the income has improved, because it's difficult and because "we should already know what we need to make". Thus the developers discover that the entire company is riding on them.

Developers can solve all the problems they're faced with. However, for maximum efficiency, they should only be faced with the problems that only they could solve. Without the development obstruction layer, the developer would only be solving developer problems, and this might reveal the inadequacies in all other departments. With the obstruction layer, the developers become the centre of dependency (which means blame) and are unable to do anything about it. Occasionally, they may receive pseudo-empowering pep-talks suggesting that they can do whatever they need to do and that they are in the driving seat of the company. However, any pep that is engendered by these talks will soon be extinguished as they small into the wall of the obstruction layer.

As a result, the company can slowly implode and nobody will realise that the fault lies on the other side of the obstruction layer, as the only people who can see it are considered, by everyone else, to be solely to blame and thus totally untrustworthy.

Here are some ideas for how to set up and obstruction layer:

Underinvest in hardware
Do not provide stationery in good supply
Lock away things like batteries which might be used for purposes other than replacing spent ones in wireless equipment
Buy hardware on the cheap so it arrives late, or breaks down often
Make it hard to buy books
Requisition developers to work with other teams on things which are only vaguely related to the project
Repeatedly change the direction of the requirements on the team
Invest stakeholders with power over the future of the product but no knowledge of the realistic requirements
Demand everything immediately and with equal priority
Refuse to replace core systems like source control
Refuse to invest in bug tracking
Refuse to adopt a system for managing requirements, insisting instead on having all 400 historic requirements maintained and laid out manually
Complicate the expenses procedure
Put more middlemanagement between the customer-facing techie and the customer in order to slow down communication
Agree to impossible contract work which can only make a loss, because it has not been budgetted with reference to any technical estimation and is of fixed scope, quality, time and resource
Occasionally buy people lunch while you tell them off
Turn your senior people into pseudo-managers, taking them away from coding, even if that's their strength, rather than invest in a real leader
Reward people on the basis of apparent willingness, rather than productivity

If you have any motivated people left after this then it will be a good indication of the high caliber of techie that you're spending good money squandering.

The Agile Team Membership

2006-06-23T13:05:00.000Z

The Agile team is usually composed of the following personalities. These reflect the diversity required to produce the necessary production simulation:

The Protagonist
The protagonist is the instigator. Under any circumstance, you can rely on him to start the ball rolling. He will sometimes engage in debates over the unnecessary just to shake the tree. He will use any technique he's ever heard of, and will look to bring in any consultants he can find (including The Pope) to prove that his home-reading-time hasn't been wasted.

The protagonist will start tons of new initiatives, all of which will fail in some way. Sometimes they will fail because the protagonist cannot finish anything, and sometimes they will fail because all they had going for them was rationale, invented by the protagonist to make himself look good.

The failure of the protagonist's older ideas will be masked by the impact of the implementation of his latest ideas.

The protagonist may find a believer and set up the code police to ensure that the new ideas are being followed, whether they are good ideas or not.

The Believer
The Believer is often The Mythical Man Moth. He is a lost soul in search of new ideas. The protagonist can use the believer to do his bidding. The believer will become fervent about anything and will accidentally ingratiate himself to management this way. Management want to believe that their team is made up of dedicated individuals. The believer dedicates himself to whatever is going and becomes the golden boy by default.

Unlike the protagonist, the believer isn't trying to make himself look good. Therefore, his status as golden boy is exceedingly fragile and he will be one of the first to get the chop if management ever get wind of how gullible he is.

The Mug
Like the believer, the mug will accept whatever you tell him. However, he's not going to be telling anybody about it. He'll just trudge on with the latest fad until the ground shifts beneath his feet.

The Antagonist
The arch-enemy of the protagonist and believer, the antagonist won't take anything lying down. Change even the brand of coffee in the office, and he'll start a campaign about it. His vociferous opposition to everything is exactly what the protagonist needs to show management why schemes are failing. "Well it would work if people wouldn't oppose it so much." Without an antagonist, the failure of the schemes would pass without a scapegoat and the believer might be uncertain of whether he's involved on the right side of a holy war.

The Defender
The defender will do whatever is necessary to protect his position without causing offense. He will find ways of adding his requirements to any process. Although he will stand in opposition to some change, he will, ultimately, find a way to incorporate that change into his life. However, his own working practices will become increasingly bizarre as each change he incorporates threatens to undermine them.

The antagonist will try to gain the support of the defender, while the believer will see the defender's adoption of the new methods as proof of everything. The protagonist will find new and interesting ways to confuse the defender with change.

The Resistor
The resistor will oppose but not directly attack any change, whether it's for the better or no. The resistor simply doesn't want anything to change, believing that "the old ways are the best". Where possible, the resistor will use a pad and pencil to record everything, and only works on the computer out of necessity.

The Passive/Aggressive
The passive aggressive will also oppose any change, finding a plenitude of reasons why "I would do things your way, but it's simply impossible". Most meetings with the passive aggressive will be spent in confusion as she either doesn't understand, doesn't want to understand, or willfully misunderstands the demands of the protagonist. The protagonist finds the passive aggressive the most wearing and ultimately uses the get them out pattern to deal with the situation.

The Ostrich
The ostrich just wants a quiet life and so takes any opportunity to ignore the effects of change. They will play along with the protagonist and the believer, will be outwardly optimistic to the defender and resistor, and will ignore the antagonist and passive/aggressive completely.

The ostrich has sandy eyes, but can get to sleep at night.

The Pope
In order to provide extra support for the protagonist, and extra fervour to the believer, the Pope can be brought in. The Pope is seen as the holy leader of the cause and speaks only in truisms and riddles. The Pope's word cannot be questioned without consequences.

Even management cower at the thought of an audience with The Pope.

Production Simulation

2006-06-23T12:12:00.000Z

While software engineering is quite a lot unlike manufacturing a motor car, the Toyota production system metaphors only work when you pretend that it is quite a lot LIKE manufacture.

In addition, while Agilistismical practice is quite unlike that which yields effective results, it is in your interest, in order to be able to remain in the organisation, creating further change and further Agilisma, to declare that the yield has been positive. Cue Production Simulation.

Production Simulation
This is what happens when you use:

Optimistic reporting - promising the world about the future and sugaring the pill about the past
Reality refactoring - confusing the management about what they thought they knew about their business - redefining familiar terms and adding Japanese where necessary
Claiming all success as proof - where you demonstrate that your influence is within an environment where success is still possible (even though the success usually comes from elsewhere, outside of your control)

If there is anything to show management at the end of each reiteration, you should be able to spin that into a placebo which simulates production via the illusory progress effect.

The Consultancy Challenge

2006-06-22T16:13:00.000Z

Some valuable questions have been submitted. I will answer them with reference to other articles on this site.

How do I persuade management that there's been gains in productivity when all evidence points to the contrary?
See Keeping your job against the odds/evidence. The mixture of obfuscation of the facts and promotion of the placebo-effect can create illusory progress. This is coupled with jumanji and Sugaring The Pill.

How do I stop myself from being sacked once management realise that I've been pulling the wool over their eyes for a year?
If you know what you're doing, management will never see through you. Remember, you have destroyed the documentation, reduced understanding, enforced weak coupling between upper management, middle management and the team, and strong coupling between management and yourself.

If it looks like you're about to be sacked, then try sepuku, which involves telling the organisation that they'll never be good enough for you and leaving before they push you.

Should I change my name to something that sounds Japanese in order to persuade people that I know what all these Japanese terms actually mean?
I would say not. However, choose an epithet like sensei or pokemon.

The original questioner had chosen the names Tamagotchi Hiroshima. I would recommend against any reference to Hiroshima or Nagasaki as they give away the game that your presence is a high megaton time-bomb. Maybe choose Hirohito, Fuji or possibly Sony. Never besmirch the name of Toyota though, or you will be hunted down. You have been warned.

Will I be able to sell my "expertise" in Britain for the same ridiculous sums as I'm no longer paid stateside? Surely the Brits aren't so gullible?
Provided that you follow the methods outlined in this site while visiting, find a way of offering a placebo-discount, and get a fervent admirer within the company to bring you on-site, you're laughing.

Placebo-discounts work as follows. You agree to reduce your fee because you happen to be in the area, perhaps some toadies have asked you to speak at a conference, or perhaps you've managed to recruit several companies to which you can give placebo-discounts because you're visiting them all.

Once on-site, you need to be fearsome, to suggest you're a hardnosed ball breaker. You also need to take your standard powerpoint presentation and slightly tweak it to make a "customised plan of action" for the company you've bullied into paying you. This plan of action, though written down, will still be mainly folklore and impossible to implement.

Threaten them with a follow-up visit, rather than ask them to be invited back. Brits are too meek to argue strongly enough.

Job done.

Sugaring the Pill

2006-06-22T15:49:00.000Z

The only time you get to deliver genuine good news is when:

You first arrive - when you can announce how good it is to have the opportunity to work with the company
When you brag of case studies you had nothing to do with the success of
When the team somehow manages to evade your fettling and brings a result in
When you announce that you're leaving

The latter of these should not happen. Yet how can you avoid being kicked out if the majority of the news you will deliver will have to be either bad news. The answer lie in spin and sugaring the pill. Spin is how to convert a failure into optimism about other opportunities. However, the canny management team will soon notice if you are not telling them about the self-evident failures happening around them. They want to respect you more for having you deliver them bad news in a way that they can spin for themselves.

A Spoonful of Sugar
Agile is all about delivering bad medicine, so Mary Poppins's edict that "a spoonful of sugar is all it takes to change bread and water into tea and cakes" is your friend. Here is how to deliver the bad news:

Sigh
Look the manager dead in the eye, accusingly
Explain exactly what has gone wrong
Explain that this is normal
Explain that the team don't seem committed to solving the problem
Explain where the process is likely to go at the moment to address this issue
Then pick on a random achievement within the team and explain it in detail, suggesting that such a small thing's success will be infectious and spread to all areas
Confuse the management with graphs, diagrams, japanese, and detail surrounding the future
Criticise the past using your innaccurate view of what used to happen
Suggest that the past is no longer happening - this is both a truism and also the result of your interference with all process; the success of the past is definitely lost forever

Leave appropriate titles of reference books which the management will be too busy to read, and they will think you've improved their company, even though you've simply stopped production.

The Mythical Man Moth

2006-06-22T14:13:00.000Z

The Man Moth is the sort of person you need in a software engineering company if you are to succeed as an Agi-beguile-erist. Agi-beguiling is the process by which you first hook a company into bring you into their employment. This takes a few forms:

All of these tools work well on the right sort of person, but who is the right sort of person?

The Mythical Man Moth
Thankfully, this person is not mythical at all. They are all too real. The Man Moth spends his entire time flying towards the brightest thing he can see. Once he finds some sort of source of light, he flutters around and around it, pointlessly and tirelessly. All you need to do, is act like a source of light. Suggest new things, suggest good things. The Man Moth is attracted to the shiny bright idea and you're full of it.

Then, you can stand back in amusement, as the Man Moth eventually extinguishes himself in the flames of the fire you fanned in his organisation.

The Mythical Man Month

2006-06-22T13:18:00.000Z

This title is also the title of a book on software engineering. However, since that book is more than 2 years old, it's clearly wrong. In addition, it suits our purposes to redefine this well-known phrase for our ends. A phrase that's been redefined, is better than one in its original definition, second only to made-up terms, and that's an anti-fallacy.

The Man Week
The Agile definition of a Man week is non existent. However, Agile defines the maximum work a man can do in a week as 40 hours. Agile also requires that people work in pairs, which it claims does not half productivity as two people between them can achieve a solid hour's worth of work in an hour. Therefore, the work we expect from one man in one week is 20 hours.

The Man Month
It doesn't take a genius to work out the amount of hours that a man might be expected to work in a month from the 20 hour week. Let's call it 90 hours.

The Mythical Man Month
This is a myth held by management. It works as follows:

If I work hard, I achieve stuff
If I work harder, I achieve more
If I work longer, I achieve more
So, I should work harder and longer
If engineers work too long and too hard, they burn out and make mistakes
Somehow the pairing is supposed to fix that, with peer checking of everything, but somehow I can't expect a pair to work more than 40 hours a week between them
So, someone has to take up the slack
Managers should, therefore, work 90 hour weeks
Management-stuff isn't as hard as engineering, so you can work longer without burning out
So, the manager should be expected to work for a man-month each week

The beauty of this foolishness is that management become so snowed under with work that they're in less of a position to manage, and more desirous of the placebo-effect and signs of illusory progress. Thus the Super-coding-Agilistic-expert-alligator-consultant™ can step in and secure himself a parasitic stranglehold.

With thanks to M. Poppins

Has The Agile Bubble Burst?

2006-06-21T22:26:00.001Z

No.

The Intangible Mist Management Mystery

2006-06-21T12:29:00.000Z

Being able to explain Agile is one thing, being able to explain it in terms which people think they understand while you're explaining it, but later cannot quite put their finger on, is the ultimate aim. Essentially, this skill will allow you to bully people to agree with you, without realising it, as you will claim that everything is common sense. The result will be that they have an increased need for you, as their understanding is proportional to how recently you last explained it all.

However, there is an additional benefit of surrounding your process in a mist of semi-understanding. This relates to how much management are in control and how much the middle management can be used to undermine themselves, once they've attempted to buy into your scheme.

If Management Understand You
Then they will be able to effectively argue against you and see the holes in your scheme. They will also be able to predict where the scheme is headed - off the edge of the nearest cliff.

If Middle-Managament Understand You
They will feel on top of the changes and will also be able to steer them away from the edge of the cliff. They will be able to take ownership of the process... away from you.

If Management Don't Understand You
They will find everything you say an interesting mystery and have to go on blind faith that your promises of the world will come to fruition.

If Middle-Management Don't Understand You
They will be unable to implement anything you suggest without you. They will start to resent you and will start to resist, which can be used an ammunition against any show of strength on their part.

If Both Middle-Management and Upper Management Don't Understand You
Then they won't understand each other. All the counter-intuitive suggestions you have made will create barrow-loads of disagreement which only you can resolve by adding more words for people to consider.

In this scenario, should upper and middle management ever get together without you to discuss the project, they will always be at cross purposes. Plus, if middle-management have the best of intentions and try to explain the way the project is likely to run positively, it will look terrible as their estimates will defy common sense and their explanations for why will seem ridiculous. Conversely, if middle-management are against the idea and try to explain why, they will seem to be just resentful and backstabbing, rather than advising management away from the cliff-edge it has reached.

The Intangible Mist
Explanations which are full of buzzwords, especially in Japanese, cannot be held in the memory and will simply appear to make sense, rather than being part of a coherent, strong, strategy. People will remember the vague ideas and the very tangible benefits those ideas claim to offer. They will not remember the explanation for how the counter-intuitive actions they have to take will result in those targets. They will nearly remember. This is the mist. Use it wisely.

Keeping Your Job Against The Odds/Evidence

2006-06-21T12:10:00.000Z

It is quite possible that an Agile process will yield genuine improvements in productivity. It's possible that the team just needed a change of scene. Alternatively, the extra strain that your Agilista-mentoralista-ism will put the team under may inspire a sort of Blitz-spirit and get them to perform despite the odds. These successes, though only incidentally related to your work, must be seized upon and claimed as proof of everything you have ever said or may ever say.

However, the chances are that your changes will not result in the massive turnaround of the company's actual fortunes that inspired the management to hire you in the first place. As there is an art to getting management to part with enough money to give all their junior staff decent pay rises (in order to pay you and keep them in penury) so there is an art to keeping your position. A lot of these tricks are discussed elsewhere on this site. Here are the tricks:

Reduce the evidence - if something is not clear, then you should be given the benefit of the doubt, since you already told management what they wanted to hear. You have already promised the world, ensured the placebo-effect with information radiators and destroyed the documentation.
Intimidate management - ensure that management feel that they would be stupid to avoid following your advice, despite the fact that it may not be working yet. You simply explain that they're not following ALL of your advice. So long as you can constantly think of new things to advise, you can continue to feed their need for the results you promised and feed their desire not to look foolish. See also I am not shouting
Drug dealer methodology - this is how you ensure a perpetual need. You feed them a bit of the drug at the start, a faked success here or there, or strategic use of the placebo-effect or illusory progress and the sort of manager most effective for protecting you. Once they've started playing your game, they will be unable to reverse their decision. This method is called jumanji

So, despite the fact that you've added nothing except a consultancy fee to the bottom line of the company, you have to keep your job. That's how human nature and your manipulative methods naturally interact.

Reiterative Development

2006-06-21T11:00:00.000Z

Iterative development is the method by which we take small steps in the direction of solving a particular problem, completing each step without loose ends, and gaining feedback before proceeding. So, if iterative development is good, and it is because it just is, then surely something which does more of it is more good. That's where reiterative development comes in. Reiterative development is the process of taking a small step towards developing a small feature, and then, in the next reiteration, repeating the process on the same feature in order to reimplement it in a subtley different way. This process can be coupled with pair-project-development, where you run another similar project alongside, developing a product which, were it to be released at the same time as the product the first team is developing, would be in direct competition.

Reasons for reiterative development:

If the team ever completed the project, you might be out of a job
If the team ever successfully captured a requirement and delivered it to be told that it was great, then you might be out of a job
Throwing away most of the basic checks and balances for quality means that a "complete iteration" will produce something deployable, but which nobody would want, reiteration allows you to fix that without admitting that you broke it

Of course, repeating the same mistakes over and over again might get noticed; repeating the same project concurrently in different fashions, with no individual project fully capable of satisfying a full set of customer requirements, might also be noticed, so you need some excuses for why this nonsense is the right thing to do:

Improving quality - redoing work even better is a preferable spin to "fixing our mistakes"
Running all the options - makes it sound like you'll be providing more, even though you're reducing throughput with redundant development
The team clearly need more coaching as they can't even get a simple requirement right - this absolves the coach from all blame, despite it being the coach's fault that the team were kept in the dark
Once we've reached critical mass, things will speed up - a suggestion that the early reiterations will pay for later reiterations - this is part of the placebo-effect, or the illusory progress pattern
We're making fewer reiterations - caused when you either lengthen the iteration, or reduce the amount of work in an iteration to reduce the probability of error and productivity

Remember, the longer the team are working on what you were brought in to help them with, the longer you will be in a job. It must be your business to keep the team from ever finishing or ever providing management with an excuse to declare your work complete.

Documentation = Evidence: Avoid!

2006-06-21T09:16:00.000Z

One of the problems with the Waterfall Method is the huge amount of documentation that it requires. This is also true for the process for generating documentation called the Salmon Method (see The Parable Of The Yakisobi) which results in a huge quantity of documentation, but as the output of the process, rather than as the input. Nobody has yet hit on the idea of writing a requirements document for a document, but surely it's only a matter of bureaucratic time.

The problems with documentation are:

It's hard to write
It's open to interpretation
It's hard to keep up to date with changing requirements
It can be used in evidence against you

When you compare this to the principles of Agile, you will see why documentation is a problem. Agile principles:

Be young
Be foolish
but, be happy
Change and change often
Don't allow the promises of the past to affect the promises you make in the future
Never stay in the same opinion long enough to have to deliver on it

Therefore, you need some good reasons for why no document should ever be written. Here are some top excuses:

Requirements - these change, so we'll have a meeting and take individual requirements and write their names on cards - those cards will symbolise the requirement and then we'll make up the rest
User documentation - we will write software so easy to use that no user documentation will be required. Or, we will write software with so few actual features that a user manual would be very empty and so may as well be forgotten.
Coding standard - we'll use pairing to enforce a coding style, or as it is sometimes known, a stalemate of conflicting opinion
Architecture overview - we will not keep any record of how the system works, the people who have worked on it will be a living record; they will pair with others who will then magically know through the process of osmosis, and the circle of life will be complete. This will fail if we shuffle the teams around or several people resign in disgust in the same month. But if that happens, then we'll abandon the projects they worked on.
Long-term plan - by the time any long term plan could have been written up we'll have changed it. That's the Agile way. To write a long-term plan would be like painting the Forth Road Bridge, and why would a software company want to do painting?

With these tools you can, effectively, block any record of what the software is meant to do, actually does, how it works, where it's going and whether it has a future. Your position will be, unlike the jobs of the developers, totally safe.

Avoid Coding

2006-06-20T17:47:00.000Z

Do you find coding to be depressing? Perhaps you think it is a lonely pursuit? Maybe your pair partners all hate you. Maybe you're simply no good at it. There's an adage:

Those who can't do, teach. Those who can't teach, manage.

As an Agilista-mentor-alista, you get to do anything but code. You can focus on process, you can focus on coaching, which is the same as just irritating the people who are doing the actual work. You can focus on training, which involves insulting people who have done things you don't like, and insulting the intelligence of everyone in the session as you read out text-book definitions of dogma which even you don't know how to apply. Or, you can focus on the process, which involves plenty of administration and reporting, but very little actual production. If you are very clever, you can even create a process which monitors how busy you are being made monitoring the process. Anything to get away from the actual production side of things.

Interestingly, this is a muda, but it is a muda to talk about how much of a muda it is, so people will back off and leave you to it.

Once freed from coding, you can spend your time on any of the following:

Annoying people
Suggesting the obvious
Suggesting new ways which have no benefits, take longer and make you feel satisfied when they're tried
Finding new ways to train people on the things they already know
Invent new terms for things
Look at new Toyotas online

Remember, though production makes products and products make money, your role is compromised if you get on with anything directly useful.

Avoid Null

2006-06-20T17:38:00.000Z

You can't make something out of nothing? Well, if you're an Agile-mentor-alist, then that's exactly what you do, but programmers shouldn't try to cash in on this skill. In programming terms, a nothing, or null, is of no use. They should be avoided. In particular, as they can sometimes cause crashes, they should be avoided at all costs, regardless of common sense. Here are some null-avoiding-patterns:

Where the language allows reference types to be null use an irrational metaphor to guarantee non-nullness
Replace null with zombies
Replace optional parameters with every permutation of the function with fewer parameters, all mandatory
Invent values
Absorb all exceptions and pretend not to crash

Customers wouldn't pay for nothing, so why program with it? Mind you, customers wouldn't pay for over engineering in the most subtle and pointless of pernickety style.

Avoid Boolean

2006-06-20T17:23:00.000Z

It is possible to misuse a boolean parameter to do something stupid. For example, if you want a function which converts your data into a string representation and another which converts it into integer, you could do something like this:


    object Convert(bool stringornot)
    {
        if (stringornot)
        {
           // return as string
        }
        else
        {
           // return as integer
        }
    }

Oh my god that's totally unreadable. Oh my god my god my god. With this single example, I am now going to make a straightforward suggestion. Do something better. Have two functions for the alternative cases. E.g.:


    string ConvertToString()
    {
        // return as string
    }

    integer ConvertToInteger()
    {
        // return as integer
    }

Now, the masterstroke. Using the extrapolation design pattern, I will now propose that no function should ever take a boolean argument to express anything which might affect its logic. This ringfencing will cause you to jump through hoops. I would also suggest you try to avoid passing more than one parameter to any function and would also suggest that each function have a maximum of one line of code in it.

The Wrecking Ball For Agile

2006-06-19T23:49:00.000Z

Though it is usually the aim of this site to explain how to hook an organisation with the promise of Agile and then create a dependency on you to further develop the illusion, I thought it would be useful to explain how to resist Agile. The aim of this explanation is to warn the Agilist what to expect of those people who can occasionally see the wood for the trees, or who simply don't want to change. If an organisation were made solely of this sort of person, then the Agilist would either have to get everyone sacked, or bring in people who are already cult-members of the Agile world in order to be able to get any sort of foothold, let alone the necessary strangle-hold. Beware of these behaviours.

Avoid change
One good way to undermine your employer's attempts to improve your job is to simply ignore all new ideas. Where possible either don't attend meetings explaining them, feign not understanding the policies, or simply agree to do it, then resent doing it, then forget about doing it and revert back to old behaviours. Do not give anything new a fair crack of the whip.

How to see only bad things in change
The human is designed to be able to adapt to change. We're one of the most adaptable species on the planet. Psychologically, though, we fear change, preferring existing patterns to anything different, whether it is better or not. The best thing to do in order to maintain the status quo is to oppose anything you either don't know, don't understand, or don't yet like. This is an ironic stance to take in the world of technology, but who said that progress had to happen?

Outgroup mentality
It is possible that change will be pioneered in a small pilot group first. The beauty of human psychology is that it's perfectly natural for a group that you're not a member of to seem threatening in some way. You must follow the urge to feel resentment, suspicion, fear and even jealousy about the other group. In order to make yourself feel better about your own status, you must come to believe derogatory things about the other group, whose work you probably know little about. Where possible blow out of proportion the small tidbits of information you have gleaned about the other group's practices, and certain knock down any apparent achievements they report.

The paltry compromise
Where it becomes absolutely unavoidable to make a change to your working practice, agree to some sort of compromise which encapsulates "the letter of the law" but not the spirit. So if, for instance, someone suggests pairing, you should agree that pairing may occur, but that it's not compulsory, that you don't have to do it, and that your own desk doesn't have to be made pair-friendly. On the face of it, you've shown support for the policy, but practically, you don't have to do a thing differently, and the policy will fail, regardless of whether it is any good.

Throwing the toys out of the pram
Where all else fails, you should have a big tantrum. Here are some good tantrum patterns:

Shout at your team in usually calm setting.
Bitch with other people on the team and wind yourself up.
Have a blazing row whenever you can.
Make appointment after appointment with senior management, explaining why you cannot stomach the change.
Threaten to sue the company for constructive dismissal.
Bring everyone you come into contact with down with constant sneering and criticism.
Find another job and leave.

And you're done
With these ideas you can be the thorn in the side of the Agilistas. Well done. Of course, we all know that empty promises are just that, but were there to be any moves afoot to really improve things, the above methods will resist them just as effectively.

It's A Multi-Player Game

2006-06-19T23:35:00.000Z

Refactoring the team is a long process, in steps, each of which causes some pain, but each of which leads a step closer to the golden city that is the perfect Agile Process. Here are some of the things to expect along the way:

Once you have started playing the game, you cannot stop until you reach the end.
You must not disobey the rules of the game, or you will suffer the consequences
All moves will have dire consequences which will take you away from your original plan.
In the calm between moves, you must make the next move.
Some people will get stuck in the game forever if you are not careful.
You have no idea what you are about to unleash.

At various points along the way you should take some time with the team to see if they think you're finished. This process is called jumanji. If the team thinks everything is perfect, then you have to show them otherwise by unleashing some more arbitrary rules or constraints which knock down their already flimsy house-of-cards of a grip on their sanity, jobs and way of life. If the team thinks that they must become increasingly extreme in order to complete the game, then you are doing your job well and the rewards shall be yours.

Everybody Needs A Sidekick

2006-06-19T23:30:00.000Z

Some of the recent questions have reminded me of the importance of having a sidekick. This character can be the eager but naive junior, or a member of the pseudo-management team eager to increase his placebo-effect. Either way, working as an Agilista can be pretty lonely if there's nobody to agree with every word you say. Sure, you can make the upper management agree with everything, but that takes effort (saying the right things, yada yada yada) and it's also fairly dull, because upper management are programmed to want everything you are offering. So, it's more satisfying to have a partner-in-arms to help you effect the myriad changes that Agile requires; without one, life could be lonely and the process may take less effort and distract you from preparing for conferences and writing your blog.

Here are some of the archetypical sidekicks that you might have:

Muttley - incredibly self-satisfied and prone to evil chuckles. Also very dim.
Scooby doo - frightened of the unknown, but has an insatiable appetite for reward. Feed him plenty and he'll stick by you.
Scully - you don't need a Scully. They're too skeptical about everything and demand actual proof. Dull, dull, dull.
Amelie/Sophie - this Audrey Tatou of a side-kick is captivating and bright, but is so easily distracted by the plot and the information that unfolds, that she believes any old rubbish and is totally oblivious of any sort of quality.
Ben (or Bill) - speaks utter crap all the time which nobody understands, perfect for maintaining the illusion of plenty going on. The fact that nobody understands this character makes them feel frustrated and stupid with less effort on your part.
KITT - very technical, very capable, but constrained to sit on the sidelines and occasionally get broken into. Excellent to send to conferences.
Luke Skywalker - young and easily manipulated into trouble. Luke has something to prove, but he's not sure what it is. He learns skills, but cannot control his eagerness nor his destiny.
Moses - the best sidekick to have. You give him your simplistic ten commandments and he'll lead the entire tribe through the wilderness for forty years.

Choose your sidekick wisely. If possible have a few.

Get 'em out

2006-06-19T15:52:00.000Z

It's a dilemma for some managers. What do you do with the lesser abled members of the team? What do you do with the people who don't seem to want to toe the line of your team? What of those people who don't respect you or your process? Should you compromise to include them?

The answers are:

Get 'em out
Get 'em out
Get 'em out
No

If in doubt, keep them around long enough to make them disillusioned and then get them out. Any suggestion that you shouldn't adopt an elitist process across the entire company and expect to make it work should be treated with the contempt you deserve.

Getting A Doer

2006-06-19T15:45:00.000Z

Another question from the your questions answered section:

Should I spend more time pandering to the junior programmer who's been put into the team leader role because no-one else wanted it?
That seems like a pretty loaded question. Why would a junior programmer be put into a leadership role? Let's tackle this question in two parts. Before that, let's look at human nature. There are some key human nature points that Agilistas everywhere rely on:

People are frightened to look stupid and so back down when they don't understand
People will take the line of least resistance
It is easy to motivate someone to do something they like doing
If you treat someone as though they're special, they'll do more for you

With these principles, it's clear that the role of an Agile coach will encounter three sorts of people:

Believers - they'll do anything they can to busy themselves with their sort of work and to get the rewards of being told that they're a good follower
Agnostics - they don't give a damn and they're frightened to rock the boat, so they'll follow the path that seems to avoid any trouble
Anti-agilists - they question everything and they're trouble. Don't have too many on the team.

If you have a principal believer, then they should be promoted to a role that enables you to harness their fervour. Feed them anything you think will increase their passion.

To answer the question then.

Spend more time pandering to the junior programmer?
Juniors are more gullible and if you treat them correctly they will do anything you want them to. You can use your relationship with them to further divide the team. However, and this is the clever bit, you can wind them up for weeks, only to have them move to another team, which you don't control, and go totally mental applying dogma without any actual direction. Give them occasional coaching and you'll be able to watch them wreak havoc. Hilarous.

The Team Leader Role Nobody Wants
They say the best person to lead is someone who doesn't want to lead. This is nonsense.

Equally, in Agile, the person who wants to run the team is also ill equipped to do so. They will focus on the wrong thing - i.e. not getting the job done, but getting the Agiling done. That's the person you want on your Agile team.

As has been said before on this blog, if there are good managers in the team they'll see through you and make it impossible for you to do what you set out to, which is establish a self-serving process, rather than deliver good software. So, if you want to ensure success of Agile against the grain of a company, you need to ensure that there is no formal management structure to get in your way. Sending in a boy to do a man's job is one of many tools to achieve this.

Progress Reporting

2006-06-19T13:46:00.000Z

A correspondent on the Your Questions Answered topic posed this interesting question:

This is all very well and interesting, but how can I use this to maximise my consultancy fees whilst still doing nothing other than sitting at my laptop and reporting back to the MD at regular intervals?
The answer, of course, is in progress reporting. While it goes against the grain of a lightweight "agile" process to have extensive reporting, it is vital for an "Agile" process to put emphasis on reporting the right things to management. This can be explained with the following scenario:

Boss I need help running my company.
Agilista Agile is the way.
Boss I need to see progress.
Agilista Oh you will.

later...

Boss How is it going?
Agilista Look at all this progress [produces semi-intelligible data with plenty of buzzwords].
Boss I don't understand it.
Agilista Ah, well, you're not meant to understand it all. Some of it is internals from the process. Do you recognise its existance?
Boss ... er... well... it's right here
Agilista And do you see its magnitude?
Boss though I'm uncertain of the units, yes I do.
Agilista Then there's been plenty of progress, which is good. You do understand don't you?
Boss [not wanting to look stupid] Well, if you put it like that.

And so, progress reporting is the lifeblood of your business. If you don't report progress, then there has been no progress. Conversely, and this is the good bit, any progress you report is seen as a success of the process, whether or not it would have happened anyway. This, coupled with the other maxim that if you break down the progress report into chunks of a tenth of the size, the progress looks to have increased tenfold, means that you are, quite literally, laughing.

Is that all?
Nearly. The whole purpose of Agile is to manage expectations. Everything you do must be in support of the expectations you want on you. So, if you want a cushy job where you spout occasional bits of dogma, leave the team to get on with the nonsensical self-conflicting process, and then claim their every success as proof of your value-add, you must manage things carefully.

Set the tempo of your relationship with management carefully. If you come in promising quick returns on day one, speaking quickly and enthusiastically, then you will be giving them rope enough to hang you. If you act quickly in conversation, then people expect you to act quickly in everything, and produce actual tangible results quickly. Conversely, if you seem desperately slow and sluggish then people will assume that you're not very bright and will not trust you. However, if you speak at a moderate pace, and leave big pregnant pauses in between, people will assume that you're bright but thoughtful. Try to be dry, deadpan and slightly dull too. This will counterpoint with the common-sense/flaming-obvious that you say when you are speaking, making you seem even brighter. Also throw in some redefinitions of well understood concepts to ensure that people are never quite sure whether they understand you, but dare not challenge your definitions lest you prove them wrong in an apparently patient-yet-really-exasperated manner.

Your behaviour sets the expectations, so from your steady, but not sluggish, and sometimes-intimidating taciturn exterior, even the slightest of achievements will seem like not only big progress, but also big progress born out of powerful common sense.

Don't crack a smile, it takes 10% off your fees.

Sitting at the laptop
Get the on-site IT people to provide you with a net connection for internet and email. Ensure that you tell the team that email is muda, so they can't email you and catch you off-guard as you spend the entire day on yours. If you can piss the team off so that they don't really want to ask for your help, lest you change yet another aspect of their working environment, then you have an excuse to charge money to sit in the corner undisturbed, claiming the results of the people who want to leave you alone as proof of why you should do it some more.

The Parable of the Yakisobi (or Fat Woman)

2006-06-17T00:31:00.000Z

Management is very difficult. At a recent conference of the highly rated French Agile Society - Societé de FRAgile - I attended a session on how an Agile team was being held back by a passive aggressive team member. The only solution was to remove the person from the team, but management had built a huge resistance to her removal. The story was told by sensei Clive Parkinson as a parable. I was so excited, I took extensive notes and can recall it virtually word for word, except for some words which I misheard because people were talking near me (editorial comments are in plaintext, the story in italics):

Once upon a time there was a large woman, large because of all the high carbohydrate food she ate. We called her the Yakisobi, or stupid flat beach?. Her responsibility was to provide the translation for the user interface text in our software, which was ironic since she couldn't speak any foreign languages (not even Japanese?) and her grasp of our own language was very poor too. She claimed to be dyslexic, but this was probably a misspelling; she was diabetic. Her favourite food was honey. According to the other women in the office, when she went for a pee, you had to hold your nose.

Such personal mismanagement can only lead to professional mismanagement and, as her crop top was inappropriate on her flabby belly, so too was her approach to her work. She could not adapt to the Agile approach, preferring instead to use the Salmon method. This is like the waterfall method, but involves swimming upstream for ages, apparently defying sense, until you arrive bedraggled at your destination, finish what you set out to do and then keel over. We tried getting her to do even simple tasks like using a planing wind? where she could set out the work she needed to do in the next week and report on doing it, but to no avail. This was one seriously shoop idmuth afock oar?

Her days were numbered but, rather than move her to another team, or even get management to spell out how much of a liability she was, we left her on the critical path. For seven years.

It's a hellish tale. Why anyone would leave a problem like this unsolved for more than seven weeks is a mystery and Clive tried to explain some of this in a questions and answer session:

How did she get the job? Poor interview technique on our part and great interview technique on hers.
How did she get diabetes? Not really sure, but type two is common among very fat people and a diet of Mars bars and honey can't be good for you.
How come management didn't sack her? At first they didn't realise how crap she was, then it was too late.
How come management didn't divert her onto lighter duties? She was a classic "barrack room lawyer", capable of playing the rules and playing management off against each other. By the time she left she was on a salary which could have paid two of the juniors on the team.
So she was bright? If she could only have shown the linguistic skills to match her playing the system skills we could have made great use of her. I'd rather have had two juniors, or paid our existing juniors a bit more - they worked hard.
Was she popular? She was certainly well known. She busied herself with everything, except her actual work. Still, if you needed Christmas decorations, fire regulations or help with talking to workmen, she was your man... sorry, woman.

Useful indeed. So if management cannot control a problem when it starts, then it can become so entrenched and accepted that it's almost impossible to do anything about it. It's a bit like diabetes. You get to choose whether to control your weight after you've had your first candied piss, if you choose to continue sucking the bon-bons like the Yakisobi, then your days will be numbered.

Dou Da - The art of the retrospective

2006-06-17T00:12:00.000Z

The term retrospective came about with one of the early forms of Agile process. The Agile-meister, who had only achieved mere "kasa" status (that of an umbrella) kept calling all bad things in the team "gay" and all good things "wicked". It was decided that the gay/wicked rating was purely subjective and needed to be imposed on the team in a way which made them all believe it was their idea. The team sat down on their beanbags (two to a bean bag, in the primitive and now abandoned pair-sitting initiave) to have a "gay/wicked" meeting. They put a Pet Shop Boys album on the stereo and started trying to talk over it.

As the intro for "I want a dog" played, the team considered their stance. Some things were bad, some things were good. The chance to go back to the old ways which had their shortcomings but seemed to work, wasn't offered. The only thing they could do was to agree what they liked and disliked and, with an inspired bit of misdirection, agree to do more of the good things and fewer of the bad things. This seemed so obvious that nobody realised that it was actually an opportunity for the Agile coach to set policy by simply writing his suggestions in green in the right box.

The meeting worked. Nobody argued. The music seemed to help, though it was a bit disruptive. They named the session after the album they were listening to. This was subtley renamed by the Agile coach to "Retrospective" and nobody noticed as they'd not been paying attention anyway because the meeting dragged on too long.

Dou Da Dos

Do encourage everyone to speak, unless you don't like them, in which case appear impatient while they're speaking
Do hijack the meeting to impart any pseudo-wisdom or dogma you might have to offer
Do speak at length until people are bored
Do threaten to have retrospectives more frequently if people aren't happy - they'll soon back down
Do delay your retrospective if the team are looking particularly unhappy about something - nobody wants a meeting which could get out of control because of feelings
Do send notes to management if the meeting makes your staff look like they need disciplinary action - best to look like you've provided records
Do rephrase all contributions in the proto-language of the Agile world
Don't explain the term proto-language
Use phrases like - there are too many quills and not enough mongeese

Dou Da Don'ts

Don't allow the reactionary member of your team to run the meeting
Don't follow up too many points from the meeting - in fact it's best to follow up none unless you were going to do them anyway
Don't let the scope of the meeting restrict your imagination - include things in there which you can't possibly change
Don't keep records for more than two weeks
Don't wear blue on a Wednesday - it's bad "sith"

Concave Hexaflexagonal Architecture

2006-06-17T00:00:00.000Z

How many sides does a Rhombus have? Four? Think again. What if you're viewing it from the side? Then perhaps it only has one side. If you're viewing it from within and it's very large, let's say it's the size of a playing field, then the number of sides might seem impossible to gauge. That's software, isn't it? Hard to work out? Lots of sides. Can be viewed from different angles.

Now, consider the Hexaflexagon. It has six sides and also six faces. Yet only two of the faces can be seen at once. If you wanted to explore the hexaflexagon, you'd have to do so interactively. This would take some time and it would not be automatable by computer... at least not in a way which fits the arbitrary definition of unit tests, regression tests and legacy code which we're imposing for the sake of argument, but also for the sake of all of our core assumptions that we're using to drive a stake through the heart of your process.

So, how do you see all the faces of a hexaflexagon simultaneously? You build it in one long strip which can be assembled into the hexaflexagon, but which can also be unravelled for piecemeal inspection by dumb testers - by which I mean xUnit, rather than some sort of unintelligent testing person. The ideal is to replace all testing people (who can prove that unit testing and automatic regression is only about 30% of the deal) with machines before anything can say "Quality's in the toilet and flushing".

Let's forget the fact that it's much harder to build a generic machine that can be used both in a test rig and in the real world simultaneously. Let's even forget that a fair amount of mock code, a lot of which is what the unit tests are actually testing (rather than the real code) has to be generated and may in fact not behave the same as the actual code. Let's forget all of that because it serves our purpose to do so. By making our machine in such a way that it can be hammered flat and played with in pieces, we can tick all the boxes and even get a computer to suggest that everything's working great all the time. Regardless of whether it is. By our definition, we've avoided legacy (bad) and improved quality (good).

Ignore the fact that all of this takes longer and proves nothing. This approach may be "ecchi", but it's not icky!

Shoehorning

2006-06-16T23:42:00.000Z

Agile is a process which only works in an isolated bubble away from the "tokyo" or "real world". The problem with this is that you'll invariably have to force it upon real people in the real world and will, therefore, be unable to choose exactly how your real team is structured. Therefore, in every Agile implementation there should be an "engawa" phase, or "shoehorning". The shoehorning comprises three different processes:

Substitution - where a missing requirement of Agile is provided by an inappropriate person - for instance, choosing a "customer" who is, in fact, not clear on how to choose requirements. This works best when you give the person you choose a confusing/misleading title.
Artificial inclusion - including people in the composition of the team because they're there, rather than because the process can possibly make use of them. A good example of this would be to include the person who designs the packaging in a project that has no packaging yet and isn't likely to for a while. The artificially included person may remain idle, or, if they're really keen, invent work for themselves to do, which is ultimately valueless, or has a lower value-ratio than makes it worthwhile. It's best if that person could have been of more use elsewhere in the company while they've been sitting misused in your team.
Rationale invention - for every illogical think you've done, especially those which challenge the nature of the organisation you've imposed on, you must find an explanation which is at least vaguely feasible. This process of rationalisation offers something to report up to board level on your activities. It does not have to be true or make sense.

The process of shoehorning is very delicate and can lead to rejection of Agile if you get it wrong. The best thing to do is respond very quickly to criticism, either shouting it down or producing further substitutes, inclusions or rationales. Alternatively, keep rewriting the rule book on how the team is composed so that nobody knows exactly what is going on. This will avoid people seeing the cracks in your process through which the lifeblood of your company drains.

Information Radiators

2006-06-16T23:30:00.000Z

If you are to maintain a sense of progress against all traditional evidence to the contrary, and if you are to successfully convince the management of your company that your team is a hotbed of useful activity, then it's vital to festoon every wall of your development area with diagrams, charts and other visuals that imply total progress. The first complaint of management will be that they don't understand what this progress means and that the units don't compare with any other data they get. Your job should be to protect the team from these complaints and ensure that the reporting system you use is unique to the team and totally unintelligible by management. You can get away with this by explaining to management that the charts are internal to the team and not for public consumption.

However, with a diagram you can prove anything, so if you want to get some particular advantage for your team, like free cokes, or the ability to lock the door to keep troublemakers out, then all you need to do is schedule a trial of the thing you want and then rig your diagrams to show a marked improvement during the trial. Simple. Management will constantly want to use your diagrams to show how successful they have been, but will also want to standardise and be able to interpret these diagrams in real terms. In this situation, change the diagram.

Information radiators are great because they suggest tons and prove nothing. If you are to get away with a process oriented approach to your job, then you must be able to imply that the process needs constant improvement. The more diagrams, the more pseudo-evidence you'll have for this. Information radiators also allow a process called gaming. Gaming is where the team are able to improve their performance by optimising the exact thing that is being measured - this could well be an improvement in the output of the team, or it could simply be a micro-optimisation of whatever it is that you want to show the world. For instance, who is to know whether a rising chart is a good or bad thing, for a particular measure? Perhaps one chart might show the number of coffees drunk, which if it rises, might suggest people are really thinking over their problems over steamy beverages... which might be a good thing, but which could easily be improved by feeding the team salt so they're thirstier, or by simply offering to get a round of drinks in, which will make the lazy bastards drink more, regardless of what they're doing.

Important: gaming your charts is the best way to enhance their placebo-effect or "tenko".

With so much opportunity for obfuscating the work of the team with walls full of information, and even an opportunity to campaign for your own room in order to gain these walls (and also gain further placebo effect from the closed-door = more productivity measurement you can rig), I thought it would be useful to list some ideas for charts you could put up.

Worth Putting On Your Walls

Number of tasks completed - don't specify how big a task is, and make the tasks smaller to improve performance
Number of conferences attended
Money spent on consultants
Time spent pairing (or halving individual productivity)
The age of the oldest member of the team
The age in minutes of the oldest support incident awaiting work
The number of members of the team
The number of members of the team who would piss on the Agile coach if he/she were on fire
The pig to chicken ratio
Length of the stand-up meeting

Never Measure

The amount of work completed in any coherent or consistent units
The number of bugs outstanding - if you have to, then throw away bugs that you don't like
The amount of time spent each day updating the charts
The resentment in the team - this should be on the rise, but chart that separately and privately
The number of corners cut in the name of progress
The number of people in every single meeting
The number of Agile books you've read
The number of Agilista asses you've kissed
The number of jobs your team members have applied for

Game Theory

2006-06-14T10:32:00.000Z

It's all a game
To quote the most Agile of the Agilists, Mary Poppins: "In every job that must be done there is an element of fun, you find the fun and SNAP, the job's a game". Ms Poppins comes from the nanny-state school of Agile in which all lowly workers should be treated as errant children, encouraged to do work through games, song, dance and the judicious use of chimney sweeps.

Some people have told Mary to get back on her broom stick and fly off. These people are foolish. It's an umbrella. The point stands, though, Agile is a series of games. These games are played in the Dojo (not involving a Yoyo, humble or otherwise) which is the office, under the presidency of a Nanny/Coach/Head Sumo.

What are the games
Here is a non-exhaustive list of the games you can play as part of the Agile process:

The standing around a whiteboard game
The planning game
The getting everyone together for a meeting game
The I'm not giving you a dressing down but you'll have spent time listening to my raised voice, game
The who's in charge? game
Retrospectives - the what can we write down about how much we messed up this time and then challenge ourselves to screw up more next time, game
The I want a new job game
The playing off management against each other game
The guess what the next job is game
What's my line? - like the TV show, but rather than getting a panel to guess your job, you have to guess it yourself
Who can be the most keen? - a competition to see who can be the most excited about nothing
Pin the blame on the donkey
Hopskotch
Story drafts - drafting and redrafting requirements until they're virtually meaningless
Cards - a variety of card games, involving pin boards, index cards and making the lack of grand progress invisible by breaking down the few things you have done into fine-grained tasks which are progressing
Call my bluff - the game that should never be played with an Agilist - you'll always lose, they have the advantage of being able to invent more terms than you can question
Hangman - when the projects start to fail, someone will get it in the neck

Maybe there are some games not listed here, please add them via the comments facility.

How Many Pair Programmers Does It Take To Change A Lightbulb?

2006-06-14T09:27:00.000Z

Short Answer
Two. Of course.

How long does it take?
More than 5 minutes, that's for sure.

Full Procedure

Try to develop a test for darkness
Rig up some sort of light sensing equipment and realise that this will only work when the room is naturally dark, so daytime is not the right time, unless the windows are boarded up
Board up the windows - they're not absolutely necessary anyway
Make an abstract interface for the lightswitch and insert it in place of the actual light switch, with the actual light switch connected back to it
Create an adapter for the existing bulb that adapts it to a testable bulb interface, and an adapter for that adapter to adapt back to the bulb socket
Reinstall the broken bulb with this new adapter
Ensure that the darkness test still holds
Use a torch to see whether the darkness test works with light at all
Go home for the night
In the morning, discover that someone else has noticed the bulb is broken and has replaced it in the space of a minute, wrecking your previous day's work
Spend the rest of the day drinking lattes with your mates and berating the short-sighted fool who change the lightbulb on his own and removed the boarding from the windows.

And there you have it
This stuff is true and not up for debate. Please let me know experiences of your own wih similarly trivial tasks which you have double-staffed and than dragged on long beyond the point where it was beneficial.

Agile Up

2006-06-14T08:26:00.000Z

Two colleagues of mine went to SmugFest '06 this week. They presented a presentation on their recent successes in shoehorning Agile into their company. Here are their slides:

Outstanding work there. As Nat King Cole once sang - "Many a tear has to fall, but it's all in the game".

Your questions answered

2006-06-13T23:50:00.000Z

Please use this post to submit any ideas for areas you would like me to cover. Remember, you can post anonymously if you wish.

I AM NOT SHOUTING

2006-06-13T23:47:00.000Z

Now, I'm a wannabe Agile-muda-scrum-meister, seventh veil, third sudoku, sixth psi. I know how things are. I have literally wrecked more than two different organisations and my theoretical knowledge is going to be used to wreck yours, if you'll let me. I have done all the research I need to do, reading 5 books, and watching seven movies, including Back to the Future, a story of refactoring reality. With the tricks I have learned, I know how to behave to be the most effective. Here are my tricks.

Distortion
Everything I hear will be processed by my brain in such a way as fits in with my world view. I will tell you back something I've heard about you and you only get to confirm or deny it. I will relay your thoughts up and relay management's thoughts down in such a way as to impose my beliefs on how everything should run. This method is called the sushi method as it leaves everything redolent of fish.

Anger
Generally people like to keep peace. If I show fits of anger when faced with even minor disagreement, it will discourage debate on larger issues.

Urgency
I will speak animatedly on matters which concern me and I will confer a sense of urgency about everything. Coupled with my apparent temper, this will make people want to do things to either appease or avoid me. Either way, they're playing things my way.

Confusion
As all stories are already distorted by me, there will be some confusion anyway. However, I will try to create more confusion with huge multi-partite explanations of anything I'm trying to stop you doing your way. These explanations will be too big to understand, will involve over-use of the whiteboard, with diagrams that you don't understand, and will, ultimately leave you more confused and unafraid to ask any more questions lest the explanation goes on longer. Alternatively, you'll think you understand but this illusion will fall away once you've left the room, or once you ask for a minor point of clarification which I'll explain in a way to make you feel you understood nothing. I will secretly change everything I've told you immediately after telling you, so that even if you understood it, you'll still not be doing what I now want.

(Un)reasonableness
I will act as though I'm a calm, rational and friendly person. I will believe that I am all of these. I will even understand your point of view. However, deep down, everything has to be done my way and I will not admit that, nor make it possible for anyone ever to do that. If possible, I will bring more people into the organisation who naturally do things in a way which sounds like my way. I will create an inner circle with them in, but we'll still not have a consensus on how it's done.

Interception
By creating a barrier between the worker and the management/strategy team, I will further a sense of mistrust between groups. I will also know of everything that is going on. This will prevent me ever getting bored as there is no pie which doesn't have my finger in it. I will extend the finger/pie metaphor further by going for a poke in the fridge in the morning. The purpose of interception is to impose myself on everything and avoid there being a critical mass of things I've not had a go at threatening to knock me off my self-created pedestal.

Possessiveness - to keep control, I must ensure that I have the opportunity to do anything and everything that comes up. If I'm stuck with colleagues in the management team I will try to spread myself very thinly across all events so that I can lay a claim to any idea that is good, or any area for which ideas are needed. If possible, I will have a piece of paper, email, or a whiteboard or flipchart drawing to back up any discussion that comes up. As a fallback I will claim to have started thinking about any new areas as soon as they're mentioned. In order to increase my possession of management issues, I will angle to get any colleagues tied up with less-managerial tasks, which I will pass off as temporary help to the team they're working with.

Acidity
Acting unpleasant or angry whenever provoked will ensure that people learn to leave me alone. Another good trick to increase my harm is to virtually hold my temper in front of the people who are a threat and then have private venting sessions against those people with my cronies and upper management. This level of acidity will enable me to grow, though it may reduce the viability of others.

I AM NOT SHOUTING
Where possible, I will deny any of these practices, even while doing them. I will not allow self-awareness or respect for others to hold me back. If faced with complaints that I cannot deny, I will act contrite, but only temporarily.

When Good People Do Bad Things

2006-06-13T23:26:00.000Z

Part of good management is to build a culture where people are rewarded for doing good things and steered away from doing bad things. Should someone go wrong, then they should not be punished, although it's important that they are clear about how they have gone wrong and how to put it right. It's not always so cut and dry, but when there's room for ambiguity, that's when there should be a partnership of management and worker to find out the best solution.

All problems that are left will fester. So don't leave problems. Also don't leave people on their own with nobody keeping them in the loop. If something has been mentioned, follow it up. The more junior the member of staff, the more important it is to keep them in the loop.

New ideas are important too, if you want to thrive then you should stay abreast of the latest developments. Perhaps you should put time into retraining or evaluating new ideas. This time is simply not available if you work at over 80% capacity. If you work at 100% capacity then you'd think that you deliver more, but the pressure of doing that will slow you down in the medium term and stop you in the long term... so don't.

Don't half-start improvements and drop them the moment something difficult happens. Don't give people license to investigate something, get conclusions from them and then stop them from finishing the job. Don't fall into the trap of assuming that any new tool has to be slowed down by having all the old work ported across to it. You can be the enemy of progress.

It's quite natural, after a few years of getting things wrong for people to become tired of fighting, or become so incensed that nothing ever happens that they take the law into their own hands. Your polarised workforce is then composed of revolutionaries and stick-in-the-mud types. There will be blood.

How To Turn Your Company Around

2006-06-13T21:02:00.000Z

Let's assume that you were able to make your company work pretty well when it just started with you and a couple of mates in a backroom somewhere. Let's also assume that it grew at a reasonable rate up until the point where you had to choose to really go for it and expand. This is the point where you either keep your strength as a company and as a leader, or you turn things around and set off the time-bomb which will eventually blow up in your face. Here's how to set that time-bomb. Everyone loves a loser, after all.

Surround yourself with people who tell you that you're great
This is absolutely vital. Where, during the early years, people could tell you that you were bound to fail and they might be right, now you can't afford to waste time stomaching the possibility that you're not guaranteed to make everything turn out right with every move you make. If possible, get a charismatic Svengali figure to tell you that you're going to make it big, also make sure you have a snake-like figure on your board who will only ever tell you what you want to hear.

Under no circumstances should doubt or reality enter your inner circle. You believe in yourself, make the promises, and your workers will make something akin to them come true.

Convince yourself that everything is great
There are lots of ways to do this, and it's vital if you want to achieve the turnaround of your fortunes. If you believe everything is great that everything you see will be great and your entire existence will seem more worthwhile, which will mean that you will be able to tolerate failure for longer, because you'll barely notice it, not accept it as failure at first, and certainly not have to do anything nasty about it for a long time.

Making positive affirmative statements is a good way to drum things into yourself. Say it every morning: "everything is great, I am great, I'm destined for great things, and people will notice and respect that". Picture the results of these great things.

The fact that you've filled your inner circle with people who agree with these affirmations will make them seem all the more true.

Don't invest in strong leadership
Good leaders cost money. Good leaders can also challenge your authority. They can staunchly refuse to accept impossible requests and can make you less able to see the almost infinite potential that your otherwise unblighted optimism yields.

Instead of a strong leader, you need one of two sorts of leader:

The carpet sweeper - no matter what the problem, he'll sweep it under the carpet in the name of short-term succes
The non-leader - he's in the same position of power as a leader, but doesn't have the experience, authority or support to make it as a leader. He will busy himself with everything and ultimately throttle everyone's efforts.

Either will do, or maybe try both.

Always trust a snake
So, you've brought the snake into your inner circle. You've put him into a position of power. Your very success depends on him. It's important not to see through him, no matter what happens. You must maintain the suspension of disbelief. Even if you see the snake either fail to commit himself until he's clear what you want to hear, or change what he's saying as he discovers that you don't want to hear it, you must not waiver. Even if you discover that, like an unobserved quantum particle, he appears to be in all states simultaneously, and only, when it's clear, from the particular observer, which particular state he should land in, does he magically appear to be "right behind" that outcome, you should never doubt his ability to make up his own mind.

The snake will also have motivating behaviour, like teasing, insulting, assaulting and otherwise abusing his direct underlings, coupled with stealing any good idea and claiming it as his own.

The snake is an excellent orator and comes with some perfect rhetorical habits which will aid him in getting himself across, moving forward, with a maximum of impact.

Neither bully nor lead your staff
It is important for you to be liked, so you must not bully the staff. In order to avoid any problems coming to a head too soon, you should also become increasingly distant from the people you used to work closely with. If possible use management via rumour - where you hear something that you don't like and then rumour it back to the person you heard it about in such a way that they can't really defend themselves, as it's not an accusation as such. This sort of non-confrontation can be just as soul-destroying as confrontation, but much less messy.

When you do have to step in, try to sugar the pill by being all coy about it and making yourself look as reasonable as possible. Deny all knowledge of anything the snake has ever done, or you may have to confront his identity as the snake.

Company values
Everyone wants to work for a good company. As a result you should gather all the attributes that people want the company to possess and then claim to possess them. Make your staff agree to uphold these values. Then the company will be perfect. Don't worry that any way to get people to agree to abstract values will be excruciatingly false or painless, or that the unspoken company values need to be just that and cannot be conferred.

Company values are mandatory for everyone except the snake.

Have a false blameless culture
It's important, if people are going to like you, for you to appear to be reasonable. If you go round pointing the finger of blame, then you will not. So you must always appear magnanimous in the face of failure. However, you can subtley let the cat out of the bag with the way that you announce your magnanimity surrounding mistakes (caused mainly through other poor leadership decisions). By declaring who you're not going to blame, or charging people with a task that sounds a lot like "clear up the mess YOU made", you'll show people who's boss, and what sort of a boss too.

Blame process rather than people
Jump at any opportunity to shake things up, regardless of the effect. A good process can cover a multitude of sins, regular process change can be increasingly self-justifying. If you can find an opportunity to double output and half costs on a team, then, by induction, you could soon have a team working at huge efficiency, leaving more people free to do the same. Ignore the fact that halving a team 3 times to get a 10 fold increase in output is mathemetically possible according to your flawed hypothesis, but realistically impossible.

Keep the problem solvers away from the problem
We all know that someone with hands-on knowledge of a problem and with the power to solve problems will make a good practical solution. Don't let people do this. Instead, insert a series of stakeholders who don't know their authority or scope or success criteria. By having a huge committee deciding what's necessary and keeping your problem solvers a few people removed from the actual end product, you will soon avoid the success you used to enjoy.

The snake will already have removed any long-term strategy you could possibly have had a hope of maintaining; his agreeing to everything will create a total deadlock in planning where everything is at the same priority level: high priority, needed immediately.

Fiddle while Rome burns
No matter how many low-down people, if they're allowed to speak to you, tell you that your company is going to ruin, don't do anything. Or, better still, tell them that they're making sense and give them some motivation to sort it out. However, the moment your middle manager speaks to you, tell them a potted version of what happened and agree to leave it to them. This manager will then spin the story into something else and effectively block anything that your low-level guy was about to think about doing.

If people challenge you directly about what's missing, agree with them and then explain why it's all so hard. Bear in mind that if you find running a business too hard then perhaps you need someone who knows how to run a business to run yours, or, if you're intent on running yours into the ground, you want that sort of person nowhere near you.

Let your best people go
Your best people won't stand for this forever. If they know what's good for them, they'll leave. Otherwise they'll turn into mush and will stay around getting increasingly useless. For your company's fortunes to turn from gold into dust, you need dusty people. For extra credits in your ruin everything scheme, treat your best people like they're trouble makers or put them onto light duties. For double bonus points, offer some of your most effective people a role which puts them directly at loggerheads with the way the rest of the organisation is being run and watch them act like the bit of grit which sometimes makes a pearl in an oyster, or sometimes turns into pus.

Sack the whingers
Once your good people have left, you can find the people who don't truly believe that you're the amazing leader you've painted yourself to be and told yourself you are and been told by your inner circle that you deserve to be. The whingers don't believe the dream and cannot be a part of it. They will drag everyone else's suspension of disbelief down from the clouds and into the real world - this cannot be allowed to happen. Sack them. If you don't do it now, then it will be harder later.

And you're done
If there's anyone left after this, you will have turned the company around, that's for sure. Good luck with that.

How to be an Agilista

2006-06-13T18:04:00.000Z

Pronunciation
That's Aj-ill-eesta, it comes from the Latin meaning literally "toss pot". It has a similar route to the name of a coffee brewer at Starbucks (Barista - bah-ree-sta - "coffee pot").

Fervour
Agilistas are nothing without fervour. If you cannot be excited about it as though it's a cult, then you should not even dare to call yourself an Agilista. After all, not only is Agile trendy, but it's based on sound engineering principles. Let's forget that the evolution method, waterfall method and countless other approaches are also based on the same sound engineering principles. Let's also forget that there are various other processes out that which produce the same results as Agile with the same (or less) effort, but just in a slightly different way. You have to believe that Agile is the king and you are the serf to it... but also the master of anyone you consider too stupid to understand why your pet approach is the only way forward.

Name dropping
A lot of Agilistaism is about who you mention. If you can mention Kent Beck or Ward Cunningam then you're laughing (probably in a maniacal fashion). If you can mention them and claim to have met them, extra points. If you can do it and claim to have written code with them, then quadruple extra points. If you can say it in an apparently blasé way, but fail to conceal your excitement, then minus two points for you, mudafokker.

It's not just the names of people, Ron Jeffries, but it's also the names of books (ooh... the white book...) which will get you noticed as an Agilista. A lot of this is showing off what you think you know, most of which is common sense... in fact you're demonstrating your commitment to the world of Agile. The more of the right books you read the more time you've invested, probably your own spare time, in giving your soul to the collective.

If Agile is not sounding like a cult, then you're not doing it properly. You have to sound like a cult... member.

Silly metaphors
A knowing smile, a glance at a fellow Agilista and then you can be happy to say things like "Are you a pig or a chicken". It's important to be able to explain these metaphors too, and you must not lose your nerve when you do so, even though they sound stupid. However, the key thing is to have these metaphors by the cart load. For Pigs and Chicken, the official explanation is "Well, if a pig and a chicken set up a business called bacon and eggs, the chicken would be involved, but the pig would be committed". Additionally you can add that the fox can stay with the farmer on the south bank, leaving the chicken in the boat with the corn, provided that the farmer's wife brings the pig with her when she buys the magic beans. It's very simple, really.

Promoting dogma
It doesn't matter whether some of your techniques would work in only 20% of the cases and simply be almost impossible to apply everywhere else. The fact that they've worked is reason enough to promote the dogma. The best example of this is "story writing". If you can stick to the idea that a story can be written for every discrete block of work, despite all evidence to the contrary, then you are indeed wealthy and the world will be yours.

One of the best ways to do this is, when faced with resistance or complaint about the fact that the real world doesn't fit your particular model, to insist that people have a go at attempting to shoehorn their problem into your restricted viewpoint. Then, when they fail, they've already committed to seeing it your way.

Changing your mind without apologising
Being Agile means never having to say you're sorry. The story cards are, again, a good example. Promoted as the only way to provide requirements, they can soon be dropped or made less important and you need only to mention that you've found them less useful and you can continue unabated, as though you didn't push the point with them in the first place.

Ohno Not More Muda

2006-06-13T17:18:00.000Z

Yes, moreda.

The seven Muda are in fact nine. Seven of nine are the original Muda and the remaining two would be a Muda not to includa:

Defects - produce something of bad quality and nobody will want it - or they won't be prepared to pay full price for it
Overproduction - make something that nobody asked for and nobody will pay for it
Transportation - mess about moving stuff from here to there more than you need to and there's increased risk to the thing and increased cost
Waiting - pay people to sit about doing sod all and you'll regret it. This especially counts when you have a bottleneck in management.
Inventory - make something incomplete that you can't sell yet and it's sitting gathering dust when you should either have finished it off, or made something you could sell sooner
Motion - moving people around, confusing people with change, all reduce output
Overprocessing - give a man a boy's task and you're losing the difference between a man's and a boy's wage
Skill - don't take advantage of a skill that someone has and you're wasting the potential and perhaps allowing that skill to go to seed
Pissing about with the process - refinement to process aside, if you're process oriented, rather than people and results oriented, then your effort is going into the one thing that cannot, alone, make you any money!

With the additional 9th Muda, we have a mudavellous list of things that will hold you back. Let's compare some things to the list:

Changing management structure - that's movement
Bringing in a consultant to tell you the obvious - that's overprocessing
Changing process frequently - that's pissing about with the process
Working on several versions of the same thing simultaneously - perhaps that's overproduction and inventory rolled into a big muda-ball
Moving people between projects just before they're finished, leaving nobody available to finish them - that's movement and inventory
Working on products without market research to determine whether there's money - that's overproduction.
Releasing products too late to compete - that's overproduction.
Releasing product without full knowledge of what's required and missing the mark - that's defects and overproduction and inventory.
Taking your experienced staff and using them for simple tasks - that's overprocessing.
Taking your experienced and skilled staff and changing their roles - that's a skills issue - some of their better skills may go to waste.

Pray you're not in a company like this. Every one of these mistakes is textbook and needs to be changed.

Wielding Power

2006-06-13T10:05:00.000Z

Not all would-be Agile coaches need to come from outside an organisation. No, you can be the person from within the organisation who starts the ball rolling. There are two possible reasons for doing this:

Interest, along with your team mates, in improving things
Self-interest in both changing the world and being seen as the instigator of change

Depending on the route you take, the results will vary. The first route is likely to be pleasant, flexible and positive, the second is likely to involve wielding power to get your way.

Improving a team collaboratively
You: Hey guys, I've just found this new idea.
The Guys: Tell us more, show us links... yeah, that idea looks cool, how do we start?
You: I don't know. Let's find out together.
The Guys: Mmm... what we know so far looks interesting. Let's try this aspect of it.
You: Careful now, some of these practices only work when in conjunction with other, balancing, practices.
The Guys: Good point, but we can't change the world in one go. We'll have to refactor it.
You: Yes, you're right, guys. How would I ever get along without you?
The Guys: And how would we ever get along without you?
[Exeunt into the sunset, holding hands]

Wielding Power
This is a far more complicated route, but ultimately more interesting. You have two possible outcomes:

You will be feared, hated, reviled, but able to crack the whip, while simultaneously believing and telling people that they're working in collaboration with you
You will lose your job

Maybe it's worth the risk, maybe it's not.

Here's the script:

You: Hey boss. I've discovered some techniques. We've been doing everything wrong and these techniques will put it right.
Boss: I don't understand.
You: You want a more effective engineering effort?
Boss: Yes.
You: You want us to work smarter, not harder?
Boss: Yes.
You: You want us to work harder too?
Boss: Yes.
You: Then these techniques are the way forward. We abandon our traditional methods and replace them with agile methods and do things in a more agile manner.
Boss: I don't understand.
You: You want our company to be able to do things quickly?
Boss: Yes.
You: And respond to change quickly?
Boss: Yes.
You: Then Agile is the ONLY way to go.
Boss: [zombie voice] Agile is the only way to go.
You: See. Now you understand.
Boss: I don't understand.
You: Well, I do. So, perhaps you should communicate your sensible business needs to me, and I'll translate them to the team.
Boss: [zombie voice] I talk to you and you tell the team.
You: And you must not talk to the team directly.
Boss: [zombie voice] I won't talk to the team directly.
You: [To team] I'm not in charge, but I will be acting as the glue which holds this organisation together.

So... the position of power is attained. The boss doesn't know what's going on. You've denounced the authority that you'll actually wield. If you were a genius, you'd be an evil genius and would get your own Bond-Villian style undersea base.

Now, you have to slowly and surely start to mistreat people until they hate you. While they're busy hating you, they won't have time to fight back properly.

Power is yours. MWah ha ha ha ha.

Oh, and force people to read lots of books which vaguely agree with the beliefs that you spout.

And try to confuse people with your explanations of things. If they don't understand, they can't argue back.

Reputation above substance

2006-06-13T09:36:00.000Z

A lot of what it takes to get ahead in the world comes down to how you are perceived, rather than what you can actually achieve. It is essential to make sure that you have the ear of management and that anyone who speaks ill of you is made to look like they've done a bad thing, regardless of whether you are effecting positive change on anything you touch.

Some tips:

Take criticism in a good humoured way, but act as though you're being magnanimous to the stupidity of the criticiser.
Google yourself to ensure you know what people are saying about you
Make links to other people's sites and get them to link to yours
Offer to do the spadework in any online communities that need pages or digests publishing - this will make you appear to be part of their group
Never be afraid to speak at a conference, regardless of whether you have something to say
Be publicly and openly critical of "people that don't get it" - don't mention names, but colour them as stupid
Dress smart but casual - best of both worlds
Tell stories about your successes
Treat any unexpected event as "interesting" and relate it to case studies, fictional if necessary, which show you in a good light

If you are going to have a business based on stepping on other people's toes, the most important thing is to look like you can walk on water.

Making People Feel Stupid

2006-06-12T15:59:00.000Z

The key to effecting change in an organisation and protecting your own position as the instigator of change is to keep a position of power and mystique. If you cannot do this, then you may be seen through and people may find an easy way to remove you or poo-poo your techniques. For the most part, people are frightened to look stupid. This is especially true for techies. So, here are some tips for how to ensure that your new disciples never lose sight of you as the new messiah:

Never smile - smiling tells people that you want to be liked
Never fully explain yourself
Always make a lot of references to other more-important sounding people
When faced with a direct question on your ideas force the questioner to try to work out the answer themselves - having to think of an answer forces them to accept the premise they're questioning
Keep your silence when under pressure - staying silent is powerful
Occasionally slip in derogatory adjectives - e.g. "Whichever stupid person did this"
Find a keen mug to be your principal disciple and, via a series of reward behaviours (like being actually nice to him or her, in private only), work them up to fever pitch as your missionary
Write a blog detailing things you've read
Be prepared to reel off the dogma at any/every opportunity
Try to avoid committing yourself too much to any specific solution - just hold on to the principals and your view of the problems

Soon you too should be able to wreak your own brand of devastation on any company foolish enough to believe that it needs your help.

Keeping In Business By Promising the World

2006-06-12T10:19:00.000Z

Here is a tip to any would-be Agile coaches. People love truisms. They find them impossible to disagree with. The clue is in the name. Truism. It's true. So, if you can speak in truisms, and structure your client's expectations about things which are undeniable, you're already part of the way there.

The next thing to do is to identify things that everyone wants. Here are some examples:

We want to sell more stuff
We want to make more product for less cost-per-unit
We want to avoid wastage
We want to improve our team in some way
We want to demolish the competition

All of these are the desires of any business. However, if you can, somehow, make a big deal of each of them, as though they're somehow new things that you can bring to the business, rather than just the regular immutable terms of engagement of ANY business, then, coupled with your truisms, you will look like the perfect person to spearhead the campaign of "moving forwards, banging the drum, into the future".

Now, here's the clever bit. You promise that all of this will be possible if the company makes a series of changes that move it ever closer to the ability to do all of these. You set the expectation that this will be a long and arduous process and you claim that the current modus operandi of the company clearly doesn't cut the mustard. You can easily prove this as it's a basic assumption of the fact that you got to speak to the boss of the company that he doesn't already believe that his company is doing everything it can to achieve all of this.

So, you're in. You have a patter that can't fail to please, a method which involves rattling the existing staff, and also involves blaming them for anything which fails to give tangible improvements, as you've stated it will be a stepwise series of improvements, Rome wasn't built in a day, they're clearly not doing it right yet... etc, etc. Brilliant.

As a final trick, mention stories of companies that have done well by improving themselves. This will build some false hope into the equation. Remember, once you've got the ear of the boss and you have set yourself up as the cure, not the cause of any problems, virtually nothing can stand in your way, especially if it's the existing staff that you've marked as the cause of the problems.

Good luck.

The Agile Suit

2006-06-11T20:39:00.000Z

Differences between Agile and Waterfall
Theoretically, it shouldn't make a difference which process you use, so long as you stick to it, are good at it, and get everything right along the way.

I'll summarise how both of these models look:

Waterfall - you say what you want. I work it all out in excruciating detail, cost it up. You pay. By the end I'm under a lot of pressure to deliver. I do my best to deliver and then you get something. By the end it gets a bit tricky as you might not have understood what you wanted, or I might have run out of time and will, therefore, have to work hard to attempt to meet the schedule.

Agile - you say what you want me to do in the next couple of weeks. I make something coherent which is a couple of weeks' worth of features and then show them to you. You fail to grasp that this is both complete and incomplete, but have a go at scheduling the next few weeks. We continue until you consider the work totally complete.

In fact in the best case scenario when everyone understands what's going on, both should deliver the same results in about the same time. Human nature suggests that misunderstandings creep into the equation and so the iterative approach of agile seems to discourage those misunderstandings. Equally, it seems that some of the implementers in the waterfall model might be using crystal balls to guess what they have to make, and so may make a load of incomplete stuff along the way, overengineering, and misunderstanding how it should all connect up... integrating at the end, things then don't hook up and all hell breaks loose. Agile is supposed to fix that with constant integration and iterative end-to-end development.

The arrogant assumption of Agile is that it doesn't introduce problems of its own into the process. While iterative is good and keeping things working is also good (and I will never debate the usefulness of automated tests, which should be put to good use in all methodologies), Agile has some project planning issues. In fact to call them issues would be a bit like calling the elephant man, "a little bit plain".

In the world of waterfall, when your bosses commit you to a fixed scope, fixed resource project, by the end you deliver something approximate and pray it's good enough. If you learn from your mistakes, you eventually should be able to deliver something that's practically the same as the requirements and useful in the extreme... provided you know your customer and do a good job of the engineering.

In the world of Agile when the product you deliver is, again, too simplistic, the response is to deny that the customer had any right to expect anything to solve their actual problem. Instead, they should be thankful that they've got another increment and shouldn't be fussing about the big picture. What's all that about? Never mind the cost. We just add the next most valuabl feature - it's your fault if we can't add something large enough to meet the next block requirement... and so on.

If buying a suit worked like this, people would go naked.

The Agile Suit
Day 1 - get measured. Agree to see what a paper cutout of the suit might look like.
Day 3 - see paper cutout. Discuss material. Are told that the material is a refinement. Perhaps see a paper 3D mockup of the suit?
Day 5 - see 3D mockup - it doesn't fit and is too flimsy to go on. Argue with tailor about not cutting any cloth and are told that cutting cloth would be a chunk, not a slice.
Day 7 - the tailor made a couple of pockets - stitching them neatly and attaching them to the paper mockup.
Day 9 - the tailor added a belt and a carnation.
Day 11 - the tailor shows you some samples of cloth and explains that you could have a sleeve.
Day 13 - a sleeve has been made and stiched into the paper suit
Day 47 - the suit is now made of cloth for the most part, but is too baggy. It has no lining. The pockets are working, but can only be accessed with the suit off. The tailor argues that the suit has been usable since Day 3, but not under all circumstances.
Day 59 - the tailor goes out of business, the suit is never worn.

Seeing is Believing

2006-06-11T11:08:00.000Z

But believing is much better than seeing. The aim of putting our process improvement above all else in the organisation is to create an atmosphere of total belief that everything could be solved if we had the perfect process. Any actual evidence which challenges the idea that things are improving should be written off as something outside of our control which should be ignored.

By believing that the perfect process would yield the perfect results, we can throw common sense to the four winds and focus, instead, on whatever trendy ideas we can get our hands on. We can reinforce this with some sensible truisms:

If we have the wrong process things will be bad.
We need to do good things...

... etc etc etc.

Anyone who questions this should be likened to that rude child who told everyone that the king was, in fact, naked.

The Muda of Muda

2006-06-10T19:21:00.000Z

Toyota is the template for life
Have you seen some of those Toyota utility vehicles? Almost indestructable. They must have a secret or two up their sleeve. Indeed, as a result of this, we're going to use the Toyota manufacturing system which was made in Japan as the template for any system we ever dream up to do with software. This makes sense because it does and anything which disagrees with it is a muda.

Enter my Dojo
Welcome, young Gaijin, to my dojo where I will Kawasaki your ass off with a bunch of mystifying katas.

Firstly, remember that it's cooler if you adopt Japanese words for the purpose of illustrating points about software engineering process.

Secondly, remember that they don't have to be meaningful, they're just meant to be buzzy.

Muda
Gotta love them tiger feet, right? No! Tiger feet are bad. We need proper human feet, highly training in the martial arts of making proper software. Muda is the word we use for anything that I don't like the sound of. Muda in Toyota terms means wastage, the idea that some things that we do in the name of work don't add value to the output and so should not be done.

The Muda of Muda
In reality, not every second of every day can be spent in creating profit for our employer. In reality, a reasonable employer would be perfectly reasonable in expecting their employees to do as much as possible to use their time to make money for the company. In reality, given that nobody wants to do a bad job, a reasonable employee would want to use their time most profitably.

Sometimes people make mistakes.

Sometimes it's subjective and no amount of pseudo-science can calculate whether taking a particular phone call will add value or remove value from the value-stream. At that point, you need trust. This trust should not be abused by employer or employee, though many do seem to feel that sitting in the office pissing about on eBay or reading the paper somehow counts towards their salary, and many employers feel the need to bring in trumped up business analysts to state the frickin' obvious and talk with fancy words like Muda.

So, Muda is actually Muda. The whole thing smacks of smugness.

Assuming that the whole team realises the important of keeping focused on delivering value, and gets feedback that they're delivering value, and is allowed to look into the obstacles that prevent them from improving their output... well, then you don't need words for it. It's just plain sense.

Not everyone is that smart.

Process
Some people are obsessive about process, forgetting that you can't polish a turd. If your people aren't up to the job then your process will, at best, turn them into automatons that hate you (see MacDonalds) or at worst will turn them into mutinous individuals.

It's the people who need to be motivated, not the process. They need leadership, feedback and the authority to bust any problems that are getting in their way. They need to know to look out for such problems, which should be a matter of leadership.

The Muda of Muda of Muda
I've no idea. It never really made sense in the first place.

Effecting Change

2006-06-10T19:10:00.000Z

Things seem to be working well
That's easy for you to say, but you're stuck in a microcosm, doing your things your way. How do you know that you're not a local optimum? You might be simply burdening everyone else with your inadequacy. You must change.

How should we know what to do?
There's a method that goes like this:

I tell you that what you are doing is wrong.
You are frightened to confront the problem and so run away.
You are caught out by me and made, like a biblical prophet, to undergo a voyage of discovery, mainly involving sitting in the putrid innards of a huge sea creature.
Now frightened to have an opinion of your own, lest more punishment occurs, you agree to do what you're told.
You leave the whale and preach the new edicts as you were told to.
The people of Nineveh agree to your demands, equally fearful of punishment, regardless of whether living "in sin" wasn't just subjective.
Everything changes.

Unsuprisingly, this is called the Jonah method of teaching. It's very effective.

What if I can't change?
Well, if your organisation is changing and you can't change then perhaps you should get out. Change your organisation, as it were.

If the kitchen is too hot, then get out of it. Don't become a muda.

What if change is wrong?
Don't be stupid. Change is never wrong. What a foolish question to ask. But, to placate yourself for a bit, why not give change a try in the false belief that if it doesn't work, or doesn't offer any significant improvement over the way things used to be, you would be able to reverse it.

The more things are changing, the less you need to worry about whether they're right. They will never settle long enough for people to notice and you can always attribute anything that's not working to the process of change. Brilliant!

Welcome to Burberry and Broccoli

2006-06-10T19:01:00.000Z

Welcome to this blog where I will explain how to do things right and how to make better software with a better process that will make you better than your competition.

Techniques we'll discuss will be Agile, Theory of Constraints, Toyota Production System, Extreme Programming, Test Driven Development and anything else which seems popular.

Feel free to comment on any of this stuff. The more the merrier.