We often think that the route to being a leaner organization is to do less, but we sometimes forget that the very tangible “less” we’ve created may not be the right solution for the organization. Take, for example, requirements documentation.
I was recently reviewing a requirements document that was a whopping 488 pages long. For those of you with the Agile bent that I don’t have, your immediate reaction might be to replace it with user stories and iterations. In fact, this project, by Boehm’s standards laid out in Balancing Agility and Discipline, would not be well suited for Agile at all. Despite the document’s unwieldy size, the requirements were extremely well known and unlikely to mutate much over the course of the project. The team size was relatively large. The business would not be in a position to make decisions rapidly because the requirements were driven by an external client. The team skill tended towards average performers. Everything about this project said plan driven was the right choice.
So the team had done what it thought was the leanest thing possible. Rather than producing many documents up front, it produced one monolithic monster. The argument was, this is leaner because this document serves all readers. As we explored the document with the various customers we discovered something interesting. The developers hated the document. It didn’t suit their needs. The customers hated the document. They didn’t feel comfortable signing off on all the technical detail that had gotten into it. We couldn’t find anyone who liked the format of the document.
In some senses, a single document appeared to be the leanest thing possible to do. The tangible “we’ll write less if we just do one document” was undone by the fact that the product now served nobody particularly well. In essence, we lost sight of the fact that translating what the customer says to us into usable requirements is value added work and therefore shouldn’t be what we’re targeting to lean out at first. Sure, there may be optimizations to the value added work, but there was much more non-value added work going on as a result of this choice.
Since the document suited nobody well, everyone was creating interim documents to re-translate the parts they needed into a structure that would be usable for them. That’s clear unnecessary processing – redoing the work that someone else did.
In this case, more documents would have been better. Documents which separated out what the developers need to know to create the code and what operations folks need to know to support the client and more. With those in hand, good translations of the requirements would lead to good code and avoid the significant rework the team was experiencing just trying to figure out which parts of the document applied to them.
Whether less is really more depends on what you’re getting less of. Less clarity in exchange for less documentation? That’s not the direction we want to head in.