Is Construction Agile?
In my last post about that buzzword ‘agile’, I introduced you to its history, and the twelve principles that underpin Agile Software Development. I like these tenets; they make it easier to get to grips with the idea of project agility. However, just blindly following the principles is, ironically, not particularly Agile.
So for this post I want to take one step backwards and look at the manifesto itself, one line at a time; from the perspective of a civil engineer:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Anyone who has sat through a company induction and been pointlessly preached this year’s company virtues by an over enthusiastic HR rep knows that successful change comes from within. However, one of the things that worries me the most about the changes I’m seeing in the industry is that a lot of them are externally driven. BIM has been mandated to us, as were the Eurocodes and even the CDM regulations, while technology is making a spirited effort to disrupt us. I put it to you that we don’t do much to uncover better ways of delivering structures- or help others do so.
Individuals and interactions over processes and tools
When you consider that the authors of this manifesto all spend their jobs writing process driven tools for people, this seems an odd one. However they realised that the best way to deliver projects was to enable individuals and ease interactions. I worry that BIM is pretty much the ultimate in process and tools over individuals and interaction; focusing much more on teaching people to use software and follow document control processes. As a contrast, some of the most agile software houses I know just make sure everyone in the project is co-located and then use massive white boards and post-it notes…
Working software over comprehensive documentation
Just a reminder, but you know the most important thing we need to deliver? This one has an oddly specific meaning for software, though- and I’ll try and make a direct translation. A good structure should be unsurprising, it should follow all the conventions that would allow the next engineer to simply determine how it works by looking. It should be obvious how it is maintained, and where the bits that need replacing are; it simply shouldn’t put people at risk. Most of our efforts in documentation are to cover this shortfall- in my experience there isn’t much focus on elegant design; just solving the problem.
Customer collaboration over contract negotiation
The Agile manifesto wasn’t really written by people who had to work across multiple teams, so I’ll extend this to the way we work with the other disciplines. There has been a lot of focus on trying to get us to collaborate. We’re really bad at it. These days I think it has a lot to do with our narrowing project margins and the risk the levels of trust true collaboration needs are hard to bare. As such, we’ve somewhat confusingly started to force collaboration through our contract negotiation. However, in the best agile sense this means really folding the customer into the project; getting constant feedback– which is something I’ve never seen, at least.
Responding to change over following a plan
Construction is the master of the waterfall method. If we didn’t invent it, then we certainly made it ours. The problem, of course, is that it’s hard to respond to change. Our love of the waterfall methodology stems from the fact that most construction suits this process; changing a massive physical object is expensive. However at the design stages it’s not atypical to see engineers across all disciplines resisting change. This is normally an artifact of both the ‘pain of change’ and the way we price for jobs. If you’ve set out a lump sum then it’s in your interest to keep the system as static as possible, especially if the design tools you have make even seemingly small changes relatively expensive to make.
That is, while there is value in the items on the right, we value the items on the left more.
From my experience, at least, that construction tends to value the items on the right more than the left is a sign that it is far from Agile. And while I haven’t really discussed the question, “should construction be agile” (that’s for another day), I will make the hypothesis now; that engineering would benefit from valuing the items on the left a little more, at least.