Agile development is mostly just hype (IMO)

Although there’s value in many of the techniques it employs.

For anybody not familiar with the topic: the root of all evil regarding agile development.

As a software developer, what I usually have to fight for is getting customers to pay for what they want (well, my boss does most of the fighting, but my support role is of such nature that I get to observe most of what happens in the process). With very few exceptions, customers prefer to be told the world can be programmed in two weeks and get a shabby and useless application when delivery is nigh, rather than be told it will take somewhat longer, and get a proper application upon delivery. And they never learn. You judge which is the more honest approach. IMO, agile development doesn’t support what I think is right (i.e. telling the customer right from the beginning what to expect). I’ll try to explain why I think this.

What the agile manifesto says:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

While I have no problem with the first statement,  I cannot wholeheartedly agree to statements 2 and 3. And I cannot accept that the only way to act according to statement 4 is by using agile methods.

Working software has a problem: unless there’s a reference to compare it against, the customer (well, most of them, at least) constantly changes his mind. Which is OK as long as you work with an unlimited budget and with no fixed deadline. Which is utopic in most cases in real life.

The same obstacle stands in the way of customer collaboration over contract negotiation. Of course you  can start collaborating with the customer, but if you’re an entity working for money, not for charity, somebody needs to pay for this collaboration. Due to a very broadly spread misconception, the customer usually is only willing to pay for the product, and often considers all the communication overhead you need to invest in getting a product right just some minor overhead you have to pay for yourself. Which is stupid: he wouldn’t treat a lawyer or an architect this way, he wouldn’t treat his own engineers this way, but it’s OK to handles software engineers this way. In my experience, customer collaboration works smoothly only after a negotiated process is set in stone by a contract. Just to make sure you get it: not the requirements for the software to be developed, just the processes to govern the collaboration.

Responding to change and incorporate change into the plan is what civil engineers (or airplane manufacturers, or ship builders, for that matter) do already for a long time. Their projects are even worse off than software projects. They last inherently longer, are usually a lot bigger from the point of view of invested resources, and as such on one hand changes are more likely to happen and on the other hand more likely to be a lot more expensive. Yet, they don’t rely on anything even remotely resembling agile methods in their processes. I surely wouldn’t want to fly in an airplane where some structural engineer patched the design and „implementation” just a day before the airplane got shipped, rather than going through an expensive and slow redesign process, followed by a thoroughly checked manufacturing and testing process. Surely I must be an exception – it is often the same civil engineers that are OK with a software built from patches all the way from requirements gathering to deployment, which crashes on them all the time (well, it’s more often their bosses, engineers tend to have a preference and a better understanding for the need of a more organized approach to developing something than management usually has).

Further, there are quite a few principles of agile development I also don’t agree with – I’ll pick only the ones I don’t like. (After all, there must be something good in agile methods if so many bright people buy into it, it just seems I don’t grok it, so at least some of the principles must be right.)

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

Chances are, you just manage to bore him to death, if increments are delivered too often and without much visible progress. Or you get a rude reaction: nothing works, nothing of what we discussed is there (in spite of agreeing with the customer about the stories to be implemented before each iteration). I have seen both situations. Rather, I’d agree on some essential milestones right from the start, with clearly verifiable goals to attain at each milestone. It’s the way customers are used to do projects in other areas, it will be the most familiar way for them to work with you in a software development project.

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

It all depends. If the customer is willing to pay for it, sure. Otherwise it simply doesn’t work, no matter how nice it sounds. And of course, no matter when changes get into the project, you need a proper way to assess cost overhead. Or you’ll be bankrupt soon (either you ask too much, so customers will stop doing business with you, or you ask too little to cover your costs, if you don’t have a proper cost assessment method – I have seen very few customers willing to pay on a time and material basis).

Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.

Sure. As long as you can afford this. In real life, however, you more often than not get management, labor market, company regulations, non-functional, non-negotiable customer requirements acting in the opposite direction.

The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.

And also the  most likely way to ensure that two days after a discussion each part remembers a different conclusion. Which is important when the two parts sit on different sides of the table. Written communication, i.e. documentation, doesn’t have this problem. Not writing anything down in a maintainable way is the most successful method of quickly aggravating the customer, in my experience. However, agile developers argue against documentation, towards code without documentation. Do you know of any other engineering process working without documentation? I don’t.

Working software is the primary measure of progress.

Bullshit. It’s software that does what it needs to do is, software that just works isn’t. In fact, building a perfectly working system that does what the customer asked for but doesn’t do what the customer needs is one of the glorious ways in which quite many software projects fail. Close to zero bugs, only you got the requirements wrong. Tough luck. Of course, the next iteration will fix it. If there’s any budget left, that is.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Why would it be needed to keep up the pace indefinitely?  Software development is clearly an activity organized by projects – every customer expects you to eventually finish working on his app, and also expects you to make a prediction about that finish before you actually start working, or he won’t give you money. You just have to plan to keep the pace up until the project finishes. Event this is not needed, because work on a project is almost never paralelizable in such a way that the workload is constant from start to finish. But how can you name a deadline if you can’t even say how many iterations you’ll need, because you shun documentation and as such don’t have a scope definition to share with the customer?

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

Again, bullshit. I have seen this work in several organizations. They were maximizing the work not done at the expense of testing (did you notice the principles say nothing about testing, although techniques employed by agile development emphasize unit testing as one of the most valuable agile tools?), or by simply not getting parts they deemed unimportant done. Because they knew very well how the end-users used to use applications, this was not regarded as a problem by regular users, since the bugs or missing parts were getting discovered at a very slow pace, allowing them to fix them in due time, without aggravating the end users. But this approach still costs. Only the programmers managed to hide the cost of their sloppy work. This is no real economy. I’d rather stick to what Einstein said: things should be made as simple as possible, but not simpler than that.

The best architectures, requirements, and designs emerge from self-organizing teams.

If only bad software could tell stories! Think spaghetti code – it’s often done by self-organizing teams with a more than lean attitude towards codee quality. A nice architecture emerges from a programmer or a group of programmers who are able to do architecture properly. These guys are usually smart enough that management or whoever from outside has no chance to interfere with their architecture. The rest of the team doesn’t matter for architecture. It matters just for transforming this architecture into source code. If the rest of the team is so much less bright than the architects are, they will have difficulties understanding the design, and implement anything but the original design. Yielding a bad product, usually. One of the most important (IMO) aspects required for agile development is a homogenous and above average skilled team, which is seldomly the case in real life.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts  its behavior accordingly.

I don’t dislike this one, actually.  I just don’t like that agile developers make it _their_ principle. Also, I think it should rather be a permenent process, instead of something you only do at regular intervals.

My conclusion is that agile development was set up by highly successful IT consultants who owe their success to good marketing more than to skills useful to their customers. Sun Tzu said it quite some time ago: a good general is likely to go unnoticed, since it is highly unspectacular how he wins his battles – a good general usually only fights battles he has already won. A bad general, on the other hand, will take part in many spectacular and risky battles, and have only costly successes to show. The same with software: anybody is more likely to remember a project which got through ten successive iterations before it was barely usable, and call it a great and spectacular success, and not remember a project similar in all aspects, only that got it right right from the first delivery. Even worse: for the project getting it right right away, they’ll remember that it took a looooong time to develop, as opposed to the other one, which took three or five times longer to complete, but provided ten or twenty (unusable or incomplete) deliveries during that much longer period.

(Now ain’t I good at throwing stones?)



Lasă un răspuns

Completează mai jos detaliile tale sau dă clic pe un icon pentru a te autentifica:


Comentezi folosind contul tău Dezautentificare / Schimbă )

Poză Twitter

Comentezi folosind contul tău Twitter. Dezautentificare / Schimbă )

Fotografie Facebook

Comentezi folosind contul tău Facebook. Dezautentificare / Schimbă )

Fotografie Google+

Comentezi folosind contul tău Google+. Dezautentificare / Schimbă )

Conectare la %s

%d blogeri au apreciat asta: