Here's a question worth throwing into your next team retro: what's actually changed in how your organization does agile lately? Not whether you use it—everyone's using some version of it by now—but how the day-to-day practice has shifted. If you've been in the game for more than five years, you've probably felt it even if you couldn't name it.
Here's a question worth throwing into your next team retro: what's actually changed in how your organization does agile lately? Not whether you use it—everyone's using some version of it by now—but how the day-to-day practice has shifted. If you've been in the game for more than five years, you've probably felt it even if you couldn't name it.
PMI and Agile Alliance just released the second edition of the Agile Practice Guide, and it's a useful excuse to sit with that question. Because the honest answer isn't "agile spread to new departments." That ship sailed a long time ago. Back in 2017, when the first edition came out, agile had already jumped the software fence—marketing teams, engineering groups, even university curriculum designers were running sprints and standups. The guide acknowledged that reach from day one.
So what's the real story nine years later? It's not geography. It's texture. It's the mechanics of how the work actually gets done.
Three Forces Reshaping Agile Practice
Talk to almost any project lead in Riyadh, Dubai, or Cairo running cross-border teams and you'll hear the same themes come up, in one form or another:
- Distance is now the default, not the exception. Teams spread across three or four time zones used to be a special case that needed a special plan. Now it's just Tuesday. Standups happen async in Slack threads before anyone's had coffee. Planning sessions get split into overlapping windows so nobody's dialing in at 2am. The guide had to catch up to that reality.
- AI sits at the table now. A couple of years ago, generative AI showing up in a sprint planning session would have felt like a gimmick. Today it's drafting user stories, flagging risks in backlogs, even summarizing retro notes so the team can focus on the conversation instead of the note-taking. That's a genuine shift in how the work gets structured, not just a new tool bolted onto old habits.
- Product thinking took over the framing. Instead of asking "what tasks do we need to finish this sprint," a lot of teams now start with "what outcome are we actually trying to create for the customer." That's a subtle but real change in how work gets measured and prioritized—less ticket-counting, more value-tracking.
None of these three forces were dreamed up by a committee. They came from watching how people actually work and updating the guidance to match. That's the whole philosophy behind this document, and it's worth unpacking why that matters.
Built From Evidence, Not Opinion
Here's something a lot of people don't realize about the Agile Practice Guide: it was never one expert's take on "the right way to do agile." It's built from surveys of thousands of PMI and Agile Alliance members—real practitioners describing what they actually do day to day, and what they wish someone had told them when they started.
That's not a small distinction. A guide built on job task analysis involving thousands of practitioners ends up looking pretty different from one written by a handful of consultants in a conference room. The content that made it in—and just as importantly, the content that got left out—was shaped by what people said actually mattered on the ground.
Why Framework-Neutral Still Matters
That evidence-first approach led to a design choice that's carried through both editions and honestly feels more important now than ever: the guide refuses to play favorites among frameworks.
Call your iterations "sprints" or call them something else entirely—the guide doesn't care. Your facilitator doesn't have to be called a "scrum master" for the guidance to apply. No single methodology gets crowned as the winner. That's deliberate, and if you've ever sat in a room arguing about whether you're "doing Scrum correctly" instead of talking about whether the work is actually moving forward, you'll appreciate why.
The point was never to convert people to one specific flavor of agile. It's to give someone brand new to the space a solid, trustworthy footing—something they can stand on before they pick a direction. In a region where teams are often blending Scrum, Kanban, and homegrown hybrids depending on the client and the project, that neutrality isn't just nice to have. It's practically a requirement.
So What's Actually Changed for You?
Go back to that opening question. Maybe for your team it's the distributed-work piece—your daily standup now spans three countries and two mother tongues. Maybe it's the AI piece—your backlog grooming looks nothing like it did two years ago. Or maybe it's the product-thinking shift—your sprint reviews have quietly turned into outcome reviews without anyone officially announcing the change.
Whatever it is, it's worth naming out loud with your team. The frameworks haven't fundamentally changed. The forces acting on how you practice them have. And the organizations that notice that shift early—rather than discovering it three sprints too late—are usually the ones that adapt without losing momentum.
If this article raised a question about your own organization, we would be glad to talk it through.
Talk to MIRAS →