Photo by Andrew Neel

There was a time where most software was built under the waterfall model. You gathered requirements, then designed your system, then wrote the code, shipped the code to QA, then shipped the code to customers. A nice perfect assembly line.

Except software development isn’t an assembly line.

When you get a physical product off an assembly line, you can’t just go “oh this would be perfect if we make this small change here in the product. Can you please reconfigure your whole factory?”

Anyone following the waterfall method today would be stuck in the same position. Every small change upends the entire process. The sluggishness of that process puts those products at a competitive disadvantage from the teams that are releasing software every week. Or every day. Or dozens, even hundreds, of times a day. Products developed using waterfall can’t meet demands of today’s consumers.

Yet, waterfall was “how things were done” in the late 20th century. It resulted in software less able to meet user needs whilst also being extremely grueling on developers. Today software teams experiment with 4 day work weeks. Under waterfall, a 40 hour week was a light week, especially when a release date was close.

Enter agile software development.

At its core, the idea is to focus on what’s most important. You don’t just work on something because it is in a requirements document. You work on something because it provides users value. You don’t write a document because it’s just “how it is”. You write documents only if they actually help.

My favorite line of that manifesto is: “Individuals and interactions over processes and tools”

Contrary to what some people believe about agile software development, this does not mean there is no process. Every developer is different and every team is composed of unique developers. There is no one process that will work for all teams on all projects. I once had a team that did will with story points. So we used story points. I had another team that struggled with story points. We tried alternatives.

The process needs to adapt to the team, not the other way around.

The problem is that this is hard. You can’t just follow a script laid out for you. You have to actually reflect on how the team is operating and make decisions on how to improve. You constantly need to practice critical thinking. And it takes a lot of practice to do well. You have to accept that things aren’t going to be perfect.

Enter the agile consultants.

Before I continue, I’ll start off by saying this isn’t a generalization of all agile consultants. I’m friends with quite a few of them. They do a decent job. I did a brief stint as an agile consultant. I like to think I did a decent job.

The problem is that doing a decent job means helping people get that practice of thinking critically about their process. It’s not about building a process for them. It’s about enabling them to iterate on their processes on their own. Without us.

That’s not a great revenue generating strategy for any consulting firm.

It also isn’t what a lot of people really want. They may say they want that, but they don’t. They go and find a consultant who will give them concrete answers. They want the playbook. They want someone to give them a process to follow.

And there will always be people willing to fill that demand.

These agile consultants will provide the processes that you absolutely must follow to be “agile”. They will provide the certifications that “proves” you know how to do agile properly. They will certainly accept your money in exchange for all of this.

The waterfall model, whose main issue was the rigidness of the process, has simply been replaced by a different series of rigid processes that are called “agile”. In truth, anything that focuses on the process instead of the people is the exact opposite of agile software development.

Story points. Sprints. Scrum roles. These are all process tools. Agile consultants can make a lot of money telling you exactly what tools to use and how to “properly” use them. In reality, these tools are like anything else. They can be used well to help your team build software. They can be misused to hinder your team’s productivity. The point of agile software development isn’t to blindly use a tool. It is to evaluate your situation, try new things, and if they don’t work: try something else.

When thinking about the development process for your team, I urge you to save your money on these consultants and focus on that first line of the manifesto for agile software development: “Individuals and interactions over processes and tools”