I have a question. When did Agile stop being an optional methodology for developing certain types of software and suddenly become an organization-wide religion?
4 Symptoms of Tech Bloat
- Talking to customers repeatedly without becoming an expert on customer behavior.
- The constant assessing and reassessing of deadlines and delivery dates.
- The brutal reluctance to start the development process until every detail is documented.
- The creeping motivation to begin with the easiest tasks, not the riskiest tasks.
Here’s why I’m asking. Software development cycles are taking longer and longer. Technology teams are growing larger and larger. Managing development requires more and more apps. Fewer and fewer people are actually doing the coding. For shorter and shorter periods of time. With less and less progress between constant checkpoints.
Agile was supposed to take care of all this, or so we thought. But somehow it overtook the process and we all became members of the cult of Jira. Is it even possible to free ourselves?
Where Did Agile Go Wrong?
Agile, for those not yet converted to the cult, is a methodology developed over the early 2000s as an alternative to documentation-driven, heavyweight software development processes.
Yes. That’s right. Agile was supposed to be an alternative to existing, cumbersome project management methodologies of the sort that were turning into earned-credit-factories like PMP and even Six Sigma.
So what the hell happened?
I can’t speak for everyone, because my own personal professional experience with Agile has always been at the periphery. I knew it was there, I acknowledged it, I let it do its thing and I kept it from making a mess. Like that one developer in every tech team’s corner who has a lot of potential but needs a lot of coaching.
At Automated Insights, circa 2010 to 2017, I never bothered with it. Honestly, and at the risk of bragging, we were doing generative AI before GenAI, even before NLG, and we were moving too fast for even Agile to keep up. We probably would have benefitted from leaning into the methodology side of it a little more, and we wound up making a lot of unnecessary mistakes at that speed.
At Spiffy, roughly 2017 to 2022, myself and the CEO and the CTO were actively against all of the formalities of Agile, but in practice, we were using the concepts — continuous development, continuous improvement, continuous deployment — but we didn’t conform to all the mandatory cycles and checkpoints and navel-gazing required to formally adopt it.
At my current startup, in 2023, I walked into an org that was essentially crippled by an over-reliance on Agile and all of its formalities. And I’m not just talking about product and engineering. The whole company was struggling with pace, delivery and quality of releases across a portfolio of applications and platforms.
Great ideas, great talent, great motivation, back-breaking process. It was a problem that took the better part of a year to fix, and in some sense I’m still working on that fix as I write this, but we’re over the major hurdles, so I can document some of the lessons.
The Primary Problem Is Tech Bloat
A lot of folks I routinely interface with, including upper management on both the business and tech side, at startups and Fortune 500 companies alike, are done or close to done with Agile.
The main reason for abandoning it, across the board, is tech bloat. Tech bloat is what I described in the opening section of this article. More people, more preparation, more documentation and more time, with less execution and focus, and thus poor results.
Tech bloat is every tech company’s enemy. It’s a danger even to those companies that aren’t strictly defined as tech companies but have a software development arm either in house or contracted out.
Tech bloat is not tech debt, which is a term for inelegance in any development process that results in a buildup of problems that crop up later, although tech bloat definitely produces tech debt.
The Chaotic Results of Tech Bloat
Here’s how tech bloat manifests itself in an organization. It’s a cycle I’ve seen play out over and over again, so you’ve probably seen or even experienced it yourself.
More documentation creeps into the process, tracking not only what was developed and why, but how — and this “how” becomes the focal point of status updates, a constant re-evaluation of how the team is working. In other words, the team spends more time discussing why things didn’t get done than they actually spend doing the things.
More deadlines are set at more frequent checkpoints, and they wind up producing micromanagement at every turn and twist of what is essentially a creative process. This is antithetical to producing quality software, as every task gets delivered at its predetermined deadline, regardless of how well it was executed.
Constant second-guessing during the reevaluation periods winds up ensuring that best practices never get declared, waste never gets eliminated and economies of scale are never recognized.
Micro-managing the production means that by the time 30 percent or so of the overall feature is finished, it’s no longer a priority. Then the org starts the death spiral of producing what’s on the roadmap, regardless of whether or not the roadmap still defines the build of a successful product.
The end result is a product that suffers under the weight of multiple, disparate customer demands. Features are often late to market and delivered in a manner and an order that is best for the tech team, not said market. Eventually, sales and marketing revolt because they don’t know what they’re selling and customers don’t know what they’re buying.
Then the org cleans house.
Is this the reason for the recent spate of tech layoffs? Well, it’s not the only reason.
The World Doesn’t Need More Features
It needs lighter software that does the important things better.
This is not a new concept, but it’s one that every methodology eventually wanders away from, all the way back to Just-In-Time and even the more ephemeral concepts of the Toyota Way.
Eventually, people start asking if the Toyota Way is Toyota enough for Toyota, and then it becomes work to make more work. And that’s what happened. Agile is now PMP with cute names and shorter meetings with more rules.
The problem is not the idea of Agile, and it never was. It’s the execution and the lack of leadership to rein it in. It’s a layer of middle management focused on deadlines over utility, cuts over growth and savings over progress.
Honestly, it’s probably too late to save Agile. You can throw it out now, and you can probably toss EOS in the same bin.
