The Agile Customer

One of the main concepts of "Agile Development Methodologies" is that the customer be involved in the entire process. And not only that they are involved, but that they are actually there, alongside the developers, while the software is written.

This is, of course, ridiculous. Most customers don’t actually have that kind of time to spare. So in reality the word "customer" is used to mean "customer representative." That is, someone who should be sufficiently familiar with the real customer to be able to understand their needs and argue for them with the development team.

This concept is a primary ingredient in fulfilling the purpose of an Agile Methodology. That purpose, in my view, can be stated as follows:

Requirements will change and be wrong. We must be able to create excellent software despite those changes.

This is accomplished by designing and developing things in small pieces (in iterations) and by frequently getting those pieces to the "Agile Customer" where we can verify that they work out, and when they don’t work out, we make the required changes immediately.

That, at least, is the idea. But I don’t think it works, and I think the reason it doesn’t work is because this concept of an Agile Customer is a bit unreal. Here’s why:

1. Your client doesn't have time to be that involved in the development process, and even if they did, they wouldn’t care
2. The business process is more complicated than a single person can fully understand, even though they think they understand it
3. A "customer representative" will know even less than the customer
4. No one is going to get it all right the first time, and they wont notice its wrong until they try to really use it
5. In a software demo the client will find about 80% of the trivial problems with the software, but only 2% of the big stuff (missing pieces, incorrect process, bad assumptions, etc)
6. In a testing environment, the client will find about 80% of the bugs in your software, but only 10% of the big stuff.
   

Basically, we expect an Agile Customer (who is not just a single person of course...) to know and remember every little detail and to recognize when details are wrong and also when they are missing. Unfortunately, real live people are really bad when it comes to these kinds of details.

The result is your customer representative won’t know all the things they need to know (because it’s impossible for them to). Your client will love your demos but won’t notice all the things about their business that aren’t accounted for (because they didn’t tell you about them because they probably don’t even remember themselves). Your pre-release testing won’t uncover the problems because it only begins to scrape the surface (because it would take too much time and effort to really use the system and not just test the system).

What’s a poor agile methodology to do?

I don’t think you should stop trying to use the “Agile Customer” approach. But you should realize from the beginning that it isn’t going to get you to 100% wonderful working software.

To do that, you’re going to actually have to release it. Often. Even when it doesn’t quite do everything it needs to do yet. Then you’ll see if it’s 100% wonderful and working.

This means you are going to have to transition people to using it, and you’re going to have to train people on it. It’s going to take time and effort. But if you do it correctly, you can save yourself time overall by finding problems earlier and fixing them before it’s too late.

The obvious problem with this is that your users will hate you. You are giving them unfinished software and telling them it’s done. You are making them deal with frequent releases, which means frequent changes in the software, which means they have to keep relearning things you changed, as well as learning new things you’ve added.

However, we can mitigate this by setting the tone.

First off, DON’T tell them it’s done! Even if you think it’s done, it’s not done. So tell them it’s solid, tell them its tested, but tell them that you and they need to work together to ferret out anything that may have been missed, or misunderstood, or changed.

Then as problems are found, don’t get annoyed or frustrated. Instead, remember that you were expecting it, and frame it as such. Every problem you find makes the software that much better. So tell the client that, and then keep them up to date on how much better the software is becoming. Show them lists of what was found, when, and when it got fixed and released. If you’re proud of how quickly you’re iterating and improving you can trick them into being psyched about it too, I mean, make them feel psyched about it too.

Then as critical parts of the software “settle down” in release, you can start adding other parts to them. You’re going to have to plan these “parts” intelligently of course. You can’t release the order intake portion of your software without the portion that allows them to view, manage, and/or print the orders… So your parts need to make sense. But you can release the majority of the order stuff and leave out some of the next steps, or additional features. You may find that you don’t need that stuff at all. Or that you had it all wrong. Or, if you’re lucky, that you had it perfect, and then you can go ahead and develop it and release it. Then you’ll discover you had it wrong. But, hey, at least you tried. And at least you got the really important main stuff out the door earlier.

Basically, you’re not doing anything differently than you would have done it before. You’re just doing it with a different expectation and a different attitude. The result will hopefully be rock solid software, happy clients, and best of all, happy developers.

Now we come to the part of the article where I fess up to the fact that while I wrote all this as if I’d been doing it for years and it works perfectly, I actually haven’t had an opportunity to actually try to follow this advice. Instead, this is more the result of the problems I’ve observed and the best ideas for how to solve them I’ve been able to come up with. Thus, if you’ve had different observations, or different ideas for solutions, or if you just completely disagree with me and think I’m a stupid moron who speaks out of turn about things he doesn’t know anything about, I want to hear about it. And that’s what the comments are for.