Agile life

Passion for the craft has a cost. When you care about how software is built—not just that it ships, but that it’s built well, that the team is learning, that tomorrow’s work is easier than today’s—you will eventually end up in rooms with people who don’t share that investment. And some of those people will have seniority over you.

The friction is real. Suggesting a better approach and being dismissed is demoralising. Being mocked for asking questions in a field where curiosity is literally the job is demoralising. The natural response is to push harder, make the case more forcefully, become more aggressive on the “tech front”—a mode I recognise from experience and which almost never works.

What works, to the extent anything does, is finding the practitioners who are also trying to improve and working with them instead. Martin Fowler’s writing on new methodology articulates something important here: agile isn’t primarily a process improvement, it’s an epistemological shift. The assumption that we don’t know everything at the start, that plans will change, that feedback from working software is more valuable than detailed specifications produced upfront—these aren’t just techniques. They’re a different relationship with uncertainty.

That relationship is uncomfortable for organisations that have invested heavily in the fiction that software projects can be planned in full before they’re built. You can demonstrate the value of iterative delivery, point to the research, run the retrospectives, show the improved outcomes. None of that will move someone who has staked their professional identity on the waterfall model being correct.

The more sustainable approach is to be patient without being passive. Work within whatever constraints exist, look for the places where incremental improvement is possible, and protect your own energy for the long game. Agile teams aren’t built by convincing the unconvinced—they’re built by the practitioners who keep showing up, keep learning, and keep delivering.

The Agile-CMMI integration work and the architectural thinking in Dr. Dobb’s Journal are worth reading alongside Fowler if you’re navigating this in a more formal process environment. The specific tools matter less than the underlying orientation: stay curious, stay humble about what you don’t know, and don’t let institutional inertia become your inertia.