agile_manifesto

More Agile Crap

As if things weren’t bad enough, the guys have now pinned up an A2 print-out of the Agile Manifesto at the scrum board. The most prominent features of the poster, naturally, are the bold-type names of the assholes who created this stone-age mentality. It looks like one of agile’s precious post-it notes writ large. What is it about agile?



One presumes the Team (always a capital T in agile) did not design this poster themselves and there will be no prizes handed out for those who can guess the name or names of those who did produce, provide, and profit-from the poster. It’s an advertisement. Many people find it objectionable to be exposed to advertising while at work, so what gives agile salesmen the right to plaster their names over what little remains of our wall-space? Do they want to take over the entire wall? Will they start on the windows soon? In fact, they did already. One of the internal meeting rooms has has two glass walls to let light in, one of which is obscured by a scrum board.

If they are such computer geniuses, why can’t they use their PC to organize their daily tasks like the rest of us do? Do they really need to keep tomato-shaped egg timers on their desk to tell them when it’s time to get up and stretch their legs, or is the timer there simply to remind them of their own self-importance? I’ve yet to see story-points allocated to toilet breaks, but the day is coming mark my words. They’ll discuss it in the grooming sessions, play cards, and eventually get around to agreeing what we all know; that the number of story points allocated to toilet breaks is: One or Two. Speaking of number twos though, I don’t think agile teams really give a shit about anybody else in the organization. They invariably tend to consider themselves the warm little center around which everything else must revolve.

I have to attend two daily stand-ups in this job, both of which take place via video conference – demonstrating clearly that even though they worship agile here, they know fuck all about it. It’s also worth mentioning that they use agile on a project that has a four-year development time and one delivery at the end. Presumably, one of the ways to use agile methods is to not use them – and that makes you agile! I’m not going to look it up, but I’d bet a buck that that argument has already been seriously put forth. Many times most likely.

Once today’s stand-up was underway I was asked why I was not standing on camera, so I briefly stepped into view, angrily waved a pointed finger at the poster behind me, and said that if I was caught on camera with that in the background people might think I am endorsing it. I demanded it be torn down, but I acknowledged in the demand that it is unlikely to happen.

“The main purpose of the daily scrum is for the Team to fight over who does which task, and for the Team to receive edicts passed on from management through it’s subservient brown-nosing scrum-mastering mouthpiece.”

Fortunately, I am only an observer on the scrum meetings and my presence in the company is temporary. I do not have to directly participate in the agile nonsense, but I witness depressingly excessive amounts of it. I also go, for example, to the over-crowded planning meetings, and I always wonder who the hell else in the world has ever thought it a good idea to involve everybody in the planning? The plans produced by such misguided spoiled-broth methods are, understandably, worthless.

You would get the same results as agile by throwing darts into a Gantt chart while wearing a blindfold, or by doing no planning at all. Incredibly, this agile team allocates the same amount of time for bug-fixing as they do for development. Seriously. “That will take 12 weeks FTE, so we set-aside another 12 weeks to fix all the mistakes we made”. But, you could scrap it and rewrite the whole thing if you allocate the same amount of time. That defeats the entire purpose of bug fixing. Agile users are not business people. That is clear as daylight.

Since learning this I’ve now added a question that I ask in contract interviews I ask the interviewer, “when planning your software development how much time is allocated for bug-fixing, if for example, it was 12 weeks effort to code, how much time is allocated to fix?” Industry average seems to be an extra 25-33%. A team that thinks it requires as much time to fix its output as it does to produce it, isn’t worth much in my opinion. On the other hand, a team who can stiff their employers by convincing them to finance such brazenly extravagant loafing must have some shit-hot negotiators on-board.

They’d do better in sales.

If nothing else, agile gets me thinking. Thinking about taking another job in another career mainly, but I also have empathy for the developers who are caught up in this. I am at mid-career and have enjoyed some degree of success as a computer scientist and industry critic. I live in a reasonably nice neighbourhood, drive a reasonably nice car, and have reasonably under control debt. What passes for the “good life” in these pitifully shallow times.

But these younger developers aren’t even going to get that. Software development now is just another corporate office job. Maybe one in ten will be able to rise up the chain and make the potentially lucrative move into corporate management, but unless you’re working for a company where there are ten managers for every employee, only a few developers will ever get promoted. The rest will remain developers.

The question the young agile developer really needs to be asking him or herself is, why are there no older developers in the Team? There is a reason for it. In most industries you can look at two equally skilled workers side by side and find a case where one is twice as productive as the other. In software development you frequently find developers who are ten times more productive than their peers. What agile attempts to do is bring this under control, allowing corporate budgets to be better managed, by leveling out the productivity across the team.

What the proponents of the scheme failed to take account of is that while it is nearly always possible to raise the productivity of a slow worker up to an average level, the productive worker who is asked to work at a slow rate very quickly becomes demotivated. I guess by now the agile gods are aware of this and have rationalized it as “cost control”. They never were businessmen. They are mostly developers who made the great-leap into consultancy. They used to write rubbish software, now they talk it.


Agile methods preclude the possibility of becoming a senior developer.

By senior here, one refers not to the meaningless job-titles they let you write on your email signatures, but senior in the sense of “highly experienced, respected, and well paid”. How many of those are on your agile team? Anyone over 30 who isn’t regarded as the “old man”? Look around you. The test team, the requirements engineers, and the support guys are staffed by men and women, boys and girls, from intern to retiree. You can spend your whole career in those roles and be reasonably certain of a comfortable retirement. But if there is no place for experienced developers in “Agile”, then what exactly do you think your future holds? My advice to you, is live for today.

One can comprehend the business case for having predictable development costs. Historically software development has had the most unpredictable costs so anything that can bring it into some kind of order makes good business sense. That there will be a cost to be paid in terms of quality goes without saying, but then again, the makers of quality goods don’t have anything to learn from agile. Another mistaken assumption of the agilists is that you could look at how the very best guys do the job, and copy them. Simple! Now go bend it like Beckham.

The main reason why junior developers fall for the agile disease is, I think, not because they are inexperienced. I think it goes deeper than that. They have grown up in a world in which they only ever got information from a screen, books, or some kind of authority figure. So when some flash prick in an expensive suit comes along and tells them about the “notice board concept – from Japan” they are well impressed. It’s new to them. Pinning notices on a board and placing the board where everybody can see it. What a clever idea!

Post Script

It seems the agile leadership have been snorting a lot of cocaine recently. How else can one explain the appearance of Kanban-style hand-drawn sprint-based “happiness indexes” popping up on office walls all around the world? I was sitting next to a developer shortly after one of these appeared, we were waiting for the scrum-master to get the video conference set-up so that we could “groom the backlog”. I happened to mention that I’ve got sixty litres of beer and a case of champagne stockpiled in my basement and that I’m cooking a seven-course dinner at the weekend. I mentioned it in the expectation that he would interpret it as an invitation to dine – which it was – and he told me I should “try to think positive”. What use is a happiness index going to be to him?

Related
The Agile Fad
Toss The Salad – The Pomodoro Technique Debunked