Agile lipstick 💄

Over the past decade of my wondrous career I've rather haphazardly stumbled in and out of the realm of agile leadership. I've been a scrum master and an agile coach, even got the PSM1 certification which is nice but not really worth the PDF it's written on these days. My best investment was in a coaching course¹ where I learned experientially all of the things I didn't learn as part of my job: active listening, rapport, acknowledgment and recognition, transactional anaylisis, I'm Ok/You're Ok, etc.

In the old-days of the internet, and the world wide web, there was a period of time known as Eternal September². Basically, the shadow-of-its-former-self that is AOL used to be an ISP that gave its browser away on free CDs. You'd find them everywhere. So many adverts at the time would give you an 'AOL keyword' to look for to get to their site, and there was an instant messenger and essentially a predecessor to the walled gardens you see so often today with Facebook, Google, Apple, and so on. They made Usenet accessible to the masses and so the existing Usenet users at the time had to basically deal with onboarding a constant influx of new users, many of whom didn't understand the rules or etiquette of the groups they found themselves joining.

I think agile, or perhaps scrum more specifically, has something of an Eternal September itself. The crux of it is that 'agile development' has become increasingly popular, practically a buzzword, and therefore the discourse has never really evolved beyond the experience of that introduction. Either it works for you after an initial period and you stick with it, or you become one of the legion who writes it off. I think this is the same reason why books like Peopleware³ and The Five Dysfunctions of a Team⁴ still feel prophetic: forty years and the world has still not caught up with them.

To be agile, in my mind, is to reject mediocrity and foster a mindset that encourages excellency; actually being excellent with each other and not just writing excellent software. This comes in many forms and the exact manifestation will change from one organisation to another, one culture to another, one team to another.

The subject of this topic, the Agile Manifesto⁵, was penned in 2001, twenty years ago, and has remained frozen in time since. Let's take a look in more detail.

The first line of the manifesto is this:

We are uncovering better ways of developing software by doing it and helping others do it.

The manifesto, at that point in time, was conceived via the process of introspection and adaptation. I actually think this is the most important part of the manifesto because it tells you how they came to the conclusion they did. By extension, do the same and you may yourself find things that you value over others.

Through this work we have come to value:

This work is their iterative process. As if to reinforce the previous understanding, they discovered a pattern throughout and realised that things they valued more when developing software were:

Individuals and interactions

Working software

Customer collaboration

Responding to change

It bothers me just how easily such valuable things as change, collaboration and interaction are discarded in favour of rigid process and other varied forms of control-freakery, trying to change the future through a cascading sequence of futile interventions instead of changing the way you do things or the way you are.

I've been doing this dance for a decade now and just like the Eternal September of Usenet, it feels like retracing the first few steps… repeatedly.

The main problem is, though, that it's so fucking difficult to empower a culture where individuals and interactivity take the stage, and you strive to put software you're proud of into the hands of your clients. It takes time and effort and it is a serious transformation that will shake your company to its very core. We're talking about empowerment, sustainability, humility, compassion.

And you can't just let the business fall back into old habits just because something went wrong, blaming it on the new and not what already was. The process is designed to bring problems to the surface so that they can be addressed in the open, through collaboration and interaction.

Fuck that noise, just put the agile lipstick on your pig instead! Throw in a daily standup, run a retrospective, rationalise the legitimate issues away, and use sprints and estimates to track performance. Write a few blogs about it when you're done, and move onto to superficially changing the next unwitting client.

Now that is easy.