Member-only story
The Myth of Small Incremental Improvements
Incremental changes do not provide emergency exits for a failing system. It’s time to recognize when a tool is not useful
You want an intro that goes straight for the jugular? Here’s one: Agile methodology’s veneration of small incremental improvements is bullshit.
I am not here to worship waterfalls or eulogize Kanban, and I’m not saying all of Agile’s philosophy is bad — I could even argue that small incremental improvements are not inherently part of its philosophy.
Nonetheless, given the common association, I felt compelled to write this article to help others recognize when they might be riding the wrong horse, or maybe they have unwittingly been participating in a status quo death cult because they can only envision their world moving in painfully slow ways.
It is usually a product, software, or business manager who takes issue with the size or nature of a code change: if your work falls afoul of their assessment of whatever constitutes “small” or “incremental”, then it’s the death knell for your hard work.
So why exactly is this bullshit? Because the gatekeeping is often the result of subjective evaluations of non-specific measurements, inconsistently enforced. Let’s look at a couple of examples so you can understand what the scrum I am talking about.
There is No Incremental Change in New Apps
All the objections hurled at an offending pull request are usually completely absent when an app first comes online. In many organizations, new apps are given a free pass and endure virtually no scrutiny from the same gatekeepers who would huff about changes not being small or incremental enough. There was literally nothing, then POOF!
Suddenly there’s an entire repository with hundreds of files, functions, and bugs yet to be discovered. Where was the spreadsheet, 3rd-party solution, or some other intermediate step? Where the hell did that skateboard come from? All this to say there are some practical…
