Developers Should Abandon Agile

I don't mean to be harsh on anyone, but after working for over a decade in enterprises, mediocrity seems to be the norm. There are of course bright and insightful people, but mediocrity is pretty much the standard. Take any good process, technical practice or whatever and see it be abused and misused.

With Agile what happens is a mediocre implementation that usually leads to the usual complaints we see about Agile. The number of times I've been told about how Scrum enables self-organising teams only to be told I have no control over the process because it has been standardised across the company.

Mediocrity demands cookie cutter solutions that can be standardised without need to engage thinking. If you work in an incompetent organisation, department or team, then there's no hope that agile or anything else can help you. In fact, the religious nature of Agile often works in favour of mediocrity as critics, even well-meaning ones, get labelled as waterfall sympathisers.

Here's a tip: calculate the cost of every meeting by taking your salary (or an estimate of the average salary in the room), dividing by 52 and then again by 40, doubling it, and multiplying by the number of people and then again by the number of hours in the meeting. Alternatively, nevermind the salary calculations: subjecting 13 people to a 3 hour meeting wastes roughly a full-time human-week of productivity.

Agile is about finding and continually adapting methods that work for the team in its actual concrete environment, but the manifesto doesn't address how to do that, and the Agile literature is all about particular methodology and not about how you manage evaluating and adapting processes as a tesm.

The critical part of Agile has almost no coverage in the Agile literature.

And I say this as an agile critic.

I'll have you know that Ohio has some pretty good developers and some pretty good Agile training.

There's an old saying in consulting. It sounds really facile and dumb, but it's actually quite deep: people like doing what they like doing. That is, inside of each of us we have proclivities to act in different ways. I like thinking conceptually and writing. This other person likes thinking tactically and keeping things organized. No matter what situation we find ourselves in, somehow or another I end up writing and thinking conceptually and this other person is responsible for keeping organized and worry about immediate problems.

The organization -- any organization -- is simply a collection of people like that. They have a natural equilibrium, and no matter what kinds of things you say you're doing or not doing, they eventually come back to that happy spot. What we're really talking about here is a version of regression to mean, only in a social sense.

If what I'm saying is true, what conclusions can we draw? My money says that anything worth doing should be something that makes you uncomfortable in some fashion. I'm not talking unrealistic deadlines or micro-management. "Being uncomfortable" could simply be the development team taking a day and working alongside the people they're trying to help.

I looked at this entire problem sideways in my Info-Ops book: https://leanpub.com/info-ops -- Instead of looking at what people did, I looked at how information was handled and moved around. I found it insightful. One of my conclusions is that discovering and creating anything of value is all about tests, either business or development tests. Thinking in terms of tests allows solutions to happen in dozens of ways, but whatever solution is chosen, you get the results you want. Compare that to the ways we usually do things, which is the reverse. Usually we start with some idea of how we want to do the solution and then try to use that to make something people want -- but it seems like we're never really sure that we're building the right stuff. And meanwhile we're all back to doing things we like doing.

Tests allow us to be ourselves while constraining what we're doing to things that are valuable. I think people grok the idea of tests when it comes to TDD. Somehow they lose focus when it's about other things, like processes, methods, rituals, and so forth. But frack, that's where they matter the most.

I don't think you go beyond agile by changing the name or disavowing it. Unless we come to terms with what the root of the problem is? It'll just be the same thing ten years from now with new buzzwords. We've been doing this for decades in technology. We should be able to do better by now. I don't want to keep playing whack-a-mole with buzzwords and people's happiness.