Why I'm Currently Not Liking The Agile Method

This is a rant I felt I needed to have after coming out of an Agile Systems class.

When Agile methods and Scrum was first explained to me in this module I was told it was a fast paced way of working the delivering what the customer wants at the heart of its philosophy. Unfortunately though, after watching the lecture I just have (Agile Methods and Scrum) I’ve noticed that the uplifting manifesto is actually littered with small print and contradictions all over the place.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This is unhelpfully ambiguous. But, not to simply pick on semantics, I’ll discuss both interpretations and explain why I think they’re both ridiculous.

The first way to read it is to release the software early, or rather to release it before it’s finished. This sounds odd, and so I quickly decided that’s not what that sentence meant. However, looking at the general ethos of releasing features incrementally this actually looks like a reasonable thing for the makers of Scrum to have decided.

What are you expecting the customer to do with unfinished software? They can’t phase it into their business, or worse directly switch to it, just to find they can no longer merge records where they want to or something. They can’t even run this software in parallel with their current software if there’s gaping holes in it.

Even here though, at your first step, Scrum has contradicted itself in that another of its principles is not to release work until it’s been tested. That must mean finished. That makes this interpretation either wrong or contradictory.

For that reason the second is more likely; finished early in respect to the deadline you estimated. I’d argue that this is bad too. The few times I have handed over a completed project before my deadline (simple because I’m new to this freelance lark, and so bad at estimating how long it could take me) only once was the customer actually happy with that. On one occasion a customer was incredibly unhappy that I’d completed early, and so messed up his project plan timetable. (I thought he was incredibly out-of-order though, and probably unusual.) Another time a customer remarked that it was just unprofessional to have over estimated how long it would take me. Every other time the customer didn’t notice and probably didn’t recognise it as either an achievement nor disbenefit.

I’ve realised that customers are happy to get the work when you said you would give it them — after all you were both set on that deadline. Anything less is apparently unprofessional.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The fine print here is that the customer can only talk to you once every thirty days. This makes no sense. What else is the project manager (uhh, sorry, Scrum Master) doing with their time? They’re not coding, so they should be talking with the customers whenever the customer wants to talk to them. After any of those discussions take place, and the manger has decided on any extension of deadline or cost because of the changes, the programmers should be made aware immediately.

It’s the project managers job to decide what features need to be worked on now, and which can wait till later. His backlog should be incredibly flexible to any concerns the customer has to make.

Not only would that benefit the customer, but the programmers don’t have to wait 30 days before realising that that function they’re working on which is ridiculously complex actually isn’t even needed anymore. For a system that promotes its agility in an industry that works at lightning pace, a thirty-day buffer it insulting.

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This is completely ignorant to how people work. You should work like a machine, with a constant typing pace of 60 words a minute. There are times where you run into problems that the solution to is incredibly elusive. Problems you’re not even expecting. A customer of mine needed to have an interactive map, with pointers to variable places (according to where the user enters). That seemed pretty easy since I know of the Google API. Oddly though, there’s no “zoom to a view in such a way that I can see all the markers” method in the API, so I  had to spend probably an hour looking for one, before resigning and writing it myself. That was essentially a large chunk of paid time in which I was doing virtually nothing.

Sometimes people are unmotivated and need a few hours, or even a day, to get back into the swing of things.

This fairly communist view of developers is somewhat contradictory to the rest of Scrum though, which makes developers sound fairly demanding and lazy.

Simplicity — the art of maximizing the amount of work not done — is essential.

Simplicity and being lazy certainly aren’t interchangeable words. Procedural programming is maximising the amount of work not done (read: lazy), but it certainly isn’t the most simple or elegant. This just screams absurdly lazy.

The laziness of agile programmers is also shown in their language of choice. From the short time I’ve spent with it so far, Ruby is the most vile language I’ve yet come across. No brackets around arguments, no curly bracket encapsulation around methods and classes, (seriously, are you guys boycotting the shift key?). I natively write PHP, and even I’m annoyed with duck typing. Just throwing in white space wherever you want, with no real standards described for it.

Whilst embracing team work, you seem to be hell-bent on the idea of being completely left alone, despite one of the agile ideas being that you should work with the “business people”. The term “business people” is used almost as a derogatory term. None of them must be allowed to speak to any of the developers but through the ambassador Master, else we’ll become horribly infected with their illogical ways.

Slide 28 talks about accept no help at all unless it’s asked for. No developer will unbiasedly judge his own work, and his team mates probably won’t critique them either. An external person must be in the ring to offer that service. Refusing help is just rude, and incredibly unhelpful.

Whilst I do have other points, this is becoming somewhat depressing, so I’ll go and get on with something more uplifting.