4 ms·

You don't believe in agile, but yet whole your comment is basically what agile is supposed to be. So I'm going to say you have seen corporation bastardization

You don't believe in agile, but yet whole your comment is basically what agile is supposed to be. So I'm going to say you have seen corporation bastardization of agile and rejected it, which is a good thing.

tansan 3y ago
I'm inclined to believe proper agile is a myth. I have never seen it done correctly, and it's always spoken about ideally. All forms of agile I have seen or heard about always breaks down in real businesses environments.
- electrondood 3y ago
  I've seen agile done extremely well two companies ago, fairly well at my last company, and decently at my current company. I've never seen it done poorly. It's the standard for a reason.
  - seadan83 3y ago
    I'm not sure you have brought that reason. A sample size of 3 where only one did better than "fairly well" would not be my reason to advocate for "Agile" to be the "industry standard." Across my sample size of about 7, half were maybe better than terrible, but only two were good enough where I would say it helped more than it hurt. The tech industry I think would do well to more rigorously study "Agile" and do some A/B testing. Unfortunately this problem space feels like trying to A/B test forms of government. The downsides are generally known after the fact, are context specific, and there are few good ways to run a control
- gv83 3y ago
  same for the legendary "maintainable/evolvable/perfectly encapsulated code". yes, until the team is very skilled, everyone is disciplined and there are tight processes around learning the architecture. 3 bad hires later because "investors want growth!!1" and you're done :D
  - mpweiher 3y ago
    > are tight processes around learning the architecture. Yep. Because we currently don't have any way of clearly, concisely and obviously expressing the architecture in the code. https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p... What if we could? https://objective.st/ https://objective.st/
    - gv83 3y ago
      cool links, thanks for sharing. I also share your feelings, but reality (or burnout) is starting to take its toll on me and I see too much uninterested people working as SWEs nowadays. I mean, tooling is probably part of the problem, but quality is going downhill real fast, with people with 2/3 years on the job not understanding simple things like HexArch or basic patterns (not advocating for anything, just mentioning something that should be common knowledge in 2023). I'm starting to think that if we want to maintain this "race to the bottom" pace, we need a more industrialized/blue collar approach and be more less about the person and more about the tool. Most jobs in my area are web crud controlling a transaction script. there is no problem to solve.
      - Silhouette 3y ago
        I mean, tooling is probably part of the problem, but quality is going downhill real fast, with people with 2/3 years on the job not understanding simple things I agree but I also wonder why we would expect them to. Many coming into the industry have had little formal education in CS or SE. Employers providing substantial training is mostly a thing of the past because retention and professional development for employees has mostly been deprecated in favour of the rapid job-hopping culture. And for a while now it's been such an employee's market that developers haven't needed to invest their own time and money into professional development in order to progress their careers. So even for relatively senior devs it's easily possible that they could have little academic education, little professional training provided by any of their employers, and little incentive to spend their own time studying. Their understanding might come from nothing but a few years of experience working on only 2 or 3 different products and - if they're lucky - some ideas they've been exposed to through more experienced mentors, team leads and code reviewers. I personally believe our industry would be infinitely better if we could get back to the idea that professional development is important and employers should both look for people who've been learning and then support their people's ongoing learning themselves. Maybe we can even do that now that the gold rush is over and job-hopping every five minutes for a pay and title bump is no longer the most reliable way to climb the career ladder.
- 6D794163636F756 3y ago
  Agile as a noun is a myth. Agile as an adjective is a journey. When I've seen a company being agile and responding to change it's not because they are using some system they learned at a seminar, it's because they trust their engineers to do the technical work, trust their product people to have solid relationships with customers, and empower both groups both in their individual roles and when communicating with each other. All of this is to say that I agree with you. 'Agile Methodologies' are a crutch for companies that cannot tolerate agility
- mpweiher 3y ago
  > I'm inclined to believe proper agile is a myth. It's not. > I have never seen it done correctly I have. And it wasn't hard. In fact, it seemed entirely effortless at the time. https://news.ycombinator.com/item?id=36727366 https://news.ycombinator.com/item?id=36727366 The Agile Industrial Complex is a horror show, but that doesn't mean it's not possible to do agile well. There absolutely is a way of doing agile well, I've been involved in a number of teams that did. And it worked extremely well. In fact, we did agile way before the agile manifesto came out, and before I was aware of there being a name for the things we were doing. We were just doing them because they make sense, they make us go fast and they let us have fun while doing it. Which is basically what the XP people said when they started writing things down. They never claimed to have invented a brand new way of creating software. No, they were observing that certain teams were very productive, and looked at what those teams were doing. If there was a pattern. Spoiler: there was. Anyway, I also introduced agile "practices" in a large company. Well, in a small team in a large company. We didn't do a single one of the practices the Agile Industrial Complex proposes and often mandates. The much more important team next to us did. They did all the AIC practices. We did the technical. And interacted closely. Did TDD, worked on trunk, paired when necessary, did stuff alone when not. Did the simplest thing that could possible work. ("Where's your database?" "We'll put it in when we need it". <later> "Oh we're done. I guess we didn't need the database ¯\_(ツ)_/¯" ). The more important team next to us that was doing Scrum with the standups and whathaveyounot failed. We delivered. Hmm. And if you can point to the practices being promoted by the AIC as being in direct and obvious conflict with, for example, what's written the Agile Manifesto, and can in fact point to ways of doing it right that are in harmony with the AM and in conflict with the AIC, then it ain't a No True Scotsman fallacy. It's a simple case of the AIC doing it wrong.
  - SkyPuncher 3y ago
    I too have seen great agile. However, it required the team to be in control of its own destiny. Namely, we didn’t have deadlines and the goals we reported against were impact. That meant we could run no-weekly sprints while safely fitting delivery into the goal reporting timetable. In most companies, it seems management is incapable of measuring progress other than “will X be done before Y date”.
- palata 3y ago
  I like the original Agile principles: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html. Now it has been abused to create a whole business with bullshit "agile coaches" who sell agile "bibles" and teach cargo cult.
  - 6D794163636F756 3y ago
    It's funny to me just how counter to the agile manifesto tenets agile coaches tend to be
    - aleph_minus_one 3y ago
      > It's funny to me just how counter to the agile manifesto tenets agile coaches tend to be Well, this strongly evidences that these agile coaches are fraudsters who don't know the elementary basics of their specialist field ... ;-)
    - jack_riminton 3y ago
      I’m adding that to my list of corporate tech paradoxes It joins: - Innovation departments being built the least innovative departments you’ll ever meet - HR departments being the worst at dealing with people
    - fatnoah 3y ago
      I always enjoyed the irony of rigid adherence to agile processes. My philosophy has always been to ask "what are our goals" and then figure out how to make our process be in service of those goals. Scrum does provide some useful frameworks for estimation and planning and continual reflection & improvement.
siliconc0w 3y ago
The key differences from the most common implementation of agile are bigger delivered chunks, multiple sets of smaller self driven teams, no highly prescriptive ways of working, and avoiding constant 'sprinting' with at least two weeks dedicated to bug fixing, maintenance, and retros/self improvement between 'sprints'.

tansan 3y ago

I'm inclined to believe proper agile is a myth. I have never seen it done correctly, and it's always spoken about ideally. All forms of agile I have seen or heard about always breaks down in real businesses environments.

electrondood 3y ago
I've seen agile done extremely well two companies ago, fairly well at my last company, and decently at my current company. I've never seen it done poorly. It's the standard for a reason.
- seadan83 3y ago
  I'm not sure you have brought that reason. A sample size of 3 where only one did better than "fairly well" would not be my reason to advocate for "Agile" to be the "industry standard." Across my sample size of about 7, half were maybe better than terrible, but only two were good enough where I would say it helped more than it hurt. The tech industry I think would do well to more rigorously study "Agile" and do some A/B testing. Unfortunately this problem space feels like trying to A/B test forms of government. The downsides are generally known after the fact, are context specific, and there are few good ways to run a control
gv83 3y ago
same for the legendary "maintainable/evolvable/perfectly encapsulated code". yes, until the team is very skilled, everyone is disciplined and there are tight processes around learning the architecture. 3 bad hires later because "investors want growth!!1" and you're done :D
- mpweiher 3y ago
  > are tight processes around learning the architecture. Yep. Because we currently don't have any way of clearly, concisely and obviously expressing the architecture in the code. https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p... What if we could? https://objective.st/ https://objective.st/
  - gv83 3y ago
    cool links, thanks for sharing. I also share your feelings, but reality (or burnout) is starting to take its toll on me and I see too much uninterested people working as SWEs nowadays. I mean, tooling is probably part of the problem, but quality is going downhill real fast, with people with 2/3 years on the job not understanding simple things like HexArch or basic patterns (not advocating for anything, just mentioning something that should be common knowledge in 2023). I'm starting to think that if we want to maintain this "race to the bottom" pace, we need a more industrialized/blue collar approach and be more less about the person and more about the tool. Most jobs in my area are web crud controlling a transaction script. there is no problem to solve.
    - Silhouette 3y ago
      I mean, tooling is probably part of the problem, but quality is going downhill real fast, with people with 2/3 years on the job not understanding simple things I agree but I also wonder why we would expect them to. Many coming into the industry have had little formal education in CS or SE. Employers providing substantial training is mostly a thing of the past because retention and professional development for employees has mostly been deprecated in favour of the rapid job-hopping culture. And for a while now it's been such an employee's market that developers haven't needed to invest their own time and money into professional development in order to progress their careers. So even for relatively senior devs it's easily possible that they could have little academic education, little professional training provided by any of their employers, and little incentive to spend their own time studying. Their understanding might come from nothing but a few years of experience working on only 2 or 3 different products and - if they're lucky - some ideas they've been exposed to through more experienced mentors, team leads and code reviewers. I personally believe our industry would be infinitely better if we could get back to the idea that professional development is important and employers should both look for people who've been learning and then support their people's ongoing learning themselves. Maybe we can even do that now that the gold rush is over and job-hopping every five minutes for a pay and title bump is no longer the most reliable way to climb the career ladder.
6D794163636F756 3y ago
Agile as a noun is a myth. Agile as an adjective is a journey. When I've seen a company being agile and responding to change it's not because they are using some system they learned at a seminar, it's because they trust their engineers to do the technical work, trust their product people to have solid relationships with customers, and empower both groups both in their individual roles and when communicating with each other. All of this is to say that I agree with you. 'Agile Methodologies' are a crutch for companies that cannot tolerate agility
mpweiher 3y ago
> I'm inclined to believe proper agile is a myth. It's not. > I have never seen it done correctly I have. And it wasn't hard. In fact, it seemed entirely effortless at the time. https://news.ycombinator.com/item?id=36727366 https://news.ycombinator.com/item?id=36727366 The Agile Industrial Complex is a horror show, but that doesn't mean it's not possible to do agile well. There absolutely is a way of doing agile well, I've been involved in a number of teams that did. And it worked extremely well. In fact, we did agile way before the agile manifesto came out, and before I was aware of there being a name for the things we were doing. We were just doing them because they make sense, they make us go fast and they let us have fun while doing it. Which is basically what the XP people said when they started writing things down. They never claimed to have invented a brand new way of creating software. No, they were observing that certain teams were very productive, and looked at what those teams were doing. If there was a pattern. Spoiler: there was. Anyway, I also introduced agile "practices" in a large company. Well, in a small team in a large company. We didn't do a single one of the practices the Agile Industrial Complex proposes and often mandates. The much more important team next to us did. They did all the AIC practices. We did the technical. And interacted closely. Did TDD, worked on trunk, paired when necessary, did stuff alone when not. Did the simplest thing that could possible work. ("Where's your database?" "We'll put it in when we need it". <later> "Oh we're done. I guess we didn't need the database ¯\_(ツ)_/¯" ). The more important team next to us that was doing Scrum with the standups and whathaveyounot failed. We delivered. Hmm. And if you can point to the practices being promoted by the AIC as being in direct and obvious conflict with, for example, what's written the Agile Manifesto, and can in fact point to ways of doing it right that are in harmony with the AM and in conflict with the AIC, then it ain't a No True Scotsman fallacy. It's a simple case of the AIC doing it wrong.
- SkyPuncher 3y ago
  I too have seen great agile. However, it required the team to be in control of its own destiny. Namely, we didn’t have deadlines and the goals we reported against were impact. That meant we could run no-weekly sprints while safely fitting delivery into the goal reporting timetable. In most companies, it seems management is incapable of measuring progress other than “will X be done before Y date”.
palata 3y ago
I like the original Agile principles: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html. Now it has been abused to create a whole business with bullshit "agile coaches" who sell agile "bibles" and teach cargo cult.
- 6D794163636F756 3y ago
  It's funny to me just how counter to the agile manifesto tenets agile coaches tend to be
  - aleph_minus_one 3y ago
    > It's funny to me just how counter to the agile manifesto tenets agile coaches tend to be Well, this strongly evidences that these agile coaches are fraudsters who don't know the elementary basics of their specialist field ... ;-)
  - jack_riminton 3y ago
    I’m adding that to my list of corporate tech paradoxes It joins: - Innovation departments being built the least innovative departments you’ll ever meet - HR departments being the worst at dealing with people
  - fatnoah 3y ago
    I always enjoyed the irony of rigid adherence to agile processes. My philosophy has always been to ask "what are our goals" and then figure out how to make our process be in service of those goals. Scrum does provide some useful frameworks for estimation and planning and continual reflection & improvement.

siliconc0w 3y ago

The key differences from the most common implementation of agile are bigger delivered chunks, multiple sets of smaller self driven teams, no highly prescriptive ways of working, and avoiding constant 'sprinting' with at least two weeks dedicated to bug fixing, maintenance, and retros/self improvement between 'sprints'.