This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: How to Make Customers Unhappy on an Agile Software Project
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
Sometimes your customers get grumpy. This makes them do unfortunate things like canceling your projects, refusing to pay you, or just not smiling when they bump into you in the halls. This isn't because they're mean people. It's often because we do things that make them grumpy, even on agile projects.
But how could this be? You've invited them onsite, given them free access to your development cubicles, and forced them to attend all of your design meetings? What could be better?
Turns out that the best onsite customers are actually good at their day jobs, which means they are actually needed at them much of the time. So as much as they're excited about participating on the team, reality keeps intruding. They can't spend very much time sitting around, waiting to be pestered by developers.
So what's an agile software team to do? Don't you need an onsite customer to make things go smoothly?
The reality is that sometimes you can't have a dedicated customer onsite at all times. Questions about which way to take Feature X might have to wait a few hours, or even a few days while you compose an email or schedule a conference call to discuss.
But ever the optimists, you plunge ahead, hopeful that the reduced communication won't create any problems. And it doesn't, until your very next software delivery.
"What happened to the Whatsit component that was supposed to be here?" asks your Customer. "We talked about this a month ago! And what is this new Easter Egg in the upper left hand corner - that's unacceptable!"
"I told you so!" says the ever helpful Tactless Tester, lurking just behind your chair. "You developers wouldn't listen to me, and now you've messed it up good!"
OK, something is clearly wrong with this situation. And it's not just that annoying tester who likes to humiliate you in public. What could it be?
Aha, you think, no one bothered to communicate with the customer before delivery of the software. Planning went well, and the priorities were pretty clear a couple of months ago. But then development started, the team wanted to use the new Insta-egg(TM) Easter Egg Maker, and decided that the customer was just mistaken when they said they needed a Whatsit.
Your problems started well before the Egg Incident. The moment the team took control over what features to build and disregarded the customer should have been a warning sign. It got worse when you didn't have any regular communication with the customer until delivery, a few months later.
Even well-run agile teams can make this mistake when the customer is not frequently available. Complacency sets in when you think you know the customer well enough to decide things for them. And you get burned by adding things you thought would be well received, and leaving out things you didn't really want to build and thought were a bad idea. Uh, whose money are you spending, anyway?
One strategy for keeping your team in check is to have regular status meetings, at least every few weeks (probably at the end of each iteration), where you communicate with your customer about progress. Not with a Powerpoint presentation or pyrotechnics, but a simple demonstration of working features since the last meeting.
This will keep your customer engaged, even if they're offsite (Web and telephone conferencing can work pretty well in this situation). There's nothing like working features to elicit clear feedback on what's right and what's wrong. And it just might keep your team from committing project suicide.
Previous Topic
