Do One Pagers Suck?
Prefer to watch this as a video? Click here.
How many times have you had an interesting chat with someone, and they’ve finished up by saying ‘Sounds great, could you put together a one pager on it for me?’. Or perhaps someone senior has complained that there are just too many documents flying round your organisation, so from now on, all reports have to fit onto a single page.
A one pager then is an increasingly common document in the modern business world. A document constrained by its very name to take up no more than one side of one sheet of A4 paper (or the pdf equivalent). They’re used to cover everything from proposals on work to be done, updates on how projects are going and reports on the final project results.
The thing is though, I’m no great fan of the cult of one-pagers in an agile context, for a number of good reasons.
First, if you’re not careful, one-pagers start to fetishise the output. What starts as a means of simplifying communication within a project starts to become an output of the project itself. People start comparing the quality of one-pagers produced by different people, praising those they like, correcting those they don’t, and promoting the idea that one-pagers are a valuable product in and of themselves. Of course, line two of the agile manifesto states we prioritise ‘working software over comprehensive documentation’, so once you start down the road of seeing one-pagers as a valid and necessary output of the project, then you risk prioritising documentation over things that provide actual value to customers.
There’s also a risk that once one-pagers become seen as a valid and necessary project output, then you start thinking the problem they were designed to fix is fixed just because one pagers are being produced. Like we talk about here, there’s a difference between identifying things and actually absorbing or learning from them. If all of your knowledge and learning gets put into one page formats, it’s very easy to file them away and ignore them, rather than really discuss, unpick and learn from them.
A bigger problem I have with one-pagers though is the way they risk breaking another part of the agile manifesto; ‘responding to change over following a plan’. If you fix the format of your documents at one page, that’s like pre-planning the format your documents will take, and following that plan, even if requirements or circumstances change. How can you know at any given time which document format will best suit your requirements in the future. The start of any project is the time when you know least about its timescales, costs and deliverables, so to fix the documentation format then, or at any time really, is to risk becoming less adaptable to change than agile requires.
I also dislike the cult of one-pagers from a collaboration point of view. If you want to collaborate with people, there will be a lot you want to discuss with them. You may have lots of different points to cover, lots of ideas you want to share, previous learnings to draw on and much more besides. How are you meant to fit all of that into one page? To my mind, if you’re insisting people only send you one page documents, then you’re saying you don’t really want to collaborate with them, you just want to know what they’re up to. There’s nothing wrong of course with wanting to know what people are up to if it’s done in the spirit of collaboration, but too often it’s done in the spirit of micro-management and control, checking people are doing things the way you want them to be done, and that they’re sticking to the agreed plan. This of course risks breaking principle five of the agile manifesto, that people in your project team are to be trusted to get the job done.
Now of course fans of one-pagers may be protesting by now that they’re an essential part of their business, as they just haven’t got time to be reading and digesting long documents. They need each report to be short, punchy and to the point, so they can read it in the five minutes they have spare as they dash from meeting to meeting. This may be true, and I’m certainly no fan of making documents any longer than they need to be, just for the sake of it, but it also misses the point.
Agile is meant to be about working at a sustainable pace, so if you really haven’t got time to read more than a page on something, then are you really working at a sustainable pace? Is your workload not only unsustainable, but also having real impacts on your ability to collaborate with other, to trust them to get the job done, to be flexible and respond to change without having every hour of your day planned and diarised weeks in advance? Honestly, if you haven’t time to read more than a page, it’s likely a sign you’re not working at the sustainable pace agile requires.
On top of this, you’re also making other people’s work lives less sustainable too. There’s a great quote from Samuel Johnson, or Mark Twain, or Blaise Pascal, where they apologise for having sent someone a long letter, as they hadn’t got time to write a short one. Condensing everything down into one page takes far longer than just writing down ideas in full as they come to you, or setting out all of the different interesting results you’ve found. In an attempt to reduce the amount of documentation going around a project, you unwittingly increase the amount of time your organisation spends producing documentation, rather than doing things that deliver value to the customer or the organisation itself.
So let me say again, I’m not inherently opposed to the idea of writing a one page document for someone. Sometimes documents will just need a single page, and documents should certainly never be any longer than they need to be. What I do advise against though is making one-pagers a thing in your organisation, a format that must be followed at all times, regardless of the context, and without looking at the underlying problems that are making one page documents seem to appealing in the first place.