The really final (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 minutes of thinking about what you fundamentally think about agile:
-is agile dead?
-is agile useful?
-is agile applicable?
Please write down your own conclusions first — so as you remember after you have read this below.
Now read on. No TLDR, please. It will be a relatively long long article. But you will love it. I know. You will love 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 you to the most precious thing in the world: thinking.
There is one more thing that is even more precious: thinking together. Let’s do it!
A kind reminder: what is agile — briefly
The original Agile manifesto says very little in a disturbingly short format:
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 is just 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 do you notice first?
Is the Agile manifesto a scientific text? A scientific enough text?
Well. 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 the religious old texts? And: have you ever come across commentaries relating to religious texts?
Have you ever tried to agree with the author? Or reason 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 very same original “source” text. E.g. if you read popular commentaries of the Yoga Sutras: what you will read will depend on who wrote the commentary and when. There are (very serious!) 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 single word in the Bible: ”timsel”. I will not give you what this book’s take on the meaning of the word ”timsel” (no spoiler please!), but let me tell you that what is eventually made as a conclusion — fundamentally differs from what is assumed about the very same word’s meaning at the start of the book (of course, if it was the same then there were no story…the entire book is about).
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 even agree on the very base definitions nor you can check the validity of the statements one by one, either.
Disturbing, right?
How do these religious texts and the commentaries differ from the verses of the Agile manifesto? Actually: do they differ, at all?
The Agile manifesto is a statement of faith —the only exception being that one can still ask the authors.
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 is 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 people do not care (by the way: not only about Agile but about anything specific in life). The rest of people can be divided into additional groups:
-Learners: people who do care and as a result try to read, learn, educate themselves
-Thinkers: the same as the previous, but try to check what they learn: against reality
-Doers: the same as the previous, but once they learnt whatever they wanted — they even apply it
-Appliers: 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, several times, 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 introspection.
The last sentence of the Agile manifesto
The last sentence says that “That is, while there is value in the items on
the right, we value the items on the left more.”.
As such they did explicitly write that: yes, we do see value in processes and tools, comprehensive documentation, contract negotiation and following a plan. They just valued things “on the left” more:
-individuals and interaction
-working software
-customer collaboration
-responding to change
This, in itself, again, weakens the standpoint of hardcore agilers: people 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. Or have comprehensive documentation. Or should not do contract negotiation. Or not to follow a plan. They just said that these, according to them, have lesser value than other, more valued stuff.
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 just the opposite: they want to kill themselves — or even get killed by the software you built (do I have to insert a link here to other articles? Really? You know that software killing people happened several times?! We have a lethal profession, it seems).
So not only that the Agile Manifesto is very far from being a scientific text, but also noone stated explicitly one very important thing: namely: its scope: where, when, how and by whom can agile 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 not work in every situation for everyone.
By the way: El Camino: the author who wrote several books about his adventure during his camino trip became very famous (Coelho, anyone?). But he surely did not became famous for being a scientist. No, he did not get a Nobel prize in any sciences as a result of these books. And: noone is trying to build tangible stuff, apart from maybe ruining or (hopefully) improving his / her life (and the life others around) based on his stories.
And: no, I do not think that anyone who has feelings and or believes in less tangible things — is necessarily stupid. Very very smart people can become believers, as well, based on their own experience or things they read. It is just good to separate science and faith.
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 projects’ success depended on these factors.
What kind of factors am I talking about?
Again, before going on with reading, think it over, what kind of factors may come to your mind when it comes to software projects’ success?
Can it be the case that Agile fits much more properly some type of projects whereas it can be a recipe for 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 most of the time.
The problem is that they forgot one thing: these patterns worked for them. When you were facing some problems before — and then you come accross a solution: you are happy. And: unless you are endlessly selfish — you want to share your experience with others. This is what happened to them.
There is one problem: these patterns worked for them in certain situations.
So: they found that Agile worked. But:
-what was the project’s 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 the organization 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 some economics question (e.g loading trucks the best way possible)?
-was there a contract they needed to stick to?
-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?
-was this code base used by many other businesses?
-how did they define project success? Did they?
And many others that just simply did not come to my mind.
And there comes my assumption here:
Critical or non-critical What was the fundamental type of the software? Consumer, non-critical app:
E.g: Tinder, Facebook (sorry Facebook!), Google
Mission critical app: lives or a very significant amount of money or reputation is at stake from the start
E.g: Boing 737 software, banking core software, software for elections, heart rate monitoring software
What was the initial project size? Small to mid-sized (few 100 mandays) Mid-sized to large (1000’s of mandays)
what did they build? Consumer app where getting and adjusting end user feedback is extremely important
was there a contract? No or a simple one
Yes and a complex one
was it an internal development? Internal with maybe some external help or Significant involvement of subcontractors
was there already existing code base to build on? Probably not
Probably yes and/or several, complex systems to integrate to
what was the complexity of each function? low — e.g. Tinder messages
high — a very large number of transactions following complex rules
how did they define project success?
We will see: the software must be likeable and super
Strict: the software has to work reliably according to some contractual pre-set factors, standards
To prove some of the above, read these 2 articles:
Agile software development is dead. Deal with it
Why are we so bad at software engineering?
Final final conclusion about Agile
The final conclusion (e.g. if Agile is dead or alive) is: that it depends.
It depends on the situation you, your company, your team is in.
And remember: why you are getting paid, especially if you are a manager, is primarily one thing: make educated judgements — well.
So the call is yours.
Just do not do one thing: do not believe. Think, instead. It helps. Sometimes.
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 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 crazy, 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 such really unbiased research (not only a survey but a real scientific research) available about software projects. Is there? If yes — let me know! I will link it in this article.
(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 — and no I am not saying the state of agile annual reports are biased, but them being a report about agile — what one can expect!?).
Do you think I am finished? Not yet. Kanban!
A final final word: about Kanban and Kanban boards. These were just again invented for specific situations: with a number of open tasks and 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-board-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 in a 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 give it a try. There are crazier ideas than that — but not that many.
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, say, maximum 10 people, with issues, tasks not more than, say, 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. Well. Think. Always. It helps.
https://blog.bennett.ink/agile-is-the-spoiled-child-of-a-decade-of-easy-money-7c94bfc1ddf2
