6 ms·

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 cle

by 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.
    - timr 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. Dysfunctional upper management: maybe. Customers don't pay money today for products delivered on an indefinite, unspecified future timeline: definitely. More software engineers should have to be involved with customer conversations to internalize this...or just, I dunno...do a construction project or something. See how much you like it when you've paid money for something bespoke, and the people doing the work refuse to set schedules or tell you what you're getting. Suddenly you'll be a dysfunctional manager, too. Agile works best when you have a consultancy situation, and the customer can be directly involved in the construction of the product while it is being built. This rarely applies. But even then, customers tend to make ridiculous demands like "advance notice before you change the software from under us so that we can re-train our large team of users", and as soon as you do that, you've got a calendar, a deliverable and a deadline. Probably some Gantt charts in there too, because only trivial projects have a single deliverable. Then you say "OK, let's actually be agile, break down the project timeline using iterative deliverables and clear development cycles"...now you have sprints. I'm not defending "Scrum" -- just saying that deliverables and deadlines are part of life.
      - pydry 4y ago
        >Customers don't pay money today for products delivered on an indefinite, unspecified future timeline They frequently do for features though. I happily waited a year for my bank to implement virtual credit cards. As a corporate user of software I have waited similar lengths of time for features I really wanted. This reality usually doesnt stop some layer(s) of management from waterfalling the shit out of everything simply because they can't conceive of an alternative. >See how much you like it when you've paid money for something bespoke, and the people doing the work refuse to set schedules or tell you what you're getting. Yeah, this is why I try to avoid that type of software development at all costs. I got burned on it when I was young, thinking that nothing was more natural than treating software like a construction project. Practically speaking, when you do ask for something bespoke - whether it's a skyscraper, crossrail or a bathroom remodeling or software, you've gotta be prepared for delays and budget overruns. Software is much the same, and waterfalling the shit out of this type of thing may be unavoidable, but so is the inevitable shitty result. There are entire sub industries that can't seem to produce anything good (e.g. healthcare software) and I think this model of operation is largely why. This is why it's better for execs to treat bespoke deliveries as something radioactive and try to minimize them as much as possible even if that means saying the scariest six words in an exec's vocab "sorry, we can't take your money".
- fatnoah 4y ago
  > This is what I often describe as doing agile vs being agile. I just started a new role leading a 30 person Engineering team at a company doing Scrum. My very first questions to everyone was why are we doing this? Answers ranged from some expectations like regular/predictable delivery of product to "because that's how software is done." From there, it's figure out a process that makes sense and actually achieves objectives. Scrum provides a nice framework, but everyone needs to be bought into the goals of it first. (My next actions were to get rid of most of the useless workflow rules in Jira and build that accountability at the team level...it works amazingly well that way) I agree that it's much more doable at a small company. Once companies get big enough, the need to centrally plan and coordinate seem to create an irresistible urge to apply identical processes to all teams, compare velocities, and all sorts of other bad habits.
jwilber 4y ago
The fact that this confusing distinction even exists is testament to how unnecessarily complicated agile is.

by andor 4y ago

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.
  - timr 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. Dysfunctional upper management: maybe. Customers don't pay money today for products delivered on an indefinite, unspecified future timeline: definitely. More software engineers should have to be involved with customer conversations to internalize this...or just, I dunno...do a construction project or something. See how much you like it when you've paid money for something bespoke, and the people doing the work refuse to set schedules or tell you what you're getting. Suddenly you'll be a dysfunctional manager, too. Agile works best when you have a consultancy situation, and the customer can be directly involved in the construction of the product while it is being built. This rarely applies. But even then, customers tend to make ridiculous demands like "advance notice before you change the software from under us so that we can re-train our large team of users", and as soon as you do that, you've got a calendar, a deliverable and a deadline. Probably some Gantt charts in there too, because only trivial projects have a single deliverable. Then you say "OK, let's actually be agile, break down the project timeline using iterative deliverables and clear development cycles"...now you have sprints. I'm not defending "Scrum" -- just saying that deliverables and deadlines are part of life.
    - pydry 4y ago
      >Customers don't pay money today for products delivered on an indefinite, unspecified future timeline They frequently do for features though. I happily waited a year for my bank to implement virtual credit cards. As a corporate user of software I have waited similar lengths of time for features I really wanted. This reality usually doesnt stop some layer(s) of management from waterfalling the shit out of everything simply because they can't conceive of an alternative. >See how much you like it when you've paid money for something bespoke, and the people doing the work refuse to set schedules or tell you what you're getting. Yeah, this is why I try to avoid that type of software development at all costs. I got burned on it when I was young, thinking that nothing was more natural than treating software like a construction project. Practically speaking, when you do ask for something bespoke - whether it's a skyscraper, crossrail or a bathroom remodeling or software, you've gotta be prepared for delays and budget overruns. Software is much the same, and waterfalling the shit out of this type of thing may be unavoidable, but so is the inevitable shitty result. There are entire sub industries that can't seem to produce anything good (e.g. healthcare software) and I think this model of operation is largely why. This is why it's better for execs to treat bespoke deliveries as something radioactive and try to minimize them as much as possible even if that means saying the scariest six words in an exec's vocab "sorry, we can't take your money".
fatnoah 4y ago
> This is what I often describe as doing agile vs being agile. I just started a new role leading a 30 person Engineering team at a company doing Scrum. My very first questions to everyone was why are we doing this? Answers ranged from some expectations like regular/predictable delivery of product to "because that's how software is done." From there, it's figure out a process that makes sense and actually achieves objectives. Scrum provides a nice framework, but everyone needs to be bought into the goals of it first. (My next actions were to get rid of most of the useless workflow rules in Jira and build that accountability at the team level...it works amazingly well that way) I agree that it's much more doable at a small company. Once companies get big enough, the need to centrally plan and coordinate seem to create an irresistible urge to apply identical processes to all teams, compare velocities, and all sorts of other bad habits.

jwilber 4y ago

The fact that this confusing distinction even exists is testament to how unnecessarily complicated agile is.