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?

I believe the real core of the agile revolution was realizing that if your process is repeatedly broken by external behavior… behavior that no amount of process seems able to change… then you should stop trying to change that behavior and instead (a) accept that behavior as being perfectly normal and rational and (b) figure out how to incorporate that behavior into your process.

For example: You have a waterfall process that dictates detailed requirements before you can begin development, but you have people constantly changing those requirements before and during the development phase which causes no end of problems. Agile turned this on its head and said ‘Stop fighting this’. This is perfectly normal and even desirable behavior… instead build a process that embraces these constantly changing requirements. And thus you end up with some form of iterative development practices with short feedback loops that allow those changes in ideas and direction to be rapidly incorporated into the software. Embrace change.

I met recently with some former colleagues who are faced with a problem. They’ve got an app that really needs major refactoring. The firm recognizes this and wants to add some engineers so they might have enough people to both re-architect the app while simultaneously meeting sales and client commitments. The teams’ fear is that those additional engineers will simply enable the firm to sell more of the existing app, which requires extensive customization for each client… thereby consuming all the new engineers’ time and resulting in the big re-architecture initiative being eternally postponed. Their instinct is to wish they would stop selling the thing so they could have time to fix it.

First of all, I love this in engineers… this passion for doing good work to the point they’re coding away on their keyboards, looking over their shoulder shouting to the sales team ‘Stop selling this thing… it’s not ready yet!’ We are, in many ways, craftsman… and we want to be proud of our work. But it’s just not realistic to expect the company to slow sales of the product so we can have time to improve it.

This is a very common complaint on any team I’ve ever worked on… finding the time to do systemic changes and refactoring while meeting client commitments. It’s so common, I think it meets my criteria for being something we should learn to accept as the manifesto accepted constantly changing requirements.

If the sales and features  won’t stop coming,  we’ve got to find a way to do both things at the same time. Incorporate re-architecture into the day-to-day of meeting client commitments. Slice the re-architecture into smaller pieces that can be woven in. Focus on high value refactoring and architectural changes that really make a big impact on quality and productivity… do them in a way that they can be used sooner rather than later. No big grandiose initiatives that may take months before they can be incorporated. Be clever!

If it matters to you, find a way to get it done while accepting the behavior you can’t change … and realize that doing so is not resignation but revolution!