The Case for Dropping Agile

Agile has been around a while now. It largely feels as if it has become bloated and overcomplicated. Maybe it's time we had a re-think?

11/23/2021 agileprocess

For some reason, we love to over-complicate software development. We spend hours, days, sat reading endless blogs (such as this one #irony), listening to consultants and learning from coaches on how we should be developing software. Scrum, Kanban, XP, even waterfall are drilled into us. We plan, we point, we argue over 3 vs 5, we obsess over velocity and we dream up deadlines that we then kill ourselves to uphold.

Is it time we rethink what software development is? Personally, I think it's time for a full reset on how we develop and deliver software.

Agile in 2021

The Agile Manifesto is 20 years old this year. It's been drinking in UK bars and pubs for two years now (legally at least), and next year it's got a big birthday bash in the USA planned with all its mates.

20 years.

Scrum is even older. Having first been referenced in 1986, Scrum is 35, starting to think about settling down and having kids, all the while wondering why it can't drink like it used to.

The issue with Scrum is that, as it has gotten older, it has picked up bits and pieces of other frameworks. What was once an "incomplete framework" (and still should be), has become a gospel of ceremonies, instructions and personnel roles. Story points and velocity, for instance, appear synonymous with Scrum in 2021. However, story points originated from Extreme Programming, and even their creator is sorry.

Agile, Scrum, Lean; it all gets confused into a single, gelatinous mess.

Yet still, we spend over £1000 on a 2-day course to learn "Agile Fundamentals" and then we display our ICAgile badge with pride on LinkedIn.

I'm not saying this to belittle anyone; I myself have completed the ICAgile Fundamentals Course and am a bonafide "ICAgile Certified Professional". I say it as a micro-example of how big an industry Agile (with a capital A) is.

The definition of agile (according to Google) is "able to move quickly and easily", but how many of our practices that we so preach enable this? Do story points make us iterate faster? Do daily standups make us more efficient?

The main uses I've seen for standups so far include:

Tieing a client down to a set meeting so that we can ask questions

Detailing any "blockers" you might have and asking someone to aid in resolving them

Providing daily status reports

But any of these are easily made more efficient by communicating in real-time any issues or situations that require input. Imagine that if, instead of waiting on a daily meeting, people just communicated when a task was ready to move on, or an issue has arisen that needs the attention of multiple people, or something is going to take longer than first envisioned because of unforeseen complexity. Imagine.

I'm not saying standups don't necessarily have their place, but you have to ask yourself what their use is if you have good communication coupled with a sense of team responsibility to simply act now.

Time to simplify

I've come to believe that the original aim of the agile manifesto can be distilled down to this: deliver better software more efficiently. This is an opinion and one I'm happy to debate, but ultimately this should be our aim as developers.

One of the smoothest scrum experiences I've had was run via an (admittedly fairly complex) excel spreadsheet, a whiteboard, and a team that did code review using a word-doc template*.

We did all this, and we talked. We had a blocker? We talked about it immediately. We needed a code review? We jumped on it straight away. At standup, we facilitated useful conversation about who was needed to test what, and who could help where and when. They were more than just a status update, they were a plan for the day ahead.

Yes, we held retros. Yes, we planned in story points. Yes, we held standups. Some of these proved more useful than others, but what if we had simplified further? What if we'd have planned feature releases instead of set sprint cycles of 2 weeks? Could we have achieved more? Could we have actually been more consistent by allowing inconsistency into our release cadence? Did we achieve agility, or did we achieve scrum? Or did we achieve neither?

Ultimately, we need to arrive at a point where we reduce our wasted effort. To this end:

Plan always

But not in too much detail too far the future. Decide as late as you can and remember that priorities change all the time.

Each time you have to replan work, you've wasted your time. Each time you plan something that is then pushed back or even dropped entirely, you've wasted your time.

It's impossible to predict what the world will look like 1, 3 or 6 months from now, so don't try.

You won't eliminate this entirely, but you can reduce it.

Create only that which is needed now

Remember: you aren't going to need it (YAGNI). Or, as I see it: you don't need it yet.

Much like detailed planning too far in advance, don't develop for a requirement 6 months (or even 2 weeks) away. If priorities change then your effort is a waste. Even worst, your assumption on what is needed could be wrong and make developing the next feature much more complicated and time-consuming. Not only then have you wasted your time now, but you've also made everyone else's life harder for all eternity.

If 2 weeks later, you realise you do need it, then it'll be an almost identical effort to add it to the existing codebase. You may even find you know more about what is needed, and it becomes less effort, or simply more useful, than before.

Always look for inefficiency

People say "continually improve", but I prefer to think of this as "continually question your efficiency". Instead of saying "this is working fine but if we tried X we should be quicker", think "what is slowing us down?".

Maybe this is just semantics, but I feel that all too often in agile transformations, we forget why we're doing this and focus too quickly on what we're going to do. I'm as guilty as anyone of this, forever espousing kanban & lean but always forgetting to lead with why the current system is slowing us down.

Ultimately, you'll always need to arrive at a plan of action, so deciding the "what" will always be the end goal. But if you can decide on why you need to improve, then generating the "what" becomes a lot easier, and less prone to simply regurgitating a system from blog posts such as this.

To conclude

The term "flaccid agile" has been around for a while now. It exists to describe the kind of agile that I'm sure we've all been party to. Essentially we're breaking up a waterfall process into 2-week "sprints", crying havoc whilst brandishing a change request form every time a client changes their mind and using sprint planning to protect the development team from nasty PMs who hate that we're always late.

It's not agile's fault. It has been misunderstood, overcomplicated, and in some instances even over-simplified to a step-by-step process. It's gone from a mindset and a set of principles to "partake in these ceremonies and you'll do Agile".

Maybe it's time we gave up with it all. Maybe it's time we reset our expectations, forget about the system that was created to improve upon the 1980s, realise it's now 40 years later, and come up with a better solution.

Maybe.

*Please don't ever do code reviews via word-doc. Even Bitbucket is better than that.