When agile jumped the shark

It was over three years ago now, but I remember it as if it was yesterday; I was sitting at my desk, tapping away on an email and trying to decide whether this message was actually the kind of thing that I was now meant to be putting on The Slack, when I became obliquely aware that one of our software engineers was showing an interview candidate around nearby. This is usually a good sign. Following the technical tests of our interview process the candidate had been asked the casual, yet critical, question, “would you like a tour of the office?” This tends to mean, “you have passed the test, so we’re going into sales mode”.

I watched as the candidate pointed earnestly over to a particularly splendid team task board on the wall opposite me. It was a thing of beauty; a map of the flow of value from inception to delivery, garnished with work in progress limits, support queues, team member avatars and, of course, a rainbow-barf of post-it notes. The candidate asked what it was. The software developer answer was as immediate as it was dismissive, “Oh, that’s just agile – it’s a Management Thing“.

In that instant I realised it – agile, at our company, had jumped the shark.

I’m not really sure what I would have liked the software engineer to have said. I guess something factual like “that’s a team task board; it’s how the team visualises what they need to do, what they are working on and what they have finished” would have been fine. My heart would have skipped a beat had he said “Oh, that’s agile! It’s the only way any rational, reasonable person would go about building software. It advocates evolutionary development, early delivery or working software, continual improvement, and rapid response to change. It’s freakin’ awesome”. Although, if they had really said the latter, I would definitely have assumed they were trolling me.

Regardless of what I’d have like him to say, what he actually said was that agile is a Management Thing. And when he said that he didn’t mean agile is something concerned with managing the delivery of software. He meant agile is something that Management is concerned with. Perhaps, that only Management is concerned with. Do you know what? He was pretty much right.

His statement allowed me a moment of forced perspective, and I saw that the application of an agile approach to our software development – the complex task boards, the Scrums, the Kanbans, the stand-ups, the sprints, the retros, all of it – were the labours of people with “Manager” in their job title. They were things that happened to the teams, like all-hands company meetings and fire drills. Things which our developers, mostly, trusted were necessary (because otherwise why would the managers make us do them, they are not that dumb?) but not things that they truly felt the value of and certainly not things they would choose to do, given the choice.

But that hadn’t always been the case, had it? When I first joined the company, my team was proud of their post-its, which broke down their features into concrete technical tasks, we knew why we needed automated tests around our user stories, we knew why we used user stories! We even had healthy discussions around what topics belong in a Stand-up meeting. Somehow, over time, we’d stopped talking with our teams about the Why behind agile and task boards and user stories and stand-ups. We taken that for granted and agile had stopped being about what it’s mean to be about; helping software development teams deliver great software.

To understand how we got to our Fonzie on a surfboard moment and what we did next, I’ll need to run you through a potted history of agile software development at my employer over the last 10 years. I’ll do that in a future post…