Technical Debit

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

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

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

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

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

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

Problem Absolving Position

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

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

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

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

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

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

Agilistaist Glossary

A

Abolishing testers

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

Agilista

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

Anger

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

Antagonist, The

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

B

Believer, The

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

Believing

the central tenet of agile. See Seeing is believing.

Blameless culture

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

Blitz spirit

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

Boolean

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

Bottlenecking

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

C

Carpet Sweeper

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

Chicken

See pig

Claiming success

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

Confusion

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

D

Defender, The

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

Distortion

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

Documentation

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

Dogma

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

Dojo

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

Dou Da

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

E

The Emperor's New Clothes

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

Extrapolation

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

Extreme Programming

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

F

Fervour

When dogma meets belief.

First line of irritation

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

G

Gaijin

foreigner or other.

Gaming

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

H

Haiku

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

Hexaflexagonal architecture

An apparently impossible approach to testing. See Concave Hexaflexagonal Archictecture

I

Illusory progress

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

Iterative development

adding features in small almost imperceptible increments. See Reiterative Development

In-fighting

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

Intangible Mist

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

J

Jonah method

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

K

Kasa

An umbrella. See also Poppins, Mary

Kata

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

L

Local optimum

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

M

Muda

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

Mug, The

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

Mythical Man Month

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

Mythical Man Moth

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

N

Necessary Bullshit

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

Non-leader

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

O

Ostrich, The

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

P

Passive Aggressive

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

Pig

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

Placebo Effect

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

Pope, The

spiritual leader of the Agile cult. See Team Membership

Poppins, Mary

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

Possessiveness

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

Problem Absolving Position

Get yourself a company scapegoat. See Problem Absolving Position

Process

the most important thing in the world.

Production Simulation

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

Protagonist

instigator of trouble/Agile. See Team Membership

Pseudo-ML

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

Q

Quality is in the toilet and flushing

swirling away from you, but leaving the shit behind

R

Radiator (Information)

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

Refactoring reality

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

Reiterative development

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

Reporting (optimistic)

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

Resistor

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

Ringfencing

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

S

Salmon method

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

Scapegoat

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

Shoehorning

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

Simple Majority

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

Standards

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

Start the ball rolling

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

Suit (The Agile)

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

Sugaring the pill

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

Sweetistics

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

T

Theory of constraints

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

Truism

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

Toyota

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

U

V

W

Waterfall

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

White Book (the)

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

World (the)

what you must promise. See Promising The World.

X

Y

Yakisobi

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

Z

Working at Concurrent Levels of Abstraction

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

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

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

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

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

Getting A Foot In The Door

A reader asks the following question:

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

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

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

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

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

Any More Questions

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

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

Is AGILE Dogmatic Enough

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

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

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

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

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

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

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

Telling People What They Don't Want To Hear

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

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.