Culting

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

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

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

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

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

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

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

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

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

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:

• Promising the world
• Speaking in truisms
• Bullying
• Sugaring the pill

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

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?

No.

The Intangible Mist Management Mystery

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

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

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!

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

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

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

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

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

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

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

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

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:

1. 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
2. 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
3. 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

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)

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

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

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

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:

1. 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.
2. 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.
3. 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

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

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?

Short Answer
Two. Of course.

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

Full Procedure

1. Try to develop a test for darkness
2. 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
3. Board up the windows - they're not absolutely necessary anyway
4. 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
5. 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
6. Reinstall the broken bulb with this new adapter
7. Ensure that the darkness test still holds
8. Use a torch to see whether the darkness test works with light at all
9. Go home for the night
10. 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
11. 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

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

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

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.