Make Agile Methodology… Agile Again! by Edward Lyons

If you've been in the software industry for more than 20 years, you remember life before Agile methodology, and what a revolution it was. Yet more than two decades in, this methodology is as much a religion as the waterfall/factory model was before. It is fair to say that for many organizations, Agile has become inflexible. How did this happen, and what can we do about it?

To review: In the old days, the process was the project. You knew what phase you were in, you knew what documentation and other artifacts you needed to produce. If you, as a technical person, felt the project was not going to succeed, or that the architecture had problems, you didn't feel as if you could object. After all, the requirements and design phases were over.

Agile liberated us from a lot of process and documentation that had little value. People implementing the project could say more about what was happening, and the users were consulted for a lot more of the project than before. Cycles were shorter, and developers didn't spend six weeks implementing something that didn't work out. It was liberating, and more accountable. It was a culture change for sure, but it was a revolution that made great promises.

It certainly succeeded wildly! As one developer said in 2021, "Agile has won. Nobody wants to be called non-agile." True! There really is no such thing as "Agile" if everyone says that's what they are. Yet, despite such widespread adoption of the word, it is amazing how often working in this environment feels like the opposite of the revolution we joined.

When I mentor young developers who want to enter the field, I tell them quite soon that it is an agile-and-ticketing world, and they absolutely need to know how things are done. That lecture does not sound like a promised land of developer empowerment and velocity. It sounds like a strict new regime that they must comply with. And the original waterfall problem, where developers felt alienated from the project's success -- can still happen in Agile, where a developer can see an ocean of small, actionable tickets, and still wonder if they will all add up to a product that will work well.

I sometimes get caught up in the rigidity that comes with standardization.

A few years ago, I was working on a project, and noticed that our sprints sometimes didn't reach their goal because of how the tickets were queued up for testing. It felt like a sprint's success was slipping through our fingers due to people not thinking of how best to use the time of our testing team. Near the end of one sprint, I told my fellow developers, "I think we should go to the conference room and talk about the tickets and how they are going to get through testing." The reaction was uncertainty, "I didn't see a meeting in the calendar."

But we met, and sorted things out, and that sprint succeeded, where the last one did not. Everyone agreed this was good. I then went to the development manager and told him that we met, and asked if we could keep doing this. He took off his glasses, rubbed his eyes and sighed. "Agile methodology was supposed to be self-organizing. We've forgotten that. Yes, keep doing this."

This developer meeting was so effective that it did become standard. Yet why did I feel the need to ask permission?

I have seen other examples of where Agile has lost its way. Some managers will have a standard meeting, even if there isn't much point to it. The bias against documentation, a big part of the initial revolution, has resulted in needed technical documentation not getting written. I have seen developers play games with the point system, realizing that by overestimating the time on a ticket, they will give themselves more breathing room later. I have also seen a team of eight engineers spend half an hour in a "refinement" meeting, arguing about the nature of a half-day ticket. Over the years, I have also seen standups and retrospectives at times become more performative than sincere. I have also seen project managers feel the need to attend and record every single technical meeting, even though virtually no one watches the recordings, and that recording can cause some to be more constricted in important conversations.

Yet I have also seen project managers show great flexibility. Project managers who are willing to cancel or repurpose a standing meeting, and ones who listen to developers and stakeholders, and do not let the ticketing system get in the way.

I have also seen fellow engineers reach out to team members proactively to offer assistance outside meetings, and also use whatever tools are necessary to get the job done. I happen to be a big believer in documentation. Not the kind we had during the days of waterfall methodology, but something more humble, useful, and focused. My project managers have supported this.

What Agile originally said was that if people on a project understood what the users needed to do, and were connected to them, they would be empowered to produce better software in less time. Yes, there needs to be process and tooling used by project managers to help make decisions on tasks and priorities. But if the process, tools, and meetings do not feel useful, than this isn't "Agile" anymore. People who would rather make progress instead of going to standing meetings were the people in the 1990s that Agile was supposed to help.

Good project managers will listen to questions about how to make the process more useful. Good project managers won't mind if you need to post your standup update in writing rather than in a meeting if you can't make it, or if you ask for a meeting to be canceled if there is little value in it. Good project managers will accept someone saying, "I think we technical people just need to meet ourselves to discuss our options, and we are not going to record it."

I have found that once you start talking about the process and what will work best, people really do listen. Silent acceptance of a process that isn't helping you is why we got Agile in the first place. We should remember that, and speak up.