This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
It seems that in order for agile development methodologies to work well, you must have a client that works well within this process as well. Those that practice this on a regular basis, would you care to share some experiences where the client was fighting you on the amount of involvment required of them? What did you do to try and convince them of this process and were you successful?
Or, do all clients just accept and embrace their involvment?
In my experience, Agile aproaches can work quite well without having an "Agile client". The improvement in internal feedback, team morale, produced quality etc. is well worth adopting Agile values, principles and practices even if you can't convince your clients to be involved in the effort.
But you are right, of course, that being able to involve the clients is what will make you *really* effective. And no, clients don't necessarily embrace that style of working together from the beginning.
For example, last year we had a project with a governance agency. They already had spent two years gathering requirements (before we got involved) and were running out of money, so they needed to have something quickly. They decided to try an "Agile" approach - which to them meant to have an intermediate release after six months instead of just one big bang release at the end of the one year left. :roll:
Fortunately, we managed to develop some informal connections to their system administrator responsible for this project, and convinced him to install an early version after a couple of weeks, just to get sure that we didn't miss something fundamental (this was the first time our software had to work on terminal servers). The feedback was invaluable to both sides, and we even managed to get some users to take a look at it. In the course of the rest of the project, we had such an inofficial release every couple of weeks, and it was quite well received by the client. Priorities changed a lot every time they tried the new features we just had implemented, and there were some nasty misunderstandings that would have been horrible to only be discovered much later in the process. What a suprise...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
We had some resistance from partner analysts who liked the waterfall structure - an intense burst of effort to get a stack of use cases signed off, then nothing for months, then QA. With small stories, iteration handoffs, etc. they have to talk to us all the time. That took some getting used to for sure but as we got better at rapid feedback - finished software - they got into the rhythm.
What we're doing is not common in the company, but I think people are getting along with it pretty well.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi