A recent Agile Meetup on “Requirements Management” reminded me of Albert Einstein’s famous definition of ‘insanity’: “doing the same thing over and over again, and expecting a different result.” Nearly all participants described the many problems with their current requirements gathering processes, but then resisted suggestions about how to improve it, implying, essentially, that they would prefer to complain, instead of fixing it.

Gathering requirements for software development projects is often a long, costly, and painful process, though it doesn’t have to be – visualization tools allow your team to see your software solution, before writing any code. It’s a simple solution that is nonetheless often resisted by those involved with inefficient requirements gathering processes.

 

A Common Problem, with a Simple Solution

During that same Meetup, I heard many questions like:

  • How do we know wording of a requirements statement accurately captures the stakeholder’s intent?
  • What do you do when they say – “I already told you what I wanted, why don’t you understand it?”
  • How do you know that the stakeholder has an accurate understanding of the business need?

These are questions I’ve heard many times during similar Meetups and roundtable presentations over the past year, and reflect some common pain points I’ve seen in software development projects over the past 30 years.

For a while, prototyping tools either weren’t user friendly, or prohibitively expensive, which meant the requirements gathering process remained inefficient, with lots of miscommunication between stakeholders and the development team. Now, however, there are several products that are essentially prototypers on steroids. They are comfortably priced, and allow stakeholders to demonstrate what they want, without writing a single line of code.

The Allure of the Status Quo

The cost and time savings of getting the requirements right the first time are potentially immense. For example, one attendee stated that he builds 10% of each module for an application, just to get the conversation started. When I suggested using a prototype instead, all agreed it would be a great tool, but diverted the conversation back to complaining about problems.

At another point, I managed to bring the conversation back to solutions and someone responded that “prototyping tools cost money!” To which I countered, “and what does it cost you to write code that will never make it to production?”

With all due respect to the Agile-ites, the discussion sounded like a group discussing the relative merits of white-out vs. self-correcting typewriters.

Picture This

There’s another famous Einstein quote that I’d rather apply to the requirements gathering process: “If I can’t see it, I can’t understand it.” Too often, stakeholders know what they want in their mind’s eye, but can’t effectively communicate that vision to the development team. Without a mutual vision, neither party understands what the other wants, or the process takes longer and costs more. Visualization tools help everyone involved communicate clearly and outline a shared vision, before writing any code. If you’re constantly having problems with your requirements gathering processes, perhaps it’s time to try doing it differently?

Jack Fischl (8 Posts)