Is there such thing as an "Agile" kitchen remodel?
What homebuilders can learn from software developers, and vice versa
Disclaimer
Upon re-reading what I’ve written, this post might skew more judgmental than curious. That’s not my intent. I’m enjoying this process. Life is good, and I am not in search of sympathy, please. I want to assure everyone that I still believe, in line with the prime directive often invoked in retrospectives, that everyone is doing their best given the skills and circumstances.
“Tear down this wall”
We started remodeling our kitchen on Monday. We redid the kitchen ourselves in our first house (we were younger and more foolhardy then, which is saying something), but we called in pros this time.
(Side note: I saw that our first house sold again not too long ago. I had a very emotional response to this fact. On the one hand, I was proud that the owners kept basically all our handiwork from when we redid that house [and we redid A LOT; ask me about it some time]. On the other hand, I felt a little frustrated that they reaped the benefits of a hot market and did so little to add real value. “I redid that kitchen! I custom-built those closets to be sized for Jenna and me! I tiled those bathrooms! I even made that tie rack!” But I know that my response is not logical. Anyway, I digress…)
We’re less than a week in, and change orders and scope creep have already arrived. Things will cost more because they have to move plumbing. We’re also identifying some stuff we might want to do while the walls are open. It’s both a bit expected and a bit of a mess.
Many people hearing this story might say, “Well, what did you expect? It’s a home improvement project. They’re all like this.”
I think we can expect more. I don’t think they all have to be this way.
And this got me thinking: What would “Agile” kitchen remodeling look like?
Back up: What is Agile?
If you’re not familiar with Agile (my knowledge was fairly limited before I joined Thoughtworks), its core values are:
“Individuals and interactions over processes and tools”
“Working software over comprehensive documentation”
“Customer collaboration over contract negotiation”
“Responding to change over following a plan”
I think the Agile Manifesto and its principles are poetic, philosophical, and practical all at once. Big fan.
I also see a lot of people get caught up in doing Agile (the ceremonies, etc.) rather than being Agile (adopting an adaptable mindset). I think this is an important distinction. For example, most of these Agile values are compatible with construction projects.
Stop me if you’ve heard this before
Big software projects and big construction projects have at least one thing in common: They are often late and over budget.
Why? Uncertainty and changes in scope. You open up a wall and you find plumbing that you need to move. Or you talk to more customers (or the same customers) and they (or you) realize that you didn’t get all the requirements the first time.
Humans are terrible at predicting the future. It’s just the way it is.
Prioritizing isn’t easy, but it is easier to revisit the work in a backlog compared to a remodeling wish list. The next sprint is at most only two weeks away. And besides, throwing more money (i.e., more people) at a problem in an attempt to get more done (the way you might in a remodeling project) often doesn’t speed up software projects (and might actually slow them down).
But remodeling doesn’t work in sprints. Which makes sense. No one wants their kitchen to look like the photos above every two weeks. That would be extraordinarily disruptive and wasteful.
But that doesn’t mean construction can’t learn a thing or two from software development (and vice versa).
What construction can learn from software development
“Well the contract says…”
Just yesterday morning I was discussing 3-way switches with the project manager (3-way switches refer to lights you can turn off and on in two different locations).
Him: (Handing me a change order that explains the additional electrical costs) 3-way switches were not in the contract scope, so there is an additional cost.
Me: Shame on me for not insisting that that be part of the contract. But also, I took the owner at his word when he said that one of the company’s distinguishing features was thinking through and including all the little details. Like, say, 3-way switches.
I want to be clear. The project manager is a very good and reasonable person. He is trying to run a profitable project and doesn’t want to eat into his margins. We are working with a capable and competent company. I totally get that things happen.
I’d also like to think I’m also a reasonable person making reasonable requests. Even if they’re not backed by the full force of a contract (again, shame on me). This is a case where a more Agile remodel (“customer collaboration over contract negotiation”) would make for a happier customer. And it might be slightly less profitable for the company in the short term, but it would be more profitable long-term if we have them do more work for us in the future (possible, but unlikely).
“We won’t know until we open up the walls”
Of course you won’t. The same is true for developers starting on a very uncertain bit of work. That’s why sprints typically have time dedicated to analysis for future stories so they’re ready to be worked on later.
Not to get all autobiographical again, but I’ll return to the disagreement with the project manager. We’re opening up a wall that has plumbing and electricity in it. They are charging us more to move these things. Makes some sense, except that I pointed out that these things were in the wall before we started (you can see from the basement and the wall itself). This is the purpose of doing analysis in advance. Of course things might be more complicated when the walls come down (there were unexpectedly two lines that came together into one). Totally get it. That said, careful analysis still helps.
Cross-dysfunctional teams
We intentionally chose a design-build firm for this project because they typically have more of an end-to-end view (as compared with having one company design and another one build). This kind of company is about as close as you can get in construction to a product manager, someone who really owns whole project lifecycle and ultimate outcome. But even design-build firms ultimately separate work by trade at some point. Carpenters on Tuesday, plumbers on Wednesday, electrical on Thursday, and so on.
As an exercise, try this: walk through your neighborhood and look for houses that are under construction (if you’re obsessed like me, you might already do this). Look for vans or trucks parked nearby that advertise services across multiple unrelated trades (electrical and drywall or plumbing and carpentry). Sure, you might find a company that does electrical-plumbing-HVAC or painting-drywall, but I doubt you’ll find any that work in truly disparate trades (i.e., that are both broad and deep).
And yet, having both kinds of skills on the same team would be super helpful. The person who cuts open the drywall to run new electrical wires can have her teammate patch the hole more quickly and easily. As an example, we had an electrician put recessed lighting in our living room, leaving a bunch of holes in our ceiling and walls. Then we paid a drywall company to patch those holes. It would have been nice to coordinate with a single company. But general contractors exist to fill this void, especially for big projects. Agile software development makes someone like a product manager responsible for the entire outcome (e.g., a ceiling with lights and without holes).
What software can learn from construction
But not to beat up on the construction industry too much. Software development is far from perfect. I also think there are a few things that software development can learn from home remodeling projects, too.
Build it like it will last 100 years
Our house turns 100 years old in a couple of years. And with any luck it will stand for another 100 after that. But there is no such thing as a 100 year-old computer or programming language. Technology evolves quickly.
Still, good developers take pride in crafting code that is elegant and durable (and has less debt). I would posit that building durably isn’t just for physical construction, even if its lifespan is likely much shorter.
Estimate pessimistically
Remodeling houses is difficult. It’s tough to figure out which walls conceal pipes or what someone was thinking when they did a project 20 or 100 years ago. And forget about documentation. Building software often means remodeling or putting an addition on someone else’s work. Getting good at empathizing with previous generations of builders (physical or digital) helps avoid frustration and achieve a better outcome.
Know when to gut it
Sometimes taking down all the plaster or drywall allows you to see the structure and the options more clearly. Sometimes refactoring or scrapping a lot of code, even if it feels like demolition, is a good first step toward rebuilding better.
Beware of snowballs
“If we replace this pipe, then we’ll have to cut out the ceiling and this part of the wall, which means ripping out the tile and redoing it, and then we might as well remodel the whole bathroom.” My friend is going through something exactly like this right now. Not fun. Went in expecting a simple bathtub replacement and ended up with a new bathroom.
In Agile software development, it is common to break down and estimate work with user stories and story point estimates. It’s helpful to be specific and user-focused about what needs to be done, and it’s also important to account for the ripple effects of the changes that work will kick off. Analyzing the knock-on effects as part of estimation can help teams appropriately manage their workload.
Hammering it home
There are a lot of reasons why remodeling a house is not like building software. I get it. But I also think, to borrow a lesson from a book called Range (turns out he also has a Substack:
) about the value of generalists, a lot of hard problems in one domain are solved by people who are good at something completely different. So here’s to better building, whether in software or homes.