.jpg)
If I recall correctly the Agile Framework (I’ll use the capital A for Agile Framework) became a thing in the early 2000’s. I didn’t pay much attention at the time because I was busy working on video games and only figured out years later we were doing what I nicknamed “Agile by accident” with our game development teams. If I were smarter I would have written a manifesto about how we were developing, authored a book, then cashed in on doing Agile transformations for the next decade. But I digress. I’m not interested in doing a history of Agile post or getting into arguing the finer points concerning the framework but to share some experiences, observations, and some things that have worked for me.
How Agile Became Its Own Worst Enemy
Here’s the thing that I’ve always found ironic about the word agile and the Agile framework. Somewhere along the way the Agile framework became the opposite of what it was supposed to be. I've watched and been a part of organizations that spent months planning their "Agile transformation," hiring consultants to tell them the “Right Way” to do standups, sprint planning, and retrospectives. We’d argue over JIRA custom fields, create elaborate workflow diagrams, and institute mandatory ceremonies. Then after a couple of months we’d look at the results and start trying to fix the fixes we implemented fixes for…
The whole point, the actual point, of Agile is right there in the name. It's about being nimble, responsive, and adaptable. Yet I've sat in more meetings than I care to count where teams debated whether their sprint should be exactly two weeks or exactly three weeks, as if the wrong choice would be the sole cause of us not being able to deliver.
What "Agile by Accident" Actually Looked Like
Back in my game development days, we didn't call what we were doing Agile. We called it "trying not to ship a broken game so we got a paycheck and didn’t end up unemployed." Our process evolved organically because it had to. We'd sync every day, not because some framework said we should, but because if we had broken the build overnight the entire art team would be sitting around with nothing to do. We did iterations because you can't build an entire game at once, we did continuous integration because the game needed to work at all times and we needed to test if the core gameplay was actually fun before we showed it to our publisher who could pull the plug on the entire project.
The lesson for me was to have the process serve the team and the product. Not the other way around.
The Bag of Tools That Actually Works
Here's my current, always evolving bag of tools for project delivery, cobbled together from various Agile flavors and whatever else seemed useful:
Sprint planning that isn't always sprints. Sometimes it is two-week cycles, sometimes it's a month, sometimes it's "let's get this demo done before the board meeting in three weeks." This matches the process with the goal.
Standups that stand up for themselves. Check in regularly, but the format depends on what the team needs. Sometimes it's a quick Slack thread. Sometimes it's a longer sync because we're wrestling with complicated decisions. The point is communication, not do it because it is required.
Keep your backlog trimmed. I hate it when backlogs become black holes. I've seen product backlogs with 300+ items that haven't been looked at in six months. Keeping your “list of things to do” ruthlessly pruned is something I try to do on a daily basis with everything on my plate and it should be the same for development teams. If it's not going to get done in the next quarter, it goes in a "someday maybe" list and most times ends up in the trash bin.
Planning that acknowledges reality. All work involves a lot of dependencies on external other teams, committees, board approvals, and seasonal cycles. Trying to force that into a standard Agile framework is like trying to fit a square peg into a round hole. Plan around constraints and build buffers, lots of buffers, software development needs lots of buffers.
Regular communication beats the perfect process. I'd rather have a team that talks to each other constantly in whatever format works for them than a team that has pristine Agile ceremonies but doesn't actually collaborate.
Visibility trumps documentation. Everyone should be able to see what everyone else is working on and why. Whether that's in JIRA, Asana, a Miro board, or a physical kanban wall doesn't matter nearly as much as people think.
Feedback loops rule. The point of iterations isn't to have neat two-week chunks. It's to show progress and get feedback early. Sometimes that means deploying to production daily. Sometimes that means showing a prototype to stakeholders every month. Match the loop to the need. Additionally, don’t underestimate how the feedback loop feeds the team. Having others engaged in your outputs as a developer is huge. (I have a whole other theory about development feedback loops that might end up being another post.)
The thing that took me way too long to figure out: being agile about Agile is itself an Agile practice. A framework should evolve with your team. What worked six months ago might not work now. What works for the product team might not work for the content team. The process should be adapted to the team's maturity, the project's needs, and the organization's constraints.
Start With the Principles, Not the Practices
If you're implementing Agile or trying to improve how your team works, start with the principles, not the practices. Think about:
- How do we make sure everyone knows what's happening?
- How do we get feedback quickly?
- How do we learn from our mistakes?
- How do we adapt when things change?
Then look in your toolbox and pick the tools that seem like the right fit for the team, the organization, and the problems at hand. The tools, standups, sprints, retros, backlogs, CI/CD, automated testing, and now a host of AI tools, are just tools. They're useful when they help you, but harmful when they become mandatory boxes to check that are not outcome driven.
Being agile means being willing to change how you work when the situation changes. Even if that means changing how you do Agile.
And if that seems obvious... well, you'd be surprised how many organizations miss it. But then again, maybe you wouldn't be.
