More Agile Than You
We’re in the middle of a pretty major home renovation project (kitchen, mudroom, bathroom). Our dining room has been turned into a temporary kitchen. Thankfully, it has everything you need as long as it’s not more than a sink, microwave, and hot plate. Three fifths of the family has been displaced from their normal bedrooms. Everything is chaotic. Add an all-encompassing thick coat of dust and grime and you get the picture.
But it gets worse.
To add insult to injury, I’ve concluded that our contractor is more Agile than most of us software-types. Yes, our General Contractor (GC) runs his job using Agile techniques that are effective, simple, and efficient. And I’ll bet he does not even know he’s Agile let alone read the manifesto. Consider the following.
- Architectural Blueprints vs. User Stories: Contractors provide a bid based on a loose specification namely the architectural blueprint. The architectural blue print includes all the big features including where the walls go, depth of the foundation, and where the large mechanical elements live (HVAC, electrical, plumbing). But the architectural drawing is largely devoid of finish and fit details such as exact specs around trim carpentry, and exact cabinetry. The Agile analogy is the user story. High-level functionality is mapped out without consideration to exactly how the pieces and parts will be fabricated. These fine points are addressed as the work progresses.
- Architectural Blueprints vs. Whiteboard User Design Sessions: So if the blueprint is the user story, how do the Home Owner (HO) and builder come to agreement on the details? When it’s time to finalize how the trim carpentry is implemented, the GC, the carpenter, and the HO hover around the work area and describe the overall vision for the space leading into a detailed discussion as to how specifically the work is to be done and how it will look. After a simple 5 minute dialog the carpenter has what she needs to knock out the work. The GC determines if the vision is in or out of scope. And the HO gets exactly what they want. The agile software analogy is the developer sitting with the user and listening to specific desires, and mocking up the solution on a whiteboard.
- Allowances vs. Iterations & Releases: When our GC bid on our job, there were certain things that he just could not estimate. A great example is appliances. The range of cost here is simply vast and is largely dependent on the tastes and pocket book size of the HO. Sidebar – did you know you could spend $15K on a refrigerator? So our contractor solves this problem by putting an allowance in his bid for appliances. If the HO goes over the allowance, it is understood up front that they will cover the overages. In the Agile world we have the concept of development iterations with fixed scope and duration. If development time needed to implement a story exceeds the allocated time, they are pushed into the next iteration, or simply dropped.
- Home Owner Feedback vs. Story Acceptance: Virtually everything that happens on the job is subject to scrutiny by the end user – the HO. At each stage the GC is checking with the HO that the job as implemented is acceptable. If it’s not, immediate rework steps are taken to correct the improperly implemented story.
- Fixing Errors vs. Rework: Invariably, mistakes are made. The GC reviews finished work on a daily. If there’s something that is not done to the HO’s liking or does not meet the GC’s quality standards it is noted and fixed, usually the same day. Because our GC uses high quality trades people, these mistakes have been very minor; quick and easy to fix. The flexibility and speed of the process far outweighs the costs associated with any rework. The key observation here is to build a team that you can rely on to make the right decisions without lots and lots of paperwork needed to specify every little build detail.
- Daily Meeting vs. Daily Stand Up Meeting: Every day the GC meets briefly in the morning with the trades people scheduled to work that day. Assignments are given and then people split up and get to work. The point is that it’s a daily occurrence – there are no detailed plans laid out days or weeks in advance. Of course there are high level plans (framing on week x, electrical on week y, etc.). Coordination is done essentially real time with a heavy reliance on the team’s construction expertise thereby negating the need for detailed instructions. The GC acts like a true agile manager, fostering communication, breaking down barriers, allowing his team of experts to do what they know how to do without lots of excess motion. Note also that often times the HO (user) is invited to the meeting to provide feedback, ask questions, and offer suggestions. Oh, and yes, the meeting is held standing up.
- Drawing On Walls vs. Working On Code: The architectural blueprint specified where the closet walls were located, but said nothing about what was in the closet in terms of shelves, closet rods, or drawers. When it was time to finish the inside of the closet, the GC called a design meeting and told us what he had in mind. Once the general concept was agreed to, he took a marker and a ruler and drew it out on the closet walls so we could feel what the finished product would be like. Then, the GC told the carpenter to go build it in the off-site cabinet shop. The carpenter turned the wall sketches into the precise measurements needed. I liken this to delivering working code over paper specs. We did not worry about exactly what was in the closet. Rather, we drew it out when the time was right. We signed off when we could see it on our walls.
So am I making it sound simpler than it is? Perhaps. Construction industry technology evolves at a much slower pace than the world of IT. Stable building codes exist that explain how work is to be implemented. Tradesmen (think carpentry, drywall, etc.) have time to become highly proficient at what they do because they have done it every day for years. So things are much less complex compared to the tangled web we weave in the IT world. Regardless, I’ve learned a thing or two from my GC about being Agile.
I welcome you comments.
Mike Brannan
