Can Agile be accomplished without client involvement?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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?

Answer 5

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.

Answer 6

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...

Answer 7

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.

Answer 8

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.

Answer 9

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.