NOTE: I originally posted this at my old company's website in 2010, but as that blog has been taken down, I thought I'd resurrect this post here.
I was chatting to my wife the other evening and started to discuss reading lists. I wondered aloud how many years I had to live (30? 40? 50?), and was thinking about how many more books I would be able to read in that time. A book a week for 40 years would mean I could read about 2,000 more books in my lifetime.
A quick search netted this wonderful article from the Guardian Online: 1000 novels everyone must read, so that was a great starting point.
I thought about how the task of building a reading list would look like if I approached the task like a software project.
The Waterfall Approach
- Use the Guardian article, Amazon reviews and recommendations to create the complete list of 2,000 books I am going to read.
- Prioritize the list.
- Buy all of the books in the list.
- Work through the list, reading the books in order.
Now deciding ahead of time what you are going to read for the next forty years is clearly ludicrous, as so much will change in that time. My interests and priorities will change. The world will change. The available books will change. Even the cost and technologies for delivering books will change. All of this means that making decisions now about events far in the future is a pointless and expensive exercise, as most of the books in the list would go unread.
The Agile Approach
- Decide how far ahead you want to plan – far enough to avoid running out of books to read, but not so far as to make change costly.
- Make a much shorter list of books to read.
- Prioritize the list.
- Buy the first few books in the list.
- Keep updating this shortlist as your interests change and new books are published.
This approach has the advantage of having less overhead to maintain (a few books instead of 2,000), cheaper (less cost and inventory up front) and more flexibility (the list can change more easily over time).
Don’t plan in detail too far ahead, but be prepared for change
On many software projects, we are asked to plan iterations and projects months and even years into the future. This is as foolish as planning your reading list far in advance.
Just as most of the 2,000 books in our waterfall reading list would probably go unread, by the time we get to the end of a long software project, we know so much more about what we need to do and so much has changed that a lot of the later detailed planning has to be completely redone as it is worthless and out of date.
I’m not saying it’s worthless to have high level plans – in fact this is really important. We need to know if certain things have to be lined up ahead of time (for example communicating release plans and outages, getting users trained, making sure other teams are ready for the downstream affects of our changes) and we need to know when the last responsible moment to make those decisions will be.
We also often need to provide our customers with a ballpark idea of the costs and schedule of a project (is it a week? a month? a year?) before the project begins, but we shouldn’t treat this as being cast in stone. The plan has to be flexible enough to change with the landscape. The cost and schedule estimates need to be improved and updated as time goes on, as uncertainties about the project are reduced (I’ll write more about this in another blog post).
While a high level plan is a good thing, what is foolish is detailed design, task planning, assignment and estimating for items far in the future of a project. While this may give the illusion of control and predictability, it is just that: an illusion. In fact it’s harmful to have that level of detail because the more design artifacts and task details that need to change in a project, the higher the overhead of maintaining these details and the more rigid the project will become.
Just like keeping your reading list short and easy to change, you should keep your iterations and detailed project plan short. This will give you a flexible plan that can adapt as the project progresses.
For more ideas about shrinking your iterations, see my recent blog post on the topic.