“If I had asked people what they wanted, they would have said faster horses.” — Henry Ford
Establishing and documenting requirements is the first step in any development process. It is also where most projects start to go off the rails. Agile techniques can help, but even agile techniques need to be managed properly.
The first step is to understand the difference between what people want and what they need. Nothing is more annoying or counter-productive than when the dev team kicks off the project by asking, “So, what do you want it to do?”
On the other hand, clients usually start the conversation by telling us, “We need you to do THIS,” and then asking, “So how long will it take, and what will it cost?” But it’s rare that we actually end up doing what it was they thought they wanted us to do in the beginning.
When we do succeed, it’s because we start by learning their business. We make sure we understand how they make money, and how they spend it. From there we can help them see how technology can affect those things. That helps them discover what they need, at least at a high level of abstraction.
In the old days, we would then roll up our sleeves and attempt to transform that understanding into “requirements” expressed in a high degree of detail. The expectation being that the only way to make the development process deterministic was to start with unambiguous requirements, and then faithfully implement them.
That never worked, because you can never really anticipate and document everything up front. It yielded mountains of paper that were never looked at again.
This is where Agile comes in. Once you peel away the dogma, you realize It embraces the simple concept of “I know what I want when I see it.”
We capture the requirements at that high level of abstraction, prioritize them, and then begin implementing them in bite-sized pieces so the customer can see things take shape, and make corrections as they see fit.
This is what makes Agile effective, and why it is succeeding where prior methodologies have failed.
The tools that support this process (and there are many) are generally pretty good from the developer’s perspective, but not real great from the “stakeholders” view.
To get around those deficiencies, we try to capture the high-level requirements (what Agile represents as “stories”) in a separate document that at least convinces users that we “get” them. Honestly, no one has improved on this method yet, so we continue to use it. In the best circumstances, what happens next is that the users just sort of “trust” the team until a couple of iterations (“sprints”) have gone by, and they’ve seen real progress. Once we are over that hump, the process starts to move along swiftly and collaboratively.
Of course, developing in this “agile” fashion makes it very difficult to answer that key question: “How long will it take, and what will it cost?” That, as they say, is a whole ‘nother discussion.
For more information on managing application development please download a guide for CEOs about creating great software from Applied Visions today.
hbspt.cta.load(2637494, ‘7be9b60b-533e-4a11-9fb1-d6f541024810’, {});
