Agile development is a topic surrounded by many misconceptions. Every now and then — usually at conference coffee breaks — you can hear project managers bragging about their plans for doing their next project the “agile way”. Why not, they think, leave out all the expensive requirements analysis, project planning and design? Great! Let’s do yet another death-march code & fix project, but this time with the blessings of the software industry gurus.

That’s not at all what agile development is about. As anybody knows, who has ever dared trying, agile development is hard work: it means being very systematic and disciplined all the time. Just because you don’t do all the thinking and planning up-front (as prescribed by the waterfall model), it doesn’t mean that you don’t do it at all. On the contrary. You do these activities a lot, but in smaller chunks and in phases where these activities provide the most value. Not neglecting those activities and doing them at the right time requires a good deal of discipline and stubbornness, especially when the customer won’t stop whining about the fact that the product is still not ready and that every day the product is not out will cost the company a fortune.

Ah, speaking of the customer: One element of agile methodologies is the so-called on-site customer. The on-site customer is a crucial element, if not the most important element in any agile development effort. This person knows the problem domain and the requirements best; developers can always approach him and clarify what is really needed or ask for early feedback by showing prototypes. The on-site customer also steers the project by (re-)prioritizing features, thus defining what the team should build next. But this is just one side of the coin. There is much more value in having the customer close to the developers.

Being together with the development team throughout the project, the on-site customer gets first-hand insight into the making of his product. Through the on-site customer, customers and developers can talk directly for they are not separated by walls or politics; they meet regularly and understand each others perspectives, needs and feelings. Mutual understanding is the foundation of trust and trust is one of the most powerful ingredients to a project’s success. In my opinion, this other side of the coin is at least as important as the first one.

But, boy-oh-boy, how hard is it to find someone who is willing to sit in the driver’s seat instead of just taking a taxi? Isn’t steering much more work and potentially dangerous to a person’s career than just insisting on a contract to be fulfilled? And how onerous is it to sit with us strange developer folks? People, who wear unconventional clothing and by and large don’t care much for their grooming, hate to small-talk and — if they talk at all — tell only inside jokes that no customer will ever understand, let alone laugh about.

If you ask me, that’s the hardest agile practice: finding an on-site customer who is ready to take the heat, is technically competent (is even able to write acceptance tests!) and is willing to sit together with such a strange breed like us. It’s certainly not the stereotypical suit-wearing, gelled-hair kind of businessperson that every company has in abundance.