Agile Software Development and the Lazy Client Trap

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Agile Software development is all about the feedback loop. Do a little bit of something, get a little bit of feedback, change what you are doing if the feedback tells you so. There are all sorts of feedback loops in a typical agile development process, from the automated, like TDD and continuous integration, to the biological, like user testing. If one of these loops breaks down, you are in for trouble.

Which is the biggest problem? No question: the lazy stakeholder or client. By lazy, I mean those unwilling to participate in evaluating the software after every iteration. The ideal client with install the software in their environment (web or desktop), kick the tires, try to do their jobs with it, do some informal user testing with colleagues or friends. Bug reports and tweaks will flood in (you do have a defect tracking system, don’t you?) and be scheduled for future iterations. More serious problems, such as a wrong or missing business requirement, will also be caught early this way. Early means cheaper. Early means better.The lazy client; you’ve seen them. They don’t test the software, they just nod their way through the end of iteration demo: “Yup. Yup. OK.” Six months later at

The lazy client; you’ve seen them. They don’t test the software, they just nod their way through the end of iteration demo: “Yup. Yup. OK.” Six months later at lunch time, they do some testing and realize the software doesn’t work for them. The bill we present them for fixing all of the things they were too lazy to verify during the agile development process doesn’t work for them either.

There are definite costs to agile development, but what you get out of it is the possibility of rapid feedback and adjustment. If you’re an absentee stakeholder, you have no one but yourself to blame for an unsuccessful project. If you’re a software developer, catch those lazy clients early. Don’t let them get away with it! Make them use the software, through encouragement, nagging, pleading, or onerous contract terms if you have to. No nodding through the demo!

Finally, as a stakeholder, ask yourself the question: if you have neither patience nor interest to use the software you are having developed, should you be developing it in the first place?