Stop me if you've heard any part of this before.

"Hey, our new sprint is about to start, so can you add stories for the upcoming sprint? Make sure they align with our 'Definition of Done' — you know, the one scribbled in some forgotten doc that hasn’t been updated in four years. I want to know when things will be DONE DONE. Is that too much to ask? And no, I’m not writing any of the stories or worrying about implementation — that's for you to worry about, but I will critique the acceptance criteria. Waves hand Be sure to include tests, metrics, alerts, documentation, rollout plans, and all that good stuff, but make sure your tickets don’t span longer than two weeks. Also, we need accurate estimates, but don’t let any unaccounted work interfere with your stories."

That’s right ladies and gentleman, we’re talking about Agile.

A brief history of Agile

In an effort to know thy enemy, let's take a quick detour into the history of Agile itself. Methods and philosophies to deliver incremental software are as old as software itself. Agile came into popularity in 2001. Before that, many "frameworks" were popular, such as Scrum and Extreme Programming (that's right, Scrum and Agile are technically different, in case you didn't know). But mostly, it was a bit of a free-for-all, with teams and organizations mixing and matching different frameworks and doing what felt right to their teams, their culture, and their management structure. Then, in 2001, 17 software engineers gathered at a ski resort in Snowbird, Utah, and laid the foundations for what would become the "Agile Manifesto" and the principles of Agile software development that would gain huge popularity in the coming decades.

I want to take a quick tangent here. I find that this popular anecdote buries the lede. Okay, yes, they wrote some guidelines on project management that became very popular, but who were these 17 engineers that went to Utah, chilled for a few days, and changed the face of software development for years to come? Is there a secret club that I’m not in? It turns out it was some of the most popular figures in SCRUM, Extreme Programming, and other popular frameworks at the time. They actually publish the history here on this very cool, very retro website.

Okay, now that we've got that tangent out of the way, let's remind ourselves what Agile is all about, according to its founders, not according to a super ninja Scrum Master, CSM, PMP, MBA senior specialist expert from Deloitte (you know who you are). There are 12 core principles behind Agile project management - and they are worth a look, if you have not read them before. And that’s it. That’s "Agile." There are dozens of books on the subject, and many of the original 17 engineers working on the framework of the manifesto have written their own books on their interpretation of the subject, but at its core, Agile is a set of 12 guildlines written more than 2 decades ago by some very smart people.

Agile in practice

It’s 2025, and I’ve been writing software professionally for 10 years. That either makes me a dinosaur or a small infant just starting my career, based on whether or not you know what the word "rizz" means. In my experience, project management practices across the software development industry aren't a monolith. I’ve worked as a contract developer, a consultant, at a small startup, a unicorn, and at a soul-sucking FAANG (hint: it was Amazon). There’s a lot of variation in how project management is done. It ranges from "there is no formal project management" to ultra-strict "Scrum" with two-week sprints and the full gauntlet of formal meetings.

So, where are we going with this? While I don’t have an answer to how project management should be done, I do want to offer some observations. Here are a few common patterns I've observed in modern project management and how I believe these practices have drifted from Agile's original goals, resulting in a less efficient and more frustrating development process.

Simplicity--the art of maximizing the amount of work not done--is essential.

Maybe I gave it away in the introduction, but I've spent a lot of time (as an Individual Contributor, mind you) writing and reviewing tickets to ensure that the Jira story "definition of done" aligns with the latest revision of a process document inspired by a production incident or the whims of a VP. Does a 600-word Jira story really help us? Maybe. In some cases, it’s a useful tool for documenting business requirements and facilitating communication between teams. But I've also seen instances where my team and I spend a lot of time "playing" in Jira (or similar tools), focusing on acceptance criteria, splitting tasks into multiple tickets, linking dependencies, choosing the right label, debating whether something is an epic/task/story/bug/issue.

I’m not trying to rail against project management tools, but I often see organizations taking a lazy approach to project management by loosely following """Scrum""" with arbitrary and infrequently enforced rules that are pushed down from the top and applied inconsistently across organizations. Managers want easy progress tracking, so they shift the burden down the org chart onto the engineers and create a lot of "work about work."

The Agile manifesto also tells us, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." Heavy project management processes and tools add extra work and force managers and developers to communicate through a medium where nobody really knows what the other wants to see.

Continuous attention to technical excellence and good design enhances agility.

One of the 12 tenets of the Agile manifesto is "Continuous attention to technical excellence and good design enhances agility." I think you would be hard-pressed to find a set of engineering managers or product managers who disagree with this statement. On paper. But here’s the thing: I’ve often observed that company stakeholders are willing to trade a few weeks of early delivery in exchange for proper design reviews, writing proper tests, or building automation and observability - all things that will come back to haunt you. What you're left with is a pile of inoperable spaghetti code that can’t be modified, and everyone is frustrated that we can’t build upon it. Clean code begets clean code. Tests beget more tests. Tech debt begets more tech debt.

"Oh man, this system is a mess." Ever wonder how it got like that? It’s the result of many months or years of adding hack after hack to meet short-term deadlines, all at the expense of accumulating so much tech debt that we just ignore it like a massive pile of student loans and chalk it up to an unsolvable problem inherent to the system. That's showbiz, baby.

Now, listen up, engineers. I think this is mostly our fault for not articulating the risks and estimating appropriately. It’s our job to be the guardians of software quality and flexibility. If you end up with a mess of system architecture or code, you might need to look inward for answers. All that said, I find the tyranny of a 2-week sprint (no, we don’t have time for tests this sprint!) and the tyranny of quarterly deadlines (just manually deploy everything to hit the deadline, and we’ll go back and fix it later!) to be antithetical to the Agile principle that you should maintain a continuous focus on a high technical bar. This will pay off in spades down the line when you can modify your app without needing manual regression tests or troubleshooting urgent production issues because there are no tests.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

This is one of the most famous tenets of the Agile manifesto: the ability to respond to changing requirements. But here’s the thing — especially in big organizations, the pressure to plan out a long roadmap for your area results in little (read: no) time to respond to the changing requirements from other teams. So what happens when Team A needs something from Team B, but doesn't realize it until halfway through the quarter? What is Team A to do? Disrupt Team B’s activities? On whose authority? Wait until the next "roadmap planning session" and hope that their dependency gets accepted? What if it doesn’t? Team B could implement a similar solution to Team A, but that would leave the company with a decentralized, messy solution architecture, which is no good.

What am I trying to say here? I’m saying that in my experience, some companies plan their software development teams with such rigidity that they’re unable to adapt to changing requirements. Changing requirements, even abandoning some projects in favor of others, shouldn’t be organizationally taboo. It should be something that management encourages and fosters, with a culture that promotes collaboration across the whole company, not Team A vs Team B. Now, a lot of this is based on being able to measure value accurately across organizations, but I think companies would operate much more efficiently without such strict silos that require complicated, multi-layer negotiations just to change requirements at any point in the development process.

Conclusion

So where does that leave us? Agile, in its original form, feels like a bit of a lost art in today’s software development landscape, replaced by everybody and their uncle's interpretation. Maybe it’s time for a reboot? An Agile 2.0 that reflects the realities of today’s world, where speed, flexibility, and collaboration are more crucial than ever. Maybe we just take it back to basics and renew focus on the original Agile principles: clear communication, technical excellence, and the ability to adapt when things inevitably change.