Peter Mac And Associates

Is your customer Agile?

My customers don’t build software systems for a living. If they did I guess they wouldn’t need my services. I don’t fix cars for a living but you can imagine the look of perplexity on my face when a mechanic tells me the slipped diff needs replacing and the alternator bushels are worn right down.

A customer has an idea of what they want to get built. You meet, discuss. The ball-park figure is 6 months person effort and will cost $100,000. What happens next? Do you tell them you’ll see them in 6 months time with a product and an invoice?

I think it is one of the most critical factors to the success of a software development project that customers are on the same wavelength as the people they have hired to do the work. I’m talking about expectation management from both sides of the coin.

If you’re building an agile project (for argument’s sake let’s use 'scrum'), your customer needs to be around for sprint planning and review meetings. They need to be made aware of the time and frequency commitment required of their staff for testing. They need to know what can and can’t be updated in a Product Backlog. For that matter, has anyone explained to them what a product backlog is?

Having been involved in software development since the mid 1990′s, I’ve seen lots of changes in the way things are done. I’ve worked on projects where the 190 page business requirement spec was the bible, and programmers wouldn’t lift a finger until an equally impressive technical spec was completed. I’ve also seen projects where the client took up residence on the far side of the room and could be called upon at any time with fingers pointing to a screen and the question “So…is that what you mean?”.

I’ve worked with a number of agile techniques with different levels of success. Each technique has had it’s pros and cons from a programmer’s perspective or as a team leader I’ve occasionally had to go back to the manual and check if we’ve been doing things the right way. How long should a sprint run really be? Why do I feel like we’re pushing requirement changes uphill? Where’s the customer when you’re ready to deliver the latest batch of output? Oops, someone forgot to tell the customer.

If your customer is not fully aware of the needs you have of them and can’t provide the staff to fulfill those needs then your project is going to hit a wall sooner or later.

Tips for managing customer expectations are:

• Educate your customer in your way of working.
• Not all projects fit into a fixed methodology. There’s no point in trying to shoe-horn all projects into a methodology that won’t work.
• Ensure a customer based subject matter expert is available for requirements gathering and testing.
• Ensure mobile phones and other distractions are turned off during meetings.
• Draw up a schedule of the deliverables you expect to provide and the user acceptance testing time demands around these deliverables.
• If any blockers can be foreseen, tell the customer early. Don’t procrastinate the bad news.
• Try and develop a partnership with staff working as close together as possible.
• Stay open to changing requirements.
• Score changing requirements in terms of difficulty vs payoff. If it’s a 8 out of 10 in terms of difficulty to achieve but only gives a 2 out of ten in benefit, the numbers should speak for themselves.
• Try and keep your customer informed of what’s around the corner. If you have 2 week sprint runs, make sure they know what’s happening in a month’s time. This helps keeps minds focused on the big picture.