notes and views on crm, social media, and the human side of information technology

Agile analysis, waterfall delivery

ITERATIONS, SCHMITERATIONS… Many a developer shop claim they are using an agile (as in RUP, not XP) approach, yet when time comes for them to put money where their mouth is, they are doing the ol’ good Waterfall.

Part of the problem is - the Customer. The Customer wants to know, up-front, what the application will look like.

But - although there is some truth to the old saying that all software would work perfectly if it weren’t for the users - blaming the customer is rarely a sound business tactics.

Why would the customer need to know exactly if he could trust the vendor implicitly?

Yes, trust. So many failed projects on their books, few companies have faith in vendors’ competence. They put provisions and clauses in the contracts so that they can sense an impending catastrophe before it strikes. One of these clauses: the Analysis shall deliver a complete specification of the final product.

Poor analysts.

They become designers, software architects, and documentation makers. Rarely do they have time to spend on their favorite subject, Requirements. Meaning the requirements rarely make it into the design, which leads to a product not matching the client’s needs, which leads to … poor satisfaction and a little less faith, again.

Here’s a solution: think agile, and the Waterfall can work.

Some deception is needed. The analyst will create beautiful visual representations of the final product - be it UML diagrams, a GUI prototype, or web page demos. And he has to work the client to make him think this is, indeed, the product. It has to be logical and detailed and, yes, sexy. The analyst has to seduce the client so that he sees the final product even though he’s actually looking at an abstraction. One that is decidedly incomplete and open to changes.

Indeed, visual modeling is a great way to capture, verify, and test requirements.

I understand the Agile camp looks at diagrams with certain disdain. Truth is, diagrams have no value in themselves - the client needs the code (or function thereof) - BUT they have a tremendous power in that they suck the customer in. He has something to look at, to dream about. And in that process he can express his wishes better than through written word.

Of course, the visuals don’t tell the whole truth; they do, however, define a boundary for any requirements that can and will come later. Which can allow for some agile approach even though the process goes from Analysis to Design to Development etc. and doesn’t allow for requirements to be formally introduced once Analysis has finished.

The product will never look exactly the same as the specs produced by analysts. It might, however, be closer to the customer’s needs, and even if the customer notices the differences, I doubt he’ll complain.

Additional reading

September 26, 2007 | Filed Under Software delivery 

comments

Leave a Reply