5 ms·

Agile and scrum is not a solution to anything. Participating in agile voodoo has no measurable impact. In fact, I think in many cases agile makes you immediatel

Agile and scrum is not a solution to anything. Participating in agile voodoo has no measurable impact. In fact, I think in many cases agile makes you immediately slower. Developers than realize they have to pad everything with bullshit estimates they pulled out of thin air so they're not getting punished for missing work or bad guesses. I just assume if the company is doing agile they have lost faith in their developers when it comes to organizing or producing value.

sanedigital 4y ago
You have been blessed to work on self-organizing and self-managing teams. When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features. Scrum isn't perfect, but its an "industry-standard" practice that we can use to get quick buy-in from client stakeholders, and then use to apply even the most basic level of process to these teams. As an engineer at Google or a freelance developer it never made much sense to me. But as a manager of remote, distributed, international teams? It makes a lot of sense.
- trentnix 4y ago
  > When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features. Sounds familiar. Back in my consultant days, we would encounter companies that wanted to be “agile”. They’d insist they were waterfall and it wasn’t working. Truth is, if they’d actually been doing waterfall they’d have been performing far better. Instead, they were just chaos, reacting to one fire after another with no plan to get out. Additionally, many teams were simply staffed with poor managers and poor engineers. There’s no consulting-fu or process-fu that was going to overcome that. You can’t win horse races with pack mules, my dad (a basketball coach) used to say.
  - ethbr0 4y ago
    >> But as a manager of remote, distributed, international teams? > You can’t win horse races with pack mules, my dad (a basketball coach) used to say. You can boil it down to saying that Scrum is either (a) micromanagement or (b) an admission that your developers and their managers suck. Fix the problem, instead of slapping a bureaucratic band-aid on that's going to attrit any remaining quality developers.
    - trentnix 4y ago
      > Fix the problem, instead of slapping a bureaucratic band-aid on that's going to attrit any remaining quality developers. I don’t think this is right. It’s like a sports team: your system, your philosophy, your approach matters. Like in basketball, you might utilize the flex motion offense or you might use the Tex Winters’ triangle. Good teams can succeed with both, but depending on your personnel and what you’re up against, you might find one strategy works better than the others.
      - ethbr0 4y ago
        Good teams can succeed with both, but it's billed as a panacea for bad teams.
        eric-hu 4y ago
        Do you realize you’re attacking a straw man? Has anyone in this thread said that Agile is a panacea? I think we can agree it is not, nor is anything a panacea.
        ethbr0 4y ago
        The response was re: sanedigital's remark that it was a good way to minimally fix (implied) bad teams. And I've seen it used exactly that way in practice at bad companies. It's not a strawman if it's lived experience and professed corporate IT strategy at a lot of non-tech companies.
  - hef19898 4y ago
    As my current, very pragmatic scrum master told me: we try to cover the failure to plan woth agile and wonder why nothing gets done (or something along that line). Well, now our chaos is agile...
andor 4y ago
What you are describing makes sense within Scrum, because scrum asks for commitment. It has nothing to do with "agile" though. In fact, the agile manifesto clearly says "individuals and interactions over processes and tools". An organization that follows processes that don't make sense to its employees is not agile, despite what they claim.
- shsteimer_1 4y ago
  This is what I often describe as doing agile vs being agile. Most large companies are constitutionally incapable of being agile, for a while host if reasons I don’t feel like iterating here, but I’m sure you can fill in the blanks. But they are more than capable of putting in rules and processes that allow them to do agile. The problem is that doing agile without being agile does far more harm than good.
  - BoorishBears 4y ago
    > Most large companies are constitutionally incapable of being agile, for a while host if reasons I don’t feel like iterating here, but I’m sure you can fill in the blanks. There's a long list but only one really needs to be mentioned: Payroll costs $XX,XXX,XXX and is due every 2 weeks. I've sat through "agile training" and it's the most plain grift I've ever seen. Selling developers on a deadline-less utopia, but walking it back just enough to not make management types paying for the whole thing balk. Switching which side of the scale their finger is on based on who seems the most engaged at a given moment. But at the end of the day, it's always predicated on the idea that developers can always provide backpressure against clients. Well you're free to do that, and clients are free to not pay, and unless your developers will work for client IOUs that's the end of the game. Agile mentality is great. The idea of rapidly iterating and rapidly producing feedback is great. But "Agile methodology" has evolved into a productivity ponzi scheme meant to add a place for consultants and trainers to insert themselves for $$$
    - pydry 4y ago
      If the execs and managers can't get out of the mentality of planning X deliverables for Q3, Y deliverables for Q4 and Z feature by December 10th to satisfy a $10m customer then it becomes hollow and fake no matter how genuine and well meaning the consultants are. I dont really blame them. They've gotta eat, and occasionally they probably do get a client who is genuinely willing to enact a real transformation. Dysfunctional upper management is the real problem.
YZF 4y ago
Agile (EDIT: The Agile Manifesto specifically) is meant to solve a very specific problem. It's meant to solve the problem of describing software via a contract, taking a long time to build the software described in that contract, and then the software not being useful despite an enormous amount of effort/resources poured into it. If you are working in an optimized team, that understands the business, understands the customer, and efficiently and incrementally delivers business value building the right kind of software then these practices won't help you and as you point out may actually hurt you. The above though is some minuscule fraction of software teams in the real world (and some may not know it). The problem with Agile practices and Scrum is that despite their theoretical ability to improve the way we build software, and the good intentions of the original ideas, inefficient teams and companies will always find a way to adopt the practices they think are good (and therefore keep them inefficient) while rejecting the practices that may help them. That's the conundrum of pretty much any process (and funny enough "people over process" in a twisted way means people that have no clue will subvert any process that tried to push for doing things better in most orgranizations).
- LAC-Tech 4y ago
  Agile (EDIT: The Agile Manifesto specifically) is meant to solve a very specific problem. It's meant to solve the problem of describing software via a contract, taking a long time to build the software described in that contract, and then the software not being useful despite an enormous amount of effort/resources poured into it. Really? The impression I get it's that it's geared towards internal teams who can "iterate" until the cows come home. Contractors work on a fixed time-frame and/or cost, agile doesn't jive well with that unless you're just labour augmentation.
  - deleted 4y ago
    [deleted]
- tkiolp4 4y ago
  The Agile Manifesto it’s a nice read but you cannot put it in practice. It’s like the Bible: everyone has its own interpretation. Not sure why we still talk about it.
lr4444lr 4y ago
This comment is totally opinion and no evidence. But also oh so cathartic to read. Rant on, sir!
jrockway 4y ago
I'm not a big fan of agile, especially the more formal it gets. The problem that engineers have with it is that it does make things slower. Moving fast is absolutely not the goal of agile. The goal of agile is to make the development cycle predictable, so that all the moving parts of the bureaucracy can be at the right place at the right time. All of this stuff around estimation is really intended to make sure that unknowns are minimized, so that the list of work in JIRA or whatever is somewhat reflective of the actual work required. That lets the rest of the organization react to whatever the engineers are doing in a somewhat intelligent way. You can look at the progress bar on an epic, look at the date, and reasonably answer that question from a customer in the form "XXX bug is ruining my life, I hate you guys" "that will be in our Q2 release" "oh wow, I actually love you guys". That sort of interaction is what is paying your salary, so spending time to make it easy is what keeps the sales and support teams alive. I don't have any evidence, but I think it's an undeniable fact that coordination effort is very expensive. We are all familiar with how fast our 1 person weekend projects go; you spend 12 hours on Saturday evenings on something, and it feels like it progresses faster than what your team of 30 people is doing at work 5 days a week. My opinion is that projects scale exponentially with complexity. A 1 person project takes 1 person. A 2 person project takes 2 people. But then, a 3 person project takes 4 people. A 4 person project takes 8 people. A 5 person project takes 16 people. By the time you are at big company sizes, you might have 30,000 people vaguely working on the same thing; by my rule above, that's a project that's 15x more complex than a 1 person project. That's why it feels like "my friends and I could make Twitter over the weekend, why do they need 30,000 employees!?" You're thinking that results scale linearly over the number of people, but it really scales logarithmically over the number of people. So now you're 1/30,000th of a 15 person project, and you don't feel as productive. You are 0.003% of the equation. If you work 10x as hard, you're 0.03% of the equation. It just doesn't fit with your mental model of productivity that you extrapolate from personal projects (where it's 100%, or 110% if you had a really good cup of coffee). That's why it feels bad, but it's also why management is not super concerned that you are spending 20 hours a week in meetings. Oh no, now you're only 0.0015% of the equation. The final question is, why does society put up with this? The answer is, there is money in these projects that are just a bit more complicated than a software engineer's personal project. You will be remembered more for the 0.003% contribution you had to the moon landing than you will for making the absolute best ever music file organizer. It sucks, but that's how the Universe works. You can embrace it, or you can fight it. But if you want to stave off the heat death of the Universe, you might need a team and a plan and maybe a few meetings to share the plan with your team ;)
i_like_apis 4y ago
Very much disagree. Well-run, minimal Agile is an amazing way to organize, see, plan, and go fast. There’s a lot of gripers who don’t like feeling managed and attack it with all sorts of false criticism though. And of course, poorly-run Agile can be pretty annoying. The key is to keep things minimal and fast: quick stand-ups, and as few meetings as needed. Who is leading it definitely matters too. Ideally it is a lead developer rather than a “product” or “project” person, IMO.

sanedigital 4y ago

You have been blessed to work on self-organizing and self-managing teams. When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features. Scrum isn't perfect, but its an "industry-standard" practice that we can use to get quick buy-in from client stakeholders, and then use to apply even the most basic level of process to these teams. As an engineer at Google or a freelance developer it never made much sense to me. But as a manager of remote, distributed, international teams? It makes a lot of sense.

trentnix 4y ago
> When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features. Sounds familiar. Back in my consultant days, we would encounter companies that wanted to be “agile”. They’d insist they were waterfall and it wasn’t working. Truth is, if they’d actually been doing waterfall they’d have been performing far better. Instead, they were just chaos, reacting to one fire after another with no plan to get out. Additionally, many teams were simply staffed with poor managers and poor engineers. There’s no consulting-fu or process-fu that was going to overcome that. You can’t win horse races with pack mules, my dad (a basketball coach) used to say.
- ethbr0 4y ago
  >> But as a manager of remote, distributed, international teams? > You can’t win horse races with pack mules, my dad (a basketball coach) used to say. You can boil it down to saying that Scrum is either (a) micromanagement or (b) an admission that your developers and their managers suck. Fix the problem, instead of slapping a bureaucratic band-aid on that's going to attrit any remaining quality developers.
  - trentnix 4y ago
    > Fix the problem, instead of slapping a bureaucratic band-aid on that's going to attrit any remaining quality developers. I don’t think this is right. It’s like a sports team: your system, your philosophy, your approach matters. Like in basketball, you might utilize the flex motion offense or you might use the Tex Winters’ triangle. Good teams can succeed with both, but depending on your personnel and what you’re up against, you might find one strategy works better than the others.
    - ethbr0 4y ago
      Good teams can succeed with both, but it's billed as a panacea for bad teams.
      - eric-hu 4y ago
        Do you realize you’re attacking a straw man? Has anyone in this thread said that Agile is a panacea? I think we can agree it is not, nor is anything a panacea.
        ethbr0 4y ago
        The response was re: sanedigital's remark that it was a good way to minimally fix (implied) bad teams. And I've seen it used exactly that way in practice at bad companies. It's not a strawman if it's lived experience and professed corporate IT strategy at a lot of non-tech companies.
- hef19898 4y ago
  As my current, very pragmatic scrum master told me: we try to cover the failure to plan woth agile and wonder why nothing gets done (or something along that line). Well, now our chaos is agile...

andor 4y ago

What you are describing makes sense within Scrum, because scrum asks for commitment. It has nothing to do with "agile" though. In fact, the agile manifesto clearly says "individuals and interactions over processes and tools". An organization that follows processes that don't make sense to its employees is not agile, despite what they claim.

shsteimer_1 4y ago
This is what I often describe as doing agile vs being agile. Most large companies are constitutionally incapable of being agile, for a while host if reasons I don’t feel like iterating here, but I’m sure you can fill in the blanks. But they are more than capable of putting in rules and processes that allow them to do agile. The problem is that doing agile without being agile does far more harm than good.
- BoorishBears 4y ago
  > Most large companies are constitutionally incapable of being agile, for a while host if reasons I don’t feel like iterating here, but I’m sure you can fill in the blanks. There's a long list but only one really needs to be mentioned: Payroll costs $XX,XXX,XXX and is due every 2 weeks. I've sat through "agile training" and it's the most plain grift I've ever seen. Selling developers on a deadline-less utopia, but walking it back just enough to not make management types paying for the whole thing balk. Switching which side of the scale their finger is on based on who seems the most engaged at a given moment. But at the end of the day, it's always predicated on the idea that developers can always provide backpressure against clients. Well you're free to do that, and clients are free to not pay, and unless your developers will work for client IOUs that's the end of the game. Agile mentality is great. The idea of rapidly iterating and rapidly producing feedback is great. But "Agile methodology" has evolved into a productivity ponzi scheme meant to add a place for consultants and trainers to insert themselves for $$$
  - pydry 4y ago
    If the execs and managers can't get out of the mentality of planning X deliverables for Q3, Y deliverables for Q4 and Z feature by December 10th to satisfy a $10m customer then it becomes hollow and fake no matter how genuine and well meaning the consultants are. I dont really blame them. They've gotta eat, and occasionally they probably do get a client who is genuinely willing to enact a real transformation. Dysfunctional upper management is the real problem.

YZF 4y ago

Agile (EDIT: The Agile Manifesto specifically) is meant to solve a very specific problem. It's meant to solve the problem of describing software via a contract, taking a long time to build the software described in that contract, and then the software not being useful despite an enormous amount of effort/resources poured into it. If you are working in an optimized team, that understands the business, understands the customer, and efficiently and incrementally delivers business value building the right kind of software then these practices won't help you and as you point out may actually hurt you. The above though is some minuscule fraction of software teams in the real world (and some may not know it). The problem with Agile practices and Scrum is that despite their theoretical ability to improve the way we build software, and the good intentions of the original ideas, inefficient teams and companies will always find a way to adopt the practices they think are good (and therefore keep them inefficient) while rejecting the practices that may help them. That's the conundrum of pretty much any process (and funny enough "people over process" in a twisted way means people that have no clue will subvert any process that tried to push for doing things better in most orgranizations).

LAC-Tech 4y ago
Agile (EDIT: The Agile Manifesto specifically) is meant to solve a very specific problem. It's meant to solve the problem of describing software via a contract, taking a long time to build the software described in that contract, and then the software not being useful despite an enormous amount of effort/resources poured into it. Really? The impression I get it's that it's geared towards internal teams who can "iterate" until the cows come home. Contractors work on a fixed time-frame and/or cost, agile doesn't jive well with that unless you're just labour augmentation.
- deleted 4y ago
  [deleted]
tkiolp4 4y ago
The Agile Manifesto it’s a nice read but you cannot put it in practice. It’s like the Bible: everyone has its own interpretation. Not sure why we still talk about it.

lr4444lr 4y ago

This comment is totally opinion and no evidence. But also oh so cathartic to read. Rant on, sir!

jrockway 4y ago

I'm not a big fan of agile, especially the more formal it gets. The problem that engineers have with it is that it does make things slower. Moving fast is absolutely not the goal of agile. The goal of agile is to make the development cycle predictable, so that all the moving parts of the bureaucracy can be at the right place at the right time. All of this stuff around estimation is really intended to make sure that unknowns are minimized, so that the list of work in JIRA or whatever is somewhat reflective of the actual work required. That lets the rest of the organization react to whatever the engineers are doing in a somewhat intelligent way. You can look at the progress bar on an epic, look at the date, and reasonably answer that question from a customer in the form "XXX bug is ruining my life, I hate you guys" "that will be in our Q2 release" "oh wow, I actually love you guys". That sort of interaction is what is paying your salary, so spending time to make it easy is what keeps the sales and support teams alive. I don't have any evidence, but I think it's an undeniable fact that coordination effort is very expensive. We are all familiar with how fast our 1 person weekend projects go; you spend 12 hours on Saturday evenings on something, and it feels like it progresses faster than what your team of 30 people is doing at work 5 days a week. My opinion is that projects scale exponentially with complexity. A 1 person project takes 1 person. A 2 person project takes 2 people. But then, a 3 person project takes 4 people. A 4 person project takes 8 people. A 5 person project takes 16 people. By the time you are at big company sizes, you might have 30,000 people vaguely working on the same thing; by my rule above, that's a project that's 15x more complex than a 1 person project. That's why it feels like "my friends and I could make Twitter over the weekend, why do they need 30,000 employees!?" You're thinking that results scale linearly over the number of people, but it really scales logarithmically over the number of people. So now you're 1/30,000th of a 15 person project, and you don't feel as productive. You are 0.003% of the equation. If you work 10x as hard, you're 0.03% of the equation. It just doesn't fit with your mental model of productivity that you extrapolate from personal projects (where it's 100%, or 110% if you had a really good cup of coffee). That's why it feels bad, but it's also why management is not super concerned that you are spending 20 hours a week in meetings. Oh no, now you're only 0.0015% of the equation. The final question is, why does society put up with this? The answer is, there is money in these projects that are just a bit more complicated than a software engineer's personal project. You will be remembered more for the 0.003% contribution you had to the moon landing than you will for making the absolute best ever music file organizer. It sucks, but that's how the Universe works. You can embrace it, or you can fight it. But if you want to stave off the heat death of the Universe, you might need a team and a plan and maybe a few meetings to share the plan with your team ;)

i_like_apis 4y ago

Very much disagree. Well-run, minimal Agile is an amazing way to organize, see, plan, and go fast. There’s a lot of gripers who don’t like feeling managed and attack it with all sorts of false criticism though. And of course, poorly-run Agile can be pretty annoying. The key is to keep things minimal and fast: quick stand-ups, and as few meetings as needed. Who is leading it definitely matters too. Ideally it is a lead developer rather than a “product” or “project” person, IMO.