The issue I’ve always had with Agile – with a capital A – is that the manifesto itself is not agile; it’s been cast in stone – or, at least, embedded in a stati

The issue I’ve always had with Agile – with a capital A – is that the manifesto itself is not agile; it’s been cast in stone – or, at least, embedded in a static web page. (That’s why I’ve never “signed” the manifesto.) I’ve been in this game for enough decades to know that you have to reinvent yourself every five years or so. Some things remain the same over time, of course, but a great deal changes. These changes must at some point affect the assertions laid down in the Agile Manifesto. Where is the mechanism for change? I must at this point point out that I consider myself agile. I absolutely have skin in the game. Now, to the language of managers. I work at CTO/Head of Tech level. That involves a bunch of strategic, operational, and financial stuff that doesn’t pertain to tech matters (tangentially sometimes), but my role at the tech level I regard as supportive not <air quotes> managerial. I usually describe my role as “looking after” not managing – I actively remove the terms manager and management from that part of my role. I expect – nay demand – that the teams responsible for delivery drive development/maintenance. My role is to provide them with what they need – to support, to look after, and so on – individuals and interactions. For me, that’s agile. That’s a dynamic process that’s enabled by tooling and that tooling changes rapidly. No set of pronouncements or practices can remain relevant in such a dynamic environment; unquestioningly following a static text is dangerously close to religious practice – I don’t regard this as a good thing, ymmv. So, while I believe that the Agile Manifesto is an excellent baseline, it is flawed and somewhat contradictory in operation. But, like democracy, it’s the best we’ve got.