My builders are agile

Analogies are always good when demonstrating the benefits of a system, a tool or a process. People, often those on the fringes, need to see or hear why there is a benefit to said system/ tool/ process as a single voice is often lost in the discussion.

So this post covers something close to home, in fact it is my home. As a UX advocate building digital experiences in an agile way, I was intrigued to how my builders would go about their job as they promised a quick build. Typically I knew tradesman work independently in what we know as “waterfall” fashion so were my builders different? Were they agile?

Background

Early days on site

The building task at hand was to combine what was 2 spaces (kitchen and dining room) that occupied a one story flat roof extension. As well as knocking through solid walls they also had to remove the flat roof for a pitched roof. New kitchen space would be created and in turn gas, electric and water would be moved.

Knowing the user

I had been recommend the builders and had been impressed with their focus on the user (some say customer) – Me. Now I’m sure all tradesmen say the customer is king; but listen to what they say. Do they say “we” or “i” or do they say “you”. All our pre-chats focused on “you”; “creating a space you will enjoy”, “what fits in with you”… For tradesman, recommendations are what keeps the work coming in and to do that you need happy customers. You only get happy customer if you address their needs rather than create developments solely matching an architects drawings.

Outcomes not outputs

So what was the purpose of the building work? Was it to build a new kitchen or was it to create a better experience for those living in the house. The latter (an outcome) is what my builders wanted to create. They wanted to build something to address my needs, a communal space for the family to sit together and enjoy, rather than just bricks and mortar.

Standup/ Sprint Planning

This is when I really noticed the difference. On day one all the tradesman were in the room, the bricklayers, the electrician, the plasterer, the gas engineer, the plumber, the kitchen fitter… Collectively they went through designs, allowing for openness and critique; what would work, what might not. Together they agreed the objective and addressed areas to focus on for the immediate period. Every day after that, those involved always had a stand-up (including mandatory coffee cups and bacon rolls) discussing what they had done, what they are going to do.

Now that isn’t normally the case with this type of work. Often the plasterer comes after the bricklayer, the plumber comes after that, then the electrician. The problem here is that decisions get made out of context. You soon find that having the plug socket or sink tap in a certain place now can’t happen because of the wiring or brickwork that preceded that person. The customer then has to accept this decision and move on. In a home that’s pretty critical. Taps and plugs affect appliance location so I could end up with my dishwasher located away from the sink where I actually need it to be. I’m sure you have all been to a house thinking why is the cooker there? Now you know.

Co-design

Sketch on the wall

Yes we had architect plans and kitchen plans; but it’s no good these being on paper (or email) and not shared. All our plans were nailed to walls or scribbled on the walls. In some cases lines were put on the walls to determine the actual heights/ lengths of kitchen units as paper alone couldn’t demonstrate real physical size. The scribbles were often a collaboration, two or more people (at times with the user) putting ideas on the table. Scribbles/ sketches are great at showing the possibilities to gain instant validation. It digital terms they are cheap too (no hours building code to demonstrate a concept); but in builder terms they are extremely cheap. Imagine putting a window in place and only then deciding it’s too small and needs swapping!

Communication

Builders like to talk (sing too) but it was the openness and constant conversation between them and the user that worked for us. Never did a day end with us returning to the house without a latest update (in person or phone). Communication is two-way, so talking is equally important as listening. We needed to make sure deliveries arrived when expected or at least when they made sense. For example, delivery of kitchen units needs a lot of space. Space would only be ready once the internal scaffolding was removed. On the face of it, these are small conversations, but the key is they are consistent and constant.

Change

Kitchen in mid build

A true benefit to agile is adapting to change. Waterfall thinking makes adapting to a change pretty hard. If you do change, then plans restart again and draw out the process even more. In building terms a change could affect when you can plaster a wall. This could be expensive in terms or time and money as they then get delayed, as then does the electrician, the kitchen fitter and so on. As a client you then lose your slot and have to wait till they can come back on site.

We had a pretty big change during the build. When we knocked the adjoining walls down, we realised the floor heights were different by over 10cms. Now as we expected to walk between the two areas we didn’t want a step between the two, more so we wanted it flat. Again like at the start, this was raised with all concerned, let’s call it a mid-sprint review, and openly discussed. We needed level flooring but what was the impact on the plumbers or gas engineers? For them knowing in advance helped them prepare when they were onsite (bringing more pipework for example).

 The outcome (the benefits)

Finished work

So firstly; we got what we needed – an amazing living space we enjoy and utilise (unlike the old kitchen). Builders have a happy client and no doubt more work will come their way.

Switching this to a digital comparison. Building for user (customer) needs is crucial when building successful experiences. Like tradesman you’re not going to get far with poor experiences. Plenty organisations will fill the gap you leave.

In terms of time, in total the work took 2 weeks, with most of the structural work completed in 2 days!!! For the user this was great, with minimal time spent without key appliances. For the builder equally great, as it’s more time for more jobs.

In digital land, building in small chunks, validating at each step in the long run is very effective. Whilst team members (aka builders) won’t necessarily build quicker, what they do build is concurrent with the other members thus upping the velocity. As it is validated with the user it also means minimal (if any) re-work or “phase 2” work is needed. 

Quality. With daily conversations and onsite walkthoughs I had early sight of developments and could feedback instantly. This in turn could then be fed back to the tradesmen. I can honestly say there isn’t one thing out of place or not thought out. 

Shipping code in a timely manner is often at the compromise of quality. Whilst code quality is not really visible only when it’s revisited do you see the mess within when a project is badly managed. Technical debt is often accrued which means it’s harder and more costly to iterate time after time hence why you see (or use) sites with a pretty shocking user experience. Shipping code in iterations involving code reviews, code pairing and retrospectives means that quality is at the forefront of decisions. Aligning that with build principles means you can build on quality. Code that works, code that can be re-utilised, code that can be built upon down the line. 

Empowered team. Now whilst this doesn’t affect me (the user) directly, exposing the team to agile working will and does make them better. For the builders on the spot problem solving to solve floor heights gave some of the newer team member’s exposure to something they had never done before. 

The same goes for digital. Creating an environment of empowerment and continuous learning only improves the team, how they build and what they build.

Conclusion

The step to agile (from waterfall) is something clients, stakeholders and teams all need to embrace for it to work. The benefits (above) are pretty clear to see, but sometimes the perceived negatives can hold you back. Let’s take a look at some:

1. Lack of a plan is often mentioned. As per above agile has a plan, in fact it has more hours spent on planning than waterfall as plans are discussed and changed every day.
2. Unknown time to complete is another one. Yes my builder never said it would be ready on day X. But this was delivered much quicker than those other builders who estimated this work and gave me a day.
3. Finally documentation. The obsession with locked down documentation and moving away from this literally can bring down agile in a second. Again, as per above my building work is littered with documentation, the sketches, the lines, the doodles on kitchen plans. Agile documentation is rich, far richer than an architectural plan or a specification document.

So please share this true analogy and let me know of other non-digital agile analogies.

NB. Our “agile” builders are Mersey Developments.