4 ms·

Development methodologies sort of work -- they don't work perfectly, but nothing really does. Most teams practice some sort of pseudo-version of methodology #1

Development methodologies sort of work -- they don't work perfectly, but nothing really does. Most teams practice some sort of pseudo-version of methodology #1 while they do the practical work of methodology #2. That doesn't mean methodology #1 is useless. Agile/scrum really did have an impact on the industry, and the proof of that is how hard it is to find people who still advocate for the kind of waterfall methodology that was once accepted by pretty much everyone. The annoying thing about development methodologies is meeting people who don't understand that the map is not the territory and insist that a perfect application of a methodology is absolutely necessary. They drive everyone else crazy with buzzwords and process. Most people are fine with a sort-of agile process that takes reality and business value into account.

wpietri 4y ago
As somebody who was very involved in the Agile movement early on (2000-2008 or so), I don't think Agile deserves the credit here. What I think actually happened was that the rise of the internet made faster release cycles both possible and necessary. Scrum rode that wave, saying that they had the solution. But most Scrum implementations I've seen are not what I'd call conscious, proactive process change. It's just a new set of labels for accelerated versions of the old behaviors (waterfall or code-and-fix or a mix), plus a revenue stream for consultants and a certification scam for everybody else. I wrote more about that a long time ago, and still stand by it: https://williampietri.com/writing/2011/agiles-second-chasm-and-how-we-fell-in/ https://williampietri.com/writing/2011/agiles-second-chasm-a...
computerdork 4y ago
I completely agree with this. Yeah, it's not like they don't work at all, it's that they work to some degree. And, yeah, I think a lot of devs would agree that the traditional waterfall is not as good a process as agile. You could say that it's an antiprocess, whose basic idea is that the old inflexible waterfall with its overly structured teams is inefficient. Yes, small, tight-knit teams working closely together and iterating quickly is much more productive, creative and rewarding way to work. ... although, in my humble opinion, the one thing that agile really needs to stress more (that is key in the waterfall) is requirements. A (couple of) dedicated rounds of requirements where you talk with users (and stakeholders) saves a ton of dev time - agile does have requirements, but at least in my experience, devs seems to gloss over it.

wpietri 4y ago

As somebody who was very involved in the Agile movement early on (2000-2008 or so), I don't think Agile deserves the credit here. What I think actually happened was that the rise of the internet made faster release cycles both possible and necessary. Scrum rode that wave, saying that they had the solution. But most Scrum implementations I've seen are not what I'd call conscious, proactive process change. It's just a new set of labels for accelerated versions of the old behaviors (waterfall or code-and-fix or a mix), plus a revenue stream for consultants and a certification scam for everybody else. I wrote more about that a long time ago, and still stand by it: https://williampietri.com/writing/2011/agiles-second-chasm-and-how-we-fell-in/ https://williampietri.com/writing/2011/agiles-second-chasm-a...

computerdork 4y ago

I completely agree with this. Yeah, it's not like they don't work at all, it's that they work to some degree. And, yeah, I think a lot of devs would agree that the traditional waterfall is not as good a process as agile. You could say that it's an antiprocess, whose basic idea is that the old inflexible waterfall with its overly structured teams is inefficient. Yes, small, tight-knit teams working closely together and iterating quickly is much more productive, creative and rewarding way to work. ... although, in my humble opinion, the one thing that agile really needs to stress more (that is key in the waterfall) is requirements. A (couple of) dedicated rounds of requirements where you talk with users (and stakeholders) saves a ton of dev time - agile does have requirements, but at least in my experience, devs seems to gloss over it.