7 ms·

Agile is the worst form of Software Development Methodoloy, except for all the others. Which is to say: To all the people jeering for Agile's demise, please pr

Agile is the worst form of Software Development Methodoloy, except for all the others. Which is to say: To all the people jeering for Agile's demise, please provide a superior alternative. I came from a world dominated by Waterfall, and I never want to go back to that. A lot of companies get Agile wrong, and it isn't a panacea, but it is much closer to what developers are naturally inclined towards (e.g. rapid incremental improvements) than Waterfall ever was. So I challenge anyone who wants to replace Agile, please lean into how developers work rather than trying to mold their work onto your rigid front loaded methodology. Trying to bring in ideas of other industries, like engineering or architecture, that build physical goods and only have one shot at is a folly.

CraigJPerry 7y ago
Yeah people have short memories of the pre-agile role demarcation and wasted handover time between them. It was utterly frustrating to be powerless to improve specification quality and find out you built exactly what was asked but you were asked for the wrong thing. The silos were horrible. Devs were often as bad as BAs, dev’s just were just crapping on the testers instead. Spare a thought for the production ops person at the very end of the chain. Here comes 3 months of developer work in one weekend and no it doesnt work but we’re still going live because the entire tech org is invested in this release. Now you have smaller squads, you can postpone a release without it looking bad on the top person and thus affecting your career prospects. In agile models you have the power to fix crap processes that don’t work. You can call out any BS on the retrospective and make it super visible when things are being swept under the rug.
- Spooky23 7y ago
  This. I worked on the customer delivery side of a $750M software project that was a steaming pile of shit, with critical defects that were known for a year with zero effort to address. The integrators were paid to deliver a spec, and it took about a year to get change orders created to diverge from the spec. The old school waterfall outsourcing models are truly awful, but you don’t really understand how bad unless you’ve lived it. Stupid agile religious practices are dumb for any startup type org, but are probably better than the alternatives in many big enterprise scenarios, where the goal is chunk up the work so marginally qualified people can do something.
thomascgalvin 7y ago
> To all the people jeering for Agile's demise, please provide a superior alternative. The goal of Agile is to let smart people work incrementally towards a somewhat nebulous goal. The ceremony that's arisen around that tends to be put in place by people who feel the need to manage, but don't know how to help their developers achieve that goal. The alternative, as far as I've seen, is to hire smart, curious people, let them work closely with the end user, and pay them a lot of money. In this situation, the engineers will typically self-organize effectively.
- closeparen 7y ago
  My org was like that when it was 20 people on one floor doing pretty much their own thing in groups of 2-4. Now it’s 100 people across two countries, expected to collaborate closely with sibling orgs. Management philosophy has shifted to “we will ask a few handpicked experts to write down the best way to do a thing, and then everyone else is a machine for executing that procedure.” If software engineering worked like that, we would have automated it.
- parasubvert 7y ago
  But, see, Engineers do not self-organize effectively, without some kind of frame of constraints to guide them - customers/users, design, time, quality, tech, architecture, etc. Assembling a talented team that ultimately delivers nothing of value is practically a cliche in this industry.
jimbob45 7y ago
The problem with Agile is that vanilla Agile almost certainly doesn't fulfill your company's requirements. However, if you put some serious thinking into tuning it for what you need, it will be serviceable. Agile would work much better if every implementation stated upfront, "Does not work right out of the box".
ebiester 7y ago
I think you're debating a strawman there. The argument is not that we need to return to other pre-agile SDLC methodologies but rather take what we've learned and go further. From the article: > Now, continuous delivery is what’s expected, and the industry is ready for the next thing. But that next thing shouldn’t be another methodology, according to Mary. > There is no methodology in my field of software engineering that can conceivably last more than five to eight years,” she said. “Everything that is 10 years old is obsolete. Everything that is 20 years old is archaic.” > Furthermore, she said, methodology requires codification. Beginning with the Capability Maturity Model (CMM) in the ‘90s, software development methodology meant developers had to show they had standards and that they followed them, rather than demonstrating that their standards were constantly in flux depending on consumer needs. That’s the definition of quality standards lean manufacturing practitioners in Japan originally espoused, Mary said, and they’re not compatible with methodology. Instead, they’re all about learning. > To that end, Mary is excited about all the ways artificial intelligence will allow software engineers to learn better and faster. Automated testing, continuous deployment and cross-functional collaboration are now table stakes, Mary and Tom agreed. Cutting edge companies will discover the next great approach through an engineering mindset and a willingness to learn. ___ Consider that Mary and Tom Poppendieck were responsible for many of the Lean inclusions of the agile movement, which (largely) came from watching plant manufacturing at Toyota. Similarly, much of the DevOps movement was tied to this as well. If you want to talk about what is next, it is likely taking a first principles look at what we're doing today, questioning best practices again, and saying, "if we were going to make a manifesto in 2020, what would it look like?"
- Someone1234 7y ago
  You claim I'm "debating a strawman" but then quote the article that literally says they have no alternative in mind (my chief critique) and point towards artificial intelligence to solve the issue somehow. The only "strawman" here seems to be taking my point about pre-Agile methodologies out of context, and using it to dismiss the entire idea that this article is unconstructive/has no actionable solutions.
  - ulisesrmzroche 7y ago
deleted 7y ago
[deleted]
username90 7y ago
> To all the people jeering for Agile's demise, please provide a superior alternative. Give individuals ownership over different parts and then let them self organize, that is all you need if you hire competent people. I'll never work at a place which doesn't work like that again.
- closeparen 7y ago
  To be fair, there are a lot of engineers on the market with a small-but-positive value under a structured process who would be totally useless in an environment like this. I can see why it might be rational to managers.
  - drapred7 7y ago
    The problem is that software engineers are paided poorly compared to bankers, executives, and a myriad of other occupations relative to how it used to be 30 years ago. Even doctors aren't paid like they used to be. So way too many smart people go into finance and real estate, which are jobs that really anybody could do, except that our corrupt system makes it worthwhile to pay the smartest people to come up with new ways to scam the public and the government. See: Fed policy, CDOs, sub-prime loans, QE...
    - jevgeni 7y ago
      Sub prime loans are the only thing out of that list where the public was scammed. Everything else you listed are internal banking things.
      - drapred7 7y ago
        The public absolutlely paid the price in the form of bailouts. If those banks had been allowed to fail I would agree with you, but they knew they'd probably be bailed out from the beginning and used CDOs to ensure it. QE is a direct transfer of wealth from dollar holders to investors and banks. No way around that.
downerending 7y ago
There are plenty of examples. The Linux kernel development process comes to mind. I suspect that most knowledgeable developers rolled their eyes when Agile was "invented". It's a mish mash of a lot of things that were already obvious at the time and some weird kool-aid like pair programming. And just one more in a long line of consultant enrichment schemes.
quicklime 7y ago
Agile is the worst form of software development methodology, second only to waterfall. It's still pretty shitty, though. One of the reasons Agile (with a big A) is so successful is that its peddlers have convinced everyone that there are only two options: Agile and waterfall. When you're up against a strawman, it's easy to win. But it's absolutely a false dichotomy. There's a quote in the article that I like: > Find me an actual tech company that talks much about Agile, and I will be astounded. In my experience, people at tech companies (at least the FAANGs) rarely talk about Agile, although they do talk about things like continuous integration/testing/deployment. They do not obsess over methodologies for how to move post-it notes around a whiteboard (Scrum vs Kanban) or agonize over how to word a user story narrative, or other parts of Agile Theatre. People at some non-tech companies, especially those supposedly going through a "digital transformation", seem to have fully bought in to the crap that Certified Agile consultants are selling though. So a superior alternative to both Agile and waterfall is what's in use at a lot of the big tech companies. For example, the engineering culture at Google, which relies on design docs and a very good set of developer tools and infrastructure. It's not perfect, but it's far, far superior to Agile. And before anyone makes the argument that those non-tech companies are not doing "real Agile", but Google is, let's be linguistic descriptivists and accept that Googlers don't call their methodology "Agile", whereas the Scrum consultants at big corporates do.
- parasubvert 7y ago
  This is ultimately the point I think Mary is trying to make. Agile became and end to itself rather than a way to learn how to build software within minimal waste and delay given imperfect information. Obsessing over it is a cargo cult. That said , plenty of tech companies have inconsistent practices that don’t necessarily lead to great success. To say Google’s methods are “far far superior” to Agile assumes they’re uniform, portable or relevant externally, or that they lead to above average success. That’s debatable given Google’s reputation for abandoned half-built products and an almost comical lack of customer focus.
- cachestash 7y ago
  Are there any public examples of a google design doc? Would like to study it
drngdds 7y ago
Yeah. I maintain that most complaints about Agile are actually just complaints about crummy managers. It's really not that bad (in my experience) when the people you're reporting to have reasonable expectations and treat estimates as estimates.
- seph-reed 7y ago
  For the most part. Nobody who wants to be a manager should, and everyone who could would rather not. The big drawback to good managers is that they stand up for their teams and don't kiss boot the way bad ones might.
sourcaustic 7y ago
Please do not aim to replace Agile, you'll just be creating new problems. Go back to the basics of the Agile Manifesto, understand where your organization fits in the problems that it aims to fix, then overview the different solutions proposed by various methodologies, pick and choose the ones that address the biggest problems that you're facing and adapt them for your own purpose. Start small, as each solution may introduce some processes and distract from the actual mission. Augment only when necessary. You're Agile. You don't need to buy entirely into a single methodology. When people say Agile in software today, they really mean the Jira-flavored Scrum. Some now claim that they've abandoned Scrum and you hear more about Kanban. Sometimes they really are switching, other time they're really just doing Scrum with a Kanban board. But again, they're often falling into the same traps of forcing solutions, rituals, and processes they might not really need into their flow. You want to be Agile? Start small. A simple checklist is a good way to start.
dionian 7y ago
Agile is supposed to be the rejection of methodologies and embracing of people over processes. That's the sheer irony in all this. "Individuals and interactions over processes and tools"
Groxx 7y ago
Agile's pretty much only defined by being "not waterfall" (which is defined as "not agile, and worse") and "if it doesn't work, you did it wrong", so that's sort of a tautological statement.
opportune 7y ago
I currently work at a FAANG and we have a chaotic, low-touch approach that honestly seems to work pretty well. There are only two issues I see with it: it requires a high degree of trust in the engineers from management, and it could be possible to skate by doing the bare minimum without it being noticed (it is noticed usually, it's just not publicly shamed in regular standups). This has the major benefit of allowing developers to manage priorities as things change/pop up/assumptions change, and gives them the latitude to take on complex tasks that aren't easily decomposed or estimated a priori. I think part of the issue is that Agile is meant to be a Process imposed from top down to improve productivity by X%, a way for management and a small army of backlog/task managers to say they are doing Something and having impact (or literally the only thing they actively do). Not only can it easily get in the way of that, it almost always fosters an environment of shaming and lack of trust, because it is too tempting for estimates to be taken too seriously or productivity/performance measured "objectively" by invoking the task-tracking system (in which case you incentivize only taking on very easy, very well understood tasks). It doesn't always devolve to that, but I think at many places if anybody Important up in the management chain starts thinking that way, it will inevitably trickle down. Thus any sufficiently large organization will corrupt Agile. Perhaps some companies need that level of accountability and visibility, even knowing and disliking the drawbacks, but not all of them. I am honestly not convinced that a rigid process is necessary at all. Yes it makes sense to have a system where you keep track of things that need to be done, but if there's a culture of trust, I don't think the system needs to be gamified or fetishized as much as it usually is.

CraigJPerry 7y ago

Yeah people have short memories of the pre-agile role demarcation and wasted handover time between them. It was utterly frustrating to be powerless to improve specification quality and find out you built exactly what was asked but you were asked for the wrong thing. The silos were horrible. Devs were often as bad as BAs, dev’s just were just crapping on the testers instead. Spare a thought for the production ops person at the very end of the chain. Here comes 3 months of developer work in one weekend and no it doesnt work but we’re still going live because the entire tech org is invested in this release. Now you have smaller squads, you can postpone a release without it looking bad on the top person and thus affecting your career prospects. In agile models you have the power to fix crap processes that don’t work. You can call out any BS on the retrospective and make it super visible when things are being swept under the rug.

Spooky23 7y ago
This. I worked on the customer delivery side of a $750M software project that was a steaming pile of shit, with critical defects that were known for a year with zero effort to address. The integrators were paid to deliver a spec, and it took about a year to get change orders created to diverge from the spec. The old school waterfall outsourcing models are truly awful, but you don’t really understand how bad unless you’ve lived it. Stupid agile religious practices are dumb for any startup type org, but are probably better than the alternatives in many big enterprise scenarios, where the goal is chunk up the work so marginally qualified people can do something.

thomascgalvin 7y ago

> To all the people jeering for Agile's demise, please provide a superior alternative. The goal of Agile is to let smart people work incrementally towards a somewhat nebulous goal. The ceremony that's arisen around that tends to be put in place by people who feel the need to manage, but don't know how to help their developers achieve that goal. The alternative, as far as I've seen, is to hire smart, curious people, let them work closely with the end user, and pay them a lot of money. In this situation, the engineers will typically self-organize effectively.

closeparen 7y ago
My org was like that when it was 20 people on one floor doing pretty much their own thing in groups of 2-4. Now it’s 100 people across two countries, expected to collaborate closely with sibling orgs. Management philosophy has shifted to “we will ask a few handpicked experts to write down the best way to do a thing, and then everyone else is a machine for executing that procedure.” If software engineering worked like that, we would have automated it.
parasubvert 7y ago
But, see, Engineers do not self-organize effectively, without some kind of frame of constraints to guide them - customers/users, design, time, quality, tech, architecture, etc. Assembling a talented team that ultimately delivers nothing of value is practically a cliche in this industry.

jimbob45 7y ago

The problem with Agile is that vanilla Agile almost certainly doesn't fulfill your company's requirements. However, if you put some serious thinking into tuning it for what you need, it will be serviceable. Agile would work much better if every implementation stated upfront, "Does not work right out of the box".

ebiester 7y ago

I think you're debating a strawman there. The argument is not that we need to return to other pre-agile SDLC methodologies but rather take what we've learned and go further. From the article: > Now, continuous delivery is what’s expected, and the industry is ready for the next thing. But that next thing shouldn’t be another methodology, according to Mary. > There is no methodology in my field of software engineering that can conceivably last more than five to eight years,” she said. “Everything that is 10 years old is obsolete. Everything that is 20 years old is archaic.” > Furthermore, she said, methodology requires codification. Beginning with the Capability Maturity Model (CMM) in the ‘90s, software development methodology meant developers had to show they had standards and that they followed them, rather than demonstrating that their standards were constantly in flux depending on consumer needs. That’s the definition of quality standards lean manufacturing practitioners in Japan originally espoused, Mary said, and they’re not compatible with methodology. Instead, they’re all about learning. > To that end, Mary is excited about all the ways artificial intelligence will allow software engineers to learn better and faster. Automated testing, continuous deployment and cross-functional collaboration are now table stakes, Mary and Tom agreed. Cutting edge companies will discover the next great approach through an engineering mindset and a willingness to learn. ___ Consider that Mary and Tom Poppendieck were responsible for many of the Lean inclusions of the agile movement, which (largely) came from watching plant manufacturing at Toyota. Similarly, much of the DevOps movement was tied to this as well. If you want to talk about what is next, it is likely taking a first principles look at what we're doing today, questioning best practices again, and saying, "if we were going to make a manifesto in 2020, what would it look like?"

Someone1234 7y ago
You claim I'm "debating a strawman" but then quote the article that literally says they have no alternative in mind (my chief critique) and point towards artificial intelligence to solve the issue somehow. The only "strawman" here seems to be taking my point about pre-Agile methodologies out of context, and using it to dismiss the entire idea that this article is unconstructive/has no actionable solutions.
- ulisesrmzroche 7y ago

deleted 7y ago

[deleted]

username90 7y ago

> To all the people jeering for Agile's demise, please provide a superior alternative. Give individuals ownership over different parts and then let them self organize, that is all you need if you hire competent people. I'll never work at a place which doesn't work like that again.

closeparen 7y ago
To be fair, there are a lot of engineers on the market with a small-but-positive value under a structured process who would be totally useless in an environment like this. I can see why it might be rational to managers.
- drapred7 7y ago
  The problem is that software engineers are paided poorly compared to bankers, executives, and a myriad of other occupations relative to how it used to be 30 years ago. Even doctors aren't paid like they used to be. So way too many smart people go into finance and real estate, which are jobs that really anybody could do, except that our corrupt system makes it worthwhile to pay the smartest people to come up with new ways to scam the public and the government. See: Fed policy, CDOs, sub-prime loans, QE...
  - jevgeni 7y ago
    Sub prime loans are the only thing out of that list where the public was scammed. Everything else you listed are internal banking things.
    - drapred7 7y ago
      The public absolutlely paid the price in the form of bailouts. If those banks had been allowed to fail I would agree with you, but they knew they'd probably be bailed out from the beginning and used CDOs to ensure it. QE is a direct transfer of wealth from dollar holders to investors and banks. No way around that.

downerending 7y ago

There are plenty of examples. The Linux kernel development process comes to mind. I suspect that most knowledgeable developers rolled their eyes when Agile was "invented". It's a mish mash of a lot of things that were already obvious at the time and some weird kool-aid like pair programming. And just one more in a long line of consultant enrichment schemes.

quicklime 7y ago

Agile is the worst form of software development methodology, second only to waterfall. It's still pretty shitty, though. One of the reasons Agile (with a big A) is so successful is that its peddlers have convinced everyone that there are only two options: Agile and waterfall. When you're up against a strawman, it's easy to win. But it's absolutely a false dichotomy. There's a quote in the article that I like: > Find me an actual tech company that talks much about Agile, and I will be astounded. In my experience, people at tech companies (at least the FAANGs) rarely talk about Agile, although they do talk about things like continuous integration/testing/deployment. They do not obsess over methodologies for how to move post-it notes around a whiteboard (Scrum vs Kanban) or agonize over how to word a user story narrative, or other parts of Agile Theatre. People at some non-tech companies, especially those supposedly going through a "digital transformation", seem to have fully bought in to the crap that Certified Agile consultants are selling though. So a superior alternative to both Agile and waterfall is what's in use at a lot of the big tech companies. For example, the engineering culture at Google, which relies on design docs and a very good set of developer tools and infrastructure. It's not perfect, but it's far, far superior to Agile. And before anyone makes the argument that those non-tech companies are not doing "real Agile", but Google is, let's be linguistic descriptivists and accept that Googlers don't call their methodology "Agile", whereas the Scrum consultants at big corporates do.

parasubvert 7y ago
This is ultimately the point I think Mary is trying to make. Agile became and end to itself rather than a way to learn how to build software within minimal waste and delay given imperfect information. Obsessing over it is a cargo cult. That said , plenty of tech companies have inconsistent practices that don’t necessarily lead to great success. To say Google’s methods are “far far superior” to Agile assumes they’re uniform, portable or relevant externally, or that they lead to above average success. That’s debatable given Google’s reputation for abandoned half-built products and an almost comical lack of customer focus.
cachestash 7y ago
Are there any public examples of a google design doc? Would like to study it

drngdds 7y ago

Yeah. I maintain that most complaints about Agile are actually just complaints about crummy managers. It's really not that bad (in my experience) when the people you're reporting to have reasonable expectations and treat estimates as estimates.

seph-reed 7y ago
For the most part. Nobody who wants to be a manager should, and everyone who could would rather not. The big drawback to good managers is that they stand up for their teams and don't kiss boot the way bad ones might.

sourcaustic 7y ago

Please do not aim to replace Agile, you'll just be creating new problems. Go back to the basics of the Agile Manifesto, understand where your organization fits in the problems that it aims to fix, then overview the different solutions proposed by various methodologies, pick and choose the ones that address the biggest problems that you're facing and adapt them for your own purpose. Start small, as each solution may introduce some processes and distract from the actual mission. Augment only when necessary. You're Agile. You don't need to buy entirely into a single methodology. When people say Agile in software today, they really mean the Jira-flavored Scrum. Some now claim that they've abandoned Scrum and you hear more about Kanban. Sometimes they really are switching, other time they're really just doing Scrum with a Kanban board. But again, they're often falling into the same traps of forcing solutions, rituals, and processes they might not really need into their flow. You want to be Agile? Start small. A simple checklist is a good way to start.

dionian 7y ago

Agile is supposed to be the rejection of methodologies and embracing of people over processes. That's the sheer irony in all this. "Individuals and interactions over processes and tools"

Groxx 7y ago

Agile's pretty much only defined by being "not waterfall" (which is defined as "not agile, and worse") and "if it doesn't work, you did it wrong", so that's sort of a tautological statement.

opportune 7y ago

I currently work at a FAANG and we have a chaotic, low-touch approach that honestly seems to work pretty well. There are only two issues I see with it: it requires a high degree of trust in the engineers from management, and it could be possible to skate by doing the bare minimum without it being noticed (it is noticed usually, it's just not publicly shamed in regular standups). This has the major benefit of allowing developers to manage priorities as things change/pop up/assumptions change, and gives them the latitude to take on complex tasks that aren't easily decomposed or estimated a priori. I think part of the issue is that Agile is meant to be a Process imposed from top down to improve productivity by X%, a way for management and a small army of backlog/task managers to say they are doing Something and having impact (or literally the only thing they actively do). Not only can it easily get in the way of that, it almost always fosters an environment of shaming and lack of trust, because it is too tempting for estimates to be taken too seriously or productivity/performance measured "objectively" by invoking the task-tracking system (in which case you incentivize only taking on very easy, very well understood tasks). It doesn't always devolve to that, but I think at many places if anybody Important up in the management chain starts thinking that way, it will inevitably trickle down. Thus any sufficiently large organization will corrupt Agile. Perhaps some companies need that level of accountability and visibility, even knowing and disliking the drawbacks, but not all of them. I am honestly not convinced that a rigid process is necessary at all. Yes it makes sense to have a system where you keep track of things that need to be done, but if there's a culture of trust, I don't think the system needs to be gamified or fetishized as much as it usually is.