January 20, 2014

...Learn TDD with Codemanship

What is Customer-Driven Development, Anyway?

After that last blog post, a couple of people have asked "is 'Customer-driven Development' a thing?"

Well, it almost was. Let's take a trip down memory lane...

In the Dark Ages, before we went all Agile and Lean and Wotsit-driven, an idea kicked around that sought to reimagine software development as a system that only did things in response to external stimuli from customers.

Every process, every practice, every activity was to be triggered by some customer action (or some other event determined by the customer, like a milestone, a deadline, a business rule or trigger and so on.)

Yes; you can probably tell that this has the architect's fingerprints all over it. Naive as we were, we genuinely believed - well, some of us did, at any rate - that the way teams developed software could be modeled and shaped using the same techniques we used to model and shape the software itself. Development resources and artefacts were objects. Processes were state machines that acted on those objects, or were enacted by those objects. Development teams were systems, with use cases. Software development use cases were triggered by actors - agents outside of the system.

Crazy as it was, out of all that a handful of us nurtured the germ of the idea of Customer-driven Development (though we didn't call it that at the time).

Think of your development teams a server. It sits and listens, ticking over, waiting for a customer to make a request. It might come in the form of a feature request, or a bug report, or a request for the software to be released, that sort of thing.

Today, a better analogy might be that the development team is the engine of a motorboat, and the customer is the captain who steers the boat. When the customer says "go this way", the engine propels the boat that way. Okay, that's not a great analogy, either.

You get the idea, though; the customer is in the driving seat. The customer drives development.

For true Customer-driven Development, though, the customer needs suitable controls to drive with. If they lack the necessary hands-on control, there's a danger they just become passengers. I see that a lot. The customer is being driven by the developers, or by the project manager, or a product owner, or a business analyst. And they don't necessarily end up where they wanted to go, especially when these "taxi drivers" have ideas of their own about the direction the software should be taking.

To reduce this risk, customers need to be at the wheel. And the controls need to be designed with the customer in mind. Hence my previous post.





Posted 4 years, 2 months ago on January 20, 2014