A breath of fresh air! I recently attended a meetup in Calgary and was happily surprised to hear a presentation about cutting-edge software development.
It was refreshing to engage in meaningful debates and conversations about disciplined technical practices. It was a welcome shift away from the dogmatic discussions that have dominated Agile conferences for a decade. There were no lectures about “mindset” and no sermons about “psychological safety”. The conversation felt like a revival of core Agile practices: the technical excellence that underpins iterative and incremental development.
I have always appreciated how Agile values and principles explicitly champion autonomy, respect, and humane work environments. That’s chief among the reasons I’ve directed my career toward coaching and training in this field, and that’s part of why the movement succeeds. But starting around 2015, these topics became over-represented. They crowded out the engineering conversations entirely. Conferences, Open Spaces, meetups: session after session about feelings and philosophy, endless reminders to be nicer, kinder, gentler, with barely a whisper about the work itself. And unintentionally, the business community absorbed the wrong lesson: that the Manifesto for Agile Software Development is fundamentally about soft skills, not technical excellence. The result was predictable as teams tried to “culture” their way out of problems caused by poor engineering discipline.
Beyond Dogma: Returning to Agile Roots
It’s encouraging to see that the conversation around Agile practices may be returning to its roots. We may see a revival of technical excellence that truly enables great work environments for creative people and drives high-quality software.
The meetup, hosted by Improving and the Calgary Agile group, featured a presentation by John Moura, VP of Product Engineering at LodgeLink. He eloquently discussed the technical practices of the company.
Instead of getting caught up in rigid frameworks or ideological debates, he emphasized practical, real-world applications and I found myself eager to hear the details! I asked many questions about the teams’ working agreements, patterns, and technical decisions.
Some examples I remember (to the extent my memory can be accurate) from John’s presentation:
- No Pull Request shall grow older than 4 hours. (If the work cannot be reviewed and integrated within 4 hours, find a different solution.)
- No branch shall grow older than 7 days. (If the work cannot be done and merged within 7 days, find a different solution.)
- Developers don’t attend meetings after noon.
- Teams are not larger than 2 or 3 developers.
- Team mandates are divided into React (for client-side UI) and Go (for server-side APIs). How do they work independently? They design an API contract up front, then both sides build toward that contract.
- Feature flags are configurable in runtime (do not require deployment of new code).
- Teams have a “defect budget”: within that budget, reported defects are immediately elevated to the top of the queue and fixed.
- Manual QA is entirely asynchronous and done in Prod. How?
- Dev teams write their own unit and end-2-end tests and push code known (or believed) to be defect-free.
- Manual QA is not for functional or regression checks. (If an automated test can do it, the test is written an executed by developers. Human testers should do what automated tests cannot do.) QA personnel test for broad usability concerns, UX flow through the app, feature cohesion, edge-case device compatibility, et cetera.
- Budgets are not attached to deliverables; teams are funded for the year.
- Estimates are rarely requested and do not drive decision-making about priority or timeline. When estimates are requested, they inform implementation options.
- The teams push new code into production multiple times per day. Features are exposed to end users, often selectively, and on a cadence decoupled from deployment.
- AI tools are generally not permitted for junior developers. Senior developers are provided a license to specific AI tools if they can articulate how they’ll use the tool. (I think this restriction aims to encourage developers to be deliberate and discerning about their use of AI.)
- High-profile releases of new functionality are announced and timed according to marketing goals (not feature scope). Teams manage their implementation toward those dates. Those are not deadlines accompanied by fixed scope; those are focal points that help independent teams align their effort across silos.
Of course, we can debate whether those working agreements are broadly effective or unique to their context. And we did debate it! The group raised questions for John about the efficacy of Trunk-Based Development, Test-Driven Development, the Daily Scrum, estimates, documentation, quality and flow metrics, et cetera.
Looking to the Future
As I look forward, there’s plenty to be optimistic about. The rapid advancement of technology (like AI, SaaS, and innovative architectures) promises to improve our technical practices further. I’m eager to have more conversations that explore these advancements and how they can further elevate the Agile landscape.
Conclusion
In summary, it’s an exciting time to be part of the Agile community. Despite the rhetoric claiming “Agile is Dead” I see a renewed emphasis on technical practices, coupled with incredible strides in technology. These factors set the stage for a bright future.