Scrum and flipping a house

[Natalya Whitaker]

Has anyone read the book "Scrum, the art of doing twice the work in half the time"? And then applied it to flipping? In the book he tells a story of how he hired contractors to remodel his house and they used Scrum. If I'm remembering correctly, they did it in three months on budget. His neighbor was very impressed so he hired the same crew to do roughly the same job (his house was almost exactly the same as the other guys). It took them six months and they went way over budget. Same crew, only difference was they didn't use scrum. So far all the deals I've done I've fixed up myself, but I would like to start using contractors and was contemplating the idea of "Scrum" and the "great groups" mentality to get the job done. Any thoughts?

[J Scott]

As someone who has used Scrum (as well as pretty much every Agile development technique) for some of the biggest product companies in the world (I managed a lot of teams using Scrum at Microsoft) and as someone who has flipped a couple hundred houses, this makes absolutely no sense to me.

The big advantage to Scrum in a technical development environment is that it allows the customer to change requirements anytime ("requirements volatility"), and because the development is being done in an iterative style (each defined time period you have a working unit or sub-unit that can be demonstrated), each defined time period you theoretically have a working product that can be released to the customer.

While there are some advantages to that methodology when developing software, I don't see any advantages when rehabbing a house.  First, there is no reason to change requirements mid-project -- if you are, it simply means you didn't do a good job of planning upfront.  While software requirements may change throughout a long project cycle as market data is discovered, customer feedback is solicited, the competitive landscape changes, etc., I can't think of many reasons why the requirements for a house flip should ever change mid-flip.  Second, unless you plan to do inspections each week or potentially sell the property mid-rehab, I see no reason that a rehab project should be planned such that there are multiple points where the project is in a "releasable" form.

Agile/Scrum introduces a LOT of overhead to the development process.  Some development teams consider this overhead to be worthwhile simply because it gives them a competitive advantage in their specific market and with their specific customers.  But, while using a Scrum-like process for rehabbing would introduce the same overhead, I can't think of many advantages it would bring.

In addition, with Scrum, your entire team needs to meet each morning to review progress, product backlog, etc.  Do you think all your contractors are going to show up on-site each morning even if they don't have work on-site that day?  For example, your electrician might work 10 out of 90 days on a large rehab, but if you were going to implement a Scrum model, the electrician would be required to show up EVERY DAY at the daily Scrum meetings (good luck with that!).

Of course, there are analogies between Scrum and a contractor team -- the "Product Owner" is the house owner, the "Scrum Master" is the GC or project manager and the "Development Team" is the contractors -- and the planning and communication requirements for Scrum have some general best practices that apply in many other areas (including rehabbing), but the analogy doesn't extend much past that.

The overhead associated with having Scrum Planning Sessions, Daily Scrums, Sprint Reviews, Maintaining Product Backlogs, etc. is just ridiculous in any typical house rehab scenario, and unless you want to triple the time it takes to rehab (and likely triple the cost of your contractors based on the time they'll spend on-site), I wouldn't recommend trying it.

Now, the person you're getting this information from most likely took the Scrum model, and pulled about 5% of that model out and said, "I'm going to apply this VERY SMALL subset of Scrum techniques to flipping to make my contractors more effective."  That is NOT Scrum; in fact, most development teams who use Scrum would say it's not Scrum even if you did 99% of the model.  Scrum is almost cult-like for many development teams that use it, and taking one or two best practices out of the model is NOT the same as using the model.

Lastly, I'll say that if the person you got this information from told you that they were able to bring the schedule in and stay on budget because of Scrum, he's probably lying to you.  Scrum is notorious for pushing out schedules and going over budget; the goal of Scrum is typically to the benefit of the customer and the company in terms of flexibility and requirements management; it's typically not used for efficiency or budget management (in my real-world experience -- though the model would say that it is).