The feedback loop in agile web development

by Mechaferret on November 8th, 2009

Everyone knows that waterfall software development is bad and agile software development is good.¹ The stated reason for this is that agile development gets working software to customers faster, thus (1) providing them value sooner and (2) allowing earlier feedback, so that there is less wasted effort that does not add value.

But how do you decide what constitutes “wasted effort that does not add value”? The accepted non-software touchstone for agile development, “lean manufacturing”, defines “wasted effort” as “anything that does not create value for the end customer”. But how do you know what the end customer values?

Obviously (you say), you figure it out from the “earlier feedback”.

Yeah? How?

If your application is internal and your user base is well-known, collecting and acting on feedback is easy. You have your designated “onsite customer” and maybe a few others use the latest iteration of the product and tell you what they think. But what should you do if your application is a consumer-facing web application with anonymous customers, most of whom are far more likely to go away if they are not receiving value than to fill out a feedback form?

Yes, that’s when it gets interesting.

One clear way not to go is to assume that the internal product team, possibly augmented with IA/UX and usability experts, can figure out what your target users want by applying “usability standards” and “domain knowledge”. While all of these activities have their uses, the risk is high that the initial concept will not be what the users want. This will result in the following cycle:

  1. Figure out concept of product.
  2. Design product in conjunction with IA/UX experts, taking care that each page is easy-to-use and well-designed.
  3. Take at least 2 months to build the product because each page has to be perfectly designed.
  4. Since you’re trying to be “agile”, don’t take more than two months; put the team on death march to deliver the completed product on schedule.
  5. Discover that the users don’t seem to value the new product enough, as measured by the lack of usage or revenue.
  6. Repeat.

This is a loop, certainly, but it is hardly a feedback loop. Feedback is not obtained until step (5), and it’s not very precise: it’s either “yay” (we have users and are making money) or “boo” (we’re not), which gives you very little to go on for the next iteration.

Four of those cycles can easily take up a year without adding any value for the end customer. By then, you might as well have just used the year to develop the product using a waterfall development process: you’d have created just as much value for the user, and your team wouldn’t be frazzled with impossible deadlines and frustrated by doing the same thing over and over. In fact, often this process does devolve into a form of waterfall development: the coding process may be agile, but the visual design process of

Product feature–>wireframe–>Photoshop mockup–>approved page

is done strictly in sequence, i.e., waterfall.

Happily, this is not a problem without known solutions. The idea of “lean startups”, incorporating “customer development”, has some excellent strategies for avoiding the above trap: don’t make product decisions in a vacuum, develop customers in parallel with developing features, find early adopters for feedback and enlist them as your allies, make your first release as early as possible, make subsequent incremental releases near-continuously.

The lean startup method gives you real feedback for your web application as early as possible. It also has the nice side benefit of creating a cadre of enthusiastic evangelists for your product as it works. That is a feedback loop well worth implementing.

¹Assuming that the requirements are not well-understood, that costs of changing the system after release are not unacceptable, you know the drill….

From Methods

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS