8 ms·

Agile had it's moment back then. Is agile still appropriate today? Now we have agile coaches (per team), agile leads (all teams' agile lead), scrum masters (t

Agile had it's moment back then. Is agile still appropriate today? Now we have agile coaches (per team), agile leads (all teams' agile lead), scrum masters (the guy who does the meetings), and project owners (giving requirements), and lead project owners (planning) all trying to get developer time and attention. Right size this, OKR that, attend this attend that. Wasn't agile always about finding what works best for the team and doing it, with consideration of tracking what works well and what doesn't, and refining the process to fix it? Now it seems to be some sort of glorified job role, so even if the team get it right and run well they're patronised into attending non stop meetings from non technical staff trying to justify their jobs and whose own job role even states if the team is running well and self organising, then they need no involvement. All I hear these days is, how can we fix that? And the team answers; the delay is off team, in either third parties, business itself, or we've worked around the bits that we can. The dev team is now being asked to fix other teams' delay causing problems and then effectively silently shamed for not doing it week after week (because it gets raised again and again). This is end game and wasting time if you're team reaches this point, yet the coaches still pound that shaming in like there's something that can be done in team. Of course these meetings aren't meant to do that, but when has human psychology ever been considered (being asked how to fix something a dev has no control over is now a common theme in questions I'm asked)? IMHO agile in its current bastardised form should be taken out the back and shot. When it became a rigid set of rules (oh but "that's not how it's meant to be applied" is the war cry!) which promotes long term job roles preaching it, adds nothing to the teams' ability to adapt, and the team is already meeting most sprint goals and deliverables, the team has hit peak agility already.

TheBigSalad 3y ago
Why do people always say agile doesn't work and then tell some personal baggage story that clearly shows their company is doing it wrong. Is agile really to blame?
- ianis-h 3y ago
  Implementing true agile and keeping it clean of hiearchical management is so hard that it might not be the right choice for most companies... If something is to hard to implement, maybe it is the problem.
- arter4 3y ago
  Agile, as in fast, periodic cycles of gathering requirements, design, implementation and release, is a good idea, especially when this matches your scenario. In my limited experience, Scrum usually comes with a bunch of people who think Scrum principles come from some holy book and act accordingly. You can't estimate how long your tasks will take because you are flooded by interrupts (coming from outside the Agile team or even from within)? Well, shame on you. Sprint review will show a decrease in completed tasks and everyone will wonder why. At the next planning you want to add stories without story points? The horror! You are part of an Agile team and also have to do stuff for another team? Good luck closing your tasks without missing stuff that was assigned to the Sprint. Daily meetings take more than 15 minutes? That's not how things should be! Kanban is a much more reasonable approach, because its focus is on "flow" and not "whatever we decided three weeks ago without taking into account things outside of this team".
  - andrekandre 3y ago
    > Scrum usually comes with a bunch of people who think Scrum principles come from some holy book and act accordingly. well, there is the 'scrum guide' so its not surprise imo [0] > You can't estimate how long your tasks will take because you are flooded by interrupts (coming from outside the Agile team or even from within)? Well, shame on you. i think the fundamental issue of scrum/agile is thinking one can estimate accurately in the small/short-term and do it continuously. if you have deliverables every quarter for example, as long as they are delivered isnt everything else just superfluous? [0] https://www.scrum.org/resources/scrum-guide https://www.scrum.org/resources/scrum-guide
    - arter4 3y ago
      >well, there is the 'scrum guide' so its not surprise imo [0] It sure has a book (in fact, many books), but that doesn't mean it should be treated as the <enter favorite holy book, if any>. Before ITIL4, ITIL v3 (a famous IT service management framework) didn't mention Agile. Changes must be requested (including the actual configuration items you want to change), someone else evaluates them, if the risk is too high you need approval for a specific board, and so on. Companies were following ITIL practices to the T, and some people said "don't you realize this whole thing is ridiculous in most cases?". Cue to Agile. Sure, Agile itself promotes adapting to the environment, people not process,... But then Scrum with its rigid practices is treated as a sort of religion, leading some people to say "don't you realize this whole thing is ridiculous in many cases?". Pretty ironic. > think the fundamental issue of scrum/agile is thinking one can estimate accurately in the small/short-term and do it continuously. I agree. Doing stuff and estimating stuff are clearly different skills. And it is well known that many programmers estimate time by doubling, or even multiplying by 10, the time they expect to require for a task. So you have some people who vastly overestimate, others who underestimate,...
- myaccountonhn 3y ago
  Yeah wherever I've been, it has worked quite well? Where I've worked at the focus has been on short iteration cycles and delivering value to customers, and retros were used as a tool to identify where we can improve. We didn't have any rigorous process, just added and removed processes where we saw it was needed, didn't have any scrum masters either. Sometimes I've been in teams where we removed standups and grooming, when everything was crystal clear. Then later on, we added them again when we had new people and scope was less clear. I think that is in the spirit of agile, and it has worked decently where I've been.
  - rapind 3y ago
    Is it a wonderful process that would work with any team or is it a wonderful team that would make any process work, or maybe (what I think) has the team evolved a process that works based on influences like agile and team dynamics, and is probably still refining it.
- gumballindie 3y ago
  Agile is like communism - everyone does it wrong but if done right it will work. Every single company doing agile sucks at it. All you need is to have a brief chat in the morning, and every couple of weeks go through what needs to be done and try to estimate things. Stuff not done spills over. Agile militarism is about turning software into manufacturing and it clearly doesn't work.
- TheFragenTaken 3y ago
  If you use agile and it works for you, it's because agile is amazing. If you use agile, and it doesn't work for you, it's because you did it wrong. It's the law of attraction, in software development.
- eschneider 3y ago
  Way back around 2000, I worked at a company that used what most people would think of as an agile dev process, administered by the devs, for the devs, and it worked pretty well. It did the thing that a software process needs to do: let everyone know what was important, who was working on what, who needed help, and what needed to be done differently. And it was good. As a _philosophy_, Agile gets those things done. It's fine. As a _process_, as most places that "do Agile", it exists for it's own benefit and not for what it _does_. In almost all cases, it's a people problem more than a process problem, but no process will solve those sorts of people problems.
- rapind 3y ago
  > Is agile really to blame? Well kinda. There’s wisdom in crowds (sometimes). If it doesn’t just naturally gain adoption then that has to count as a negative. Maybe the positives outweigh the negatives, but I think that’s arguable.
- SillyUsername 3y ago
  Making full time job roles around it imho is doing it wrong and this was an industry decision. Agile consultants (or fixed length contract) yes, full time roles, no unless they are going to start removing actual impediments in day to day work rather than remarking on them.
bluetomcat 3y ago
It’s selling snake oil from the beginning. Prototypical snake oil salesmen like Martin Fowler, Kent Beck and Uncle Bob have made careers out of it, and have fostered a generation of people doing it at the company level.
- disgruntledphd2 3y ago
  > Martin Fowler, Kent Beck and Uncle Bob Dunno about the last, but I have gotten a bunch of value out of Beck's TDD book and Fowler's refactoring book.
  - troupo 3y ago
    > a bunch of value out of Beck's TDD book Meanwhile Kent Beck [1]: "I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence" [1] https://stackoverflow.com/a/153565 https://stackoverflow.com/a/153565
    - disgruntledphd2 3y ago
      Yeah totally. I find tests a useful design tool in what I do, but I definitely only test everything when I'm working on a complicated piece of legacy code that I don't understand.
mberning 3y ago
What I find most appalling is that even though all these positions are staffed, there is no limit to what they will ask developers to do. They want the developer to come up with all the ideas, write the stories, do the work, do the coordination, do the release plan, roll to prod, do all the documentation, and on and on and on. This is an absolute nightmare for retention and recruiting. When I went to university to learn about computers and technology I always dreamed of writing user stories and doing other mostly pointless clerical work.
- deleted 3y ago
  [deleted]
g051051 3y ago
> Is agile still appropriate today? It was never appropriate. It was created by consultants to sell consulting services. In that way, it's a huge success. As a practical development methodology, it's always been a disaster.
- dragonelite 3y ago
  At the consultancy company i worked for in the past they would rent out dev teams in sprints time periods xD. As a way to get a foothold at a new client. First design do orientating talks about the full product. Start shaving away features for the MVP and sell the MVP as the first shot. I found it quiet genius move from their sales teams. Because usually customer went well actually i could also use feature x, y and z that didn't made the MVP product.
  - skydhash 3y ago
    It’s a good way to organize expectations between organizations, not so much between team members.
- stcredzero 3y ago
  It was created by consultants to sell consulting services. This is not how it works. "All revolutions are conceived by idealists, implemented by fanatics, and its fruits are stolen by scoundrels" — Thomas Carlyle.
HumblyTossed 3y ago
Agile was always about two things: selling agile consulting and controlling developers. It was never for the developers.
- dreamcompiler 3y ago
  "Agile" (little agile) was certainly designed by developers for developers. Your first sentence became correct after managers and MBAs co-opted the term and turned it into "AGILE" which has almost nothing to do with "agile". Maybe we should call it !AGILE ;-)
  - deleted 3y ago
    [deleted]
- dev_tty01 3y ago
  I always thought it was for managers who have trust issues.
- pyrale 3y ago
  There were some very interesting things in the agile movement before it was snuffed by sales at consultancies.
- pylua 3y ago
  It started out with good intentions -- it is hard to dispute that. However, it has turned into one thing -- a fraud factory. People preaching it can be waterfall without all the proper planning of it.
- redcobra762 3y ago
  I feel confident I can wield Agile against bad management to protect developers with extremely high effectiveness, so in that sense I would disagree.
- elzbardico 3y ago
  This is Scrum, not agile.

TheBigSalad 3y ago

Why do people always say agile doesn't work and then tell some personal baggage story that clearly shows their company is doing it wrong. Is agile really to blame?

ianis-h 3y ago
Implementing true agile and keeping it clean of hiearchical management is so hard that it might not be the right choice for most companies... If something is to hard to implement, maybe it is the problem.
arter4 3y ago
Agile, as in fast, periodic cycles of gathering requirements, design, implementation and release, is a good idea, especially when this matches your scenario. In my limited experience, Scrum usually comes with a bunch of people who think Scrum principles come from some holy book and act accordingly. You can't estimate how long your tasks will take because you are flooded by interrupts (coming from outside the Agile team or even from within)? Well, shame on you. Sprint review will show a decrease in completed tasks and everyone will wonder why. At the next planning you want to add stories without story points? The horror! You are part of an Agile team and also have to do stuff for another team? Good luck closing your tasks without missing stuff that was assigned to the Sprint. Daily meetings take more than 15 minutes? That's not how things should be! Kanban is a much more reasonable approach, because its focus is on "flow" and not "whatever we decided three weeks ago without taking into account things outside of this team".
- andrekandre 3y ago
  > Scrum usually comes with a bunch of people who think Scrum principles come from some holy book and act accordingly. well, there is the 'scrum guide' so its not surprise imo [0] > You can't estimate how long your tasks will take because you are flooded by interrupts (coming from outside the Agile team or even from within)? Well, shame on you. i think the fundamental issue of scrum/agile is thinking one can estimate accurately in the small/short-term and do it continuously. if you have deliverables every quarter for example, as long as they are delivered isnt everything else just superfluous? [0] https://www.scrum.org/resources/scrum-guide https://www.scrum.org/resources/scrum-guide
  - arter4 3y ago
    >well, there is the 'scrum guide' so its not surprise imo [0] It sure has a book (in fact, many books), but that doesn't mean it should be treated as the <enter favorite holy book, if any>. Before ITIL4, ITIL v3 (a famous IT service management framework) didn't mention Agile. Changes must be requested (including the actual configuration items you want to change), someone else evaluates them, if the risk is too high you need approval for a specific board, and so on. Companies were following ITIL practices to the T, and some people said "don't you realize this whole thing is ridiculous in most cases?". Cue to Agile. Sure, Agile itself promotes adapting to the environment, people not process,... But then Scrum with its rigid practices is treated as a sort of religion, leading some people to say "don't you realize this whole thing is ridiculous in many cases?". Pretty ironic. > think the fundamental issue of scrum/agile is thinking one can estimate accurately in the small/short-term and do it continuously. I agree. Doing stuff and estimating stuff are clearly different skills. And it is well known that many programmers estimate time by doubling, or even multiplying by 10, the time they expect to require for a task. So you have some people who vastly overestimate, others who underestimate,...
myaccountonhn 3y ago
Yeah wherever I've been, it has worked quite well? Where I've worked at the focus has been on short iteration cycles and delivering value to customers, and retros were used as a tool to identify where we can improve. We didn't have any rigorous process, just added and removed processes where we saw it was needed, didn't have any scrum masters either. Sometimes I've been in teams where we removed standups and grooming, when everything was crystal clear. Then later on, we added them again when we had new people and scope was less clear. I think that is in the spirit of agile, and it has worked decently where I've been.
- rapind 3y ago
  Is it a wonderful process that would work with any team or is it a wonderful team that would make any process work, or maybe (what I think) has the team evolved a process that works based on influences like agile and team dynamics, and is probably still refining it.
gumballindie 3y ago
Agile is like communism - everyone does it wrong but if done right it will work. Every single company doing agile sucks at it. All you need is to have a brief chat in the morning, and every couple of weeks go through what needs to be done and try to estimate things. Stuff not done spills over. Agile militarism is about turning software into manufacturing and it clearly doesn't work.
TheFragenTaken 3y ago
If you use agile and it works for you, it's because agile is amazing. If you use agile, and it doesn't work for you, it's because you did it wrong. It's the law of attraction, in software development.
eschneider 3y ago
Way back around 2000, I worked at a company that used what most people would think of as an agile dev process, administered by the devs, for the devs, and it worked pretty well. It did the thing that a software process needs to do: let everyone know what was important, who was working on what, who needed help, and what needed to be done differently. And it was good. As a _philosophy_, Agile gets those things done. It's fine. As a _process_, as most places that "do Agile", it exists for it's own benefit and not for what it _does_. In almost all cases, it's a people problem more than a process problem, but no process will solve those sorts of people problems.
rapind 3y ago
> Is agile really to blame? Well kinda. There’s wisdom in crowds (sometimes). If it doesn’t just naturally gain adoption then that has to count as a negative. Maybe the positives outweigh the negatives, but I think that’s arguable.
SillyUsername 3y ago
Making full time job roles around it imho is doing it wrong and this was an industry decision. Agile consultants (or fixed length contract) yes, full time roles, no unless they are going to start removing actual impediments in day to day work rather than remarking on them.

bluetomcat 3y ago

It’s selling snake oil from the beginning. Prototypical snake oil salesmen like Martin Fowler, Kent Beck and Uncle Bob have made careers out of it, and have fostered a generation of people doing it at the company level.

disgruntledphd2 3y ago
> Martin Fowler, Kent Beck and Uncle Bob Dunno about the last, but I have gotten a bunch of value out of Beck's TDD book and Fowler's refactoring book.
- troupo 3y ago
  > a bunch of value out of Beck's TDD book Meanwhile Kent Beck [1]: "I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence" [1] https://stackoverflow.com/a/153565 https://stackoverflow.com/a/153565
  - disgruntledphd2 3y ago
    Yeah totally. I find tests a useful design tool in what I do, but I definitely only test everything when I'm working on a complicated piece of legacy code that I don't understand.

mberning 3y ago

What I find most appalling is that even though all these positions are staffed, there is no limit to what they will ask developers to do. They want the developer to come up with all the ideas, write the stories, do the work, do the coordination, do the release plan, roll to prod, do all the documentation, and on and on and on. This is an absolute nightmare for retention and recruiting. When I went to university to learn about computers and technology I always dreamed of writing user stories and doing other mostly pointless clerical work.

deleted 3y ago
[deleted]

g051051 3y ago

> Is agile still appropriate today? It was never appropriate. It was created by consultants to sell consulting services. In that way, it's a huge success. As a practical development methodology, it's always been a disaster.

dragonelite 3y ago
At the consultancy company i worked for in the past they would rent out dev teams in sprints time periods xD. As a way to get a foothold at a new client. First design do orientating talks about the full product. Start shaving away features for the MVP and sell the MVP as the first shot. I found it quiet genius move from their sales teams. Because usually customer went well actually i could also use feature x, y and z that didn't made the MVP product.
- skydhash 3y ago
  It’s a good way to organize expectations between organizations, not so much between team members.
stcredzero 3y ago
It was created by consultants to sell consulting services. This is not how it works. "All revolutions are conceived by idealists, implemented by fanatics, and its fruits are stolen by scoundrels" — Thomas Carlyle.

HumblyTossed 3y ago

Agile was always about two things: selling agile consulting and controlling developers. It was never for the developers.

dreamcompiler 3y ago
"Agile" (little agile) was certainly designed by developers for developers. Your first sentence became correct after managers and MBAs co-opted the term and turned it into "AGILE" which has almost nothing to do with "agile". Maybe we should call it !AGILE ;-)
- deleted 3y ago
  [deleted]
dev_tty01 3y ago
I always thought it was for managers who have trust issues.
pyrale 3y ago
There were some very interesting things in the agile movement before it was snuffed by sales at consultancies.
pylua 3y ago
It started out with good intentions -- it is hard to dispute that. However, it has turned into one thing -- a fraud factory. People preaching it can be waterfall without all the proper planning of it.
redcobra762 3y ago
I feel confident I can wield Agile against bad management to protect developers with extremely high effectiveness, so in that sense I would disagree.
elzbardico 3y ago
This is Scrum, not agile.