Maybe It’s Time for Customer Driven Development

A couple of Tweets from Robert Smallshire caught my eye last month:

Seb Rose‘s reply to the first Tweet, however, went straight to the heart of the matter:

It’s not about any one practice. It’s about how that practice affects the customer.

It’s not about technology, but about customers’ needs getting fulfilled. The customer is pretty much the only one who can say definitively whether or not their needs are being fulfilled.

Learning by shipping is all well and good, assuming that it’s the only (or at least, least harmful) way to get the information needed and the customer is aware of what’s being done. As Matt Ballantine observed in his post “What if the Answer isn’t Software?”:

In the world of startup, the answer is probably that Agile development of software that is attempting to answer a non-software problem is failure. It seems to be widely accepted that 90% of software startups fail – and that’s presumably a number that doesn’t include a far greater number of embryonic ideas that don’t even make it to startup stage. Some of that failure will be because of lack of luck, some because of poor management, but many will be because they are half-arsed ideas to non-problems (“Hey, it’s like Facebook, but for frogs!”), and the others are because they are trying to address something through software which has other factors in the way (usually: people).

I don’t know many organisations that can significantly fund projects (particularly internal technology projects) to 90% rates of failure. In fact, most organisations have systematic processes in place (investment proposals) that are designed to mitigate against such numbers. Whether those processes work or not it a moot point.

Sometimes you have to build something and get it in front of people to truly know whether it will work. Sometimes (Windows 8) you can know in advance whether it’s a good idea. In either case, the customer should know when they’re paying for an experiment.

Whether you work for an in-house IT shop, an outsourcer, or an ISV, the point of your work is pleasing a customer. The proximity may be different, but the goal is not. When we talk about what we’re going to do and/or how we’re going to do it, if there’s no mention of customer impact, it’s likely that we’re on the wrong track.


2 thoughts on “Maybe It’s Time for Customer Driven Development

  1. Pingback: SPaMCAST 365 – Agile Project Charters, Improvisation, Customer-Driven Development | Software Process and Measurement

  2. Pingback: Form Follows Function on SPaMCast 365 | Form Follows Function

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.