Long stories are boring; that's why people like things like "executive summaries". Fortunately, this is the Web, so I can just write the most important ideas, and if you want the details, you can expand them by clicking on my "read more" markers which look like this and contain some further information on the subject; it's possible to have more than one level of such mark-up (this is what I'm talking about). Once expanded, the text can be collapsed back by clicking on the links at the beginning or end, like this one: This kind of mark-up is experimental and was invented by me, as far as I know.
If you have a lot of time or if you can't be bothered to click, you can expand/collapse all the hidden texts inside using the links below:
My name is Alex Deva. I've been a computer programmer for most of my life. I'm 30 years old and I live and work in Romania. I'm currently running an outsourcing company, Indigenious Development. My website is here, my CV is here. I've been involved in agile development projects for long enough to be able to determine that, on anything but short term, this paradigm is impractical, counterproductive and frustrating.
Agile development is a concept which promotes making software projects by means of continuously iterating over the work in progress with the client. Thus, the client may change the requirements during project development; developers and clients meet very often and for long talks. A detailed reference and list of links about agile software development can be found here on Wikipedia.
Before the concept of agile development was created, people used to do things "the old-fashioned way". In my practical experience, large companies and corporations still prefer that; for once, I believe that corporation inertia is a good thing. They have internal processes which are difficult to change quickly on a large scale, and in this particular case, I doubt that they ever will. That means that there were processes in place which insured that software development followed a number of well-defined steps and it is generally difficult to interfere with that process. For example, a typical process would contain the following general phases: assessment, functional specifications, development, testing, hand-over.
There are many reasons why agile development is a bad idea. Here are a few that stand out from my experience in outsourcing.
The strong points of agile development don't turn out, in practice, to be that strong. That there is less paperwork involved, while true, is more of a burden than an advantage sometimes, since there's nothing to turn to in case of a disagreement. I am in the habit of recording every Skype call I have with our clients; every so often I burn a CD with the recordings. Then I also make a minute of our conversation, in text form. But searching through an archive of recorded voice/video calls is a pure nightmare. "I never said anything like that" happens more and more.
Stress and unproductivity
If your client is the sort that really wants to keep in touch, that means in average about 5 hours of conversations a week. If your project lasts for 2 months, that amounts to at least 40 hours spent on Skype -- or about one working week. If you had spent a working week with the client, working out some decent functional specifications, you would've been able to work in peace and in your own rythm -- but agile development doesn't allow for such commodities.
Having to give a daily account of what you do also turns out, on the medium/long term, to be extremely stressful. About one hour before the call is scheduled, you already feel rushed. You know that you really need to wrap things up, and sometimes that makes you cut some corners -- and that's when trouble starts. You lose about an hour a day indulging your client, and another hour being unproductive because you know you have to sell your day's work. And, let's face it: good programmers make for poor salesmen.
The first meet-up. That is when your client wants to know roughly about how much time you need for this project. Then he multiplies it by your hourly rate and usually gets scared and leaves (in which case your life expectancy increases). Else, the client will begin to argue that you're a thief, that someone else offered to do twice as that for half the money, etc.
Assuming that doesn't happen -- and to be honest, it doesn't happen all that often --, then you start the classic war: what the client wants, versus what can actually be done within his deadlines. So far so good, this is normal; ah, but because this is agile development, you're not allowed to get very far. Therefore, you will never know all the intricacies and possible problems of the project, because you don't have a full set of specs. Therefore, you can't give your client a serious time frame for development; you have to leave yourself tons and tons of leeway. Therefore, you can't make your own near-future schedule; you don't know what your work load will be 2 weeks from now; you can never commit to anything else, because you never know. This means that you have to pump up your fees, since you can't know when exactly you'll have to start looking for a new project, and there's a good chance you'll be flat broke for a given interval.
As the project draws close to the grand finale, the client sometimes begins to realize that this isn't what he had in mind at the beginning. What happens then varies from situation to situation, but it's almost always bad. You can be told to redo large chunks of the project (possibly everything), you can be told that you won't get paid because "that's not what you agreed to make me", or you can get bad credits. In the best case, you'll get the sense of dissatisfaction from your client and you won't be very happy about what you created.
In the classic approach, this is very improbable, since you have the frozen specs to bear witness. In the classic approach, it is impossible for both you and the client to be anything but happy, if your project passes the final acceptance tests. But in agile development, this kind of semi-failure is more than a possiblity.
You get to work with a client who knows nothing of programming. This could have advantages, like the fact that you can impress him or her with some AJAX flashing lights into paying more but, with agile development, bad things happen.
Daily progress. You have to show your client almost every day that you're making progress. If your client doesn't know code from chickenscratch, then you'll have to show functionality. The problem is that it's practically impossible to maintain the same rythm while implementing functionalities; what you do today will seem more important than what you've done yesterday ("aha, so you didn't work yesterday as hard as you said?"), or your progress could be substantial, but the obvious part resemble the tip of the iceberg ("you took an entire day for THIS?!").
In practice, it is sometimes the case that you have to code and code and code before anything is visible on the surface. For example, when you create a framework or a platform for a specific product, or range of products; then you have to code one or more layers of backend before you get to do something which actually and visibly does something. What happens then is that each day you have to face your client and try to patiently explain that you are doing something. This takes time for both of you -- time which would be better invested in development work. It has also a way to become very frustrating for both client ("this guy's ripping me off") and developer ("this guy's an idiot").
With the classic approach, progress reports are different. First, they only happen when there's something important to show -- so you're not stressed out that much. Second, they're not normally associated with change requests (see below). In agile development however, progress reporting is time-consuming and frustrating.
Daily change requests. It's impossible for your client to visualize his needed product perfectly. Moreover, it's impossible for a technically challenged client to have a correct perspective of all the things which he could actually have in the product. Therefore, everytime you show the client your progress, you're like to get one of three reactions:
1. "Wow, this looks great! I didn't know we could have this. Let's change everything you've done in the past 3 weeks to work like this." Of course, if you're being paid by the hour, this works to your financial advantage; but if you care about your work, this is the kind of answer that might just get you a stroke. This can sometimes be replaced by:
2. "Wow, you can do this?! And NOW you tell me?! You've been trying to keep it easy for yourself these past 3 weeks, haven't you?" sometimes followed by: "I want you to redo everything using this new thing you've shown me today, but I won't be paying you because you were obviously trying to rip me off." (yes, this did happen to me). Depending on your character, this could be better or worse than:
3. "What the hell's with this? I didn't tell you to do it like that. Do it again like you did the rest so far. And I'm not paying for this!"
Very seldom you'll get number 4: "OK, this is good, let's move on".
With the classic approach, change requests like this are impossible, since the specifications are frozen. They can indeed appear in a later phase of the project, but then will take the form of another specs document also to be frozen. In agile development, you never know what the client will have you do tomorrow.
You get to work for a client who is also a programmer. Typically this happens in the following scenario: your client is not the end client, but only a subcontractor. The actual client is paying X hundred dollars to the subcontractor to get the project done; then the subcontractor outsources it to you for about a fifth or so of the money. In the meantime, your client acts like you're his property for an hour a day, and for that cashes in four times the money you're making. Welcome to the wonderful world of overseas outsourcing! This arrangement could have advantages, like the fact that you talk the same language and won't have such a hard time trying to get your point along but, with agile development, bad things happen.
Client knows everything. Your client thinks he knows exactly what he wants. He knows exactly how you should work. He knows exactly what the result should look like, and he knows exactly what you have to do each day. But does he?
You may have built 1000 houses, and still... ok, let me rephrase this. The more houses you build, the better you learn that each one is different. Terrain, orientation, type of ground, localization etc. -- all make for a different project every single time. Same methodology, same technique -- yes, but applied differently. The point is: there are many issues that you don't actually realize exist until you bump into them. Sitting on the edge and giving instructions will give you the impression that you're in control, but you're really not. Trying to tell your workers what they have to do may help them, but it's always the guy who actually picks the shovel that knows how deep to dig and when to stop.
The same applies to programming. Just because your client knows, conceptually, if a method goes in the model, view or controller -- or roughly how that method should be written, it doesn't mean much. You're the guy who actually has to write it, to keep track of all the side-effects, to deal with variable scopes, to see when and how to call that method, and so on. These aren't things your client can know in advance -- or if he can, it'll be cheaper for him to just dictate the code directly to a secretary.
So what happens then is situations like this: "Why did you use this API here? Why did you call this like that? Where did you get this parameter here?" And you have to waste time explaining your decisions, optimizations and algorythms like in school. You're hopelessly losing the focus on the functionality of the project and uselessly moving it to the code itself. Of course, it could be argued that the client has the right to make sure of the code quality, and that is correct; but in practice, the client will never stop at "I want you to redo this loop in a cheaper way", instead rambling on about solutions to issues he isn't even aware of.
In the classic approach, the client is free to have a section in the specs detailing, technically, which way the cogs should turn. Then you can read it, take note and adapt your coding style accordingly. In agile development, it may make you give up the money and the project in frustration.
Client has only limited knowledge. I won't stop much here because this is obvious for anyone. There's nothing more dangerous than someone who thinks that he's good at something, but really isn't. In a classic development approach, this wouldn't influence you much, but in agile development, it may be enough to make you want to shoot someone -- possibly yourself.
Client wants to run the show. If your client has a sizeable ego, he'll not only tell you what to do; he'll become an active part in the development. Of course, he won't be doing any particularly useful stuff himself; instead, your client will get your code and "clean it up" according to his own coding style. He'll move this method into that library, delete that comment over there, add another one over here (probably saying: "TODO: improve this"), rename a few files, classes, methods or variables, change the naming conventions, and God knows what else. You'll look at your code the next morning and you won't recognize a thing.
With the classical approach, this just isn't possible. But with agile development, you will waste time trying to find everything again, and if you complain about this, you'll get either the "I'm paying, I can do what I want with the code" or "I am helping you, you should thank me!". On the long term, this is enough to frustrate you beyond limits and take any pleasure off your job.
In theory, agile development is God's gift for the client/outsourcer relationship. Practice however -- at least given my experience in overseas outsourcing -- demonstrates that the human factor is a great influence in the process. When your client is your friend and you meet every now and then in a cafe (say, once every 2-3 weeks) and you show him what progress you've made, that's just great. But when your client is someone who's probably chosen you because you have good and cheap technical skills, there's no trust established, there's no face-to-face contact, and the reciprocal assumptions aren't always kind and fair -- practice teaches me that the recommended processes are bent into something almost impossible to adopt on the medium/long term.