Agile discovery: sometimes the first step is the most difficult



I’m a big proponent of the agile approach to developing systems. We here at Burnside Digital have been using agile techniques for years and they have allowed us to be more responsive to changes and bring numerous products to market in record time (and under budget).

But there is one step in the agile (or any development) process that is often the hardest and probably the number one reason that projects either fail or take much longer to complete – the first step.

Software developers throughout the decades have often times found it difficult to figure out exactly what the client wants in the first place.  This is commonly called the discovery phase in agile-speak. The basic problem is that in many cases the client simply doesn’t know exactly what they want (or can’t articulate it in terms that programmers can understand).

Agile development understands that in many cases a client won’t know what they like (or don’t like) until they actually see it in action. That’s why we build in multiple iterations and try to present the client with a semi-working prototype as early in the process as possible so that we can change direction early if we have to.

I recently read an article by Rick Freedman on the TechRepublic website, and even though it was written a few years ago he still makes some valid points.

Mike Cohn, author of User Stories Applied, supports user requirements with minimal formal structure. Cohn calls these short, pithy descriptions of a system capability or function "user stories."

The use of the word "story" is telling; rather than asking a user to describe the "speed and latency requirements" of a system, we ask them what tasks they plan to do when they sit down at the keyboard. In keeping with the "barely sufficient" concept of agile documentation, user stories are short and written in plain English as a simple narrative. So, for instance, a project sponsor asking us to develop an online job site would tell us the following stories about how different users might interact with their proposed system:

  • "As a jobseeker, I can search for jobs."
  • "As a company, I can post job openings."

From here, as in many other system development efforts, it's a matter of stepwise refinement and of digging incrementally deeper.

And there's another reason for applying the user story technique – it forces the customer to remain engaged throughout the process. Since the user story approach requires constant refinement and builds upon itself from prototype to prototype, there's no other option but engagement for the sponsor.

And that may be one of the other most important parts of the discovery process – keeping the sponsor engaged from the very beginning.



Massoud Marzban

Massoud Marzban is VP of Business Development at Burnside Digital, a successful web and mobile engineering consultancy that helps companies create software that makes the world a better place to live, work and play.


More

3 Critical Things To Do If You Are Letting (You Are) IoT Into Your Home

I had an email exchange with Timur Kovalev, CTO of Untangle , on IoT and the focus was what 3 things are critical to anyone building a Smarthome. Since I have a Smartphone, which doesn’t always work as it should, to me the subject was topical. So let’s get to it. Figure out what’s connected and what’s calling home : Timur wrote “If you don't know which devices are connecting to your network, you can't properly secure them. Consider putting a firewall with application-level visibility at the gateway to prevent malicious access attempts while giving you a deeper view into what requests your...

Xiaomi MiBand 2 Hands On and Price

Xiaomi has finally introduced the Mi Band 2 and I am impressed.

S Korea Issues Warrant Against Volkswagen Exec in Emissions Probe

4,400 Korean consumers have filed a lawsuit against Volkswagen demanding compensation over false emissions claims.