Post-agile process agnosticism

with Rick and Morty!

Agile hype is over. I think agile movement is very close to the lowest morale point in time. Everything is monetized, marketized and enterprized. SAFe is conquering companies. Scrum and Kanban are marching into non-IT world. Agile Indu$trial Complex have won the game and collecting cheques.

State of affairs

Agile leaders try to resist and keep true agile spirit intact. They are failing to pierce the bubble though. Tool vendors and consultants are winning.

Programmers were quite enthusiastic about Agile 10 years ago. These days are gone. Now agile more often meets with sarcasm and resistance:

After doing software for almost 30 years now, I honestly believe Agile has been the most destructive thing to happen to the industry. Software has become buggy shit that’s shoveled out the door as fast as possible. It’s not just your development team, it’s all development teams.

Unfortunately, Agile painted Dark:

I’ve worked at four companies that have claimed to do agile development. Not one of them has deeply embraced the principles of doing so. Generally they have added a few easy practices, like stand-up meetings and sprints. They’ve kept large-scale chunks assigned to specific developers, defining both the work to be done and the time to do it, and substantial design docs. Unit testing tends to be spotty.

We’re not living in Agile World. We’re living in Fake Agile World.

I don’t want to reflect why it happened. Most likely it was inevitable evolutionary trajectory. Every niche is occupied with money eventually. The reality is this: we are living in a world where BDUF is anything beyond 1–2 days, KISS is a motivation to rush, and marathon is a luxury.

How to fight it? I suggest to resist with

Process agnosticism

Process agnosticism is simple. Just one rule. This is how you do it as a programmer:

You don’t give a fuck about process name, until you have full rights to modify and change the process.

Sounds easy, but there is a trick here. If you want to be in full control, you should care. If you don’t care, you deserve to work as management commands.

OK, so you do care. What’s next? You will face offenses from management like: “You don’t have knowledge about processes efficiency, you didn’t even visit any Scrum training!”, “You know nothing about departments management and cross-team collaboration”, and of course “company is a complex thing and you don’t have full picture to make decisions”. If you do care, the arguments above are joy to refute. You can ask several “why?” and make manager cry. But we’ll be merciful here.

Programmers are smart and well educated. Programmers are engineers. Engineers are dealing with systems. People, Teams, Departments, Companies and Markets are systems. System thinking (whatever it is) can be applied to these entities as well. In my opinion most engineers are more capable in building efficient organizational processes than most managers. The only problem is that engineers usually prefer more predictable systems to less predictable systems. However, when programmers do care, they definitely invent ways how to work more efficiently, maintain quality, solve problems better, deliver faster and enjoy customers feedback.

I think every engineer (who do care) should control her development process and fight for control. Fight with managers, shitty policies, dumb structures and poor product roadmaps. Fight using science, systemic approach and collaboration. We need Engineering Union in every organization.

Fight for engineering control (OK t-shirt)

This fight is not for any particular process. This fight is not for Agile, Kanban, Scrum or Waterfall. This fight is for the control of your job.

What’s the role of managers then? Managers should help teams become self-aware and self-organized entities. This is mostly done through education and mentoring, not decision-making and control.

Process agnostic tools

All tools in development teams should be process agnostic. Process agnostic tool has just one major requirement:

It is easy to tweak the tool to support any changes in development process.

Unfortunately, most vendors build opinionated software that forces teams and companies to use some by-the-book process. Moreover, most tools are not flexible enough to support even minor process changes. Trivial example: you decided to review every task with duration > 14 days. Most tools are unable to highlight such tasks, thus this practice is not automated and tool just doesn’t help at all.

More severe problems are caused by process-opinionated tool selection. You decided to try Kanban and purchased Leankit. Now Kanban is your destiny, tool forces you to continue doing Kanban, even if you decide to try Scrum. Cost of switch is high, you will have to change software, migrate data, train people, and that is not easy. Or maybe you decided to try SAFe and purchased AgileCraft. It means you will have hard time changing SAFe to something else (and the time will come). Or maybe you somehow decided to go with VersionOne, and now you can’t run any process effectively.

Process-opinionated tools make organization heavy and slow. Maybe they were created with best intentions, but the final result is anti-agile.

You will have to be very creative to solve opinionated-software crisis.

True software development tool should be process agnostic. Team should decide how to work and tool should obey. In some cases team may decide that Waterfall is the best way to run small projects, and tool should provide this possibility. Unfortunately, you will have hard time finding any agile consultant that will recommend Waterfall. Unfortunately, you will not find any tool that supports agile processes and Waterfall in a good way.

Agile hype is over. But engineering is not.