I have seen a lot of posts recently saying that one of the major reasons why Agile is used is because clients often change the requirements.

However, let's say the clients do not change the requirements often. In fact, the clients have firm requirements though might be a bit vague (but nothing unreasonably vague), but I use Agile anyway.

The reason why I employ Agile is because the software is complex enough that there are details, problems that I wouldn't recognize until I actually face them. I could do a full scale heavy planning approach like waterfall, but then it would take a few months to finalize all the high level design and low level coding signatures. There is a very specific, fixed architectural design for the system though.

My question is: Would this be considered as bad, cowboy coding, anti-pattern, etc..? Must we employ waterfall and plan as much as possible in great details before we start coding when requirements are stable instead of this 'let's do it' mentality in Agile?

EDIT: The major point here is that: we CANNOT blame the clients for changing requirements. Assume the clients pointed us to a very concrete problem, give us a wish list in very reasonable details and leave us alone (ie the clients have their own productive things to do, don't bug them any more. Only demo to them near the end when you have a minimum working prototype). Would it be wrong to use Agile in this scenario?

  • 2
    @randomA: actually, IMHO you should never try pure waterfall only if you want to create a working product which need more than a week's effort.
    – Doc Brown
    Commented Jul 16, 2014 at 6:54
  • 10
    Please give me your clients Commented Jul 16, 2014 at 12:15
  • 7
    I will give 2x more for your clients than @razethestray
    – Euphoric
    Commented Jul 16, 2014 at 13:43
  • 2
    If your client does not want to "be bothered daily", learn how to do effective communication with him. For example, instead of making (probably wrong) assumptions about unclear points, collect questions in a list and send your client the list in regular intervals. Even better: arrange a meeting for discussing the points. If the requirements are so clear that the list stays empty: no meeting (but I guess it won't). If you start implementing wrong assumptions into your software, you will have a hell lot of more effort to change that later.
    – Doc Brown
    Commented Jul 16, 2014 at 16:39
  • 3
    @randomA: you can keep you client happy for some time by not asking anything, and then, when you deliver the final thing, make him very unhappy since it turns out you missed the requirements so much that you can throw your program away and start from the beginning (which the client will not be willing to pay). Or you make him a little but unhappy fro some time by asking him enough in between to build the correct program, but very happy at the end when the program will actually do what he wants and he gets what he has paid for. Pick your choice.
    – Doc Brown
    Commented Jul 16, 2014 at 18:39

4 Answers 4


Would this be considered as bad, cowboy coding, anti-pattern.

Short answer: no. Doing "agile" correctly does not mean "no planning", it does mean not to overanalyse things.

one of the major reasons why Agile is used is because clients often change the requirements.

That's an oversimplifying statement. "Changing requirements" is also about how the team's understanding of the requirements change. And it is about how the customer's priorities about the requirement change when he actually sees a few releases of the software.

In fact, "agile" works IMHO best exactly in the situation you describe - the client has a good knowledge about his overall requirements, you can write a general plan from it, fill your backlog with lots of "user stories", and have already enough information to choose the right system architecture. The short iterations of an agile development strategy then will help to make the "vague requirements" more precise, with lots of feedback if you are still going into the right direction. It will also give you early feedback about the real effort and costs (which is something you can still fail in a waterfall approach, even if you know every single bit of requirement in detail).

  • 3
    Doing "waterfall" correctly does not mean "plan everything", it does mean not to underanalyse things.
    – Giorgio
    Commented Jul 16, 2014 at 17:12
  • 1
    @Giorgio: doing "waterfall" correctly means not to apply it when requirements are "a bit vague" and "the software is complex enough that there are details, problems that I wouldn't recognize until I actually face them" (cite from the original question).
    – Doc Brown
    Commented Jul 17, 2014 at 13:55

Using agile in this situation is still a very good idea. There are many benefits to agile, only one of which is regular feedback from the customer and the ability to respond to changing requirements as you mention.

One of the main reason waterfall projects are notorious for failure is the 'nearly done' problem - testing produced piles of bugs at the end, leaving an unreleasable product and no idea whether it needs another two days or two years to fix the outstanding bugs. Agile removes this risk entirely. If an agile project is over-running, you can still deliver a working version which:

A) Proves to the customer you are actually nearly there through demo's ("All these stories are done, we can do the last few if you want") and some more time will get exactly what they want.

B) Potentially is good enough for them to be happy anyway and release.

To me, removing this risk of complete failure is enough reason alone for a business to move to an agile development process, the ability to build better software than initially planned is icing on the cake. As mentioned in other answers, those 'concrete' requirements are often still surprisingly malleable.

  • I do not understand in which way A) solves the problem you mentioned at the beginning of your answer: how do you know if the last few stories will take a few days or two years? You only really know when you actually do them, don't you?
    – Giorgio
    Commented Jul 28, 2014 at 6:44
  • 1
    You're right, but the difference is you have a releasable product in its current state, rather than an 90% done buggy piece of software that cannot be released. You also have empirical evidence of how long it took you to deliver the features that are releasable, and your estimates of the remaining work which are likely to provide more confidence that no proof that anything you have done actually works.
    – SpoonerNZ
    Commented Jul 28, 2014 at 8:05
  • It depends: if all the planned features are essential, then a product with 90 % features is unusable / not releasable: it can only be used to give a demo of what is already there. In my experience agile is not preferable in all situations: there are projects for which agile is more suitable (changing requirements, small, self-contained and independent features) and projects for which it is not (stable requirements, complex and / or mission critical features).
    – Giorgio
    Commented Jul 28, 2014 at 12:34
  • I agree - under-delivering is not good in either case, but as a stakeholder would you trust the team that produce a fully functioning version of your software to play with where everything works but some features are missing, or the team that give you a bug riddled pile of source code that theoretically has all your features but crashes lots and has lots of unexpected behaviour? I know which I would trust more.
    – SpoonerNZ
    Commented Jul 28, 2014 at 12:54
  • Of course I would trust the first team, but I do not agree that using a non-agile method you always end up with "a bug riddled pile of source code that theoretically has all your features but crashes lots and has lots of unexpected behaviour". At least, this has not been my experience up to now.
    – Giorgio
    Commented Jul 28, 2014 at 13:17

Agile is ideal if you need a frequent feedback loop with the client. This can be because the requirements change frequently, but it could also be for other reasons.

On the other hand, Agile can work equally well if the requirements are fully stable and the client expects only a single big-bang delivery, but you might have to adapt things a bit for the amount of involvement that the client expects to have during the project. This means that the Product Owner role must be filled from within your own organization and that person must have enough mandate from the customer to make decisions.

  • 1
    I am often wondering if clients that do not want to be involved too much have a real business need. I have often seen this happening in projects where an existing application is 'translated' to a new technology. You can check the code if you have questions is what they are telling you. No one is waiting for the remake.
    – user99561
    Commented Jul 16, 2014 at 16:05
  • @user99561: you are right, but in such situations the requirements are mostly not vague, they are crystal clear - as long as the new program shall behave exactly as the old one. In such a situation an "agile" approach is indeed not necessary. An iterative, mile-stone based approach (without much customer interaction) will be indeed enough.
    – Doc Brown
    Commented Jul 17, 2014 at 21:56
  • Crystal clear? Good luck figuring out what the exact behavior is and what the exceptions are. Most of the time even the business people don't understand what happens in the application. My advice: run away as fast as you can from these projects. Because you know when the project starts, but you do not know when the last bug posted because the applications behave differently will be fixed.
    – user99561
    Commented Jul 18, 2014 at 9:31

You can always split the big release into smaller releases(sprints) and ask your client for feedback. This way you are sure that you're doing the right thing and the client can keep track of your progress.

If there is something wrong, you can offer your client the chance to correct you sooner, which is very good. It is better to correct your mistakes as soon as possible, rather than show him a bullshit at the end and try to fix it when you don't even know where to start.

  • I have just added an edit to clarify. The clients showed a problem with enough details and clear wish-list and want to not be troubled further. So assume, no client feedback until near the end when you can demo a working prototype.
    – InformedA
    Commented Jul 16, 2014 at 7:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.