[commentnull]

The article starts with the current note - agile as it was preached was never actually achieved, and most companies and practioners are doing it "wrong" (for varying degrees of wrong).

But then it goes downhill with proposing yet another model that will people will try to adopt verbatim, and again, experience failure to implement.

Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.

What really killed agile fwiw, where the consultants, going from development team to team, peddling false hope, snake oil, and tedious time zapping process that people learnt to game rather than actually deliver.

Of course, someone will pop up saying agile is awesome, they love the daily scrums, the project is fab, the sky is blue, etc. Question is: can it be better?

[city41]

In my experience, the people who say agile is awesome would likely say any process is awesome. Because the true awesomeness they are experiencing comes from being on a good team. After wading through years and years of agile, even working for a major agile tool maker for a while, I've come to the conclusion what process you choose isn't that important. Get a good, passionate, driven team together, and they'll figure out how to kick ass. Without that ingredient, nothing else matters.

[dragonwriter]

> In my experience, the people who say agile is awesome would likely say any process is awesome. In my experience, the people who say agile is awesome would likely say any process is awesome.

Agile is awesome because its not a process, but a set of principles which addresses exactly the problem that context-blind adoption of processes creates that makes good teams mediocre and bad teams worse.

Most of the processes sold in a context-blind manner as "Agile" suck, but they are a recreation of exactly what the Agile Manifesto was a reaction against.

[city41]

That's true in theory but rarely in reality. The reality is Agile is a process, often a rigid one. I find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant. I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.

[dragonwriter]

> The reality is Agile is a process, often a rigid one.

No, the reality is that Agile is not a process, though there are a number of different processes sold as "Agile". (The most common now seems to be Scrum as defined in the Scrum guide and a number of variants on it; for a while XP was somewhat prominent as well.)

> find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant.

Teams that do that are Agile: that's exactly and all of what the Agile Manifesto says.

> I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.

The thing is the "Agile movement" consists of two separate and opposed forces: one (and the origin of "Agile") is people promoting exactly the behavior you mention characterizes good teams, the second (and the thing you seem to have a problem with) is people using the name that the first group came up with to promote exactly what the first group is reacting against -- rigid, context-blind adoption of externally-developed process (largely as a reaction against the threat posed by the good ideas of the first to the second groups pre-existing business of selling rigid, context-blind processes.)

[city41]

But the reality is almost everyone who "does agile" has rigidly adopted scrum, xp, kanban, etc. That is the reality most of us face. Just because a group got together 14 years ago and created a hypothetical scenario that essentially no one follows doesn't seem all that relevant to me.

And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?

The end reality is we have an entire industry built around that stupid manifesto. Sure, it's not what they wanted, but it's what we all got. We would have been better off without it.

[dragonwriter]

> And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?

Because while there are lots of people who won't understand that with an explanation, and some people who get it intuitively and don't need an explanation even with all the noise from people selling one true way, there's also lots of people in the middle who benefit from people selling there one-size fits all approaches not being the only voice in the marketplace of ideas.

> The end reality is we have an entire industry built around that stupid manifesto

No, we have an industry that existed long before the manifesto built around selling canned, context-blind process and jumping on anything even mildly popular to sell it that, predictably, when the manifesto calling for exactly the opposite of what that industry sold became popular, jumped on that to sell exactly the same thing they'd always been selling.

> We would have been better off without it.

No, I think that there are lots of people who have learned something from the Agile Manifesto, writings actually addressing how to implement its principles that don't amount to context-blind process, and related movements (Lean software development, etc.) and applied the ideas to improve teams and make software in a better way.

Most developers -- before and after the manifesto -- work in places where management is operated with shallow knowledge and poor respect for their staff and buying whatever consultants are selling in terms of process, sure, but that's not the fault of the Agile Manifesto

[avens19]

"Software is hard, people are hard"

^ this. Agile is only a set of principles set out to help write flexible software. It in no way made the actual writing of software, the gathering of requirements, the effort of design, easier; it simply gave us a process to follow that could potentially help avoid tedious re-writes. At the end of the day it's up to the people to put in the effort to make good software

[dragonwriter]

Agile does not give us a process, because Agile is not a process (it is a set of principles that can be applied to evaluate processes in the context of a particular team, but its 100% not a process.)

[tbrownaw]

Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.

People are soft and squishy. Too much rigid process pevents taking advantage of that squishiness. A complete lack of process will result in those squishy humans just producing a gooey puddle.

For every piece of process:

  * what problem does it solve?
  * what side-effects does it have?
  * are the side-effects good or bad, and how much so?
  * are there alternative solutions with better side-effects?

[laichzeit0]

> agile as it was preached was never actually achieved, and most companies and practioners are doing it "wrong" (for varying degrees of wrong).

You know Scientology, Amway and most other cult-like phenomena say the same thing: It's never the "system" that's wrong, if it's not working it means you're doing something wrong. You missed something, you didn't try it hard enough, you didn't do it like X, Y, Z.

[gchokov]

Two problems for me: [1] What bothers me is that people writing the manifesto admit that they are wrong, and they start the whole thing in the same way all over again. All over again!

[2] I have also seen practitioners and consultants that never did a single-frickin-project in their short lifetime, but preaching success. That's how you get wrong - theory and practice are often 2 very different things. And when the shit hits the fan, people say "you are doing the agile wrong". Alright.. teach me master, and admit how wrong you were 14 years ago. p.s. Apologies for the rant.

[dragonwriter]

What really "killed" Agile are two things: the absence of good guidance on how to apply Agile principles as opposed to canned methodologies, and the fact that most people don't have the skill to apply the principles without guidance.

There is some good guidance it there, but you have to get outside of the Agile "brand" for most of it, since much of the work on evaluating methods and other aspects of higher-level metamethodology that fits in with Agile principles is associated with "Lean" rather than "Agile".

[jkyle]

Agile was created by the consultants. It's a bit disingenuous to claim they also killed it.

http://agilemanifesto.org

[DougWebb]

Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.

This depends on the environment. Working for a consulting company, where time spent on the project is billed to a customer and the project has a fixed budget, Process is needed to make sure the project is estimated and executed properly, and the arse-covering helps to guarantee that you get paid when the customer makes changes mid-way through that increase the project costs.

It would be fantastic to work on projects with open-ended budgets and collaboration with customers to figure out what the software should be as it's being developed, but in the real world I don't think that is often possible. It's not just consultant/client relationships; even in big companies where IT is given a budget from upper management you have the same situation. Management won't approve a budget without a detailed description of the deliverable, and IT can't exceed the budget or deliver something other than what was promised.

Waterfall, for all of its drawbacks, handles this situation well. The problem is that no one wants to pay for all of the paperwork and management overhead it requires to function properly.

[hinkley]

Someone pointed this out to me long ago, and I've yet to see anything that disagrees with it:

Every time you see someone succeeding at Scrum, it's because they're also doing most of XP.

Maybe we need to go back to our roots. I know that several elements of XP have only recently clicked for me and I feel foolish for having taken so long (but nearly everybody I know is still struggling with those aspects too, so I'm in great company). And I was exposed to XP in '99, which means it took me 15 years.

[a8da6b0c91d]

> Most of it exists as arse-covering material anyway.

I think bean counter types throughout the business world truly believe there must be some secret fairy dust you can use to transform mid/low competency people into high competency people, and dysfunctional teams into highly functional teams. It's about wages. It's essentially a delusion that you can take cheap, socially lower status people and substitute for more expensive people as long as you have the right fairy dust.

The mentality works to a degree for certain disciplines. It works with McDonalds employees. You can apply management theory and systems to an infantry brigade and get good results from lower grade enlisted men.

The model simply does not map over to the "creative" professions and crafts. But managerial types are often averse to the idea that software engineering is a proper profession on par with their own, not commodity, and must command high pay. They prefer to keep seeking the right fairy dust.

[wavefunction]

I downvoted you for this bit

>>socially lower status people