Rabid Dogma

Proposed approaches to building products, software or otherwise, will
come and go. One thing that seems to be constant through all this
change is that the voice of the latest and greatest is convinced that
they have solved the problem once and for all.

Television will be the death of radio, satellite and cable will be
the death of broadcast. The only time something truly usurps the market
is when a clear choice has to be made, and this is usually when it
doesn’t make sense (usually financial sense) to support competing
standards. Betamax and VHS, HD DVD and Blu-Ray.

While there may be a clear winner when it comes to the final
product, this will never be the case when it comes to deciding how we
build that product. Just as there are myriad types of product and
cultures within teams, there will never be one best approach, ever.
Indeed, differentiating on the approach we use, and how efficient we
can become with that approach, is a driver that will always produce
refinements in the future. A few years from now, we will look back with
bemusement at how quaint Blu-Ray was.

While there is great value in agile approaches, there remains this
problem with how it is pitched. The agile promise is almost always
presented against a backdrop of poor examples of ‘that traditional
approach’, but there is danger that the agile community is being told
to throw out the baby with the bath water.

Let’s take an example of how to discover the scope of work for a
project, a prime example of a false dichotomy in how it is presented to
the masses. In many cases, the agile community is told to eschew those
big old, stodgy, requirements documents, in favor of story cards, brief
descriptions of features or goals for the system. There are a million
shades of gray between requirements as ‘written documents’ and story
cards. Indeed, both ends of the spectrum can be equally evil dogma.

A good analyst isn’t hung up on ‘written documents’, but on
understanding that context in which we need to develop our software.
She brings a massive toolkit to the table: data analysis techniques,
state analysis, use cases, quality analysis, myriad others. She’s not
hung up on slavishly using a specific set for every project, much less
hung up on filling out every section of someone else’s requirements
template. What gets captured is the agreements that are made by the
right stakeholders getting together to make the right decisions. This
information is then used throughout the project as the context for
building the solution.

A good analyst makes sure that the team understands and agrees that
they have the right context. This comes from discussions with the right
people involved, looking at the system from different perspectives.
This takes knowledge of a wide range of tools, and when to apply them,
as well as knowledge of who needs to be involved in each conversation.
Discovery of issues and needs in the domain is best facilitated using
vehicles other than the source code for the solution.

A static requirements document is as incomplete as a set of story
cards. One can chew up an incredible amount of time to produce
information that is not referred to when the product is built, the
other can send the team into development with little understanding of
the overall context, complexity of the problem, or an appreciation of
the efficiencies that can be had from seeing the system from different
perspectives. A different approach is needed in either case for all but
the most trivial of systems (and no, I wouldn’t do a big requirements
document for a trivial system).

The argument is to start light, learn as you go. Anything else is
bad, is waterfall, you will fail. While not all in the agile community
spout off like this, there are enough to make it a cacophony.