Origin: The Early Days of Agile
Back in the late 1990s and early 2000s, what became the Agile movement wasn’t about frameworks or certifications. It was about teams of developers saying, “We’re uncovering better ways to build software by actually doing it.”
That’s not just nostalgia talking. Those early adopters weren’t following a methodology—they were solving real problems. They wanted sustainable teams, quality software, and business results. And they found ways to get there that put humans at the center of the solution. As Agile evolves, returning to these roots could be the key to creating real value today.
My (Richard) early eXtreme Programming teams experienced this. Before XP, we were struggling with burnout and quality issues. We were busy building what our stakeholders asked for (”the requirements”), only to discover they actually wanted something else. XP gave us a calm, iterative way to build the right thing with high quality at a sustainable pace. Everyone knows XP for the engineering practices like test-driven development, continuous integration, and refactoring. But the human benefits—to our team and to our customers—were even bigger than the technical ones.
Something interesting happened as these teams succeeded. Other teams started asking, “Hey, how can we get what you have?” That’s when things began to shift. What started as discovery and experimentation became something to replicate. Those of us who were there remember thinking, “I’m explaining these concepts over and over. Maybe I should figure out reliable ways to teach this stuff.”
From Pragmatic Transformation to Hollow Buzzword
Fast forward to the late 2000s, and we entered the era of the pragmatic Agile transformation. Managers who saw high-performing teams wanted to spread those practices across their organizations. Practitioners who got promoted wanted to scale what had worked for them. Most people adopting Agile approaches were just one degree away from real, successful Agile teams.
I remember conversations in those days focusing heavily on what people had actually tried or seen in the real world rather than what a book or website claimed would work.
Then came the buzzword era.
Suddenly, Agile was everywhere. Big consultancies were selling large-scale transformations. Scaled methods got major market traction. Leaders were launching Agile initiatives because analysts said they should.
What started as an adaptive approach became mechanized. “Agile” started sounding like a slogan instead of an approach. The idea of Agile became a checklist rather than a principled approach to complex problem-solving. Teams ended up with processes that used Agile language but missed the human and business benefits that drew those early adopters.
I remember a first visit to one client who said they’d “completed their Scrum transformation” but “wanted a little advice to fine-tune it.”
It turned out they were using all the Scrum words, doing all the Scrum events. But they missed one little detail: there were no cross-functional teams. And not in a “we could use a DBA on our team” kind of not-cross-functional. No, every team was composed of one specialty. The UI design team. The front-end developer team. The testing team. Members of every team went to everyone else’s Daily Scrum meetings and tried to align their backlogs so they had a fighting chance to get something meaningful done.
They’d picked up the buzzwords. But they’d completely missed the point. This was an extreme example, but it wasn’t unique.
Elsewhere, people whose only experience of “Agile” was large scale transformations to scaled processes were experiencing it as endless meetings, Jira tickets, and story points.
The first value in the Agile Manifesto got inverted. People’s experience of “Agile” was processes and tools over individuals and interactions. There was little room for experimentation and adaptation to on-the-ground realities.
The result? By the early 2020s, we hit peak Agile disillusionment. Large-scale transformations weren’t delivering. The pandemic pushed teams remote, leading to even more emphasis on processes over people. Companies started laying off ScrumMasters and Agile coaches.
Today: A Return to Pragmatism
But here’s the thing: we’ve started seeing something exciting emerge in 2024.
Pragmatic Agile is making a comeback.
We’re having conversations with leaders who still see what’s possible. They’re not interested in frameworks or transformations. They want:
- Good product management
- Healthy team structures
- Solid quality practices
- The ability to test and learn rather than make big-bang changes
Some won’t even use the word “Agile” anymore—they’ve never had a good experience with anything by that name or it just has too much baggage —and that’s fine. The label matters less than what’s happening: cross-functional teams collaborating to build small increments of value in short cycles.
We have one client who has been doing this really deliberately, starting in their marketing org. They worked out their approach from basic principles, emphasizing outcomes and collaboration over process, and they’ve seen measurable improvements in both delivery and team satisfaction. People are having the experience of working together effectively to solve meaningful, complex problems.
The post-Agile name for this hasn’t emerged yet. But the principles that made those early teams successful? They’re as relevant as ever.
Want to bring back pragmatic Agile in your organization?
Here are some ways to get started:
- Start small and focus on outcomes. Pick one team that’s ready for change. Work with them to identify their biggest pain points and opportunities. What would make their work more sustainable and effective? Let their needs guide which practices to try first.
- Emphasize learning over process adoption. Instead of implementing a framework, set up experiments. Try a practice for a few weeks, measure the results, and adjust based on what you learn. Document what works and what doesn’t.
- Look for signs of health, not compliance. Are teams energized? Is quality improving? Are customers getting value sooner? These matter more than whether teams are following a prescribed process perfectly.
- Build capability, not dependency. Help teams understand the principles behind practices so they can adapt them as needed. The goal is self-sufficient teams, not teams that need constant coaching.
- Connect with others on the journey. Find other practitioners who care about pragmatic, human-centered ways of working. Share experiences and learn from each other. The early Agile community grew through exactly this kind of connection.
Ready to go deeper? Schedule a time to talk with us.
We’d love to hear what you’re seeing in your organization. Are you experiencing a return to pragmatic Agile? What challenges and opportunities are you encountering? Email to let us know!