I've noticed that developers and product managers alike are reluctant to write high quality specifications. In this blog post I argue that high quality specifications are still important and are not contradictory with an Agile way of working. I'll first go into why agile is great and then speculate why we've neglected the art of writing great specifications.
Every software starts with a vague idea of what it should do. Software development is turning this vague idea into a very precise description of its expected functionality. So precise in fact that this very precise description (aka. code) can be executed by computers.
Easier said than done. In broad strokes, there are 5 steps between a vague idea and a running software system:
- requirements
- design
- implementation
- testing
- deployment and maintenance
In a perfect world we would do each step only once because that's most efficient. We write down what we need, we design a system that can meet those needs, we implement this design, we test to make sure implementation is done correctly and we deploy. Unfortunately this is wishful thinking. We are not omniscient gods: we often don't know what we need and we often have no idea how we can design a system to meet those needs. So instead we mortals go ahead and start regardless. We get to our functioning software system incrementally. We develop a minimum viable product and then iterate until we have a minimum lovable product and beyond.
Surprisingly, we used to think we were godlike. In the early days of the digital age the most common development process was waterfall. It's a software development process were you proceed to the next step only when the current step is done. There is no going back. Just like a waterfall: water doesn't flow back up.
People started to get suspicious that this way of working didn't work when reports came out saying 70% of all IT projects ended up in failure.
So a bunch of smart people came up with the agile manifesto. The jist is: stop doing waterfall because you don't get enough feedback with the real world. Build software in a way that maximises feedback with the real world.
In hindsight it's pretty crazy we didn't get there faster.
To recap where we are: Agile is great and I love agile
Unfortunately the waterfall-to-agile revolution killed a great idea: well written specifications. Most software engineers don't like writing specifications. The stated reason is that writing good specifications isn't very agile. This is a confused reason.
Where is this confusion coming from?
I can't be certain but it looks like some people are making the following argument:
- Given that we tried to plan end-to-end and execute IT projects in one go
- Given that if we tried doing this we often ended up with a failed IT project
- Therefore we should do the opposite (i.e. we should not plan anything and expect to redo everything)
This is false. We should not do the opposite. We should do less of it!
To illustrate my point, take the famous cartoon below to illustrate what agile is all about.
To invent a car in an agile way first build a simple skateboard. Have people use it and provide feedback. Use this feedback to build a scooter... and so forth. During every step the user has a functional transportation device that he can test and give feedback on. Don't carefully plan all the steps because you need to consider the feedback at each step to plan the next step.
Now how should you execute a single step? Let's consider building a skateboard.
It would be wasteful to build a skateboard straight away. A good carpenter will first plan: draw the blueprints, measure the wood, decide which wood to use, and so on. Also, he wouldn't draw the blueprint on a napkin or just draw half of the skateboard. If he's a good craftsman he would take his time and make a detailed blueprint. Does this mean he will do a lot of planning? No because a skateboard is a simple transportation device so creating a detailed plan is not a lot of work.
To bring this metaphor back to software development: build a software system incrementally while keeping it usable as you go. While you do this don't be a sloppy craftsman: plan a given step carefully.
To summarise: Don't carefully plan all the steps but plan a given step carefully