Necessary and sufficient

One of the teams I work with is about midway through a project, and we're starting to take stock of what's gone well and what we've learnt that we could do better next time. (This kind of reflection is normal and healthy in an agile environment. It's when you don't have ideas on how to improve that you should start to worry.)

As often happens, the subject of requirements came up. Design is an extremely important part of the software process - it's the foundation upon which everything else is built. It's also the one which companies tend to struggle with most.

The real leap forward with the agile world is the idea that designs should be both necessary and minimally sufficient:

• Necessary means you have everything you need to start development. That means enough high-level information to estimate the entire project's backlog of tasks, and enough detailed information to get through the next sprint.
• Minimally sufficient means you have only what you need. For a task you don't expect to pick up until several weeks in the future, that means pencil sketches and storyboards over polished PSD designs, and loose descriptions over fine detail.

Waterfall models struggle because they enforce necessity without thinking about minimal sufficiency. You end up burning time creating detailed mockups of an admin panel for a program whose features and configuration options are yet to be defined. You'd think this would be trivially easy to avoid, but the lure of the "fully realised design we can take to a client" means a lot of companies fall into the trap of creating inappropriately detailed specifications upfront. (Often without need. Back in my consultancy days I'd quite happily sell things with a sketch on a whiteboard. People buy ideas, not gradient fills.)

Cowboy coders, on the other hand, are experts at the minimal sufficiency but struggle with the necessary. These are the places where projects are delayed for a month on short notice with howls of, "but nobody told me it needed an admin panel!" If anything, I'm being charitable with that picture; the worst kind of cowboy organisations can give you reams of unnecessary detail on one or two end-user screens of their application while critical details of architecture and function are shrouded in mystery.

In the perfect Agile world, you'd have both. Developers would end every pre-planning meeting thinking, "I have everything I need to start the next sprint and estimate the remainder of the project, and no more." Of course, in the real world this scenario rarely exists. But a good team would be thinking, "what did we not have that we needed, and what did we spend too much time on that we didn't need?" when it comes to the requirements they're working from.