Managing a House Renovation as an Agile Software Project
Putting together a list of tasks for a house renovation project got me to think about managing the project using “agile” software development methodology. We were keeping detailed notes anyhow; why not try to be really systematic about it?
If you’ve contemplated buying and renovating residential real estate as a business these notes should give you some notion of what you’re in for. Of course every property is different; this was a relatively new (1982) town house. At first appearance you might have thought it needed nothing more than new carpet and paint, but you would have been wrong (and I knew that going in.)
Read the project notes here.
I didn’t do an exhaustive analysis, but reviewing the initial estimates and comparing with the changes, it seems our initial predictions were quite accurate compared to a typical software project. No surprise there – a lot was known up front and we had a lot of flexibility in terms of deadlines.
While the plan changed in a lot of details, the estimates for final amount of expenses and sales price were very accurate. The biggest variable we got to adjust was time; we took an extra five months to put the property on the market at a better time. This doesn’t invalidate our results but it does point to the fact that our strategy probably won’t scale well to a large operation.
It’s somewhat analogous to the problem of investing a large amount of money (think Warren Buffet.) The biggest growth opportunities reside in the smallest companies; but it’s not feasible to spend time on so many small companies which put together would comprise only a small part of a billionaire’s portfolio. Likewise, micro-managing a house flipping operation and holding onto many properties for unpredictable amounts of time would probably not pay off for a large developer.
What is an “Agile Methodology?”
As a developer I’ve learned to divide tasks into independant, small chunks. You may call these pieces “user stories” or “issues” or something else depending on your particular methodology. To organize these tasks some people use burn-down charts, some use Gant charts, some just work from a priority list and put together “sprints,”(blocks of time, often one or two weeks,) in which to get them done.
The formalization of the “Agile” methodology came about in the early 2000s in response to large software projects that project managers and developers felt were being run with a process-heavy management style. They felt the then current approach did not serve them or their customers well. These styles of software development, sometimes known as “Waterfall”, required a large amount of up-front estimation and did not do well when encountering changing requirements from customers. Problems that programmers knew about for months could not be addressed until they showed up in final testing by the QA testers or end users.
The Waterfall approach and Agile both result in defining and estimating work on small pieces of a project; but Agile has less overhead – fewer boxes to check – In those estimates. And the process explicitly makes room – even welcomes – insertion of new units of work and removal of work deemed no longer necessary. Waterfall on the other hand goes in one direction: Specifications -> Architecture -> Build -> Test and that cycle may take a long time with no allowances for changing course or prototyping up front.
Tracking the Townhouse Renovation
While a real estate project will be more predictable from the start than most software projects, I believe a lot of the changes in direction and disparities between estimates and the final costs get lost in the scramble to finish a project; it’s easy to lose track of just how on track or off the project went, especially if you still make money. So I wanted to be really meticulous and find out just how accurate my planning really was.
I decided that the simplest methodology would do: Create a set of story cards and assign estimates and put them in a preferred order. Then, I plan to pay attention to task scheduling / order of tasks and estimates on each task. So read the sections with headings as story cards with estimates for work and materials. After that everything on the card is follow up notes tracking how close we were to our estimates.
The list of tasks goes from preferred first task to last, but order doesn’t matter a lot in some cases. The larger headings serve to group tasks together where that makes sense, such as the kitchen or bathroom remodel. Often you have features that ideally get done before other features even when no features strictly depend on any other. I know from experience that a specific order of feature completion makes life easier, and so I’ve tried to group tasks according to what my experience tells me is best.
Each task has an initial date, story point estimate, material and labor estimates, followed by notes tracking the actual progress and cost.
This project is unusual in that the place we’re flipping is nearly identical to my own house, so I know it well, having made many changes to my own place. This ought to assist me in making accurate estimates, but as we know from software development, even when we think we know exactly what the requirements are, and we’ve done similar tasks and entire projects before, estimating accurately is difficult.
Two things contribute to bad estimates: Addition of new requirements (i.e. scope creep), and discovery of new information (initially poor specification / understanding of requirements.) I prefer calling the second problem “new information discovery” because sometimes the customer discovers they didn’t explain fully what they needed, but often the new information gets discovered by the developer; they thought an API would give them what they needed to complete the feature but (for example) a public API has disappeared or no longer allows free access. Both types of problems should be minimized on the current house project. I’ll be interested to see how wrong I am about that.
With traditional story cards points are used in place of time estimates: 1,2,3,5,8,13,… following the Fibonacci sequence, to capture the reality that any more specificity will not be any more accurate in the end. I’ve included story points in my estimates, something not done on non-software projects. Managers want to convert story points to dollars paid to developers and developer time allocated to features. The Fibonacci sequence is meant to discourage over-planning. I’ll be thinking about this as the project moves along.
Each initial story got notes added to it in place. New stories got added to the end of the list with dates when they were added.
See the project notes here.