I had a conversation with one of my developers earlier this week that was eye-opening. He had been resisting some of our practices, specifically pairing and test-driven development. He thought they both took more time than just writing the code. So I asked him what Agile meant to him. And that’s when the fundamental differences between our versions of Agility became apparent.
This is why we need to reimagine Agile.
Agile is about project management
He related a story to me about how his last company, where he had worked for years, operates. Agile in that company meant that leaders decided on a product to build, including a backlog filled with months worth of work that, when built, would constitute the product to be sold. The work was split into sprints, assigned to teams, velocity was tracked, releases built, and life went on.
Throughout the project, Scrum masters would measure progress and update status, and leaders decided what to cut or what had to get done no matter how much code the devs had to write. The testers had to test, operations had to release, and so on.
To him, this was Agile. It was a way to manage projects with fixed scope, fixed time, fixed budgets, and final deadlines for being done.
And I completely understand why developers and testers would hate to work like this.
But that is not Agile!
I thanked him for his story and started talking about how I had a different view. I talked about learning and experimentation so that product managers could understand their market and make course corrections as they went. I talked about how timelines and scope were both open to change because product managers were learning every day.
And the enabling capability of a team that allowed the course to change frequently was the ability to define, test, and release features quickly, cheaply, and repeatedly. The shorter the path from idea to deployment, the more frequently learning could happen, and the better the chances of releasing the right product were.
That, I explained, was why how we wrote our code was important. We use test-driven development to write our code incrementally and leverage test automation to safely change it. Building on that, we use pair programming to distribute knowledge about our code throughout the team so anyone can change any code as needed. Then, since we have tests for everything and we all know all the code, changing and releasing the system becomes simple and routine. And that is the magic that allows product managers to use code as a way to learn about their product as we build it. That’s the magic of Agile.
And I completely understand why developers and testers would love to work in an environment like this.
Agile: Reimagined
I believe this fundamental disconnect about what Agility means is at the core of why we need to reimagine Agile. Agile has become a bad word in a lot of companies because they spend a lot of time and energy implementing Agile into their organizations and don’t get the payback they were looking for. And it’s become a bad word for so many developers and testers because it ends up decreasing their freedom and puts them on a hamster wheel of delivering random features that never seem to add up to a whole.
No matter the context, whether it be a software product in a small startup or a Fortune-100 company, or something not involved with software at all, we need to get back to real Agility and focus on people, collaboration, learning, and embracing change.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
