How to give the illusion of change by using Agile terminology

The worst fads are the ones that don’t go away

It can be difficult running a development team, project, or department in 2019. Those both above and below you in the hierarchy expect you to be constantly changing and improving in order to deliver better software. They expect you to be ‘lean’ and ‘agile’.

It was easier ten years ago when you could dismiss these things as a fad that’ll go away anytime now, but unfortunately it just doesn’t seem to be. You just need to skim Twitter or LinkedIn to see that it’s almost definitely starting to catch on.

You could try to actually read the agile manifesto and implement the changes, but that’s probably a lot of work, and you’re too busy telling people how busy you are, and arguing semantics in meetings to look clever.

Instead, we’re going to go over the different agile buzzwords and advise you how to shoehorn them into your existing processes without actually having to change the processes themselves.

Daily Standup/SCRUM/Huddle

Despite its name, The Daily Standup isn’t a newspaper about comedy, but instead it’s where you all get together, normally early in the day, and the techie folk make excuses why they didn’t do as much as they said they would the day before, and then make big unrealistic claims about what they will achieve today.

Basically, instead of gathering all the excuses at the end of the project then doing nothing to address them, just do this daily. It sounds like a ball-ache, but if you’re the Scrum Master, project manager, delivery manager or essentially anyone but a developer or tester, you can just use this time to check your email, as for some reason you’re not expected to share your excuses for why you did fuck-all yesterday too.

Retro

You probably already have those meetings where it descends into moaning, finger-pointing and petty digs at one another. That’s pretty much what a Retro is so a quick name-change should make this one a quick-win.

User Stories

Users stories in an agile process are effectively requirements written from the point of view from an end user, with vague enough acceptance criteria that the developer can use their experience and judgment to do the best job possible, but focused enough that the problem that needs to be solved can be solved.

Obviously this would be massive overkill, and come on, a functional specification has never hurt anyone.

So instead, just use a tool like Jira or TFS that has a ‘Story’ task type, then just copy and paste chunks of spec into the body of the task. That way developers can move it between columns on a virtual board (they fucking love moving tasks between columns, it’s like a videogame to them), but you don’t have to go through the faff of actually writing them in a useful or user-focused way.

Sprints

Obviously you have agreed delivery dates and deadlines with customers and stakeholders, but try not to tell that to the team as they’ll say things like “That’s not agile!” or “Really, that’s the absolute opposite of agile!”.

Instead, pretend like you’re only focusing on the next two weeks. This is called a sprint. It’s called that because people run slower during a marathon, so by splitting the marathon into sprints, it makes them think that they can go faster, even though in reality they still have hundreds of sprints ahead of them and will likely die of exhaustion before making it to the finish line.

Sprint Planning

You already know what you want the team to do next sprint, and you need to tell them somehow, so instead of in an email, just book a ‘Sprint Planning’ meeting and tell them in a way that sounds like they have a say in what’s going into the sprint.

The only problem with this is that they will discuss things and maybe get into arguments, but you can just check you email, scan Reddit, or post pictures of your children to Facebook until they’re done.

Refinement

Right, here is where using agile terminology can really benefit you. Where previously you’ve pissed people off by aggressively changing the project priorities on a whim, in refinement meetings, it’s actively encouraged!

The whole point of this meeting is to pick the highest priority requirements and then let the development team discuss and argue the most pointless of minutia, until they’re all ready to provide arbitrary estimates for the sake of a graph no-one will look at.

These estimates can come in the form either a length of time, where the amount of time it actually takes is impossible to measure, or you could use story points, which is essentially the same process as above, but using numbers that have no direct correlation with time, therefore rendering them of even less use, especially to anyone outside of the team

That’ll probably be enough, but just in case…

There are a crap-load more buzzwords your could use, but realistically the above is more than enough to get people off your back. Your team will be too rushed by the unrealistic deadlines and distracted by the endless meetings to care, and the higher-ups will just be happy that you’re saying words they can stick in a company blog.

In case of emergency though, if people start to get twitchy again, or start to see through the deception, just start saying “dev-ops” a lot. No-one knows what it means and it’s a guaranteed way to make people smile, nod, then walk away.

Good luck!