September 9th, 2014 by Adam Sandman
test management agile requirements management
Myth 3: Software tools for requirements and test management are anathema to Agile projects
One of the tenets of the Agile Manifesto concerns processes and software tools, expressing a preference for people along with their relationships and communication (I am paraphrasing out of necessity – see the note below). Some have taken this to mean that tools are bad; they get in the way and slow things down. Many people when thinking about Agile software development for the first time conjure images of whiteboards, index cards and sticky notes. Indeed, some Agile methods promote the use of such devices; the most well known being Scrum in which advocates describe User Stories as being sufficiently concise to fit on an index card. While this is a good guiding principle, it does not mean that one must literally write User Stories on index cards – although some do.
Manual Agile Methods
The use of ‘manual’ tools such as index cards was a way for early Agile mythologists to stress the informal and impermanent nature of information. It very nicely helps us to see that the process of recording information is meant to be quick and easy and that information can just as quickly and easily be torn up and replaced if it is found to be wrong. As another aspect of the manifesto points out: documentation is not the product; the working software is the product. So, now software tools for documenting Agile development appear to violate two of the four Agile Manifesto guidelines: they are not about people and they do not provide working software. Two strikes and you’re out!
Agile Principles are not Black and White
The problem lies in our inability to see gray. We want everything to be black and white because then we know where we stand. Middle ground is uncertain. We prefer to think of software as certain (although quantum computing might change that.) A bit is either 1 or 0. ‘If then else’ has only two outcomes. Software tests either pass or fail (or at least we would like to think so.) It’s no surprise then that we try to interpret the manifesto as black and white. Statement on the right ‘good’, statement on the left, ‘bad’! We want it to be that easy, but the authors of the manifesto knew better; life, and software development, is just not like that. The manifesto language is deliberately not absolute.
A Place for Agile Management Tools
The truth is that tools have their place; that place is just not ahead of individuals, interactions or working software. Provided we continually remind ourselves of this priority, management tools can be essential allies in the struggle to produce effective software.
Even small projects very quickly establish a large enough number of User Stories that index cards become insufficient. But to be as effective as index cards, a software tool must make it quick and easy to record, retrieve and change the information so that the benefits of informality are not lost as we move to a more formal tool. Further, establishing relationships between information and then using those links for analysis is just not something manual methods can achieve. Manual methods simply cannot do things such as:
- Ensure full test coverage,
- Identify high risk areas,
- Help us understanding why changes were made, and
- Give everyone, including people not on site, access to information.
Not only are software tools not an anathema to Agile projects, they provide essential capabilities with which manual methods simply cannot compete, and therefore we can say emphatically that the statement is a myth.
Note: The Agile Manifesto may be copied only in its entirety and so the line referenced above is included in the manifesto here:
The Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
You may also be interested in: