The final word about agile. It is dead. Not dead. Or…what? (and of course: Kanban boards)

There are countless articles about Agile. And the use of agile. The usability. The statistics.

Real agile. False agile.

The end of agile. The death of agile. The resurrection of agile. The always agile. SAFE agile.

This article is to have the final, determining say about agile. Am I brave? Yes, for sure.

Do I give you the answer you wanted so much: yes.

No.

Maybe.

Before you proceed please have a 2 minute-long thinking about what you fundamentally think about agile:

-is agile dead?

-is agile useful?

-is agile applicable?

Please write down the results.

Now read on. No TLDR, please. It will be a long long article. But you will love it. I know. At least the flow of it – if not necessarily the conclusion. Do not scroll down, please. Do not skim it. Please. For your own sake.

I invite to the most precious thing in the world: thinking. Thinking together.

A kind reminder: what is agile – briefly

The original Agile manifesto said very little in a disturbingly short format:

https://agilemanifesto.org/

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

A kind reminder: what is agile – in a long format

And even the longer format was not…long enough.

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

What can you notice first?

Is the Agile manifesto a scientific text? A scientific enough text? The Agile manifesto is a statement of faith – just like a verse in the Bible or the Koran or the Yoga Sutras

Our reasoning is that the Agile manifesto, although written by software engineers, in its original form is closer to a verse in a religious book than it being a strict document, not to mention a real engineering piece of scientific method or being a “law”.

Did you notice its form of being a verse? Do you think it happened by chance? The only thing that is missing is the rhythm.  But: in several modern verses the rhythm is missing, as well.

Have you ever read any of these religious old texts? And: have you ever come across commentaries relating to religious texts?

Have you ever tried to agree with the author? Or go against him/her?

If you read these commentaries on religious texts: they will not 100% agree with each other. Or let’s put it in another way: they will, 100% sure, disagree about the same source text. If you read popular commentaries of the Yoga Sutras: what you will read will depend on who wrote the commentary and when. There are debates even about the meaning of single words. By the way, my favorite Yoga Sutras commentary is this one, enjoy.

The same is true for the Bible. Have you read the book: East of Eden by John Steinbeck? The entire book is about the meaning of one word in the Bible: „timsel”. I will not give you what this book’s take on the meaning of the word „timsel”, but let me tell you that it fundamentally differs from what is assumed about this word’s meaning at the start of the book (of course, if it was the same then there were no story…).

Are you lost? You should not be: such is life. And such are verses: they are built from words. And words are, to say the least, loosely defined.

In other words (words, words, words – I have to explain what I want to say in another form so as to make sure that the message will be at least 80% clear): these kind of books are not filled with mathematical formulas. You cannot agree on even the base definitions and, besides, you cannot check the validity of the statements one by one, either.

Disturbing, right?

How do these religious texts and the commentaries differ from the verses from the Agile manifesto? Do they? Really?

The Agile manifesto is a statement of faith – and one can still ask the authors

There is one difference: the authors of the Agile manifesto wrote additional books and they can be still asked: “hey guys, what did you really think?”. They wrote their own commentaries. But: still: what percentage of the readers have read these articles or books?

And what percentage of the readers work based on hearsay (re: what is agile)? And what percentage of the readers know the Manifesto by heart AND have read and processed the books?

I have a disturbing assumption: the majority of the people do not care (not only about Agile but about anything specific in life). The rest can be divided into additional parts:

-people who do care and as a result try to read, learn, educate themselves

-the same as the previous, but try to check what they learn against reality

-the same as the previous, but once they learnt whatever they wanted – they apply it

-the same as all the previous ones together but they are able to rise above it all, then learn, by themselves from themselves – with introspection

How about the Agile manifesto? You should read it. Digest it. If you love it: learn it by heart. Repeat it every day, just like believers do it with religious texts. I am not being sarcastic here.

Have you ever heard about the word: „japa”? Check out what that means. Then buy your japa mala tool and start to use it on the Agile manifesto: repeat it every day, for years. While doing so you will know what you are talking about (a.k.a. credibility) and be able to compare what you are experiencing with the statements in the manifesto. This latter is good for later introspection.

The last sentence of the Agile manifesto

The last sentence says that “there is value in the items on the right”.

As such they could have written that: yes, there is value in processes and tools, comprehensive documentation, contract negotiation and following a plan. The authors just did not. Because they valued more things “on the left”:

-individuals and interaction

-working software

-customer collaboration

-responding to change

This, in itself, again, weakens the standpoint of hardcore agilers: who cannot even make a cup of coffee without a sprint.

Guys (and girls): noone, read noone wrote you that you should not use, apply processes and tools. Have comprehensive documentation. Or have contract negotiation. Or follow a plan. They just said that these, according to them, have lesser value than the previous, more valued stuffs.

What is of extreme importance: what can also be agile – or not: we do not know

And we arrived to the most important reasoning of mine: not only that the Agile Manifesto is very far from being a scientific text – and as such it is only applicable as a text of faith and not a text of science, the latter to be used for hardcore engineering projects in which end users become extremely happy or they want to kill themselves – or get killed by the software you build (do I have to link here to other articles? Really? You know that software killing people happens).

So not only that the Agile Manifesto is very far from being a scientific text, but also noone wrote one very important thing: its scope: where, when, how and by whom can it really be applied?

Think about that: just because living in an open relationship, using recreational drugs, or using non-recreational drugs (have you ever heard about the #Grandmother ceremony?) walking the El Camino every year works for some of us – it will work in every situation for everyone.

By the way: El Camino: the author who wrote a book about his adventure during this trip surely became famous. But he did not became famous for being a scientist. No, he did not get a Nobel prize as a result of this. And: noone is trying to build tangible stuff, apart from ruining or improving his / her life (and the life others around him/her), based on his stories.

And: no, I do not think that anyone who has feelings and or believes in things – is stupid. Very very smart people can become believers, as well, based on their own experience.

My belief – and it will be yours, too

So: let’s face it up: the authors of the Agile Manifesto did not clarify the statement’s scope. Nor they did use statistical tools to analyse some fundamental factors and check how software project success depended on these factors.

What kind of factors I am talking about?

Again, before going on with reading, think it over, what kind of factors may come to my mind when it comes to software projects?

Can it be the case that Agile fits much more properly some type of projects whereas it can be a complete failure for others?

Give it 2 minutes, think and collect these factors for yourself. Write them down, please.

So: the authors of the Agile Manifesto have never had a scientific statistical analysis of different types of projects and their success. They just merely became happy that they came accross some patterns that worked.

The problem is that they forgot one thing: these patterns worked for them. When you had some problems before – and you come accross a solution: you are happy. If you are not endlessly selfish – you want to share your experience with others. This is what happened to them.

But: there is even more to it: these patterns worked for them in certain situations.

So: they found that Agile worked. But:

-what was the project fundamental type? Building a mission critical system from scratch, or building another Tinder?

-what was the legal form of the organization that ordered the work? How long did it exist before?

-what was the initial project size? In mandays, functions, screens, lines of code

-what did they build? A consumer app, a business app, a complex app, an app with a UI, an app that optimized?

-was there a contract?

-was it an internal development or an external or a mix of both?

-was there already existing code base to build on? Or did they build from scratch?

-how did they define project success? Did they?

And many others that just simply did not come to my mind.

And here comes my assumption:

To prove some of the above, read these 2 articles:

Agile software development is dead. Deal with it

Final final conclusion about Agile

The final conclusion is: that it depends.

It depends on the situation you, your company, your team is in.

And remember: why you are being paid, especially if you are a manager is primarily one thing: make educated judgements – well.

So the call is yours. Easy.

Just do not do one thing: do not believe. Think, instead. It helps.

If you still cannot sleep well

So you are just in the middle of implementing Agile at whatever bank, retail chain, university. Everyone around you is a scrum master already (yes, yes, I know that scrum and Agile are not the same thing, I know).

Or you have been all your life an Agile lover. Believer. Or a Waterfall conservative.

And then you read this article. What happens now?

Find your next project. Just do not try to decide, based on your beliefs, alone.

If you still want another result

Do it for yourself. And ourselves as well. As we are interested like hell, in the results.

If you are still in love with any of the methods mentioned here and want to become really useful and possibly even famous (at least in software circles) – then find a few statisticians and run a survey of software projects with the factors above as inputs and project success as output.

Of course if it was this easy, someone has already done this. But I am afraid there is no really unbiased such research (not only a survey but a real scientific research) available about software projects.

(No, I am not talking about the state of agile surveys and similar other surveys, either. I am talking about controlled, well-designed, as-much-as-possible independent research projects about software success).

Do you think I am finished? Not yet

A final final word: about Kanban and Kanban boards. These were just again invented for specific situations with a number of open tasks, issues not higher than „N”, for tasks of certain type, that appear, disappear within a given amount of time in a specific type of organization while developing certain (in this case tangible) products.

A Kanban board is magical to some (just click and see how many results there are for Kanban software: this is an impressive number in itself), while for others a Google sheet with 4 columns will do the same trick.

To all Kanban-lovers: do you hate me for writing this? If yes, then it is your faith making you feel like that.

A Kanban board can accommodate tasks for a team of a handful (maybe up to 10) people having open issues, tasks of no more than, say, 100 (no I do not have a scientific number for this, either, nor you have it, I am afraid).

But: how can you effectively manage 1000 tasks, open issues on one Kanban board? You can, of course, it is just impossible to oversee what is really going on. So the Kanban board, while it can be used for that as well (I personally know of at least one person who would excel at doing so) it does not mean that you should.

So the Kanban board is possibly (again, again: no scientific proof for this is available, it is only my belief) for a fast-paced project with a team of 10, with issues, tasks not more than 100. Shoot me. Of course. If you enjoy shooting, just go ahead.

+1 – 2023 update – the article about something very similar:

Agile is the spolied child of a decade of easy money

https://blog.bennett.ink/agile-is-the-spoiled-child-of-a-decade-of-easy-money-7c94bfc1ddf2