Having spent the second half of my software engineering career doing ‘agile’ development, I think I’ve spent more time trying to convince people what agile is not than explaining to the uninitiated what it is. Since the so-called manifesto was published in 2001, the whole thing’s been so abused, monetized and co-opted that, for all intents and purposes, it seems to have lost any tangible meaning. By 2014, I had basically decided I would simply use the word ‘lean’, since the culture around agile was so polluted with nonsense…
What made this thing so popular in the first place? I remember reading about it and feeling like it was a bit revolutionary… I was excited by it. Excited because, in many ways, it was a repudiation of decades of stodgy and bureaucratic software practices that I always despised. My blog is called ‘On the Contrary’, after all, so I naturally found this upending of the table appealing.
If I peel back the layers and get at the hot molten core of agile, though, what is it really? What was its intent?
When launching a new business or a new initiative, I see lots of teams make the mistake of obsessing over what process they are going to use to manage the software production efforts.
They start, typically, with some ‘textbook’ example of SCRUM©… this quickly leads to obsessive debate over what ticketing tools to use… which then devolves into silly discussions over what ‘states’ the ticketing process should have (‘waiting for tests’, ‘testing in progress’, ‘testing failed’, etc)… Add in some arguments about what roles would be on the team and the delicate parsing of the responsibilities that do, and do not, belong to each… it doesn’t take long before I’m wondering: ‘When did we stop being software engineers and become process engineers?’
The problem is that we’ve forgotten the FIRST principle of the agile software movement:
Individuals and interactions over processes and tools
Oh yeah… forgot about that.
When a pack of Software Engineers met in Utah in early 2001 to discuss a new way of building software, the summit did not produce a brand new SDLC, but rather a simple set of guidelines for software teams to follow in order to achieve better results with less friction. This ‘Agile Manifesto’ was as much a guiding force for future software development as it was an indictment of the processes that continue to plague the industry. As simple as the guidelines are, they can be profound when applied properly:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.
I find it informative to invert the guidelines and ask ourselves what it looks like to build software badly. If you want to build it the wrong way, you’ll define the process and choose tools first, write a whole bunch of documentation and requirements before you write any code, negotiate a detailed client contract but ignore those clients while you’re writing the code, and stick firmly to your plan regardless of what happens along the way. As horrible as that sounds, I’m afraid it also sounds pretty familiar to anyone who’s been in the industry for a while.