According to David Thomas, we went from following principles of an agile manifesto to doing Agile™ (just google image search “agile development cycle”). Why did agile switch from being an adjective to being a noun? And how can we change our way of thinking so that we continue to build great software, without terms like “Agile” dragging us down?
David Thomas offers up a reason: it’s because it’s easier to package and sell Agile™ than it is to explain the ideals behind the methodology. “We code with agility” doesn’t have the same ring to it, and businesses can’t commit large amounts of time and resources to a project without good clarity on how the project is structured. It’s certainly true that projects with no structure will fail, and we’ve built guard-rails into our own software development processes to provide that structure. But sometimes when a process is too fully fleshed out, it leads to an inability to adapt and improvize when new information arrives. The process becomes calcified, and can’t react to change. Leaving a little bit of wiggle room can allow agile to work its magic.
Why we build automation, not products
But there’s another reason why we’ve strayed from doing things with agility and towards Agile™.
As developers, we think that we’re in the business of building products, when really, we were building automation. The model T was produced with an assembly line, a product of automation. A good piece of software, on the other hand, is not a product of automation. It is automation.
It’s crucial that we start re-thinking what we do in terms of building automation, not building products. Because a lot of the principles that work when you’re building a product (operational excellence, quality, speed, and low inventory) end up not working well when you’re building automation.
(Mis)treating an agile process as a product
Once you start thinking of software development as building products, the natural next step, having been conditioned by industrialism and modernity, is to try to make the process of building software as reliable, fast, and of as uniform quality as possible. What we are looking for, therefore, is Process as a Product. We want to treat our development methodology like a widget that any factory can produce.
But what if Process as a Product isn’t something that lends itself to being mechanized, and instead requires healthy doses of creativity and human agency? What if writing software is less like building a car and more like conducting an orchestra?
The pieces of the machine of software development are people, and people are not machines.
Of course, this is not a new thought (industrial economy vs information economy), and furthermore there is a cottage industry of products trying to automate the process of writing software. Until they are successful, we have to deal with the human parts of our assembly line.
We must stare directly into the cold hard reality that the “parts” of our machine are humans.
Also, PKC is hiring!