6 ms·

The entire "agile" methodology strikes me as a prominent example of a software engineering cargo cult. Yes, good projects have been executed successfully using

The entire "agile" methodology strikes me as a prominent example of a software engineering cargo cult. Yes, good projects have been executed successfully using agile methodology. No, this does not mean that using agile caused these projects to work out well. Most agile projects fail, just like most non-agile projects. There is no evidence whatsoever that agile methodology causes projects to work out well -- but there is a whole mini-industry of training, books, seminars, "scrum masters" and so on built around the idea that it does.

projectileboy 10y ago
I agree, although I don't see that there's anything uniquely terrible about "agile". You could say the same thing about almost anything in our industry.
solipsism 10y ago
There's very little evidence whatsoever about any software development methodology or practice working well or poorly. That said, most experienced developers I've interacted with consider most of the Agile principles to be wise -- either common sense, or shown to be true via decades of experience. Here are the principles: * Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. * Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. * Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. * Business people and developers must work together daily throughout the project. * Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. * The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. * Working software is the primary measure of progress. * Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. * Continuous attention to technical excellence and good design enhances agility. * Simplicity--the art of maximizing the amount of work not done--is essential. * The best architectures, requirements, and designs emerge from self-organizing teams. * At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Which of these would you argue aren't wise principles for all of us to use when developing software? Now, if your beef is with Scrum (or some other branded methodology) in particular, I'd be more inclined to agree.
- qb45 10y ago
  Agile principles vary from place to place. Some I have seen: * We hold daily meetings because we are agile * We don't think about the future because requirements may possibly change * We don't make detailed implementation designs before coding starts because it's so waterfall * Everything has to be agreed on by 15 people * Everything not agile is waterfall and waterfall is Bad (TM) It looked like cargo cult attempts to preemptively solve problems others got 40 years ago from some different cargo cult.
- trhway 10y ago
  >Which of these would you argue aren't wise principles for all of us to use when developing software? most of these aren't principles, these are wishes. Like i can say i have 2 principles - be wealthy and be healthy - and those 2 principles look like very wise and hard to argue with, don't you think? Except for the stuff like this : > The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. >The best architectures, requirements, and designs emerge from self-organizing teams. which is just some personal beliefs or dreams of somebody, and is obviously not true in general. There is a reason things are called 'manifest' and not even a 'paper/essay', less 'peer-reviewed paper'...
  - solipsism 10y ago
    most of these aren't principles, these are wishes. Like i can say i have 2 principles - be wealthy and be healthy - and those 2 principles look like very wise and hard to argue with, don't you think? Becoming wealthy takes time and luck. It's not something you can just turn on at will. I just read through each of the principles, and I find exactly 0 of them that share that quality. Most of them tell you specifically what to do, and they are things that you can start doing at any time. Name one or more specific principles that are like "become wealthy" and we can talk about them specifically. We may be reading them differently. > The best architectures, requirements, and designs emerge from self-organizing teams. which is just some personal beliefs or dreams of somebody, and is obviously not true in general. I've worked remotely for a long time and love it. However, I certainly recognize that there's a legitimate cost to the team. I've also worked for years with teams that are split geographically. Again, the distance is a cost. Of course there are benefits too. That's why we pay the cost. But the principle says the best architectures, requirements, and design. How exactly could physical distance be a net negative to architectures, requirements, and designs, all other things being equal? The methods of communication at your disposal face-to-face are a strict superset of the methods at your disposal when physically separated.
robbiemitchell 10y ago
I have seen teams implement agile with the tools and processes, but not the spirit. Sprints, standups, etc. but without being driven by data and without cross-functional effort. So they turn into miniature waterfalls.
lordnacho 10y ago
It may well be done by cargo cult, because there's a lot of catchphrases to do with Agile that people are eager to use. I can definitely see how people can get excited, do a superficial attempt at implementing, and then wonder why it didn't work. But IMO the main thing about Agile is short feedback cycles. If your feedback is real (not just pleasing management), you can't avoid improving your product faster than some methodology (I hesitate to use such a word; it's really just rules of thumb) that insists on taking a long time between feedbacks. This also means that it's somewhat tautological that Agile methods will work. If you keep making product, you're getting work done. If you're not getting work done, you're not doing Agile.

projectileboy 10y ago

I agree, although I don't see that there's anything uniquely terrible about "agile". You could say the same thing about almost anything in our industry.

solipsism 10y ago

There's very little evidence whatsoever about any software development methodology or practice working well or poorly. That said, most experienced developers I've interacted with consider most of the Agile principles to be wise -- either common sense, or shown to be true via decades of experience. Here are the principles: * Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. * Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. * Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. * Business people and developers must work together daily throughout the project. * Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. * The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. * Working software is the primary measure of progress. * Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. * Continuous attention to technical excellence and good design enhances agility. * Simplicity--the art of maximizing the amount of work not done--is essential. * The best architectures, requirements, and designs emerge from self-organizing teams. * At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Which of these would you argue aren't wise principles for all of us to use when developing software? Now, if your beef is with Scrum (or some other branded methodology) in particular, I'd be more inclined to agree.

qb45 10y ago
Agile principles vary from place to place. Some I have seen: * We hold daily meetings because we are agile * We don't think about the future because requirements may possibly change * We don't make detailed implementation designs before coding starts because it's so waterfall * Everything has to be agreed on by 15 people * Everything not agile is waterfall and waterfall is Bad (TM) It looked like cargo cult attempts to preemptively solve problems others got 40 years ago from some different cargo cult.
trhway 10y ago
>Which of these would you argue aren't wise principles for all of us to use when developing software? most of these aren't principles, these are wishes. Like i can say i have 2 principles - be wealthy and be healthy - and those 2 principles look like very wise and hard to argue with, don't you think? Except for the stuff like this : > The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. >The best architectures, requirements, and designs emerge from self-organizing teams. which is just some personal beliefs or dreams of somebody, and is obviously not true in general. There is a reason things are called 'manifest' and not even a 'paper/essay', less 'peer-reviewed paper'...
- solipsism 10y ago
  most of these aren't principles, these are wishes. Like i can say i have 2 principles - be wealthy and be healthy - and those 2 principles look like very wise and hard to argue with, don't you think? Becoming wealthy takes time and luck. It's not something you can just turn on at will. I just read through each of the principles, and I find exactly 0 of them that share that quality. Most of them tell you specifically what to do, and they are things that you can start doing at any time. Name one or more specific principles that are like "become wealthy" and we can talk about them specifically. We may be reading them differently. > The best architectures, requirements, and designs emerge from self-organizing teams. which is just some personal beliefs or dreams of somebody, and is obviously not true in general. I've worked remotely for a long time and love it. However, I certainly recognize that there's a legitimate cost to the team. I've also worked for years with teams that are split geographically. Again, the distance is a cost. Of course there are benefits too. That's why we pay the cost. But the principle says the best architectures, requirements, and design. How exactly could physical distance be a net negative to architectures, requirements, and designs, all other things being equal? The methods of communication at your disposal face-to-face are a strict superset of the methods at your disposal when physically separated.

robbiemitchell 10y ago

I have seen teams implement agile with the tools and processes, but not the spirit. Sprints, standups, etc. but without being driven by data and without cross-functional effort. So they turn into miniature waterfalls.

lordnacho 10y ago

It may well be done by cargo cult, because there's a lot of catchphrases to do with Agile that people are eager to use. I can definitely see how people can get excited, do a superficial attempt at implementing, and then wonder why it didn't work. But IMO the main thing about Agile is short feedback cycles. If your feedback is real (not just pleasing management), you can't avoid improving your product faster than some methodology (I hesitate to use such a word; it's really just rules of thumb) that insists on taking a long time between feedbacks. This also means that it's somewhat tautological that Agile methods will work. If you keep making product, you're getting work done. If you're not getting work done, you're not doing Agile.