Experience-driven Instinct

Hopefully the most confusing byline of all time. Square these circles for me. I dare you.

I'm currently searching for a new role, going through the rigmarole of technical tests with people I'm vastly more technical than, cultural fit interviews with people who have never built teams above 10, and final round interviews with founders who have never taken a company past 1M ARR.

Woe is me dear reader, woe is me. But sometimes life throws you diamonds, and holy shit was this one shiny.

Yesterday I went for an interview for a company I'd never heard of. It was a direct meeting with the CEO, which struck me as weird because normally the C suite is gated. Well, weird is good - this guy was a gun, and had done me the courtesy of actually reading my resume. He interviewed me as someone who had experience in starting companies, growing teams, operating with mandates etc. I don't think we even talked about technical outside of broad project delivery. He also (consciously or subconsciously) answered a raft of questions I had in his opening spiel. It is so unbelievably refreshing to have these discussions.

During the meeting he mentioned the company had adopted the Basecamp Shape Up delivery style and it had been transformational. I'd never heard of this style before, but I had such a positive interaction with him I immediately jumped into Basecamp and started reading.

Holy shit stick in a puddle of mud. These guys get it.

The Gaping Maw of Useless

Like most people I've been on the agile scrum train for at least 10 years. I've never seen it really work long term - the backlog forever grows, people quit, sacrifices are made and tradeoffs to be solved later are workshopped and added to the backlog and never get done and for Christ's sake the never ending meetings fuckkkkkkkk.

My take on this has always been something along the lines of oh... its just not done properly or oh... we weren't tight enough with the project scope or oh... the PM is sacrificing the engineers on the alter of corporate career progression by making impossible promises, or some other generic reason plucked from the bucket of general responses for another failed agile project.

Like most people I believe I'm somewhat immune to herd mentality. I'm a smart, independent, objective critical thinker. Right? Lets see what the mirror of self reflection has to say: Wrong bucko - you're as dumb as a pile of particularly stupid bricks. I've always put the endless failures in nouveau agile due to myself and the teams failure to adhere to process. The problem wasn't the discipline, no, the problem was that myself and others lacked the discipline to follow the methodology. We just had to be better and the secrets of successful product delivery would unfurl before our eyes.

Here's a hot take: agile sucks. Always has, always will. Agile cannot be done correctly. It has never worked and never will work. And the reason it falls apart so quickly in every single project both you and I have ever been on is because it sucks. It sucks not because of lack of discipline - it sucks because its a process that in no way captures reality.

Here is a single quote pulled directly from the Shape Up book, with my commentary helpfully added.

Our project teams consist of either one designer and two programmers or one designer and one programmer. They’re joined by a QA person who does integration testing later in the cycle.

This. Just this. 1000% of this. In my experience the best work is always done by one person that is deep inside a problem. Sometimes you get stuck on a tiny piece of the entire thing and need to "talk" to someone to work through it or get some arcane piece of knowledge you weren't aware of; but realistically all great and ingenious and elegent work is a one (wo)man affair with short periods of thinking and short periods of explosive production and long periods of tinkering and learning.

Lets compare this to some common agile claims...

Pair Programming

The Promise

You can share ideas and cross polinate knowledge!

The Reality

You have two people with vastly different skill sets and experience trying to come to a consensus on an issue. This means that the issue is never properly explored and great solutions are never discovered because you're both trying to agree at a surface level understanding of a new thing.

Early circuit breakers on bad design decisions

The Promise

Having two or more people on a problem can accurately stop bad choices entering the implementation

The Reality

Its absurd that we talk about iterating on development in the macro, and yet when rubber hits the road we don't do it in the micro. The correct way to do this stuff is to fuck around with the problem, try new things and get a Macguyver contraption working.

Having 1 or more people overlooking your shoulder saying "no" before you have a working anything means you never get to feel it out. You don't ever get to prototype and get a sense for it. Nope, your process is end solution building from day one - and this is monstrously damaging to both engineering creativity and engineering discipline. Great work comes from insights, and insights come from experiece. And experience comes from trying and failing and learning, even in the narrowly defined micro builds.

Reflections

The truth is that some part of me has known all of this for a long time. I was lucky much earlier in my career to break away from the blind adherence to the cult of OO programming. I had a set of loosely coupled opinions driven from experience that told me OO was wrong. I couldn't tell you why, I couldn't define how, but I had this instinct that knew it was wrong. I went searching and discovered Ocaml and functional programming and nothing was ever really the same again. This was driven in large part due to changing languages and runtimes but not paradigms and still encountering the same fucking problems. I realised that the tool was wrong, so its time to get a better tool.

Perhaps with age I have become calcified, but I'd never done this with agile. Instead of questioning the tool, I'd shifted blame elsewhere - its me, its the team, its the PM, the requirements are shifting etc. The process is perfect if we follow it. We are the ones at fault. We are broken. Heil Fowler. But across dozens of projects, large and small, and hundreds of developers and PMs and POs and BAs I've never seen agile work.

I thought I was calculating and objective and independent and critical in my thoughts, but like the masses I jumped on the agile bandwagon. I was lazy and naive and wrong. And now its time to get off.

Agile is broken. Agile is defective. Agile is a morale crushing, creativity destroying process that leads to nothing but angst and stress and useless meetings. The people spearheading it and its stalwarts are the least productive members of an industry. Ignore them with contempt.

Back to this articles byline - fuck agile. Stop worrying about agile. No one cares about your burndown charts. Tactically nuke it all from orbit. Enjoy the destruction. Save Newt.

git gud.

---