Twice this year I have visited companies which want to try a more Agile way of working but who have requirements coming of their ears. I’m talking hundreds of pages of requirements. Sometimes as use cases and scenarios. Sometimes as big meat documents written by expensive consultants and bearing names like “Requirements Specification” or “Business Design.”
Its hard to argue with such requirements documents, in part because its hard to read them and understand what they are about. The thing they have in common is a level of detail. They go into great detail on what needs doing and how you might go about doing it.
Its not the first time I’ve seen such documents. I’ve been on similar projects before. One variation is a project I saw last year were the documents were not requirements documents but strategy documents. Several big name consultancies had been into this (media) company and do strategic work around a new product. Lots of presentations, lots of SWOT analysis and so on.
What all these documents have in common, apart from being expensive, is that they are worse than useless. They give the impression that things are know but they aren’t know. They knowledge walked out the door, what you have is a snapshot of someone’s understanding. But its a snapshot that nobody can really take in because its so big. And it is a snapshot that is rapidly aging.
As I’ve said before: the bigger a document the less likely it is to be read, and if it is read, then the bigger it is the less that will be remembered of it.
To which we might add: the bigger the document is the more there is to go out of date.
Yet because these documents exist people feel compelled to use them. They may even be mandated to use them. They don’t feel they can say to their boss: this was a useful learning exercise, no we will do it for real. So we then embark on a process that try to use documents which only get in the way.
Having someone investigate requirements or strategy can be useful. But think of it as a learning and feasibility exercise. And above all: don’t let that person leave the project.
At best these documents are historical reference source; as worst they are an obstruction.
Set a clear goal for the work and work out what you need to do to meet it. As Tom Gilb says, this should fit on one page of A4.
As you work towards this goal you will uncover requirements. You might want to note them down but remember there is no point in running far ahead of the development team.
Once you have something up and running - even in demo - what people think they want will change. So start small, get something working and get a team that delivers.
Just say No to big requirements documents. Say Yes to short, concise, goal to aim at.
Allan, agree on the big binder specs. Often hard to read, rarely a joy. By the way, not all humans are created equal when it comes to good writing.
ReplyDeleteI have a problem with a "no documentation" policy, however. Especially in large organizations there are regulatory/legal reasons for documenting - or even more importantly, signing off - requirements. This does not away with the fact that they are, to a varying degree, discovered/evolved rather than captured/determined. But an answer I have so far not seen from agile folks is how to deal with situations where more than just code needs to be available as documentation. I'd regard this mostly an engineering problem (model-driven development comes to mind), but I fear that we fool ourselves if we believe that ex-post documentation is better than ex-ante. Bad writing remain bad writing, and thick binders remain thick binders, no matter when produced. It may even get worse, however, through the use of agility because the convergence process is so elusive. What to do?
Point of clarification: I'm not arguing for "No Documentation."
ReplyDeleteBetween nothing and too much there is an awful lot.
And more explanation requires more time than I have right now.