I couldn't write a book on Agile. I have worked in several shops that call their process Agile. One of the main points of Agile development is regular client involvement. After a sprint, the work can be demo'd to the client to obtain their feedback. Rinse and repeat.

The problem I come across is that many clients do not want to be that involved. They would much prefer a waterfall approach. Gather the requirements up front, then come back when you are done. In my experience, waterfall does not work. Clients do not know what they want until they see it. The waterfall dilemma is further propagated by a large community of developers that want to have all the requirements up front. This way they know what they are building, they can architect accordingly, and the client is to blame because they "signed off" on said requirements.

Am I incorrect? Can Agile work without client involvement? If so, how and how do you overcome the issues I discussed?

  • 12
    Don't let "agile" become your hammer so that everything else looks like a nail that needs pounding in to you. Commented Feb 15, 2012 at 18:44
  • 1
    In my experience preference toward waterfall approaches is generally due to a lack of understanding how either software or design works. The good news is that means Agile isn't the big problem, it's the client's attitude/understanding. The bad news is the client's attitude.
    – Zelda
    Commented Feb 15, 2012 at 23:42
  • @BenBrocka: That's not terribly surprising, considering that that's what Waterfall was specifically designed for. The author wanted to write a paper about what a development process that was created by someone who doesn't understand software development might look like and why such a process cannot possibly work. So, he specifically invented Waterfall as an example a process that is designed by someone who doesn't understand software development and that cannot possibly work. Obviously, it's no surprise that it appeals to people who don't understand software development nor is it a surprise … Commented Feb 16, 2012 at 3:55
  • @BenBrocka: … that it doesn't work. What's surprising is why anybody would even want to use a process that is specifically designed to not work. I guess nobody bothers to actually read the paper. Commented Feb 16, 2012 at 3:58
  • 1
    @JörgWMittag Actual adoption of Waterfall (whether they realize it's waterfall or not) is mostly just because it's a standard model of business decisions; boss wants something, underling does it, the customer is happy, right? Of course it doesn't work but it's a nice simple model for nice simple minds :)
    – Zelda
    Commented Feb 16, 2012 at 14:10

9 Answers 9


How could it? The very nature of the technique dictates some sort of feedback loop between the customer and the developer.

Parts of your team can, however, act as "proxy" customers (a similar process to "eating your own dog food") so that you can "pretend" to be agile, although that won't be as satisfactory as getting actual customer feedback.

Like it or not, the customer will be involved in the design process; it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is).

Since the customer wants "Big Design Up Front," help them understand that it will take more time and effort upfront on their part to get the design right the first time.

  • 5
    Parts of your team can, however, act as "proxy" customers - in my experience, testers made pretty effective "proxies" of the kind you mention. When I was a tester myself, I also sometimes pretended to wear a customer suit so to speak. Such a proxying have limitations though - eg QA guy complaining about how much time it takes to install the product might just feel that way because they do it daily while customer does it once a year or two
    – gnat
    Commented Feb 15, 2012 at 19:36
  • it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is). Who is it really more expensive for though? Most clients don't see it as paying for your time to get their current vision of a solution in place. Sometimes they just have a problem and have no way of knowing what the solution should be until you tell them what it will be. At that point if what you told them doesn't actually solve their problem then it is YOUR FAULT not theirs. How is it their fault that you misunderstood their real problems in the first place? cont...
    – maple_shaft
    Commented Feb 15, 2012 at 20:39
  • cont... why should they have to pay for it? Just to save face with the customer and not completely screw over any chance at repeat business then you have to turn around and do the rework for free because they demanded the fixed price contract in the first place. This is the more prevalent attitude and exactly what P.Brian.Mackey is experiencing. Customers strong arm these negotiations and when you are just one of 100 startups trying to score the contract then the guy with the realistic and fair Agile based contract will have to wait in the back of the line. It is HARD out there right now.
    – maple_shaft
    Commented Feb 15, 2012 at 20:43
  • @maple_shaft: Clearly you've been burned by this. But, as with all things, it comes down to choices. Agile exists because waterfall has its problems and people are not perfect. If the client has been advised of the risks, and wants waterfall anyway, that's their choice. It's also the software shop's choice to decide whether or not it's worth risking waterfall on a client that doesn't understand the risks, or denies the validity of those risks. Commented Feb 15, 2012 at 20:46
  • @RobertHarvey Even a bad client in a bad economy is still a client and they still keep the lights on for a few more months. The risks for the client in the case I mentioned are minimal and contained to whether they received the solution promised on time. The risk for the software shop in this case is if this pain-in-the-rear client is going to suck us dry.
    – maple_shaft
    Commented Feb 15, 2012 at 20:52

The short answer to your question is 'no'. Here are comments on some parts of your question. To be accurate most of the answers are based on my personal experience and observation.

In my experience, waterfall does not work.

Waterfall is a sound methodology for delivering systems of varying complexity. It is unfortunate that it is not well presented or understood. One reason for that is that it does not make enough money competing with the methodology of the day that keep on popping up. You may surprised to know that many of the banking, insurance and manufacturing systems were built only using Waterfall approach and many of those are still in production today. It is sad that the software industry is based on hype more than science.

Clients do not know what they want until they see it.

This is a myth. A big one too. This may be the case in web page design/layout but for business data processing, most users want something that works. Some of those users still use AS/400 screens and 3270 CICS monitors with RGB and they can get their business done with those tools. Also, those same users accepts SAP and ORACLE ERP systems without having any say in the design of the interface (and some times in the functionality). Most business users will even adapt their work habits and flows if the system is producing the correct function. The stress here is on function not looks. Business people understand how they do their work very well 90% of the time.

The waterfall dilemma is further propagated by a large community of developers that want to have all the requirements up front. This way they know what they are building, they can architect accordingly, and the client is to blame because they "signed off" on said requirements.

You can't blame developers for wanting to know what they are building because those developers want to go home cook dinner and press their shirts for another drill after they spend 3 hours or so learning the next tech. that will replace their current skill set! The blame game makes no one a winner. Think in terms of each party's roles and responsibilities and the picture will be very clear.

In conclusion, Project managers,Programmers, and Web Designers are no replacement for Business Analysts whom should know how to collect requirements from end users regardless of the methodology.

  • 3
    +1 - For contending "clients do not know". It is a matter of different domains have different types of clients. This is why agilists can't understand waterfall people. They believe that you can only say what you want when you see it. It isn't true, but that is all they see from their customers. While waterfall proponents can't understand why you can't get the overwhelming majority of requirements understood up front so that the design can take all issues into account. It's probably because waterfall people don't deal with willy-nilly customers very much.
    – Dunk
    Commented Feb 15, 2012 at 22:45
  • 1
    @Dunk, thanks for your comment. I like your wording" "willy-nilly customers'!
    – NoChance
    Commented Feb 15, 2012 at 23:01

I think that one of the main benefits of Agile is the ability to get more detailed requirements for each feature overall. When the client gives all of their requirements upfront, each feature tends to be a vague idea, with a bit of functionality defined. Agile forces the client to revisit each feature and focus on exactly what they want and how the feature will fit into the bigger picture. To get this same amount of detail (enough detail to implement the features) into the spec, waterfall really requires you to do one of two things:

  1. Guess. Implement until you run into something that is vague, then make a judgement on how you feel the feature would best be implemented. This is obviously not ideal, since it leads to the "Wait, that's not what I asked for!" scenario.

  2. Put far more emphasis on design upfront. Essentially, when the client throws their half-baked spec at you on day one, plan to go through every minute detail before implementing anything. Ask the client to clarify everything ad nauseum to the point where you know every implementation detail for the entire project. While not perfect, this is better than option 1. You still might run into details that you had not anticipated, and it might even send the client running for the hills, but if they really do not want to be in communication during development and you are not psychic, this is a necessity. This is basically waterfall, and it comes with all of the associated downsides, including being extremely difficult to execute properly.

  3. Take the half-baked spec, but ask for clarification as you go anyway. Work until you reach a vague part of the spec, then ask the client to clarify. Of course, this is not what the client asked for, but if they do not want an application as murky as the spec and refuse to define the spec upfront, this is the one remaining option. It does not have all of the benefits of Agile (such as regular client approval to make sure everyone is on the same page), however, it does allow you to get the information you need to develop. Since option 1 will probably leave you with a sub par product, option 2 is wasteful and frustrating to the client (you will probably need to spend at least twice as much time on design and spec gathering overall if you do it entirely up front), this is really not such a bad option. The key here is to be diligent in modifying time lines and price with each change that comes up. If you do it right, you might find that the majority of the Agile practices are compatible with this arrangement, even if the client does not know it. IMHO, this is really in keeping with the spirit of Agile, in that you are supposed to adapt the methodologies to your particular arrangement.

If the client really cannot live with the consequences of any of these three options or full blown Agile, I have a hard time imagining how this client could really be worth your while.

  • You left out option 4. You take the spec with the overwhelming majority of requirements. Do the design (probably iterative) with customer reviews. Implement and test the code (probably iterative). Hold periodic program reviews informing the customer of progress and decisions. They give feedback, you incorporate their comments and move on.
    – Dunk
    Commented Feb 15, 2012 at 22:52
  • The situations you describe above would only occur with teams that don't know how to do waterfall. Yes, it is difficult to execute properly. Agile is also hard to execute properly. Everytime somebody fails at agile, some agilist throws out a new rule that wasn't followed and claims that is the reason for the failure. It's never agile's fault. At least waterfall proponents admit that it takes good people with good skills to make waterfall work.
    – Dunk
    Commented Feb 15, 2012 at 22:54
  • Your option 4 is exactly what I intended to describe in option 3.
    – user3792
    Commented Feb 15, 2012 at 23:04
  • How could I make my answer better? I cannot tell if you agree or disagree with what I am saying.
    – user3792
    Commented Feb 15, 2012 at 23:06
  • You can improve it by maybe taking out the word half-baked for starters. Remove the part about this is not what the customer wanted. Remove the murky spec part, etc. In waterfall, the important part of capturing the requirements is to get the architectural significant ones and the ones the system absolutely must do to be useful up front. After that, changes are usually not that big of a deal. Believe it or not, there are and always have been iterations, whether formal or informal in waterfall development. Long before agile came along.
    – Dunk
    Commented Feb 17, 2012 at 22:08

They don't want to put in the time and if given a choice they'd rather get software for free, but you're still going to charge them, right? This gets blurred if you're developing software internally for your company. They think the IT Department has been bought and paid for (salaried employees), so they might as well get as much work out of you as they can.

You can be potentially agile. Get all the specs and start coding. Once the client interupts the work because they just thought of soomething and you have to make changes and reworks, you just became a little more agile. You could also do the approvals within your team. Have one of your team put on a suit and tie and pretend to be the customer.

Making a large time commitment up front may scare them away. Suggest doing a sprint to try it out. Then give them the chance to opt out. You can always shift to a waterfall for the rest of the project. Also suggest that different people on their team could do the review and approve if time is a constraint for the person writing the check.

At some point, you have to tell them that you don't think the waterfall is going to work. Ask them if they were satisfied with this approach and if so, why don't they have the last guy do this project?


No methodology can work without client involvement. Having sign-off on requirements can be meaningless as I witnessed in projects I participated. Your problem goes beyond being able to do Agile, you need to educate your client and make sure they understand how important it is for them to participate.

  • 2
    Isn't it a question of the amount and frequency of participation by the client and not a matter of all or nothing?
    – JeffO
    Commented Feb 15, 2012 at 18:42
  • 3
    A client that refuses to participate often is in my view a client in need of education. It is not unusual for the client's business experts to put in a position where they have to interact with the software development company and still perform their day to day activities and that needs to be addressed by talking to their higher ups. Commented Feb 15, 2012 at 18:48

I think it's difficult but still possible. I think Robert's proxy idea works but it's necessary for the proxy to spend as much time as possible with the 'real' client so they can see things from their point of view. That way the proxy can ascertain what features are really important and get a feel for the user experience the client expects/desires.

But at some point you'll need to show the software to the 'real' client...


It is possible to avoid real customers, in fact sometimes it is needed for the regulatory. Usually the customers of medical software are not involved. In those cases other entities may substitute the customer role, for example the marketing team can be considered the customers.


Agile does require the tight loop to replace big up-front design which is Hard--Quite hard but actually it can be done, agile is not the only way.

You may want to find one of the modifications of Agile--there are many and one probably addresses this specific problem, but if not make up your own if you think you can.

All these processes were made up by smart people--and smart people can make any process work. You don't think waterfall was invented because it never worked for anyone do you? It evolved because some people could make it work, and others looked on and said "I have to refine that and feed it to MY team that can't seem to produce as effectively"--at that point it probably worked better than what they were doing, but if you don't recognize that not every programmer can solve every problem it can really baffle you why two teams using the same process can have different results.

The problem is that many processes require talent to implement them--we're talking talent as rare as pro sports players out of a pool of everyone who has ever played a sport--chances are most of us have never met someone capable of making the crappy processes like waterfall work and that's why so many people think it can't succeed--they've never seen it work.

It takes much less talent to make Agile work, yet it requires some very specific investments such as having the customer look at what you are doing constantly so that errors can't propagate, and things like ruthless refactoring so that you don't build up a technical debt that the team can't unravel a few months down the line.


Define the customer.

Is it another company? Another individual?

Is it another team within your company?

Is it a product champion within your company?

Is it you?

All of the above are possible, and quite reasonable depending on the circumstances. You don't want to take a single view down the tunnel about what it is to be Agile, so to say a definitive NO would be incorrect. YES on the other hand requires a little lateral thinking.

Think about the word Agile for a moment. The very clever group of people who coined the term couldn't have picked a better metaphor for the concept they were trying to describe. When you say Agility, what comes to your mind? Being fleet of foot? Fast to react perhaps? Fast to adapt?

Now think about all of the commonly accepted Agile practices out there, and ask yourself what they really bring to software development methods that are considered to be Agile.

I am the customer to all intents and purposes for my solo projects. I even wear a real hat sometimes, when I really want to make a distinctive mental change in my customer role. This makes me no less Agile than I am when I am at work. For all I care, my cat can be the manager. He makes sure I take a rest break every once in a while, and reminds me to avoid getting too obsessed with any single task. You may prefer to use your fancy "Pomadoro Technique", but I prefer the "Rascal" Timer!! The thing is, I work in a strictly Agile process whenever I write code for myself. I'm not the hacker-come-cowboy type, who lives a life of endless development spikes and accomplishing nothing. I like to craft my software, schedule the development around my work and personal lives, and complete it in a manner that I would expect to do if I were working for a real customer. When things interrupt my schedule, I adjust and prioritize my project work accordingly. I use all of the standard Agile practices and techniques that I can apply solo, and I "deliver" working code to myself (or a friend or colleague to test) as often as I can. If all of this isn't Agile, I ask you what is?

So my answer is Yes, you can be an Agile Software Developer, and you can apply an Agile methodology, and you don't necessarily need the customer, or even the manager. You can work on a project all by yourself, and wear multiple hats. It may not necessarily be Ideal to do away with those other roles however, as it is very helpful to cooperate with others to achieve a goal. They act as a sounding board for your ideas, and they feed you requirements that you might otherwise find difficult to generate sensibly on your own. The other very important role that the customer and manager satisfy is that of keeping you focused on your goals, without endlessly adding features and refining your code beyond what may be strictly necessary.

Still, if you work in a disciplined manner, sticking strictly to your methodology of choice, and apply Agile practices, and if when you get side-tracked, or you change your mind (when wearing your customer hat) and your product design or direction takes a turn, if you can adapt your schedule, and adjust your priorities just as you would imagine your customer would expect you to, then you are being Agile.

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