10 ms·

There is an insider story about how these methodologies comes about. So there are few groups of people whose sole job is to do consulting on failed/late/over bu

There is an insider story about how these methodologies comes about. So there are few groups of people whose sole job is to do consulting on failed/late/over budget projects. Mind you, they don't write code but rather they observe how things are going and then prescribe process/management improvements (McKinsey style). Once in a while, these folks bump in to terrible projects and whatever they prescribed sometime works like a charm. In that case, they take that prescription on road and advertise the hell out in conferences, magazines, blog posts. Unlike regular developers, they have all the time in the world to do these activities. They write books and give interviews and by the media power of distributing information suddenly they pop out as process gods who knows how to fix any project. Eventually the new things starts to fad, people realize what works in project X didn't worked in Y, speaker engagements starts drying out and then these folks need new thing to repeat the cycle. The obvious problem is that these folks prescribing the development process are not active developers. They are not even part of any real project over any long duration. They are in job of inventing and selling processes and handing out management advice as consultants. Whatever they prescribe, might have worked only in specific context and for specific symptoms, usually with huge dose of luck. Next time when you see new process fad, look up the history of originator of this process, what company he is part of, how much code has he written, how he makes money. You will know what I'm talking about.

mmcnl 9y ago
This is not true for agile. The agile manifesto was in fact drafted by software developers. Also, agile doesn't prescribe any process at all, in fact, it does the opposite. Agile in essence is quite beautiful, unfortunately it gets twisted and turned upside down until it's just another methodology (which is exactly the opposite of its original meaning).
- megaman22 9y ago
  You can't argue that there hasn't arisen an entire industry of snake oil salesmen whose sole purpose is pushing Agile, and Scrum, and whatever.
- varjag 9y ago
  Some 10 years ago I attended a purportedly OO development conference which was by that time taken over by agile crowd. It was full of nice, chatty and energetic people. I was lost. It felt like slipping through a crack in the Universe, Sliders-style, into reality where you can't understand people discussing the things you do for years. There were few other developers attending, seemingly just as startled by all this. The whole thing ended with some Agile activity for all attendants which I can best describe as a mix of kindergarten class and Baptist sermon. I could not comprehend the intent, the procedure and the desired outcome (and whether it was achieved).
  - emodendroket 9y ago
    Oh, you know, I'd forgotten about the paper airplanes and pasta sculptures.
  - maxxxxx 9y ago
    That's how I felt when I attended my Scrum Master training. There was almost nobody in there who actually wrote code. The discussions were very abstract and about situations I had never encountered in work life.
    - rukuu001 9y ago
      Couple points re this. People attending SM training are often just middle managers learning enough to know WTF their SMs and PMs are talking about in meetings. Also, there's no requirement for SMs to be coders, it's a role a lot of BAs take on. Some experience in software development context is desirable tho. I found a lot of my SM training relateable to real life. My team went crazy for planning poker because it got a lot of assumptions out early. Standups were impossible because some people started at 1pm, others finished at 4pm. I see Scrum as a bag of tools to apply to teams. Some work, some don't.
- dannyrosen 9y ago
  There's working with agility and there's "Agile." One is a product one is not.
- cc81 9y ago
  I actually like vanilla Scrum and think often you need a formalized methodology for the team to follow. I've worked with a lot of different teams and there are a few things I've noticed being pretty common among developers (or sometimes being guilty of myself). 1. Not working on what you are supposed to be working on. Sometimes some developers feel that they should probably rewrite X or add Y and does so without consulting anyone first. Something it is good and sometimes it just takes time or adds regressions you did not need at the time. 2. Senior developers owning a piece of the code base. Often grabbing a huge chunk of work for themselves on it and then you don't hear from them for a while when they hack away. Sometimes they do good work and sometimes not and if they are sick or away and no one knows how their code works. 3. Junior (or some senior) developers being stuck for a long while without asking for help. 4. Ignoring the customer and building what you think should be built. None of those are automatically fixed with Scrum and I know some here will just say "Yeah, we have a professional team that actually talks with each other and does code reviews" so they don't need it. And I get that but for a lot of those small teams building some CRUD application at a large enterprise the formalized communication ways are a god send in my experience.
  - deleted 9y ago
    [deleted]
  - piva00 9y ago
    I agree with you that a formalized methodology is required for you to start with agile, be it XP, Scrum, Kanban or whatever the flavor the team itself feels more comfortable doing. What no one tells these teams is that the methodology/process itself should be flexible, should be allowed to change to accommodate the idiosyncrasies of their work environment. What I've noticed helping some small companies is that teams learn some framework and use that as their "agile" concept and then proceed to be overzealous of the process itself, completely forgetting the original manifesto. Like always, it's a strange whisper game...
    - gregmac 9y ago
      Adjusting the process literally is part of Scrum. At the retrospective, if something isn't working, you call it out and change it. That can be something as big as completely changing the methodology. I've never worked on a XP team but my understanding is formally there is no retrospective process - I would definitely want to put one in place if I did work with it. Any development process that doesn't allow for changing itself is shortsighted and ultimately self-defeating.
- emodendroket 9y ago
  Something like Scrum springing up is completely predictable though
- ZenoArrow 9y ago
  To me the key differentiator in agile approaches is whether it's business-led or developer-led. If developers can decide on what gets done and when, then agile can work quite well, but to me that's just a pipe dream in most cases. Unless a company's sole business is software, and the financial health of a company is strong, developer-led agile is a hard sell for business owners, even if it leads to long term benefits. So what happens instead is business-led agile which in my experience is worse than waterfall, as you get constant demands for poorly defined new features, with tight deadlines as that's being 'agile'. In other words, agile has just become a stick for companies to beat their developers with. That wasn't the original intention, but I would suggest that's at least part of the reason why management types like the term 'agile' so much.
  - goalieca 9y ago
    Developer led as in you give me some requirements and a deadline and then get out of my way and let me decide how i will break down my task and coordinate with other team members? Give me waterfall please! :)
    - ZenoArrow 9y ago
      Interesting. What issues have you had with developer-led agile?
      - goalieca 9y ago
        That it’s not really developper led and is just another form of micromanagement. A developer led way of development would do away with sprints if it suited the purpose. It would prioritize requirements over stories if it suited the purpose. It gets even more frustrating when you have to start to work a certain way with scrum (eg frequent commits, vertical development, etc).
- mannykannot 9y ago
  Waterfall was also drafted by software developers, who noticed that many of the least tractable errors had their roots in poorly-specified requirements and poor design. It was a first pass at a problem that is still with us.
- deleted 9y ago
  [deleted]
- jholman 9y ago
  > The agile manifesto was in fact drafted by software developers Really? When I look at the list of authors of the Agile Manifesto, I recognize several names as belonging to people who have made a career out of coaching and advising. Several of those people made their careers by bragging about their involvement in a catastrophic failure. I mean, they're probably all better software developers than I am. But I think that sytelus's description seems to be right on, at least for many of the Agile Manifesto authors.
icebraining 9y ago
Well, let's see: Extreme Programming (XP): created by Ron Jeffries, Kent Beck and Ward Cunningham - all developers. The Agile Manifesto: written by seventeen developers (http://agilemanifesto.org/ http://agilemanifesto.org/). Scrum: created by two of the seventeen above.
- zwischenzug 9y ago
  I would distinguish between agile as conceived and agile as sold. Agile itself was very simple and limited as a manifesto, arguably trivial and obvious.
  - deleted 9y ago
    [deleted]
  - icebraining 9y ago
    That's my point: you can't do as the original poster suggests ("look up the history of originator of this process"), since those are often developers.
  - bborud 9y ago
    Precisely.
  - piva00 9y ago
    I was too young on my career at the time to know how much agile was trivial and obvious when it appeared, it sounds more like a Columbus' egg but I'd appreciate if anyone can give me sources on how obvious agile was before the manifesto was released.
    - notduncansmith 9y ago
      For anyone else who hadn't heard this phrase before: https://en.wikipedia.org/wiki/Egg_of_Columbus https://en.wikipedia.org/wiki/Egg_of_Columbus Thanks for introducing me to it :)
    - hackerfromthefu 9y ago
perlpimp 9y ago
it is about interactions within the team, as about how team interacts within, author pointed to article about this: https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/ https://rework.withgoogle.com/blog/five-keys-to-a-successful... meaning that process doodads are ok but you have to focus on interaction.
olavk 9y ago
> Once in a while, these folks bump in to terrible projects and whatever they prescribed sometime works like a charm Not always true. For example Extreme Programming actually originated from an effort to save a large software system in trouble (a payroll management system for Chrysler). But in this case the prescription didn't work and the project was never completed. It is pretty impressive to be able to sell a methodology on this background.
- k__ 9y ago
  I read that the main selling point of XP is "a group of highly skilled people doing their thing" Which only works as long as you got highly skilled people to start with.
  - Silhouette 9y ago
    Which only works as long as you got highly skilled people to start with. Moreover, I would argue that almost anything you put down on paper as the development process can work if you've got an interested team of skilled people. Such a team will naturally adapt and adjust until they've got something effective, if necessary to the point that the original on-paper idea has all but disappeared if it wasn't helping. That's also essentially the first point of the original Agile Manifesto, though of course it's been happening since long before anyone ever wrote it down and gave it a name.
    - raarts 9y ago
      You're not wrong, but all those software methodologies aren't meant for the teams of very good developers, because they don't need them, but for the large majority of mediocre programmers who need to be herded.
      - Silhouette 9y ago
        Right, so the effectiveness of any particular methodology when applied by a team of very good developers isn't particularly useful information. What would be more useful is knowing whether the same methodology brings significantly better results when adopted by a team of average developers when compared to whatever they were doing before. I'm agreeing with k__ here.
walshemj 9y ago
No the Waterfall model and BS 5750/ ISO9000 both originated in traditional engineering - back in the day I actually worked on research to apply BS5750 to software development.
- fapjacks 9y ago
  What the parent means is: Can you point to any other (faddish) methodology that didn't come about in that way? Also, waterfall was provided in the original paper as a minimally-viable methodology of software development which was specifically recommended against. A kind of "If it comes down to using waterfall or using nothing, I guess use waterfall" type of thing.
  - walshemj 9y ago
    ask the USA and UK MotorBike and Car industry about the "faddish" methodology the Japanese companies used to hand them their ass
    - fapjacks 9y ago
      But we're not talking about "the USA and UK MotorBike and Car industry" now are we? Or, you know, really anything but software development methodologies?
      - Nomentatus 9y ago
        Actually, I'd say the statistical methods used by the Japanese (mostly to zero in on sub-par team members by shuffling them through teams and measuring the results) do have some similarity to test driven development, and even the sort of frequent (rough) measurement that Agile allows.
noir_lord 9y ago
I've been trying to find good material on software development in an enterprise setting in the 'real world' not the magical world of unicorns and pixies you nicely described. If anyone knows any good sources shout out.
aswanson 9y ago
Test driven development is about the only methodology that has worked for me. Agile, etc has been useless, at least at the gigs I've worked.
nickpsecurity 9y ago
Thanks to dang, we know exactly where the waterfall model came from: https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wat... http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf http://www.craiglarman.com/wiki/downloads/misc/history-of-it... It starts with a brilliant writeup on software process that shows waterfall as an example of what not to do. That document recommends iterative practices. Then, it got twisted into the waterfall model that was applied everywhere. The OP's comparisons to religion are quite warranted here.
proc0 9y ago
Yes, precisely, and the people who buy into it and force their organizations to adopt the latest fad, DON'T WRITE SOFTWARE. I'm so fucking tired of managers trying to play chess with teams when he has never really dealt with a software problem. I really think all these methodologies are ways for non-programmers to CONTROl programmers. In the near future, I think programming will be required for any software company employee, because compared to writing competent software, whatever the fuck management is doing will eventually be some form of automated reporting/dynamic to-do list.

mmcnl 9y ago

This is not true for agile. The agile manifesto was in fact drafted by software developers. Also, agile doesn't prescribe any process at all, in fact, it does the opposite. Agile in essence is quite beautiful, unfortunately it gets twisted and turned upside down until it's just another methodology (which is exactly the opposite of its original meaning).

megaman22 9y ago
You can't argue that there hasn't arisen an entire industry of snake oil salesmen whose sole purpose is pushing Agile, and Scrum, and whatever.
varjag 9y ago
Some 10 years ago I attended a purportedly OO development conference which was by that time taken over by agile crowd. It was full of nice, chatty and energetic people. I was lost. It felt like slipping through a crack in the Universe, Sliders-style, into reality where you can't understand people discussing the things you do for years. There were few other developers attending, seemingly just as startled by all this. The whole thing ended with some Agile activity for all attendants which I can best describe as a mix of kindergarten class and Baptist sermon. I could not comprehend the intent, the procedure and the desired outcome (and whether it was achieved).
- emodendroket 9y ago
  Oh, you know, I'd forgotten about the paper airplanes and pasta sculptures.
- maxxxxx 9y ago
  That's how I felt when I attended my Scrum Master training. There was almost nobody in there who actually wrote code. The discussions were very abstract and about situations I had never encountered in work life.
  - rukuu001 9y ago
    Couple points re this. People attending SM training are often just middle managers learning enough to know WTF their SMs and PMs are talking about in meetings. Also, there's no requirement for SMs to be coders, it's a role a lot of BAs take on. Some experience in software development context is desirable tho. I found a lot of my SM training relateable to real life. My team went crazy for planning poker because it got a lot of assumptions out early. Standups were impossible because some people started at 1pm, others finished at 4pm. I see Scrum as a bag of tools to apply to teams. Some work, some don't.
dannyrosen 9y ago
There's working with agility and there's "Agile." One is a product one is not.
cc81 9y ago
I actually like vanilla Scrum and think often you need a formalized methodology for the team to follow. I've worked with a lot of different teams and there are a few things I've noticed being pretty common among developers (or sometimes being guilty of myself). 1. Not working on what you are supposed to be working on. Sometimes some developers feel that they should probably rewrite X or add Y and does so without consulting anyone first. Something it is good and sometimes it just takes time or adds regressions you did not need at the time. 2. Senior developers owning a piece of the code base. Often grabbing a huge chunk of work for themselves on it and then you don't hear from them for a while when they hack away. Sometimes they do good work and sometimes not and if they are sick or away and no one knows how their code works. 3. Junior (or some senior) developers being stuck for a long while without asking for help. 4. Ignoring the customer and building what you think should be built. None of those are automatically fixed with Scrum and I know some here will just say "Yeah, we have a professional team that actually talks with each other and does code reviews" so they don't need it. And I get that but for a lot of those small teams building some CRUD application at a large enterprise the formalized communication ways are a god send in my experience.
- deleted 9y ago
  [deleted]
- piva00 9y ago
  I agree with you that a formalized methodology is required for you to start with agile, be it XP, Scrum, Kanban or whatever the flavor the team itself feels more comfortable doing. What no one tells these teams is that the methodology/process itself should be flexible, should be allowed to change to accommodate the idiosyncrasies of their work environment. What I've noticed helping some small companies is that teams learn some framework and use that as their "agile" concept and then proceed to be overzealous of the process itself, completely forgetting the original manifesto. Like always, it's a strange whisper game...
  - gregmac 9y ago
    Adjusting the process literally is part of Scrum. At the retrospective, if something isn't working, you call it out and change it. That can be something as big as completely changing the methodology. I've never worked on a XP team but my understanding is formally there is no retrospective process - I would definitely want to put one in place if I did work with it. Any development process that doesn't allow for changing itself is shortsighted and ultimately self-defeating.
emodendroket 9y ago
Something like Scrum springing up is completely predictable though
ZenoArrow 9y ago
To me the key differentiator in agile approaches is whether it's business-led or developer-led. If developers can decide on what gets done and when, then agile can work quite well, but to me that's just a pipe dream in most cases. Unless a company's sole business is software, and the financial health of a company is strong, developer-led agile is a hard sell for business owners, even if it leads to long term benefits. So what happens instead is business-led agile which in my experience is worse than waterfall, as you get constant demands for poorly defined new features, with tight deadlines as that's being 'agile'. In other words, agile has just become a stick for companies to beat their developers with. That wasn't the original intention, but I would suggest that's at least part of the reason why management types like the term 'agile' so much.
- goalieca 9y ago
  Developer led as in you give me some requirements and a deadline and then get out of my way and let me decide how i will break down my task and coordinate with other team members? Give me waterfall please! :)
  - ZenoArrow 9y ago
    Interesting. What issues have you had with developer-led agile?
    - goalieca 9y ago
      That it’s not really developper led and is just another form of micromanagement. A developer led way of development would do away with sprints if it suited the purpose. It would prioritize requirements over stories if it suited the purpose. It gets even more frustrating when you have to start to work a certain way with scrum (eg frequent commits, vertical development, etc).
mannykannot 9y ago
Waterfall was also drafted by software developers, who noticed that many of the least tractable errors had their roots in poorly-specified requirements and poor design. It was a first pass at a problem that is still with us.
deleted 9y ago
[deleted]
jholman 9y ago
> The agile manifesto was in fact drafted by software developers Really? When I look at the list of authors of the Agile Manifesto, I recognize several names as belonging to people who have made a career out of coaching and advising. Several of those people made their careers by bragging about their involvement in a catastrophic failure. I mean, they're probably all better software developers than I am. But I think that sytelus's description seems to be right on, at least for many of the Agile Manifesto authors.

icebraining 9y ago

Well, let's see: Extreme Programming (XP): created by Ron Jeffries, Kent Beck and Ward Cunningham - all developers. The Agile Manifesto: written by seventeen developers (http://agilemanifesto.org/ http://agilemanifesto.org/). Scrum: created by two of the seventeen above.

zwischenzug 9y ago
I would distinguish between agile as conceived and agile as sold. Agile itself was very simple and limited as a manifesto, arguably trivial and obvious.
- deleted 9y ago
  [deleted]
- icebraining 9y ago
  That's my point: you can't do as the original poster suggests ("look up the history of originator of this process"), since those are often developers.
- bborud 9y ago
  Precisely.
- piva00 9y ago
  I was too young on my career at the time to know how much agile was trivial and obvious when it appeared, it sounds more like a Columbus' egg but I'd appreciate if anyone can give me sources on how obvious agile was before the manifesto was released.
  - notduncansmith 9y ago
    For anyone else who hadn't heard this phrase before: https://en.wikipedia.org/wiki/Egg_of_Columbus https://en.wikipedia.org/wiki/Egg_of_Columbus Thanks for introducing me to it :)
  - hackerfromthefu 9y ago

perlpimp 9y ago

it is about interactions within the team, as about how team interacts within, author pointed to article about this: https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/ https://rework.withgoogle.com/blog/five-keys-to-a-successful... meaning that process doodads are ok but you have to focus on interaction.

olavk 9y ago

> Once in a while, these folks bump in to terrible projects and whatever they prescribed sometime works like a charm Not always true. For example Extreme Programming actually originated from an effort to save a large software system in trouble (a payroll management system for Chrysler). But in this case the prescription didn't work and the project was never completed. It is pretty impressive to be able to sell a methodology on this background.

k__ 9y ago
I read that the main selling point of XP is "a group of highly skilled people doing their thing" Which only works as long as you got highly skilled people to start with.
- Silhouette 9y ago
  Which only works as long as you got highly skilled people to start with. Moreover, I would argue that almost anything you put down on paper as the development process can work if you've got an interested team of skilled people. Such a team will naturally adapt and adjust until they've got something effective, if necessary to the point that the original on-paper idea has all but disappeared if it wasn't helping. That's also essentially the first point of the original Agile Manifesto, though of course it's been happening since long before anyone ever wrote it down and gave it a name.
  - raarts 9y ago
    You're not wrong, but all those software methodologies aren't meant for the teams of very good developers, because they don't need them, but for the large majority of mediocre programmers who need to be herded.
    - Silhouette 9y ago
      Right, so the effectiveness of any particular methodology when applied by a team of very good developers isn't particularly useful information. What would be more useful is knowing whether the same methodology brings significantly better results when adopted by a team of average developers when compared to whatever they were doing before. I'm agreeing with k__ here.

walshemj 9y ago

No the Waterfall model and BS 5750/ ISO9000 both originated in traditional engineering - back in the day I actually worked on research to apply BS5750 to software development.

fapjacks 9y ago
What the parent means is: Can you point to any other (faddish) methodology that didn't come about in that way? Also, waterfall was provided in the original paper as a minimally-viable methodology of software development which was specifically recommended against. A kind of "If it comes down to using waterfall or using nothing, I guess use waterfall" type of thing.
- walshemj 9y ago
  ask the USA and UK MotorBike and Car industry about the "faddish" methodology the Japanese companies used to hand them their ass
  - fapjacks 9y ago
    But we're not talking about "the USA and UK MotorBike and Car industry" now are we? Or, you know, really anything but software development methodologies?
    - Nomentatus 9y ago
      Actually, I'd say the statistical methods used by the Japanese (mostly to zero in on sub-par team members by shuffling them through teams and measuring the results) do have some similarity to test driven development, and even the sort of frequent (rough) measurement that Agile allows.

noir_lord 9y ago

I've been trying to find good material on software development in an enterprise setting in the 'real world' not the magical world of unicorns and pixies you nicely described. If anyone knows any good sources shout out.

aswanson 9y ago

Test driven development is about the only methodology that has worked for me. Agile, etc has been useless, at least at the gigs I've worked.

nickpsecurity 9y ago

Thanks to dang, we know exactly where the waterfall model came from: https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wat... http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf http://www.craiglarman.com/wiki/downloads/misc/history-of-it... It starts with a brilliant writeup on software process that shows waterfall as an example of what not to do. That document recommends iterative practices. Then, it got twisted into the waterfall model that was applied everywhere. The OP's comparisons to religion are quite warranted here.

proc0 9y ago

Yes, precisely, and the people who buy into it and force their organizations to adopt the latest fad, DON'T WRITE SOFTWARE. I'm so fucking tired of managers trying to play chess with teams when he has never really dealt with a software problem. I really think all these methodologies are ways for non-programmers to CONTROl programmers. In the near future, I think programming will be required for any software company employee, because compared to writing competent software, whatever the fuck management is doing will eventually be some form of automated reporting/dynamic to-do list.