Discussion

Saying Goodbye to Agile

DeathArrow: But if Agile is going to die, what are Scrum Masters going to do?

smackeyacky: And good riddance too.Agile was always aiming to solve the wrong problem (that code is the bottleneck) but it turned out to be a massive lie exposed by LLMs.It’s always the poor specs, terrible analysis and release constraints that kill projects.

k__: "Agile was always aiming to solve the wrong problem (that code is the bottleneck)"No, it aimed to solve the "out specs are bad and we need to iterate faster" problem."a massive lie exposed by LLMs"No. LLMs add no insight about the problem and they expose nothing. They just help to engage this well-known problem with another tool.

mrloba: I really doubt spec driven development is gonna last. As before, creating working software and iterating on it is faster and makes it easier to understand what you thought you wanted but don't, even if it's vibe coded. So, hello agile, welcome back.

DeathArrow: I think there is some good middle ground between spec driven development and iterations, like Compound Engineering. https://github.com/EveryInc/compound-engineering-plugin

zer00eyz: Someone once described agile as this: Its just pantomime and posit notes... implying that the process (from the outside) was more performative than anything else.From "scrum masters" to "planing poker" it's all very silly.

mnsc: Oh no, the kids are going to invent agile again aren't they?

DeathArrow: >It’s always the poor specs, terrible analysis and release constraints that kill projects.So most of the problems are related to business people and not the development teams? Who would have guessed?

DeathArrow: I wonder if there is no AI product yet which runs scrum ceremonies, assigns user stories in planning and computes story point velocity after the sprint ends.

EugeneOZ: Absolutely awesome, thank you, Lewis!

dijit: There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere.In that: if it fails, it is only considered evidence that you were not doing it enough.The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.It's also true for Cloud providers; that they're not suited for certain tasks is no longer considered an engineering trade-off, it's that you architected your solution wrong, and the answer is to buy even more into how the platform works.If your microservices become slow or difficult to debug, it's never that fatter services could have been preferable, it's that we didn't go hard-enough into microservices.If Austerity is not working as an economic model; the answer isn't to invest in growth, it's to cut even more corners.I feel like I see it all the time.

jeremyjh: If brute force is not working, you are not using enough.

hcfman: The way the author defined water fall makes it sound pretty good to me.Put your hand up if you are ever programming with poor specs?Put your hand up if you have a better idea of what really was wanted after the first cut?And what I really dislike is those that try to design a Swiss Army knife from day one when they haven’t a clue. Jump immediately into over complexity.

darkhelmet: Agile, as implemented in every big company that I've worked for, was a lie.It was really telling at a smaller company that was trying to behave like a big company. I asked a coworker (who had great metrics) what the secret was for dealing with the middle-management-heavy and quite dysfunctional environment. He told me how he did it. Paraphrased: "It's easy. During each sprint, I work on the next sprint's work. Once it's complete I'll know how to make sure things match the work that's already been done and that way its always a bullseye and on time - because the work is already done.". Agile at that company was a joke to the people who got things done, and was a weapon used against people who didn't realise it in time. It sure generated a lot of metrics and stats though. I used to joke amongst coworkers that the company produced metrics, not products.

dijit: Meaningful work for a change?

somesortofthing: What does "writing specs" here actually mean? Every agile project I've ever worked on has had a design doc that laid out architecture, the basic shape of contracts, dependencies and so on. In fact, the agile artifacts(tickets, estimates, epics etc.) have always been downstream of a design doc source-of-truth. A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.

Hamuko: Same as before: nothing.

prerok: Agile never claimed that.Agile is about working code instead of hundreds of pages of spec nobody reads.

FpUser: Lucky me, I've never had to say Hi Agile in a first place. It is a tumor. Been in programming since 80s. Mostly on my own except 6 years long stint at the company. Quit in 2000 from position of CTO

waschl: Isn’t Communism the original here? It’s often claimed that all historic attempts to establish Communism don’t work cause it wasn’t done in the right way.In all seriousness, this pattern is probably hard to avoid in any reasonably complex entity/environment. If any such situation would be solved in a global solution (aka silver bullet), it would be used by everyone. As this seems not possible, any framework like Agile, Communism, … can only be a guidance to be applied locally, and broken internally and by external factors in many ways

thelastgallon: Religion. Your life isn't better because of {not devout enough, didn't self-flagellate enough, didn't donate enough to the religious leaders/church/god, committed some other sins, belief is lacking}

endymi0n: I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams.For reference, here's all the Agile you need, it's 4 sentences:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThe real problem is that capital-A Agile is not agile at all, but exactly the opposite: A fat process that enforces following a plan (regular, rigid meeting structure), creating comprehensive documentation (user stories, specs, mocks, task board) and contract negotiation (estimation meetings, planning poker). It's a bastardization of the original idea, born by process first people who tried to copy the methods of successful teams without understanding them.

operatingthetan: I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.

prerok: I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.

protocolture: >I feel like I see it all the time.Sometimes its justified. Like "This is only satisfied when x, y and z are correct"But then you get"We will do x and y as a compromise but not z"And then you have to explain that, the compromise is actually worse.

anilakar: Wasn't the whole waterfall model originaly a caricature to higlight all the issues one will inevitably encounter if they eliminate feedback loops and go with a strictly sequential development paradigm?

jeremyjh: > A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.Oh that was it you're right. We have those documents but they are full of lies. Yet everyone can read it and believe it to be true in the way they want it to be.

t43562: It's usually because your company doesn't fundamentally want it. You cannot have roadmaps with lists of features that you advertise to customers AND have the flexibility to decide to ignore things that turn out to be useless or disporportionately time consuming.If someone handed you a plan for making a jet engine and you messed around with the instructions ... why would you expect it to work? If you have a bug because there are not enough tests ... you write more tests don't you? Why would a method be forgiving when compilers and reality itself aren't?

prerok: TFA first claims that agile invented none of the things it encompasses, seems not to challenge those claims, but then just jumps to agile is dead because LLMs can code based on spec.This is just a confusing and confused article.Agile just finally embraced that specs are incomplete and can even be wrong because the writer of the spec does not yet really know or understand what they want. So they need working software to show the spec in action and then we can iterate on the results.We are still doing that and will be doing it in the foreseeable future. Agile is very much alive and here to stay.

brigandish: How did he see into the future to know which work he'd be doing on the next sprint, and how did he also finish the current sprint's work with a bullseye thus allowing the next sprint's to begin and match it?

tiew9Vii: > In that: if it fails, it is only considered evidence that you were not doing it enough.Seen this multiple timesThe problem is agile as in the original manifesto was an ethos, not a process.Everything since the manifesto, called agile, has tried to wrap an ethos up as a process, playing lip service forgetting the ethos.High performing teams are already doing agile, following the ethos without attempting to be agile. High performing teams made to do agile become average teams and low performing teams made to do agile can become average teams.

t43562: If your company doesn't fundamentally want "agility" then it will be an exercise in futility but if you're a person who doesn't want to do useless work then you're an agile proponent fundamentally.

moron4hire: Dude, this mode of ex post facto rationalization is waaaay older than communism. It's basically one of the main "retention warnings" of most religions.

patcon: I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion.I'm not religious is any traditional sense, but I'd argue that it's not always the hallmark of a bad dynamic when a system always asks of you to do inner work when failures happen in contact with the real world. Sometimes that's a healthier mode than the alternative -- externalizing the blame, and blaming the system (or the god).I suspect there a very abstract game theoretic conversation that could be had about this :)

jeremyjh: The point is the agent writes the specs and the human reviews and revises or asks for another rewrite that takes 90 seconds or less. So specs are both cheaper and better than anything I've seen before. They still get a lot wrong and it is hard to review them very carefully, but its easier than reviewing code to suss out design intent.

rcaught: Aigile

lopsotronic: Strategic Bombing - the idea wars can be won from the air alone - is the absolute worst of these. It's a religion that might well someday kill us all, or a great many of us. In the quest to dot it "enough" . . .On a lighter note . .The world of overly-complex CCS (component content systems) like DITA has made this "Agile flavor of treadmill[1]" into the entire business, greased with liberal squirts of FOMO and "Industry Standards".It rhymes with capital A Agile in many ways, although in the case of DITA specifically I'd posit that the underlying assumption of the spec is a vast category error: that natural language has formal types.[1] i.e., "you aren't doing it properly" . . . and with every change in technology the DITA / XML priesthood claimed to hold the keys to unlock it. SEO? Information Typing. Web Content? XML/XAL pipelines. Big Data? Content granularity. LLMs? Information typing and schema will "help" llms and not just be an unholy clog in the guts of vector embedding operations. And yet, the years go by, and all of it has worked and continues to work fine without switching the world to DITA (and a writing universe of strict validation based on speculative assumptions).

Cwizard: That’s Scrum you are thinking of. Not agile.

bartvk: I don't get the negativity, there's plenty wrong with agile (notably the hours of meetings) but all in all, it's a method and I don't see anything better right now.

duped: I'm of the belief that most project management voodoo is just that - voodoo. There is no rigor, there's no formal basis for ideas, and there's no testing of hypotheses and rejection when evidence counters it.Engineering (even in computing) has a formal basis and practice. Project management does not. Systems thinking and industrial organizational psychology does, but rarely do you see it applied like bullshit such as agile (and in environments that do - it works spectacularly).Out with the voodoo, and in with the scientific method, I say.

AndrewThrowaway: If AI fails, you wrote the prompt wrong.

Cwizard: Yes, exactly. It works great. But it is not cookie cutter enough for most orgs to adopt which is what led to Scrum, SAFE and what else. And then organisations take those frameworks (often change them to get even more agility out) and adopt them like it is gospel.I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea??Not sure what the solution is. There might not be any.

hussfelt: Ran into the same wall - ceremony eating the actual work. The Flight methodology cuts through it: a landing date, a single captain, no story points, no mandatory standups.The tagline from the handbook: "Agile started with a manifesto. It ended with Jira."Handbook: https://agile.flights/docs/introduction/why-flights/

duped: > In that: if it fails, it is only considered evidence that you were not doing it enough.This is a cult tactic, for what it's worth

danw1979: Ideologues are everywhere.If it isn’t presented as a theory that might be proven wrong, or an idea that might not work, that’s when my alarm starts going off.Another signal: trying stuff we already tried that didn’t work, usually with an unconvincing reason why it’s different this time.

Aurornis: My favorite Agile-ism is when Agile is defined as “the process that works for the team”.If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!

andersmurphy: This is a great point! Reminds me of Agentic software development. When it doesn't work out it's only evidence that you could have used more agents.You can never use enough tokens.

boomlinde: > In that: if it fails, it is only considered evidence that you were not doing it enough.Good way to ensure devotion to a process rather than devotion to a desirable outcome. Seems distinctly cult-like.

dannyobrien: I think it's worth linking to the original Agile Manifesto[1], because that's pretty much all the consensus you're ever going to get on what's "agile" and "what's not".Lewis is right that most of these principles were described before the manifesto, but I can vouch for the near-impossibility in many contexts of convincing anyone who wasn't a coder (and a lot of coders too) why these might be sensible defaults.For every person burned by a subsequent maladaptive formalization of these principles, there was someone horribly scarred before the agile manifesto by being forced to go through a doomed waterfall process.

t43562: Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th.""Oh, feature no 32 is going to take months and we realised that users can just....""No"

ytoawwhra92: The point is that sometimes you don't know the spec is wrong until you've built the software and it's being used.

9dev: Still though, that cycle can be iterated many times in a single day. Write a spec, let the agent build it, use the software, evaluate results, repeat.

ytoawwhra92: Yes, that's agile software development.

9dev: > […] when applied to small, excellent teams.Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated.That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more the alignment and median expertise lessen. At some point, you need to introduce control mechanisms and additional communication tools to rake in the outliers.I don't really have a better answer, though…

sminchev: I watched a video a few years ago where one of Kent Beck, Martin Fowler, Jeff Sutherland, Ken Schwaber, I don't remember who exactly, explained what they wanted to do with the Agile Manifesto, what screwed up. He explained that they wanted to give guidelines, not a strict rules. They wanted flexibility. But people started selling this as courses, business, rules. Some Agile practitioners become fanatics on the topic. And this created misunderstanding and chaos :DFor 20 years, I have seen it working and not working, and the reasons are a lot. It can be affected of level of expertise, quality of documentation, pressure from management, engagement of the clients, etc.Simple example of failing, and how one of my team overcome it. There is no specification. Option 1: team complains that the specification is bad, and this makes the code quality bad. Option 2: the team pro-actively prepared the specifications, gave them to the client for approval. Writing the specification was, a kind of, added flexibility, that was introduced in the sprints.Another example, why should the sprints be fixed at 2 weeks. Sometimes, people try to finish for two weeks and they produce bad quality code, because they are time pressured. Be flexible and make them 3 weeks, if the sprint includes things like, preparing specifications, or if the sprint includes pauses for bug fixing. :)So it is not the Agile that makes the project successful, it is the people. Agile just help for tracking where you are , and what you need to do ;)Now with AI, you can use Agile again, there are agentic frameworks that support it and they give good results, in my opinion. If the people use it wisely, think what they do, and try to do things better, it will work. Of people are lazy, don't know what they are doing, don't have expertise on software development, it will fail :)

OtomotO: It's basicy gas lighting at this point

tass: Not the op, but you only commit to what you already did in this sprint.So this sprint shows what you delivered 2 sprints ago, next sprint will be the work you just finished.

steinsgatezero: Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.

qsort: > I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion.Yes, and that's because God, spirituality and religion make fuzzy truth claims and can be used to argue for and justify anything. God can be used as the excuse to start a genocide and the inspiration to stop it, spirituality can be the way for wounded people to work with their trauma and the vehicle for people without scruples to sell horoscopes or some shit, religion (the same religion) was used to justify and uphold slavery and to fight for its end.They are containers for our politics, our lifestyle, for who we are and for who we hope to be.The Agile manifesto is a series of statements in the form "we like X more than Y." It doesn't say anything. To make it mean anything you have to project onto it a framework of interpretation that exists independently of the "sacred text" itself.So yeah, they are similar, and that's because Agile, sociologically, works like a religion.

9dev: No, not quite. The specifications we use for agents make any ticket written before them pale in comparison. That enables a hybrid workflow that is both spec-driven and "agile", in the sense that you're doing very rapid development cycles.

locknitpicker: > My favorite Agile-ism is when Agile is defined as “the process that works for the team”.What compels you to believe it isn't?I mean, read the Agile Manifesto. All it does is basically define a set of values and principles. Things like "customer comes first" or "we welcome changes in requirements" or "software must be delivered frequently".What leads you to believe Agile implies a fix set of precise, rigid rules?

urban_winter: Yes!Ask anyone with 30 years in the industry whether "agile", for all its problems, was a force for good or bad, and the answer will be an emphatic Good!If nothing else, it gave us ammunition to argue against the impossibility of delivering a fixed thing in a fixed amount of time - which was the universal view from senior stakeholders of what competent software delivery looked like.

adrian_b: Iterative development has existed since forever, since earlier than written history.It is not something invented by the Agile proponents.They have proposed a much more specific variant of iterative development, which at least as I have seen it implemented in any company which claimed to implement it, was really bad in comparison with the right ways of organizing development work, which I have seen elsewhere.Any high quality product must be designed starting from a good written specification. Obviously, almost always the initial specification must pass through one or more update cycles, after experience is gathered through the implementation. This has always been universally used, not just by Agile practitioners.There have always existed bad managers, who wrongly believed that a development process can always be linear and who did not include in their timelines the necessity for loops, but that was just bad management, so if Agile proponents pointed to such cases, those were just strawmen, not the best existing practices.

jillesvangurp: A requirement specification is how you prompt software engineers. One-shotting it doesn't work (waterfall). You need to put the SEs in planning mode. They will ask you questions and refine the plan. And you end up with a better plan. But if you make it too complicated the plan will go off the rails. So, you need to make them assign Fibonacci tokens to their planned tasks. Now you have a better plan and you can assign your SEs to tasks and get them working on it. Fibonacci tokens are not time units. This is very important. But you will run out of tokens after two weeks. So you need to buy some extra pizza tokens and make them work until midnight (crunch time!). That's how you get the job done. Every time. Sort of.I bet some jerk is going to organize a multi agent scrum process at some point and burn some tokens on this nonsense.

locknitpicker: > This is a great point! Reminds me of Agentic software development. When it doesn't work out it's only evidence that you could have used more agents.A concept older than agentic software development is bad workmen blaming his tools.I mean, if you can't possibly hammer a nail then is it reasonable to blame the hammer?

poisonborz: As others said, if agile fails, "you were not doing it enoug".But if agile is criticized... only worse alternatives are given, if at all. Here, spec-driven development is inferior, as in most cases the goal is only vaguely known. Cyclical development is not some hollow mantra, it is how life works. All the rituals around it were just to faciliate more communication. A lot of people in this field just hate that, they want their tickets and to be left alone.Now that implementation cycles are even shorter, there is even less manual need for coding, agile methodologies will be actually more prevalent.

4ggr0: at the same time, how can you judge something so harshly if you've never experienced it yourself.

hapticmonkey: Showcase/release your product at regular intervals and get feedback from relevant people, so you can adjust course if needed.That’s it. Whatever process it takes to get that occurring (without burning people out) should be the goal.

locknitpicker: > In that: if it fails, it is only considered evidence that you were not doing it enough.I think you are purposely omitting the fact that those failures have root causes that come from violating key Agile principles.Things like "we started a project without a big design upfront and we accepted all of the product owner's suggestions, but whe were overworked and ran out of time, and the product owner refused to accommodate requests, and when we finally released the product owner complained the deliverable failed to meet the requirements and expectations".This scenario is very mundane and showcases a set of failures that are clearly "not doing enough Agile" because it violates basically half of them.> The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.Agile is a set of principles focused on the process and its execution. What compels you to talk about Agile and pretend that processes and execution are anything other than the core topic?If your stakeholders change requirements but don't change allocated resources and fail to stay up to date in the daily affairs to monitor and adapt, how is this anything other than glaring failures to adhere to basic Agile principles?

tux1968: But that isn't evidence that the method works. If you're a native tribe, that has an ancient traditional rain dance, it is invoked whenever there is a drought. Sometimes it rains shortly after the dance is performed. But if it doesn't rain, it's not proof that you danced poorly, it's evidence that you didn't understand the situation fully or properly. The instructions or "wisdom" you relied on, didn't actually capture something useful.

t43562: My evidence is that I was on a team that was not overly controlled by management and had clever people in it without any instant attitudes of rejection so they adapted to it. We produced updates bi-weekly and we had a huge backlog of stupid features which we were never going to get round to - we were able to get the important things done and it was one of the best feelings I've ever had about work.Since then I've been on teams with any number of pathologies. From developers it is sometimes the desired to be special - those ones who want to work on their bit of the code and not let anyone else touch it. From managers it's things like forcing the way stories are split so that they're always too large and can never fit into a sprint - because they think that everything must be a "user visible change". Management types also sit in retrospectives and use them to crap on everyone. Product managers demand features which they don't know will really interest customers and are inflexible about them - they want "everything" just in case and that delays the work and deletes any chance of a feedback loop.The good agile feeling came from being able to have control and be successful. When it's messed up, you're out of control and cannot avert disasters. Whatever method you want to call it, I think we need to feel we're in control enough to succeed.

Balinares: I mean, Switzerland and North Korea both call themselves democracies but the specifics matter. The specifics matter!These discussions are always fascinating in a sort of baffling way to me because I've only had great experiences with what I call agile. Like, you bring it into the team and within months everyone is gushing about how much better life is now. Yet threads like this one are full of people reporting awful experiences.Apparently whatever it is they're doing involves a lot of meetings and little actual flexibility? The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them? Every team and every business is different and you have to iterate to arrive at whatever will work best for you. That's possibly the one most important point, IMO. Dropping the things that don't work is a key part of that!Eric Brechner of Microsoft (of all possible places...) gives a great talk on his team's approach, and I've had good experiences using it as a starting point: https://www.youtube.com/watch?v=CD0y-aU1sXoBut again, every team is different. Even the greatest possible theoretical approach is only a starting point.And like with Switzerland vs North Korea, I guess the key thing is how much ownership of the process those subjected to it have?

ilitirit: I personally have never worked in a team where Agile has failed. But I've also seen it fail all around me. Especially when it's mandated without buy-in. Or when people just don't "get it".e.g.- 45 minute "standups" (!?)- PI "planning" that consisting of deadlines and glorified multiplayer MS Paint- Rigid adherence to ceremonies or processes that add zero value- Retros that focuses on complaints and venting with no actionable outcomes- etc etcEvery time I've introduced Agile to a team or project that was new to it I was always met with skepticism. But 6 months down the line noone on the team/project wanted to go back to the "old" way of working. I don't even really care about any text book definitions. These are the only things we try to stick to:- Short, daily standups- Planning based on risk reduction- Estimates based on complexity (ties in with risk reduction)- Actionable retro items- User demos every sprint

mitthrowaway2: From my reading, it's really quite brilliant. He just says that he's about to start the tasks that, in reality, he's just finishing up. Then he delays reporting that the task is done. His estimates are then always made with perfect hindsight.

440bx: This is the horseshoe theory of Agile. If you do Agile hard enough you end up at SAFe which is basically waterfall.

f1shy: Waterfall disguised with other names and extrem expensive certification.

Erndob: Which also conveniently makes you spend more money on tokens.With agile, at least no one was charging you for it. Like sure, there’s a cost to the process. But there wasn’t direct agile.com profiting from you.Meanwhile agentic workflows every solution to the problem is giving more money to the ai companies.Model is bad? Made more expensive model. Still bad? Here’s an infrastructure that reads huge text files again and again making you consume tokens. Still bad? Here’s a way to easily spin up multiple agents at once so you can delegate work. Still bad? Here’s a new service that will automatically review code. Still bad? Maybe a biggger more expensive model will help.

f1shy: >> With agile, at least no one was charging you for it.Depends. There are companies [1] making loads of money out of it. Charging for certification and imposing the idea that either you are certified, or you are going to fail. They are even eating the lunch of PMI, as PMI (PMBoK) is turning into an Agile manual. Where I work is being expended literally millions per year in Agile.[1] https://scaledagile.com/what-is-safe/

f1shy: I've seen similar effect with Montesori, Waldorf, Kumon methods. If something is wrong, is because it was misunderstood, or not properly done.

strangegecko: The problem is a disconnect between management and those who build.My thoughts when PE forced Agile on my employer were dismissed as "you're the technical expert, we're the process experts".As someone without decision power, you read words of empowerment but your reality is a different one, and you're left resolving that dissonance on your own (quietly, otherwise you get pushed aside).

tux1968: What is the chance that you've perfectly captured every aspect of the situation that lead to success? Versus, what is the chance that you were lucky enough to be in situations where a multitude of factors, both appreciated and unappreciated, combined to lead to success?There are a million possible reasons for failure, but here is a very easy one: It doesn't matter how good you feel about the development process, if the company has the wrong objective. You will still end up being frustrated, and failing. Of course this will have all sorts of pathological and uncomfortable ramifications.So while it is easy to say, "just act this way and you'll have success". You're not actually appreciating all the hidden elements that allow any hope of acting that way. You've been lucky enough to be in situations where it happened to work (ie. the rain dance made rain), but that does not mean it's actually representative, or that the prescription actually captures the important information, other people can use to replicate success.

Balinares: I've had good success in both high-skill teams (in one case, almost half the team's engineers ended up at Google at some point or other) and... teams that were still in the process of skilling up. I've found people generally want to do good things and have some room to grow even if they're not yet at your desired level; and when you have demotivated people around, the causes tend to be systemic. Which, thankfully, implies possibly fixable.

duskdozer: If it's an internet-required smarthammer without a handle that instead hits out on voice prompt, sometimes without enough or with too much force, sometimes knocks the nail out of the way and punches a hole, and sometimes hits you in the face, then yeah

sadeshmukh: https://en.wikipedia.org/wiki/No_true_Scotsman seems pertinent here.

beAbU: The fact that you spell agile with a capital "A" says all I need to know.