Recently, during a conversation on software development “methodologies” (just the word “methodology” makes me cringe because it’s a needlessly convoluted and complicated notion) one of the participants said something along the lines of “‘Agile’ isn’t for everyone. Most people just aren’t cut out for doing software development that way.“.
I strongly contest that notion. ‘Agile’ has become some bullshit bingo term that’s slung around in order to perpetuate precisely those misconceptions the Agile Manifesto intended to upend. ‘Agile’ unfortunately is often seen as YAMMSP (Yet-Another-Management-Method-for-Software-Production), an improvement on but still an extension of the Taylorist illusion that software can be produced in an industrial, deterministic and predictable manner.
In a recent article Jan Ambroziewicz of 10Clouds argues that “being agile” isn’t about methods (or *shiver* methodologies) but about the shared values, the philosophy and the attitude of the people involved. Agility is a personal trait that he summarises as:
“Agility as a part of a strategy means two things to me: First: be reasonable, not radical. Second: iterate.”
He goes on to say
“Have you heard of those roadmap and planning charts where you can see the whole lifeline of a product? Topics, dates, durations, logistics, deadlines. It’s porn for managers. But same as porn, it rarely has something in common with the real life.”
I’d go even further in saying that these artefacts that still seem so entrenched in the way software is created today are not just porn for managers, they’re management masturbation because they create the illusion of value where no real value has been created. Ultimately, these roadmaps and charts are meaningless but feel-good waste that provides you with a sense of achievement where nothing has been achieved. Very much like pointless, excessive meetings what these activities bring about often is just the semblance of achievement, productivity and purpose.
‘Agile’ isn’t that newfangled, weird way quirky programmer types like to create software with. It’s the reasonable, the normal way of creating software – or in fact of doing any creative work! Process and methodologies are at best tools that help with that work but all too often they’re actually obstacles that stand in the way of producing value. It’s only through adapting to “how things are usually done” that we unlearn the reasonable way of accomplishing things and adopt more rigid, counterintuitive approaches.
Taking up the initial statement, most people are in fact cut out for creating software the agile, the reasonable way. They perhaps just have to learn it again because through years of bad practice they’ve just forgotten.