Stop pretending you understand agile

On paper pushers, and their abilty to suck life out of everything they touch Published:

This one is for the grift- I mean scrum masters who couldn’t FizzBuzz if their life depended on it, but will insist on telling engineers how the work must be done.

Because if it does not show up in the Burndown Chart, was it even real work?

Bastardizing Scrum

I was “taught” Scrum. For all the shit that it gets nowadays, its initial vision sort of made sense. Rather than a complicated hierarchy and endless meetings we were supposed to get a somewhat simple structure:

  • Product Owner - makes the final business decision to prioritize
  • Scrum Master - greases (corporate) the wheels to remove as many impediments as possible, motivates the team to do the minimum of process required to prevent upper management descending upon them.
  • The team - does the work

With one little caveat: The scrum master can be a member of the dev team, it does not have to be a separate full-time employee.

An enforcer in our midst

And one of the gravest mistakes made, in my opinion, was enshrining the Scrum Master as an actual full-time job, separate from the concerns of the team.

Instead of having a “servant leader” who understands the challenges faced by the team, we ended up with “process managers” who serve the Jira.

  • They do not follow up on the team’s needs with the rest of the organisation - they instead ask whoever voiced the need whether or not they’ve made progress
  • They do not apply backpressure to protect the team - instead they relay every question and demand as-is
  • They often say “we need to”, yet they produce no actual work of their own.

There’s also not really enough work to fill an entire schedule, so these types end up loving busywork. And what better way to show how useful you are than by having the entire team engage with your pretend work?

This leads to situations where daily meetings drag on endlessly for nothing, sometimes followed by a “post-daily” meeting, because 30 minutes of hearing about whatever molehill was the team slacker’s latest moutain wasn’t enough. No, in order to truly be a team, we need a separate call to hear all about the latest on the corporate grapevine.

If you are this kind of manager: fuck you.

No one knows what agile means

Ask your local Scrum-certified “agile master” what the manifesto is. Ask about any of the authors. There’s a solid chance they have no clue. Too few of us devs know about the likes of Robert C. Martin, Kent Beck, Martin Fowler - so what does some non-technical paper pusher care about them or their work?

This in turn, means that none of these “agile” people know about the principles supposed to underpin the methods they claim to apply. But they will fight tooth and nail to defend their ignorance.

Fighting asinine processes? You must not be a team player.

Finding it weird to count “remaining story points”? You’re being pedantic, difficult.

See it’s not about what we do, but what we all agree we are doing. Everyone buys in to the lie - why won’t you?

“Some folks think that Agile is about going fast. It’s not. It’s never been about going fast. Agile is about knowing, as early as possible, just how screwed we are.”

― Robert C. Martin, Clean Agile: Back to Basics

Yet the main selling point of “agile work environment” is a thinly veiled: “look, we gave you that shiny thing with all the fancy meetings all the Good Devs want, now we’ll be collecting our return on investment”.

Are we too dumb or too scared to call bullshit on that?

Your dedication does not matter

Agile was a cry from the heart from engineers who simply wanted to be allowed to work.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This very principle was flipped on its head. With the advent of so-called “agile methodologies”, individual motivation is assumed - even if it is just a façade. The support and trust have been turned into endless metrics, designed to make “Individual Contributors” mere executors of a plan they had no part in making.

Caring in such places is a trap. Because no matter how much you want to care, it simply will not be rewarded. Plannings are set, “business value” decided weeks before you even heard of the request. You are the last link in a very long chain, and all you get for your implication is a creeping sense of impotence as you see opportunities being passed up.

It gets worse if you’re a subcontractor, of which we have plenty in France: so-called ESNs “Entreprises de Service du Numérique” (Digital Services Companies). Because you only get to join a project for as long as there exists a contract between your parent company and the client - sometimes there even are several ESNs nested like Russian Dolls, all between you and the client.

In the places that rely on such sweatshops, it is quite common have a dev team composed entirely of subcontractors. You get paid pennies on the dollar to work with people from a different, competing sweatshop. Like you, they also get paid peanuts. Some of them might be actual monkeys - and sometimes you’ll be wishing they were.

The client? They can only do authorized work. You’ll get paid anyway - you are leased to them. But unless they pass some budget oversight committee, they are happy to have you sit on your ass. See, there’s an overall budget against which you are billed no matter what. But to make use of your time, projects need their own budget. French bureaucracy is an art de vivre.

I have quit jobs over this.

There be (unwitting) traitors

There’s a special place in my heart for so-called “devs” who do not have a drive to do better, to be better. Their complacency enables the aforementioned life suckers. Doesn’t matter if they are bored, doesn’t matter if the pay could be better, doesn’t matter if things don’t really make sense. They’ll complain, but 5 years later they’ll still be here, maybe on a different project, but still doing the same (no)thing.

After all, if their stake in the project does not extend beyond their monthly paychek, why on earth should they care? There will be other projects, other clients. Let someone else make the decisions and worry about whether or not any of this makes sense - 9AM, 5PM, home, thank you.

Their role is to make the Jira ticket move from “TODO” to “IN PROGRESS” then “DONE”, nothing more. And they do it, all day everyday, and they do it right. They will attend the mandated ceremonies, perform the sacred rites, and deliver what is expected.

But because they have no “Software Culture”, no desire to peek behind the curtain, they cannot understand the bigger picture. So over time, the original vision degrades, lost to time and thousands “looks good to me” reviews, until the system turns into a Big Ball of Mud1.

These are the types who also think that a JSON API is REST2.

You cannot hope that they will understand your issues with what they call “agile”, because they simply are not wired for it. Doesn’t automatically make them dumb, mind you. It’s just that your passion will always be but their occupation.

SAFe

SAFe, of course, stands for “Shitty Agile For Enterprises”

  • Martin Fowler (rather, a friend of his)

From the conference A Retake on the Agile Manifesto • Humble, Thomas, Badiceanu, Fowler & Kirk • GOTO 2014.

For the fortunate souls to have never encountered this, here is a short summary:

It’s a never-ending BDSM session where devs are the gimp and there’s no safe word.

Most people do it wrong

You can’t “do” agile

It’s counter intuitive, I know. But agile is not a method, it’s not a framework - it’s not even guidelines. It’s nothing more than a set of principles you are supposed to make your own. Values to share and champion.

“Agile” does not mandate, “Agile” does not forbid.

In fact, “Agile” is not even a noun, it was supposed to be an adverb.

Agile software development has an associated cost

  • It takes time to talk to one another.
  • It takes time and resources to properly setup a continuous chain of delivery, and train people to use it.
  • It takes money to hire skilled and motivated individuals.

You cannot slap “agile” on a junior team with an impossible deadline and hope that things will work out. Jira is not a culture.

Bits and pieces seen through the years

Team weather - pick a sun, with or without clouds, with or without rain - that’s you! That’s how you feel today!

This shit is severance-tier. We’re grown-ass men, fuck off with your kindergarten bullshit.

Producing and consuming story points if it ever was in question that “complexity-based estimates” are nothing more than gamified time commitments.

Post daily meetings - ‘nuff said.

Footnotes

  1. https://www.laputan.org/mud/

  2. https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/