4 ms·

> incompetent managers or tech leads. This is one of the things that ruined my last gig. I have 3 decades of experience. Managers and tech leads are unlikely

> incompetent managers or tech leads. This is one of the things that ruined my last gig. I have 3 decades of experience. Managers and tech leads are unlikely to have a fraction of that, so let me do my job. > Agile is a time stuck and time waster This was the other thing. We fell into the hands of Agile cultists (really no other way to portray them) and wound up getting buried in process, useless meetings, etc. > I'm probably not with your product or service's target demographic Same! I've never worked on anything that I would have an interest in using personally. I don't have anything against the products, and they served their target audience well, but that's not me. > Stop drowning us in processes. See above. The so called "Agile" stuff they brought in basically crushed our development staff. It was used as a bludgeon.

junon 5y ago
Describing agile as a cult is spot-on. Regardless of its intent, I've never seen nor heard of it being implemented in a way that promotes iterative R&D on a development team. Agile is more suited toward software maintenance IMO, not building new software. Rarely are senior engineers looking for the former.
- dblohm7 5y ago
  > Agile is more suited toward software maintenance IMO, not building new software. One other learning that I've taken from big-A Agile is that it is only suited for teams where everybody is a "generalist" within the team. By "generalist" I mean that any developer on the team can work on any issue within that team's purview. If your team is responsible for any component where only a subset of the team has the specialization to work on it, team-wide sprint planning actually hinders progress.
  - g051051 5y ago
    In the "agile" environments I've seen, devs are expected to be the ultimate generalist. We have to do planning, documentation, testing, qa, ops, and still write the code.
    - chris11 5y ago
      Personally I don't see that as a bad thing. I care more about ownership, I'd much rather be responsible for a project instead of just tickets.
      - g051051 5y ago
        That philosophy preaches that any person can fulfill any task equally well, which isn't true. QA and ops are distinct skill sets, very different from what's needed to be a good developer. If I'm doing all that other stuff, when does the code get written? By who?
necovek 5y ago
> This was the other thing. We fell into the hands of Agile cultists (really no other way to portray them) and wound up getting buried in process, useless meetings, etc. That's curious since "agile", as the name suggests, should be very lean on the process. There is nothing agile about a lot of process details! Sure, people get too invested and miss the boat, but in general it's not too hard to remind them what "agile" is about (hey, it's in the name!), and in my experience, they usually relent.
- g051051 5y ago
  You've been lucky. I've seen first hand, heard from my peers in other companies, and read throughout the industry, that Agile is probably the most poorly named thing out there. Just because they put it in the name, doesn't make it a lean, lightweight, easy to use process. So in my experience, "Agile" is not in the least bit agile.

junon 5y ago

Describing agile as a cult is spot-on. Regardless of its intent, I've never seen nor heard of it being implemented in a way that promotes iterative R&D on a development team. Agile is more suited toward software maintenance IMO, not building new software. Rarely are senior engineers looking for the former.

dblohm7 5y ago
> Agile is more suited toward software maintenance IMO, not building new software. One other learning that I've taken from big-A Agile is that it is only suited for teams where everybody is a "generalist" within the team. By "generalist" I mean that any developer on the team can work on any issue within that team's purview. If your team is responsible for any component where only a subset of the team has the specialization to work on it, team-wide sprint planning actually hinders progress.
- g051051 5y ago
  In the "agile" environments I've seen, devs are expected to be the ultimate generalist. We have to do planning, documentation, testing, qa, ops, and still write the code.
  - chris11 5y ago
    Personally I don't see that as a bad thing. I care more about ownership, I'd much rather be responsible for a project instead of just tickets.
    - g051051 5y ago
      That philosophy preaches that any person can fulfill any task equally well, which isn't true. QA and ops are distinct skill sets, very different from what's needed to be a good developer. If I'm doing all that other stuff, when does the code get written? By who?

necovek 5y ago

> This was the other thing. We fell into the hands of Agile cultists (really no other way to portray them) and wound up getting buried in process, useless meetings, etc. That's curious since "agile", as the name suggests, should be very lean on the process. There is nothing agile about a lot of process details! Sure, people get too invested and miss the boat, but in general it's not too hard to remind them what "agile" is about (hey, it's in the name!), and in my experience, they usually relent.

g051051 5y ago
You've been lucky. I've seen first hand, heard from my peers in other companies, and read throughout the industry, that Agile is probably the most poorly named thing out there. Just because they put it in the name, doesn't make it a lean, lightweight, easy to use process. So in my experience, "Agile" is not in the least bit agile.