When everything is a religion the word no longer holds any meaning. Maybe we should attempt to distinguish between a ritual and a habit? What is the distinction? I think the amount of emotion people attach to it. To me religion is like a hamster wheel for the emotional life of people. Too much activity with no observable gain. A habit is more reassuring and only lightly emotional in a lightly soothing sort of way.
Agile could be a religion if it comes with lots of worry whether we are doing it the right way. It can also be a set of habits if you just do some practical things regularly.
You all do understand that you cannot really be working together if you never talk in some kind of lightly structured way about what is to be done, right?
The article poses the question, is the agile structure the best way? Is it the only way?
Also, people do not need formal "structure" to communicate concepts. Is strict formal structure over projects better or less strict?
The closest way of knowing is to run scientific experiments. However, this is akin to running experiments to determine whether communism or capitalism is better. It's brutally hard to come up with an experiment or even the resources to run such a thing.
This is the article's point. If there's no science or theory backing agile or OOP up.... why do we, by default, consider it the "best" way and make it so ubiquitous? His answer is religion. OOP and agile are religions.
I guess I disagree that agile is defined by its structure.
I think it's defined by its value proposition - that shipping early and often and getting direct feedback from users produces better products than not doing so.
Which itself rests on the assumption that a product's value cannot be objectively asserted and is only the sum of its users' perceptions.
I've recently been intrigued by the Leiden Theory of language evolution. It basically suggests that language is perhaps better conceptualized as a separate organism that has co-ecological niche which happens to be the co-evolved biology of our minds. This semiotic organism is made of our neural components in a similar way to how simpler biology is made of atoms and molecules.
It also has some hypotheses on how God is an invitable emergence from all language, as it is the base type:
> The Leiden theory explains religion as a disease of language and predicts the existence of God and other such parasitic mental constructs as artefacts of language. God is the quintessential prototype of the non-constructible set because it can mean anything. This makes God the meme almighty.
And so, in that viewing, everything contains elements of religion, because religion is just some sort of super-meme, like the catch-all mail filter when things don't yet match another category ;) (sorry, just read the other post on mail)
I’m pretty sure the author’s exposure to agile wasn’t agile done right. Rather it was surely just someone who read a few books and didn’t implement it correctly.
The person is actually talking about a broad range of things that don't just apply to agile. It's a little bad to compare this area to religion but, for agile, the analogy is apt because people feel it's the "only" way to do things.
What this person is talking about is a part of engineering where no theory or science applies. Take these two examples:
1. Solving the problem of the shortest distance between A and B involves a line... this is covered by mathematical geometric theory.
2. The best way to travel from point A to point B in the United States is not covered by theory.
The two examples illustrate a dichotomy:
1. Problems that can be solved with mathematical theory or science.
2. Problems that can be solved with "Design"
Problem space 2 is the umbrella that agile falls under. Usually when we hit a problem related to 2 we employ the word "design." The design of a house, Object oriented design, the design of a bridge, the architecture design of the program, UX design... etc. etc. "Design" is a method to find a solution to a problem space that is either too complex or we have little theoretical understanding. Designing something is akin to guesstimating a solution. We do not have any proof that a "design" solution we arrived at is the "best" solution, we only know that it is "a" solution (after verification of correctness).
Agile is like object oriented programming because both are methods created by guesstimation aka "design." There is no theory or proof (though there could be correlations) that either is the best possible solution.
Agile is especially religious because of the specificness of it: A series of random rules to manage a project out of a solution set where trillions of rules and external factors apply. Intuitively, there is literally no way agile is the "best" solution. Until we can quantify the effectiveness of a project and until we experimentally employ other structures and methods for project management and SCIENTIFICALLY compare the effectiveness of all these methods can we begin to iterate toward a solution that is closer to "best."
You throw out the rituals ("processes and tools", "plans") when they don't work. That's called a retro.
How do you know if you're doing it right? You'll have "working software". That's a pretty subjective idea, so you'd better have someone to help you judge that, i.e. a "customer".
I worked somewhere where we made a conscious decision at a retro to not do them so often. But to be honest that was probably the most agile place I've been at. But perhaps good retros are the exception, not the rule.
At the place I worked, we started with a pretty regimented scrum - Monday morning planning poker, fixed-length sprints, which were closed and groomed, etc. I hated that crap. There was also a tech lead bully that insisted on doing things his way, and would use the code review process to keep other people's code out of the system. It was a real death march. By the time we had the basics of the system running, it was a dozen layers of synchronous blocking code where simple REST requests would take between 2 and 60 seconds to complete.
Eventually the bully left, and after that we eventually wore our (non-tech) team lead down into getting rid of discrete sprints and planning poker, and the devs tended towards just 'working on the next thing'.
I think the biggest factors we had in our favour were:
1) The team lead (pretty much the boss, too) was not technical, so he had no choice but to leave the tech decisions to us.
2) The tech bully left us in such a shitty state that it became obvious we'd need big changes, rather than token ones.
3) We got quite a bit of rapport happening and eventually the team lead understood that we actually wanted to get the system working nicely. The devs also got better at pitching ideas, like why a certain large changes were necessary.
I can't imagine we would have gotten to steer the ship in any meaningful way without a bunch of factors lining up like that.
> How do you know if you're doing it right? You'll have "working software".
This is _exactly_ the problem - agile is never defined by itself, it is defined in terms of some desirable outcomes. Project was on time and succesful? Great victory for agile. Project failed? Need more agile in the future.
In my experience, all this is used as a smoke screen by management types who have no real idea what they are doing to externalize their own accountability.
If you've done well you've probably learned and adapted.
If you havent done well, you probably to reflect and work how to do it better next time.
In that case, you can also replace "Agile" with "Kung-Fu!" Actually, I'm serious. There are various anti-philosophies in art and the martial arts which say something like this.
Yes, as a team you should be able to make that decision. A good scrum master would want you experiment and improve if there is reason behind it.
The key thing is that the changes have to make things better. You should be able try those things and see if they improve things.
Lots of teams use kanban, and some teams mob. If you mob as a team what's the point in standups?
What's the point in sprints, if your continously improving, continously releasing, continously getting feedback and able to forecast well without them? Your better than scrum in my opinion then.
Scrum is a bit basic these days, but it's a good baseline start from. Thats the problem with a lot scrum purists. They will never get beyond a fairly basic level of performance.
That's not what I mean. I'm not using the term "working software" as "great project success". I mean it as something executable that you can develop, test, and get feedback on.
The software will be slow and buggy and do the wrong thing. If you find this out in month 1, then that's great. If you start with 2 months of careful planning to make sure you don't get it wrong, you'll find out it's wrong in month 3.
> agile is never defined by itself, it is defined in terms of some desirable outcomes.
In some ways that's appropriate, because nobody actually cares about being agile. They care about shipping working software on time. So the real essence of agile is asking "How can we ship working (or closer) software faster?", and adjusting your process in response. If you aren't at least willing to adjust your process, you aren't doing agile.
Lately I've started to think Agile also bears some striking similarities to Communism. It has its dogmatic adherents, and it actually sounds good on paper. It's just that everywhere I've seen it tried, it fails. And the reason given is always "that wasn't proper Agile".
Like other dogmas or ideologies, it's unfalsifiable. No amount of real-world experiments can invalidate it if the reason is always "that wasn't real Agile".
Agile is fine, but I believe it was born as an overreaction to Waterfall and excessive processes, the generation that followed blindly adopted it as a dogma, even when the project at hand doesn't benefit from it (also because "agile" is a great marketing word w/ positive meaning, and leaders suffer from FoMo.). People who've been at the trenches long enough seem to be waking up to this fact, and we must be careful to not overreact on our own.
Agile seems great when both you and the customer have zero idea what you're doing, but not all projects are creating something completely new. I've seen enough projects fall into the trap of reinventing the (square) wheel by 1. not trying to state the problem correctly 2. doing zero research 3. not even interviewing more experienced people. Creating something that nobody asked for and failing fast is supposed to be agile, but agile says nothing about how to calculate risk/reward, or just assumes prototype are super cheap. That's rarely the case in practice - I've never see a prototype being tossed away, just turning into technical debt.
Nowadays I much prefer the Cynefin framework [1] to reason about problems and projects, even if it's not super clear on how to apply, because it at least makes you consider two degrees of freedom.
Has any software or creative company ever actually adopted "waterfall"? It seems like a straw man used to criticize inefficient processes and promote Agile, but has it ever been implemented in the way that it's described?
More importantly, is there any actual evidence that Agile is works better than alternatives?
I was on a team at Microsoft that was strictly Waterfall; our business reps wanted to release functionality in six month cycles, so Waterfall was a good fit.
We eventually moved to Lean (a type of Agile) which worked well with this six-month requirement. It gave engineers the ability to work on different pieces and in whatever order they pleased, as long as everything landed in the six-month block.
> Has any software or creative company ever actually adopted "waterfall"?
Yes, plenty.
I once worked at a CMM level 4 company. Network hardware vendor, before the days that FPGA was really useful. You had to get your shit right, the first time.
was born as an overreaction to _X_ and excessive processes, the generation that followed blindly adopted _Y_ as a dogma
This happens to everything. It's a pattern as pervasive as Sturgeon's Law, and may well be related to it. Musical genres come about as a reaction to the excesses of dominant genres, then become a dominant genre themselves. This happens to books, TV shows, movies, video games -- basically everything in modern culture. It even happens in academia and in startups.
The reason for this pattern, is that it's often hard to understand the underlying forces and the cost-benefit factors and incentives that shaped _X_ and _Y_. The solution for getting yourself out of the churn of rejecting the old "paradigm" or whatever and adopting the new, is to understand the underlying forces and react directly to them. If you're going to react and deal only with the surfaces of things -- isn't that kind of the definition of the "Cargo Cult" mentality?
(also because "agile" is a great marketing word w/ positive meaning, and leaders suffer from FoMo.)
At my last company, Agile was the specific response to smaller competitors having quicker iteration cycles. I think it's wholly appropriate response in that case. Also, at one company I interviewed at, it seems that their version of Agile was going towards the "mini-iterated-waterfall" variant, with the manager advocating that every story be broken down to minute-enough detail that estimates would finally be nearly 100% accurate. Are those mistakes or the right move? Time will tell.
From the article: What Agile actually is remains vague, even more so than Object Orientation ever was, and that’s no simple feat.
Object Orientation is just a vague strategy for code organization. What it actually is depends on the particular techniques and the context of the group actually implementing those. In that, there is a deep parallel to Agile and to religious dogmas and personal philosophy: It's pointless to talk about something so vague, while it's productive to examine specific groups in their success or failure in implementation.
In other words, don't confuse guidelines and techniques for silver bullets and magic. Don't comply with _Y_ just so you can label yourself "Y." Look at your structure of cost/benefit and the team's incentives and figure out how guidelines and techniques mesh with those.
Are you saying if we only understood the cost-benefit factors and incentives that shaped music genre _X_ we'd only need on genre of music and all successors would seem out of place?
Are you saying if we only understood the cost-benefit factors and incentives that shaped music genre _X_ we'd only need on genre of music and all successors would seem out of place?
Bzzzt! No. Try again.
Actually, changing costs and cost-benefit coming from advances in technology did have a tremendous effect on 80's music.
What's out of place late at night in a dark smoky club? It depends. Be in the moment. Adapt! It's the static, dogmatic mindset that is based on the over-application of a fictional timeless comprehension (which can't possibly fit in a tiny human mind) which results in strawman questions like: "Are you saying if we only understood the cost-benefit factors and incentives that shaped music genre _X_ we'd only need on genre of music and all successors would seem out of place?"
> Musical genres come about as a reaction to the excesses of dominant genres, then become a dominant genre themselves.
This is sort of a tangent, but does this really happen anymore? I think that you're right, but I can't really think of any genres that have come about in the last 30 years that are a response to the excess of dominant genres. Come to think of it, what you're saying may have just been a 20th century phenomenon. Or maybe as early as late 19th century.
"Moral reforms and deteriorations are moved by large forces, and they are mostly caused by reactions from the habits of a preceding period. Backward and forwards swings the great pendulum, and its alternations are not determined by a few distinguished folk clinging to the end of it." — Sir Charles Petrie, The Victorians
I don't think "religious dogma" is narrow enough terminology to describe what is going on. The real distinction is between system-based and teacher-based ideas and practices.
With a system-based idea (such as Newtonian mechanics), you can learn it and use it correctly merely by reading some set of canonical works. Everything you need to know is in a book, and if you understand the book correctly you get the right results out of it.
Agile, on the other hand, seems to me to be much more teacher-based. If you want to know if you're doing Agile right, you have to talk with an Agile expert, and your own understanding is always under threat of being declared "not Agile" by the experts.
The choice between approaches is a tradeoff, IMO, there's not one best way. Interactive teaching is better at accurately providing the state-of-the-art opinions and practices of experts, while systematic ideas are much more testable and falsifiable. If you want to copy what a successful expert does, go talk with the expert; if you want to know whether the expert is right or not, read their book.
I'd divide it differently: waterfall is process based, Agile is outcome based.
You know you're doing Agile right when you have code in front of a user and they're telling you what they like and don't like and what they wish they could do but can't and are connecting your product to their goals and stories.
Agile gives you some structure and best practices around shipping early and often, communicating ina particular way with stakeholders and your team, and measuring progress.
But ultimately everything - ceremonies, comms, management, PM software - is subordinate to the idea of "a user using your product to do the things the product is designed to do."
Another way in which agile is like religion: its evangelists always have a jargon-loaded answer to every possible criticism of it.
They really remind me of being a kid in Sunday school and asking the teacher questions like "but if god created all of us, who created god?" or "what if somebody was born and raised in the middle of the amazon and never even heard of Christianity - will he go to hell?". There was always some bizarre logic-twisting response to those questions which didn't really answer them but was enough to try and shut you up.
Similarly, if you say "Agile doesn't work because X" - they will say "thats not REAL Agile...". But if you say "Agile is dogmatic" they will say "Agile lets you do what you want, its not a dogmatic rule based approach".
So there is simultaneously one "real" way of doing Agile and also no real way because it is not dogmatic.
You sure your not getting these answers from different people?
Someone new to agile might go on a scrum course and think this is the one way of doing agile.
People who've been around awhile know you have inspect and adapt your process to specific implementations. There is no agile 'process' for this reason. It's also the reason agile mostly relies on having good people who can inspect and adapt. Agile is basically means creating a process that has been shown empirically work in your situation.
Its true the examples I gave are probably a bit exaggerated but I think the general point still stands. I think you have even demonstrated that contradiction yourself although in a much more eloquent way?
If Agile lets you inspect and adapt freely, then at what point does Agile does stop being Agile?
I definitely fall strongly on the anti-dogmatic side.
Agile is built around the simple value proposition that shipping products earlier, more often, and with more direct feedback from customers creates better products. We might even call this "The Golden Rule" of Agile. (This certainly verges on being a philosophy.)
If you believe that, and always act in accordance with that idea, and your team and stakeholders and users do so as well, there's no need for dogma. You will deliver great products and life will be good.
But the sad truth is a significant fraction of people are skeptics and cynics and doggerels and hairsplitters and technocrats and incompetents and martinets and apathetics and fusspots; in simple terms, they're only human.
So instead of one Golden Rule we have law after law after law and with law comes lawyers on both sides (or pharisees if you like.)
But if you inspect and adapt according to the Golden Rule, you'll always be doing Agile because you focus on the outcome and not the process.
Either you ship or you don't. Either you add value or you don't. Either you talk to users or you dont.
I'm not trying to be antagonistic but you sound exactly like the religious people we're talking about. And your response still doesn't answer the question - at what point does Agile stop being Agile?
Are you saying that any team that "ships products earlier, more often, and with more direct feedback" is following Agile? If thats all that Agile is then why do we need whole books on Agile, coaches, training seminars etc. if it can be summed up in one short sentence?
EDIT: Your definitions is also a tautology - nobody is going to argue that you should ship products late and with little feedback from customers.
When you make it a procedure - especially when you make it a rigid one. "Let us take this rigid approach to become agile" is just as stupid as it sounds.
> nobody is going to argue that you should ship products late and with little feedback from customers.
No. But some approaches result in more customer feedback than others do. So in practice, people do in fact choose to ship with less customer feedback.
I went to the Denver Agile conference a few months back and I mentioned to my boss that I felt the way they were presenting was very cultish. Instead of saying: if you follow this practice it has these benefits, I just felt the entire conference was a presentation on dogmatic adherence for the sake of holistic enlightenment. You must do this or condemn you entire project to the ninth level of programmer hell. If I wanted dogma I would go to church. I came here for a logical application of a standardized practices based on axioms not holistic bullshit.
Agile Coach here. This is spot on. The field of Agile coaching, books, conferences, and personalities is the most self referential circus of bullshit anyone could dream up.
Not to be a Talmudist but the vast majority of people who advise others on Agile haven't even read the foundational texts behind the prevailing theories.
The truth is Agile in all its forms is merely a reaction to what came before it and has precious little basis in any sort of proven first principles. For all the ink spilled on Agile it has failed to produce a unified field theory. Instead it is a collection of camp fire stories, post hoc assertions, and petty disagreements over style.
It's a bunch of fucking muppets. I hate most of my colleagues, I really do.
57 comments
[ 2.7 ms ] story [ 115 ms ] threadMathematics and science and all things isomorphic to either.
Agile could be a religion if it comes with lots of worry whether we are doing it the right way. It can also be a set of habits if you just do some practical things regularly.
You all do understand that you cannot really be working together if you never talk in some kind of lightly structured way about what is to be done, right?
Also, people do not need formal "structure" to communicate concepts. Is strict formal structure over projects better or less strict?
The closest way of knowing is to run scientific experiments. However, this is akin to running experiments to determine whether communism or capitalism is better. It's brutally hard to come up with an experiment or even the resources to run such a thing.
This is the article's point. If there's no science or theory backing agile or OOP up.... why do we, by default, consider it the "best" way and make it so ubiquitous? His answer is religion. OOP and agile are religions.
I think it's defined by its value proposition - that shipping early and often and getting direct feedback from users produces better products than not doing so.
Which itself rests on the assumption that a product's value cannot be objectively asserted and is only the sum of its users' perceptions.
http://www.himalayanlanguages.org/files/driem/pdfs/prague.pd...
It also has some hypotheses on how God is an invitable emergence from all language, as it is the base type:
> The Leiden theory explains religion as a disease of language and predicts the existence of God and other such parasitic mental constructs as artefacts of language. God is the quintessential prototype of the non-constructible set because it can mean anything. This makes God the meme almighty.
And so, in that viewing, everything contains elements of religion, because religion is just some sort of super-meme, like the catch-all mail filter when things don't yet match another category ;) (sorry, just read the other post on mail)
Is the above paragraph satire, or real?
What this person is talking about is a part of engineering where no theory or science applies. Take these two examples:
1. Solving the problem of the shortest distance between A and B involves a line... this is covered by mathematical geometric theory.
2. The best way to travel from point A to point B in the United States is not covered by theory.
The two examples illustrate a dichotomy:
1. Problems that can be solved with mathematical theory or science.
2. Problems that can be solved with "Design"
Problem space 2 is the umbrella that agile falls under. Usually when we hit a problem related to 2 we employ the word "design." The design of a house, Object oriented design, the design of a bridge, the architecture design of the program, UX design... etc. etc. "Design" is a method to find a solution to a problem space that is either too complex or we have little theoretical understanding. Designing something is akin to guesstimating a solution. We do not have any proof that a "design" solution we arrived at is the "best" solution, we only know that it is "a" solution (after verification of correctness).
Agile is like object oriented programming because both are methods created by guesstimation aka "design." There is no theory or proof (though there could be correlations) that either is the best possible solution.
Agile is especially religious because of the specificness of it: A series of random rules to manage a project out of a solution set where trillions of rules and external factors apply. Intuitively, there is literally no way agile is the "best" solution. Until we can quantify the effectiveness of a project and until we experimentally employ other structures and methods for project management and SCIENTIFICALLY compare the effectiveness of all these methods can we begin to iterate toward a solution that is closer to "best."
You throw out the rituals ("processes and tools", "plans") when they don't work. That's called a retro.
How do you know if you're doing it right? You'll have "working software". That's a pretty subjective idea, so you'd better have someone to help you judge that, i.e. a "customer".
In practice I find retros to be a special place where engineers can vent their discontent and nothing will ever be done about it.
At the place I worked, we started with a pretty regimented scrum - Monday morning planning poker, fixed-length sprints, which were closed and groomed, etc. I hated that crap. There was also a tech lead bully that insisted on doing things his way, and would use the code review process to keep other people's code out of the system. It was a real death march. By the time we had the basics of the system running, it was a dozen layers of synchronous blocking code where simple REST requests would take between 2 and 60 seconds to complete.
Eventually the bully left, and after that we eventually wore our (non-tech) team lead down into getting rid of discrete sprints and planning poker, and the devs tended towards just 'working on the next thing'.
I think the biggest factors we had in our favour were:
1) The team lead (pretty much the boss, too) was not technical, so he had no choice but to leave the tech decisions to us.
2) The tech bully left us in such a shitty state that it became obvious we'd need big changes, rather than token ones.
3) We got quite a bit of rapport happening and eventually the team lead understood that we actually wanted to get the system working nicely. The devs also got better at pitching ideas, like why a certain large changes were necessary.
I can't imagine we would have gotten to steer the ship in any meaningful way without a bunch of factors lining up like that.
#1 was clustering similar sad faces.
#2 was as a team, agreeing on actions we could take on those clusters.
#3 was tracking how well we did on performing those actions.
If it's just venting, it's not overly useful.
I would try to fix the retros though or have some kind of alternative to allow the team to change the process.
This is _exactly_ the problem - agile is never defined by itself, it is defined in terms of some desirable outcomes. Project was on time and succesful? Great victory for agile. Project failed? Need more agile in the future.
In my experience, all this is used as a smoke screen by management types who have no real idea what they are doing to externalize their own accountability.
Replace agile word with that in your paragraph and it makes sense without sounding silly.
If you've done well you've probably learned and adapted.
If you havent done well, you probably need to reflect and work how to do it better next time.
Things arnt 'proper' agile when they are not about adapting but instead following a specific process your team cant change.
If you havent done well, you probably to reflect and work how to do it better next time.
In that case, you can also replace "Agile" with "Kung-Fu!" Actually, I'm serious. There are various anti-philosophies in art and the martial arts which say something like this.
OODA loop, plan do check act, kaizan etc
The core is the same.
Cool, tell that to your "scrum master" next time you see him.
The key thing is that the changes have to make things better. You should be able try those things and see if they improve things.
Lots of teams use kanban, and some teams mob. If you mob as a team what's the point in standups?
What's the point in sprints, if your continously improving, continously releasing, continously getting feedback and able to forecast well without them? Your better than scrum in my opinion then.
Scrum is a bit basic these days, but it's a good baseline start from. Thats the problem with a lot scrum purists. They will never get beyond a fairly basic level of performance.
The software will be slow and buggy and do the wrong thing. If you find this out in month 1, then that's great. If you start with 2 months of careful planning to make sure you don't get it wrong, you'll find out it's wrong in month 3.
Now the kittens do stand ups everyday and meow on cue. It's a success for management.
In some ways that's appropriate, because nobody actually cares about being agile. They care about shipping working software on time. So the real essence of agile is asking "How can we ship working (or closer) software faster?", and adjusting your process in response. If you aren't at least willing to adjust your process, you aren't doing agile.
Like other dogmas or ideologies, it's unfalsifiable. No amount of real-world experiments can invalidate it if the reason is always "that wasn't real Agile".
Agile seems great when both you and the customer have zero idea what you're doing, but not all projects are creating something completely new. I've seen enough projects fall into the trap of reinventing the (square) wheel by 1. not trying to state the problem correctly 2. doing zero research 3. not even interviewing more experienced people. Creating something that nobody asked for and failing fast is supposed to be agile, but agile says nothing about how to calculate risk/reward, or just assumes prototype are super cheap. That's rarely the case in practice - I've never see a prototype being tossed away, just turning into technical debt.
Nowadays I much prefer the Cynefin framework [1] to reason about problems and projects, even if it's not super clear on how to apply, because it at least makes you consider two degrees of freedom.
[1] https://en.wikipedia.org/wiki/Cynefin_framework
Cynefin is great, but it is merely an abstract set of principles.
More importantly, is there any actual evidence that Agile is works better than alternatives?
We eventually moved to Lean (a type of Agile) which worked well with this six-month requirement. It gave engineers the ability to work on different pieces and in whatever order they pleased, as long as everything landed in the six-month block.
Yes. My last company was squarely "Waterfall" (though it wasn't called that) and is moving to "Agile."
Yes, plenty.
I once worked at a CMM level 4 company. Network hardware vendor, before the days that FPGA was really useful. You had to get your shit right, the first time.
This happens to everything. It's a pattern as pervasive as Sturgeon's Law, and may well be related to it. Musical genres come about as a reaction to the excesses of dominant genres, then become a dominant genre themselves. This happens to books, TV shows, movies, video games -- basically everything in modern culture. It even happens in academia and in startups.
The reason for this pattern, is that it's often hard to understand the underlying forces and the cost-benefit factors and incentives that shaped _X_ and _Y_. The solution for getting yourself out of the churn of rejecting the old "paradigm" or whatever and adopting the new, is to understand the underlying forces and react directly to them. If you're going to react and deal only with the surfaces of things -- isn't that kind of the definition of the "Cargo Cult" mentality?
(also because "agile" is a great marketing word w/ positive meaning, and leaders suffer from FoMo.)
At my last company, Agile was the specific response to smaller competitors having quicker iteration cycles. I think it's wholly appropriate response in that case. Also, at one company I interviewed at, it seems that their version of Agile was going towards the "mini-iterated-waterfall" variant, with the manager advocating that every story be broken down to minute-enough detail that estimates would finally be nearly 100% accurate. Are those mistakes or the right move? Time will tell.
From the article: What Agile actually is remains vague, even more so than Object Orientation ever was, and that’s no simple feat.
Object Orientation is just a vague strategy for code organization. What it actually is depends on the particular techniques and the context of the group actually implementing those. In that, there is a deep parallel to Agile and to religious dogmas and personal philosophy: It's pointless to talk about something so vague, while it's productive to examine specific groups in their success or failure in implementation.
In other words, don't confuse guidelines and techniques for silver bullets and magic. Don't comply with _Y_ just so you can label yourself "Y." Look at your structure of cost/benefit and the team's incentives and figure out how guidelines and techniques mesh with those.
Bzzzt! No. Try again.
Actually, changing costs and cost-benefit coming from advances in technology did have a tremendous effect on 80's music.
https://www.liverpoolmuseums.org.uk/wml/exhibitions/thebeatg...
all successors would seem out of place?
What's out of place late at night in a dark smoky club? It depends. Be in the moment. Adapt! It's the static, dogmatic mindset that is based on the over-application of a fictional timeless comprehension (which can't possibly fit in a tiny human mind) which results in strawman questions like: "Are you saying if we only understood the cost-benefit factors and incentives that shaped music genre _X_ we'd only need on genre of music and all successors would seem out of place?"
This is sort of a tangent, but does this really happen anymore? I think that you're right, but I can't really think of any genres that have come about in the last 30 years that are a response to the excess of dominant genres. Come to think of it, what you're saying may have just been a 20th century phenomenon. Or maybe as early as late 19th century.
With a system-based idea (such as Newtonian mechanics), you can learn it and use it correctly merely by reading some set of canonical works. Everything you need to know is in a book, and if you understand the book correctly you get the right results out of it.
Agile, on the other hand, seems to me to be much more teacher-based. If you want to know if you're doing Agile right, you have to talk with an Agile expert, and your own understanding is always under threat of being declared "not Agile" by the experts.
The choice between approaches is a tradeoff, IMO, there's not one best way. Interactive teaching is better at accurately providing the state-of-the-art opinions and practices of experts, while systematic ideas are much more testable and falsifiable. If you want to copy what a successful expert does, go talk with the expert; if you want to know whether the expert is right or not, read their book.
You know you're doing Agile right when you have code in front of a user and they're telling you what they like and don't like and what they wish they could do but can't and are connecting your product to their goals and stories.
Agile gives you some structure and best practices around shipping early and often, communicating ina particular way with stakeholders and your team, and measuring progress.
But ultimately everything - ceremonies, comms, management, PM software - is subordinate to the idea of "a user using your product to do the things the product is designed to do."
They really remind me of being a kid in Sunday school and asking the teacher questions like "but if god created all of us, who created god?" or "what if somebody was born and raised in the middle of the amazon and never even heard of Christianity - will he go to hell?". There was always some bizarre logic-twisting response to those questions which didn't really answer them but was enough to try and shut you up.
Similarly, if you say "Agile doesn't work because X" - they will say "thats not REAL Agile...". But if you say "Agile is dogmatic" they will say "Agile lets you do what you want, its not a dogmatic rule based approach".
So there is simultaneously one "real" way of doing Agile and also no real way because it is not dogmatic.
Someone new to agile might go on a scrum course and think this is the one way of doing agile.
People who've been around awhile know you have inspect and adapt your process to specific implementations. There is no agile 'process' for this reason. It's also the reason agile mostly relies on having good people who can inspect and adapt. Agile is basically means creating a process that has been shown empirically work in your situation.
If Agile lets you inspect and adapt freely, then at what point does Agile does stop being Agile?
Getting good at agile means getting good at inspect and adapt.
Agile is built around the simple value proposition that shipping products earlier, more often, and with more direct feedback from customers creates better products. We might even call this "The Golden Rule" of Agile. (This certainly verges on being a philosophy.)
If you believe that, and always act in accordance with that idea, and your team and stakeholders and users do so as well, there's no need for dogma. You will deliver great products and life will be good.
But the sad truth is a significant fraction of people are skeptics and cynics and doggerels and hairsplitters and technocrats and incompetents and martinets and apathetics and fusspots; in simple terms, they're only human.
So instead of one Golden Rule we have law after law after law and with law comes lawyers on both sides (or pharisees if you like.)
But if you inspect and adapt according to the Golden Rule, you'll always be doing Agile because you focus on the outcome and not the process.
Either you ship or you don't. Either you add value or you don't. Either you talk to users or you dont.
Are you saying that any team that "ships products earlier, more often, and with more direct feedback" is following Agile? If thats all that Agile is then why do we need whole books on Agile, coaches, training seminars etc. if it can be summed up in one short sentence?
EDIT: Your definitions is also a tautology - nobody is going to argue that you should ship products late and with little feedback from customers.
When you make it a procedure - especially when you make it a rigid one. "Let us take this rigid approach to become agile" is just as stupid as it sounds.
> nobody is going to argue that you should ship products late and with little feedback from customers.
No. But some approaches result in more customer feedback than others do. So in practice, people do in fact choose to ship with less customer feedback.
The Tao which can be spoken is not the true Tao.
There was always some bizarre logic-twisting response to those questions which didn't really answer them but was enough to try and shut you up.
Look at the results. Follow the money.
So there is simultaneously one "real" way of doing Agile and also no real way because it is not dogmatic.
How about substitute "Agile" with "Jeet Kune Do?"
Not to be a Talmudist but the vast majority of people who advise others on Agile haven't even read the foundational texts behind the prevailing theories.
The truth is Agile in all its forms is merely a reaction to what came before it and has precious little basis in any sort of proven first principles. For all the ink spilled on Agile it has failed to produce a unified field theory. Instead it is a collection of camp fire stories, post hoc assertions, and petty disagreements over style.
It's a bunch of fucking muppets. I hate most of my colleagues, I really do.
Upper management completely changed all the processes.
all teams were broken into scrum teams without consulting developers or other members.
Everyone I have talked to is unhappy. Any random decisions are justified as agile.
Is this normal process of adapting agile in the company?