Not that I have an issue with the ethos by any means; my issue is more to do with the constant, infuriating need to talk about it all of the goddamn time (rich, coming from an agile consultant, I know). I’m rapidly falling out of love with Agile with a big ‘A’.

This is me. I am this toast.

The issue I’ve really got is that all too often these conversations about what agile is, whether this particular method is agile enough, tend to do nothing except get in the way of actually doing what really matters when we’re building software. Specifically, it tends to get in the way of building the software. I’ve lost count of the number of instances in my career where I’ve witnessed the conversations about the approach to a particular piece of development work far exceed the time it eventually took to build, release, and indeed measure, the feature in question.

I’m not by any means saying that I don’t think reasoned debate regarding how we are working as a team is a bad thing, and by all rights these discussions can serve a useful purpose and provide us with the tools and benchmarks by which we can continually improve. What I am saying is that there’s most definitely a time and a place for said discussions (read: retrospectives), and lacking any checks and balances to restrict those conversations to the appropriate forum can result in a particularly problematic trend emerging, where the conversations about approach take over the discourse entirely, and neglect the more fundamental reasons why we’re doing the jobs were doing in the first place: to build a product that people want to use.

Yes, debating the methodology we’re going to use in order to estimate (or indeed if we even should estimate) the work has value, and indeed so does that conversation around whether that ticket really constitutes an independent deliverable; however, sometimes (and I stress, not all of the time) there’s an element of us just needing to get on and build something.

Cost of delay is, indeed, a very real thing; and sometimes the tendency with teams can be to evangelise a process and neglect the realities in which the team is operating; yes, there’s a longer tail objective within any digital product team to ensure that the entire business in which it sits is aligned to those methods and ways of working; but that is by no means an objective that can be achieved overnight. Ignoring the reality of where a digital product fits within a business context, and simply insisting that this approach ‘isn’t agile’ may very well ignore that fundamental point, which can lead to a very disjointed team structure. Collaboration is compromise, and the ability for pragmatic compromise is a fundamental skill that an entire product team should be able to rally behind and recognise.

There’s a tendency to pull out the ‘A’ word as a blanket catch-all to curb any further conversation about a subject, as if competing over who knows best is a productive use of time. Really, aren’t we all one team with one common objective? Collaboration, rather than competition about who is the most agile, is the path to real team success, and pragmatism is your compass. The agile pissing contest just makes everyone damp. And smelly.

Smelly, smelly doge.

Sure, a massive landscape of methodologies have sprung up off the back of the agile manifesto, and the huge raft of businesses that have spun up to facilitate the ‘agile transformation’ haven’t helped matters (especially when they may be championing a cookie cutter process change to fix a whole heap of problems that are much more fundamental), but one thing we need to remember here is that agile is just that; it’s a set of priorities to help guide in decision making, a mindset; it’s not a stick by which to beat people, or a prescriptive process.

Yes, keeping an eye on those priorities can help aid day to day decision making, but by no means is there a one size fits all process that is going to work in any organisation without some actual application of common sense and contextual awareness, and a methodology is not the be all and end all. A team working on a waterfall project can be easily as agile as your most seasoned Kanban crew if they’re all championing the important stuff – delivering value.

I fundamentally blame TLC for all of this.

Fundamentally, I think this all just boils down to being a bit nicer to each other. Digital product development is an industry that allows ever more diverse teams to collaborate, and this industry has given me the opportunity to work on products and with people, with skillsets and backgrounds that wouldn’t have been possible otherwise – and with those diverse opinions and experience sets, it’s all too easy for teams and individuals to champion their own opinions and view of what works, arising from their own experiences, above those of other people.

We forget that an equally valid experience is backing up anyone else’s point of view, and we ignore the fact that any decision come to has, fundamentally, arisen from the same common objective – albeit filtered through a slightly different lens on the current situation. When someone’s opinion differs, let’s take a minute to explore the idea that maybe there’s a very valid reason as to why we haven’t considered that, rather than inevitably getting out the yardstick to measure how agile, or not, that solution might be.

And on that note, rant over. Our teams have all fundamentally come together for the same reason, our interpretation of how to reach that end goal might just differ somewhat. Let’s all give each other the benefit of the doubt a little bit more. And now an adorable kitten to illustrate my point.

This kitten is giving these ducks the benefit of the doubt, despite their suggestions sounding very ‘waterfall’. FEEL THE LOVE.