Be less frAgile
I've seen countless so-called "Agile" implementations, and I'd say most of them had very little to do with the manifesto. It started out as a rebellion against rigid, bureaucratic engineering processes, and it has, sadly, too often become another piece of corporate theatre. Agile is supposed to free teams from excessive structure and documentation so they can focus on the only thing that actually matters, delivering working software.
What in the name of corporate hell is going on here?
Traditional engineering is slow and methodical, understandably so, you don't get a second chance at building a bridge. Software is different. You can iterate on it quickly in a way you never could with physical infrastructure, and the Agile Manifesto was built on exactly that realisation. Somewhere along the way though, frameworks like SAFe and an obsession with JIRA turned all of this into a corporate machine that misses the point entirely. I think it's worth going back to the four values the Manifesto was founded on, if only to see how far we've drifted from them.
Start with individuals and interactions over processes and tools. Agile was never about JIRA workflows, velocity charts, or stand-ups that feel more like interrogations. It's supposed to put real people first, solving real problems through conversation. In plenty of organisations though, developers spend more time updating tickets and sitting in ceremonies than they do writing code, shackled by processes that do nothing to spark real innovation. If your "Agile" is putting up barriers rather than removing them, you're doing it wrong.
Working software over comprehensive documentation is next, and the one teams seem to forget fastest. Documentation has its place, of course, but Agile shifts the focus to delivering value, which isn't the same thing as filling out Confluence pages. Too many teams get bogged down in reporting and detailed specifications that are obsolete before they're even implemented, favouring the paper trail over progress. The best documentation, I'd argue, is clean, well-organised code rather than a monolithic document nobody reads. If you're spending more time justifying your work than delivering it, something has gone a bit sideways.
Customer collaboration over contract negotiation matters just as much. Agile asks for tight feedback loops with customers, not just at the start of a project but throughout it. Too often teams still treat requirements as a static contract and only speak to stakeholders at predefined intervals, or worse, not at all. SAFe and the other enterprise frameworks reinforce this, stacking layers of bureaucracy between developers and the people they're building for. Agile was meant to bring us closer to customers, not bury them under more middle management. If your "customer collaboration" amounts to a quarterly planning session, I'd say you're missing the point.
Which leaves responding to change over following a plan. The digital world moves fast and Agile intends for us to move with it, but some treat the sprint backlog as sacred and refuse to pivot even when priorities have obviously shifted. Others apply the methodology so rigidly it ends up looking like old-school waterfall in disguise. Agile isn't a script to follow, it's a willingness to adapt. If your team has to ask permission to change course, you're not being agile, you're just using new terminology for the same old problems.
Of course, a team with no agreed way of working has problems of its own. The trouble starts when the process becomes the job.
What gets lost is that Agile doesn't dictate anything. It's a set of principles rather than a recipe, and there are no accepted norms for process. SAFe isn't agile, Scrum isn't agile, JIRA isn't agile, and daily interrogations certainly aren't agile either. The whole point is to get working software out the door, and if your team is buried by process rather than empowered by it, the answer is probably to strip things back. Challenge the meetings, the approvals and the frameworks that slow you down, and give developers the autonomy to solve problems without someone hovering over them. Talk more and document less. Get close to your customers, actually listen, and let priorities shift when new information turns up instead of clinging to a plan that's already out of date.
Agile works best when it's kept simple and human, and I think most of what gets sold as Agile these days is noise on top of that.