4 ms·

Organizing groups of people to put together something decent in a highly limited amount of time and with humane treatment is extremely hard. I don't see Program

Organizing groups of people to put together something decent in a highly limited amount of time and with humane treatment is extremely hard. I don't see Programming, Motherfucker addressing that in any way.

Silhouette 15y ago
I don't see much evidence of Agile methodologies addressing that in any way, either. That's rather the point. After this long, if Agile is as superior to the alternatives as its advocates frequently claim, there should be heaps of empirical data miles high to justify each and every practice these consultants charge so much to explain by now. So where are they? The best I've seen any big name Agile consultant cite is a handful of small-scale experiments, mostly using CS students rather than experienced industrial practitioners, invariably not controlling for using unit tests alone without the TDD process, that show that projects using TDD have modest but inconsistent and frankly unspectacular gains over projects that don't bother unit testing at all. I'm a scientist. I believe in the data in front of me, and my conclusions on these matters are falsifiable. I will be happy to revise my opinions if and when new evidence shows any of them to be incorrect, but that evidence had better be more than a few alleged experts telling me what they think I should believe if I'm going to change the development practices of entire teams based on it.
- wpietri 15y ago
  It would be awesome if somebody would fund those experiments. But since Agile methods are mainly about sustaining high quality over the long term for teams of experts, studies with a useful n would be stunningly expensive. And honestly, there's no great reason to believe Agile consultants. Most of the market for software process improvement is in helping the clueless and/or terminally lazy. (And there's often even better money in not helping them, but instead just making them feel special.) Plus, a lot of the benefit from particular practices depends on the existing code, the business conditions, and the people involved. I think the right way to deal with Agile techniques is the same way one deals with new tools or new languages: try 'em for a while and see. E.g., I tried out TDD for a while and ended up liking it a lot. As does the rest of my team, such that they all were specifically looking for test-driven shops when I hired them. But even we tend to only use it on core code; test-driving most UI just doesn't pay off.
  - Silhouette 15y ago
    > But since Agile methods are mainly about sustaining high quality over the long term for teams of experts > Most of the market for software process improvement is in helping the clueless and/or terminally lazy. So are we trying to help teams of experts or the clueless and/or terminally lazy here? I don't know many clueless, terminally lazy experts, so it's got to be one or the other... Also, experts will evolve a workable process for any given project without needing to follow any particular Agile process to start with. That's one of the reasons they're experts. Also also, while it's convenient to pretend that no serious studies exist because of the cost, it should still be pretty clear that Agile processes have potential, because there should be a strong correlation between the time many organisations introduce them or which teams within a large organisation have adopted them and an improvement in measurable performance for the Agile groups. Correlation doesn't prove a causal link, of course, but lack of correlation is a strong indicator that no such link exists.
    - wpietri 15y ago
      > So are we trying to help teams of experts or the clueless and/or terminally lazy here? Me? I'm trying to help teams of smart, well-intentioned people. Which is why I'm happy to share what's worked for me and encourage people to try those things if they're interested. That's what motivates the early Agile people I know. But consultants are mostly in business to make money, and the bulk of their audience is clueless, so most of what gets sold as Agile today is tuned for them. I go into more detail on that here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... > Also, experts will evolve a workable process for any given project without needing to follow any particular Agile process to start with. That's one of the reasons they're experts. True, but that ignores the people who aren't experts yet. They're the ones I care most about. And it ignores the substantial costs of learning all the important lessons yourself; it's often better not to reinvent the wheel. > [..] teams within a large organisation [...] Personally, despite 10 years of looking, I have never seen teams within a large organization successfully adopt what I would consider a serious Agile approach. I have seen a lot of large organizations adopt Agile jargon and get nothing out of it, though. The problem is that Agile methods require a shift in power relations from top-down to bottom-up. Their approaches and values are basically antithetical to a lot of American business culture and MBA dogma. And successful exploitation requires deep change on the business side as well. I think Agile failed for the same reason that Lean Manufacturing failed here: the important part wasn't the easily observed rituals, but the cultural differences. And the vast majority of the people who are "doing Agile" (whatever that means) would not accept deep cultural change.

Silhouette 15y ago

I don't see much evidence of Agile methodologies addressing that in any way, either. That's rather the point. After this long, if Agile is as superior to the alternatives as its advocates frequently claim, there should be heaps of empirical data miles high to justify each and every practice these consultants charge so much to explain by now. So where are they? The best I've seen any big name Agile consultant cite is a handful of small-scale experiments, mostly using CS students rather than experienced industrial practitioners, invariably not controlling for using unit tests alone without the TDD process, that show that projects using TDD have modest but inconsistent and frankly unspectacular gains over projects that don't bother unit testing at all. I'm a scientist. I believe in the data in front of me, and my conclusions on these matters are falsifiable. I will be happy to revise my opinions if and when new evidence shows any of them to be incorrect, but that evidence had better be more than a few alleged experts telling me what they think I should believe if I'm going to change the development practices of entire teams based on it.

wpietri 15y ago
It would be awesome if somebody would fund those experiments. But since Agile methods are mainly about sustaining high quality over the long term for teams of experts, studies with a useful n would be stunningly expensive. And honestly, there's no great reason to believe Agile consultants. Most of the market for software process improvement is in helping the clueless and/or terminally lazy. (And there's often even better money in not helping them, but instead just making them feel special.) Plus, a lot of the benefit from particular practices depends on the existing code, the business conditions, and the people involved. I think the right way to deal with Agile techniques is the same way one deals with new tools or new languages: try 'em for a while and see. E.g., I tried out TDD for a while and ended up liking it a lot. As does the rest of my team, such that they all were specifically looking for test-driven shops when I hired them. But even we tend to only use it on core code; test-driving most UI just doesn't pay off.
- Silhouette 15y ago
  > But since Agile methods are mainly about sustaining high quality over the long term for teams of experts > Most of the market for software process improvement is in helping the clueless and/or terminally lazy. So are we trying to help teams of experts or the clueless and/or terminally lazy here? I don't know many clueless, terminally lazy experts, so it's got to be one or the other... Also, experts will evolve a workable process for any given project without needing to follow any particular Agile process to start with. That's one of the reasons they're experts. Also also, while it's convenient to pretend that no serious studies exist because of the cost, it should still be pretty clear that Agile processes have potential, because there should be a strong correlation between the time many organisations introduce them or which teams within a large organisation have adopted them and an improvement in measurable performance for the Agile groups. Correlation doesn't prove a causal link, of course, but lack of correlation is a strong indicator that no such link exists.
  - wpietri 15y ago
    > So are we trying to help teams of experts or the clueless and/or terminally lazy here? Me? I'm trying to help teams of smart, well-intentioned people. Which is why I'm happy to share what's worked for me and encourage people to try those things if they're interested. That's what motivates the early Agile people I know. But consultants are mostly in business to make money, and the bulk of their audience is clueless, so most of what gets sold as Agile today is tuned for them. I go into more detail on that here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... > Also, experts will evolve a workable process for any given project without needing to follow any particular Agile process to start with. That's one of the reasons they're experts. True, but that ignores the people who aren't experts yet. They're the ones I care most about. And it ignores the substantial costs of learning all the important lessons yourself; it's often better not to reinvent the wheel. > [..] teams within a large organisation [...] Personally, despite 10 years of looking, I have never seen teams within a large organization successfully adopt what I would consider a serious Agile approach. I have seen a lot of large organizations adopt Agile jargon and get nothing out of it, though. The problem is that Agile methods require a shift in power relations from top-down to bottom-up. Their approaches and values are basically antithetical to a lot of American business culture and MBA dogma. And successful exploitation requires deep change on the business side as well. I think Agile failed for the same reason that Lean Manufacturing failed here: the important part wasn't the easily observed rituals, but the cultural differences. And the vast majority of the people who are "doing Agile" (whatever that means) would not accept deep cultural change.