5 ms·

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 va

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?

avens19 11y ago
"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 11y ago
  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.)
gchokov 11y ago
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.
laichzeit0 11y ago
> 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.
city41 11y ago
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 11y ago
  > 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 11y ago
    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 11y ago
      > 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.)
tbrownaw 11y ago
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?
dragonwriter 11y ago
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 11y ago
  Agile was created by the consultants. It's a bit disingenuous to claim they also killed it. http://agilemanifesto.org http://agilemanifesto.org
a8da6b0c91d 11y ago
> 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 11y ago
  I downvoted you for this bit >>socially lower status people
DougWebb 11y ago
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 11y ago
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.

avens19 11y ago

"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 11y ago
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.)

gchokov 11y ago

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.

laichzeit0 11y ago

> 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.

city41 11y ago

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 11y ago
> 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 11y ago
  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 11y ago
    > 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.)

tbrownaw 11y ago

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?

dragonwriter 11y ago

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 11y ago
Agile was created by the consultants. It's a bit disingenuous to claim they also killed it. http://agilemanifesto.org http://agilemanifesto.org

a8da6b0c91d 11y ago

> 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 11y ago
I downvoted you for this bit >>socially lower status people

DougWebb 11y ago

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 11y ago

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.