After the death of Agile

Here is a translation of the author's article Doug Bridgens, in which he reflects on his experience and critiques Agile. His article contains no analysis or argumentation at all; these are personal reflections on the topic of a particular developer.

This is my second translation and I will allow myself in this preface a couple of sentences about why I spent my time on this translation:

1. The article is small in volume and will not take much time;

2. The article raises a question and gives a practical answer to it;

3. The article touches on a topic that is interesting to me personally – a retrospective look at modern trends;

That's all, enjoy reading.

What Happens After Agile Dies?

I started programming in the 1990s, working on Unix OS. Our “office” in those days was called a laboratory, and we revered the old-timers who only worked at night and sent updates via email in scattered files.

Google, Linux, Amazon, cookies, Wi-Fi, laptops, etc. – all this is still to come. At the time, there was excitement about DNS technology, which was rapidly gaining popularity and would eventually provide something called the World Wide Web.

During this time I was working on SCAFS, which was a hardware cache between the OS and the hard drives. It cached SQL queries and provided a performance increase of more than 20 times! Great result for the times SCSI tires

Back then we were a small team of specialists in various fields from developers to sales managers. We had bugs, features and a roadmap. We interacted with customers a lot and took part in trade shows.

Our product was autonomous, but at the same time integrated with the OS and database. I think we released updates every three months, and bugfixes were rolled out even faster (and this was on magnetic tape!).

Looking back, I feel that it was in this informal setting that I completed my training. I met a lot of different people with different approaches to work. People and the community taught me to be accountable for my work and helped me realize the importance of effective communication.

Today I can confidently say that we were a young, energetic team capable of working asynchronously.

No formal framework was imposed on us. Management and micromanagement were needed only by unformed teams; we were expected to be adults. Ideas and opinions spread freely, unlike today (how ironic!) – the time of dogmatic Kafkaesque trials.

I'm disheartened by what business has done to the development process. Agile is the business version of the design process, imposed on developers as self-development. It is a cult that fuels narcissism.

I'm currently working on a web application and my thoughts are on how to write less code. Is 11,000 rows more likely to have fewer errors than 22,000?
One of the risks of solo development is that the project will take a huge amount of time to find and fix bugs. This is a pure business approach.

If you want to spend less time on code, you need to spend more time on development, which ultimately leaves even less time on code…

I aim for weekly deployment. And here is my template.

From Monday to Thursday I develop my plan while walking or doing my own thing. Ideas seem to appear when you least think about them. Long walks to interesting places are the best time to put your thoughts in order.

From Friday to Sunday I write code. When you don't have to make any design (architectural) decisions, coding is easy and fast.

This approach is contrary to Agile. Intuitively counterintuitive to what we're used to, but try it for yourself: try the task AdventOfCodespend a couple of days developing a plan and only then sit down at the keyboard.

Spending 80% on planning and 20% on implementation may seem counterintuitive. But this leads to faster development, lower operating costs and increased motivation. It changes things when you realize that developing good software isn't really about writing code.

This way of planning is actually nothing new. It aims at more effective communication. In my case, I communicate with my future self through a step-by-step guide.

My hypothesis is that code review will give way to other quality assurance methods, meaning that only my walkthrough will be reviewed, and the code will be a reflection of it.

Therefore, in a post-Agile development world, companies that refuse micromanagement and embrace the idea of ​​autonomous development will create a better product.

Sample

I created this template in the Things 3 app for Mac and iOS. I wanted a simple task management that I could read and edit on the go. The ability to display tasks as a widget on the home screen works great as a space limiter.

#### Trigger

What happened to make this worth doing.

#### Purpose

What functionality MUST be delivered.

#### Strategy

- High level decisions I will take to do this.

#### Thoughts

- Any context to decision making, peripheral things, knock-on's, etc.

#### Walkthrough

- [ ] First thing to do

A task description. Adding pseudo code lets me evolve function/var names and types as I build up the walkthrough tasks.

func loadData(id int64) account.Data {
    if !dataExists(id) {
        fetchData(id)
    }
    return getData(id)
}

- [ ] Second thing to do