5 ms·

Any discussion about agile invariably yields the predictable flurry of personal hangups and misrepresentations. Most common of all, though, are the claims that

Any discussion about agile invariably yields the predictable flurry of personal hangups and misrepresentations. Most common of all, though, are the claims that if you just have a great team full of great developers, you don't need a process. Agile and waterfall both be damned. But most teams aren't great. Most of the teams of people participating on HN statistically aren't great. But those teams still need to develop something -- banks and big cos and countless firms are churning out code by the millions of lines, by millions of completely average developers -- and agile is an honest conclusion that the classic method of software development doesn't work, most critically by biting off work in such enormous chunks that implementation or design issues -- the fit to the problem -- aren't discovered until enormous efforts have been wasted. So talk about how agile failed, in your estimation, at some shop or another. But the truth is that almost anything would be a "failure" versus the idealized notion of a perfect design built expertly by great developers. Agile is trying to make the best of a normal situation.

lawl 11y ago
I'm not sure what your argument is here. Because the classical model failed agile can't fail too? I think you're also misunderstanding "great teams". I at least do not mean a team of great developers, but a team that works well together. It's a great team, not a great group of developers. You can have the best developers in the world, it won't work if they can't stand each other.
- irrigation 11y ago
  The "argument" is that making software is an ugly, brutish affairs in virtually every case, with virtually every approach. There are extraordinarily few cases throughout history where a team converged, looked at the problem, built a solution, and voila, everyone emerged happy. In the real world there is always a discord between requirements and reality, skillsets and the problem space, change management and the need for rapid change, scope creep, and on and on. It is the story of every software project everywhere throughout time. But invariably the comments will fill with tales of woe with agile (usually with people betraying a complete lack of understanding of it, as an aside, such as seen with most uses of the term "scrum" throughout these discussions. It serves as the canary in the coal mine when noxious gases are afoot), as if troubled projects are some unique reality of agile. They're a reality of every single methodology. Agile merely tries to help reduce a few of the bigger and most deadly issues, which are friction with the business (the ability to adapt to change), and enormous investments of time and money to a project that ends up being a solution to the wrong problem. It doesn't suddenly make everyone cooperative and great. As to my "misunderstand", so the solution as you see it is just to have developers that work well together. Easy peasie solution.
  - lawl 11y ago
    Once again. > Because the classical model failed agile can't fail too? > so the solution as you see it is just to have developers that work well together. Easy peasie solution. No one said it's easy. No one said you can just have it. No one claims it's the solution to how we build software. > usually with people betraying a complete lack of understanding of it, as an aside, such as seen with most uses of the term "scrum" throughout these discussions Why don't you just tell me you think I completely lack understanding of the subject matter?
    - deleted 11y ago
      [deleted]
    - derriz 11y ago
      The beauty of Agile is: if you question or criticize it, you don't understand it; if it didn't work for you, you didn't apply it properly; if you applied it rigorously and it failed, you didn't have a deep understanding of it. Was it Sartre who said "it is what it is not"?
      - dudifordMann 11y ago
        Agile is not an "it", agile is not static. Application of agile principals means guiding and improving development processes. This is not a damned if you do damned if you don't scenario. As the article suggested, you have to "inspect and adapt". If something did not work for you, then capture the results, perform a lesson's learned, and try again. To say "apply agile methods", is to apply a nimbleness of the mind. This is where not everyone "gets it" right away. If someone suggests a paradigm shift from what you as a developer are accustomed to, you may very well fall flat on your face. But to apply agile methods means to be able to get back up and try a different approach.
        collyw 11y ago
        The very definition of agile seems itself to be very "agile" and constantly changing depending on the discussion.
LordHumungous 11y ago
None of the people who complain about agile offer any viable alternatives. I get the impression that these are developers who simply hate being managed period, and would prefer that management never spoke to them at all.
- yxhuvud 11y ago
  I certainly wouldn't mind if the middle manager that had an hour long meeting today never spoke to me again. The first slide was MLK with "I have a dream" which then continued onwards with 15 minutes talking about how to move post-it stickers on a whiteboard and 15 minutes spent doing a failed analogy between a GPS and continuous reevaluation of when the next release will be done. At the same time, management has decided to have a release cycle that is 10 months (or in reality after the inevitable delays: 12)..
- sheepmullet 11y ago
  Because there isnt a one size fits all approach that works well. The most effective project I have worked on had ~15 hours of meetings every week.
sheepmullet 11y ago
"But most teams aren't great" Most teams work hard enough to become great. Most teams work long enough hours to become great. Most teams are smart enough to become great. Most teams even have the desire to become great. So what is stopping them? At the developer level: Lack of autonomy, lack of purpose, and lack of mastery. These issues aren't fixed by Agile. At the management level: High turnover. Lack of attention/focus on things that aren't easily measurable. Lack of leadership. Constant arbitrary deadlines. A short term focus. Politics. Again, none of it fixed by Agile.
- wppick 11y ago
  This is a great insight, and describes some of the projects I've worked on exactly. I think a fix to these two problems is to hire great developers that you can trust, and give them much bigger tasks. I find that the management breaks things up into too small of tasks so that they can measure it, which creates a bottom up approach, and that's just not how good software works. I prefer the top down approach, which means design the code from a high level (architecture, components, overall structure) then drill down and build the different parts.

lawl 11y ago

I'm not sure what your argument is here. Because the classical model failed agile can't fail too? I think you're also misunderstanding "great teams". I at least do not mean a team of great developers, but a team that works well together. It's a great team, not a great group of developers. You can have the best developers in the world, it won't work if they can't stand each other.

irrigation 11y ago
The "argument" is that making software is an ugly, brutish affairs in virtually every case, with virtually every approach. There are extraordinarily few cases throughout history where a team converged, looked at the problem, built a solution, and voila, everyone emerged happy. In the real world there is always a discord between requirements and reality, skillsets and the problem space, change management and the need for rapid change, scope creep, and on and on. It is the story of every software project everywhere throughout time. But invariably the comments will fill with tales of woe with agile (usually with people betraying a complete lack of understanding of it, as an aside, such as seen with most uses of the term "scrum" throughout these discussions. It serves as the canary in the coal mine when noxious gases are afoot), as if troubled projects are some unique reality of agile. They're a reality of every single methodology. Agile merely tries to help reduce a few of the bigger and most deadly issues, which are friction with the business (the ability to adapt to change), and enormous investments of time and money to a project that ends up being a solution to the wrong problem. It doesn't suddenly make everyone cooperative and great. As to my "misunderstand", so the solution as you see it is just to have developers that work well together. Easy peasie solution.
- lawl 11y ago
  Once again. > Because the classical model failed agile can't fail too? > so the solution as you see it is just to have developers that work well together. Easy peasie solution. No one said it's easy. No one said you can just have it. No one claims it's the solution to how we build software. > usually with people betraying a complete lack of understanding of it, as an aside, such as seen with most uses of the term "scrum" throughout these discussions Why don't you just tell me you think I completely lack understanding of the subject matter?
  - deleted 11y ago
    [deleted]
  - derriz 11y ago
    The beauty of Agile is: if you question or criticize it, you don't understand it; if it didn't work for you, you didn't apply it properly; if you applied it rigorously and it failed, you didn't have a deep understanding of it. Was it Sartre who said "it is what it is not"?
    - dudifordMann 11y ago
      Agile is not an "it", agile is not static. Application of agile principals means guiding and improving development processes. This is not a damned if you do damned if you don't scenario. As the article suggested, you have to "inspect and adapt". If something did not work for you, then capture the results, perform a lesson's learned, and try again. To say "apply agile methods", is to apply a nimbleness of the mind. This is where not everyone "gets it" right away. If someone suggests a paradigm shift from what you as a developer are accustomed to, you may very well fall flat on your face. But to apply agile methods means to be able to get back up and try a different approach.
      - collyw 11y ago
        The very definition of agile seems itself to be very "agile" and constantly changing depending on the discussion.

LordHumungous 11y ago

None of the people who complain about agile offer any viable alternatives. I get the impression that these are developers who simply hate being managed period, and would prefer that management never spoke to them at all.

yxhuvud 11y ago
I certainly wouldn't mind if the middle manager that had an hour long meeting today never spoke to me again. The first slide was MLK with "I have a dream" which then continued onwards with 15 minutes talking about how to move post-it stickers on a whiteboard and 15 minutes spent doing a failed analogy between a GPS and continuous reevaluation of when the next release will be done. At the same time, management has decided to have a release cycle that is 10 months (or in reality after the inevitable delays: 12)..
sheepmullet 11y ago
Because there isnt a one size fits all approach that works well. The most effective project I have worked on had ~15 hours of meetings every week.

sheepmullet 11y ago

"But most teams aren't great" Most teams work hard enough to become great. Most teams work long enough hours to become great. Most teams are smart enough to become great. Most teams even have the desire to become great. So what is stopping them? At the developer level: Lack of autonomy, lack of purpose, and lack of mastery. These issues aren't fixed by Agile. At the management level: High turnover. Lack of attention/focus on things that aren't easily measurable. Lack of leadership. Constant arbitrary deadlines. A short term focus. Politics. Again, none of it fixed by Agile.

wppick 11y ago
This is a great insight, and describes some of the projects I've worked on exactly. I think a fix to these two problems is to hire great developers that you can trust, and give them much bigger tasks. I find that the management breaks things up into too small of tasks so that they can measure it, which creates a bottom up approach, and that's just not how good software works. I prefer the top down approach, which means design the code from a high level (architecture, components, overall structure) then drill down and build the different parts.