4 ms·

The post is fundamentally about all the performance of making stories, assigning points, allocating work and doing standups all the time. None of that is requir

The post is fundamentally about all the performance of making stories, assigning points, allocating work and doing standups all the time. None of that is required to actually create software. If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.

bruce511 2y ago
>> None of that is required to actually create software. Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.) >> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone. Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress, the existence of "intractable problems", work going unfinished creates significant stress up the ladder. In a perfect world the dev team is given a perfect spec, and a reasonable time to do it in, and after being "left alone" they deliver the finished product on time. Given that that world doesn't exist, given that the "money we're spending" may turn out to be completely wasted (because the spec was wrong, or because the problem us much harder than anticipated), the ideal case seems unlikely to happen. I say this not as a defense of crappy management processes, or even less as a defense of crappy managers, but rather in the spirit that understanding the problem goes a long way to solving it. And yes, many places have bad processes and bad middle managers. I don't envy you that. But finding a way to better solve the manager's problem typically improves the relationship.
- Aeolun 2y ago
  > Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.) You are essentially saying “Shit is bad, give up on it ever improving.”
  - bruce511 2y ago
    Not at all. Quite the opposite. To improve the situation you first need to understand it. It seems to me that most devs don't understand the root problem, so they both don't understand, and don't constructively improve the current solution. Improvement is not "leave me alone". Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
    - ozim 2y ago
      I would not say most devs. I think ones that are against scrum are loud about it on the internet. When it comes to have their salary paid out they will not speak up for themselves to push back against shitty management. Like accepting ever increasing velocity until they burn out or accepting bad requirements because business is sayin “it needs to be done now” and working blind only to be scolded they did bad but requirements were bad in the first place.
    - relaxing 2y ago
      > Improvement is finding efficient ways to remove stress from higher-ups. How about gym memberships and mindfulness exercises? Is the rise of Agile tied to the demise of the three-martini lunch?
    - Viliam1234 2y ago
      > Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill. The stress at the bottom is there by design. If you start meeting the deadlines too reliably, the higher-ups will probably conclude that there are needlessly many people in the team, and will try to remove one and see what happens. Repeat until things start cracking apart.
      - bruce511 2y ago
        I guess that depends on your management. I've not experienced that myself, but I'm sure there are places where it happens.
        Viliam1234 2y ago
ako 2y ago
Scrum/Agile is basically an answer for things that went wrong in the past. Building software has a long history of delays, running over time, running out of budgets, etc. As a stakeholder/customer, you need certainties up front: how long is it going to take, what is it going to cost? And if you think this isn't reasonable, just consider, would you hire a contractor to work on your house that can't tell you up front cost and duration? Anybody doing work needs to be able to estimate duration, progress, risk of delays, etc. Other people's work depends on your deadlines. Go/no go of a project depends on cost and duration. Insight and tracking is required. None of this was done any better before agile.
- skydhash 2y ago
  What is required is frank conversation with the stakeholder/customer, because there are so many trade offs decision to make. Devs don’t like to estimate tasks because there’s an exploration phase (which cost time an energy) to have the solution and the cost of time and energy for the implementation. And it’s recursive. Agile was basically saying, let the devs do their thing, but have a conversation every once in a while to discuss new directions to the projects based on new evidence found. And unless the team have already built the same project (with the same people involved), it will always be a bet. No amount of tracking or insight will remedy that.
  - ako 2y ago
    Agile recognizes that software development is a design process with uncertainties and not a repeated tested manufacturing process (product development versus product manufacturing). With the uncertainty of a design process in mind, and the need for estimates, it suggests comparing similar tasks to get an empirical estimate. But since it's just an estimate, you regularly need to validate that the estimate is still considered correct.
Double_a_92 2y ago
Stories = Requirements Engineering Assigning Points = Roughly estimating how long it takes you to implement it Allocating Work = Well... allocating work Standups = Talking with your colleagues about the current work and clearing problems Reviews = Showing your results None of that seems unreasonable. The only thing that kinda sucks are the rigid sprints, because they just cause artificial stress by setting unnecessary deadlines.
- skydhash 2y ago
  They’re not unreasonable in themselves. What sucks is the process around them, because it impedes progress. Why because each tasks varies, and often it morphs while you’re working on it. So whenever a metric is fixed or something interrupts you repeatedly, it just sucks.
  - perrygeo 2y ago
    Or worse than impeding progress, everyone adjusts their expectations to only that which can comfortably fit into a sprint. Big gnarly bugs, meaty technical problems, or innovative solutions - too risky. Better just take a few random tickets off the board and keep plodding along. The direct effect is organizations start systematically ignoring the forest and start obsessing over the trees, simply because trees are easier to measure. And then inevitably wondering aloud "why is velocity AND quality tanking?". Anyone with half a brain can see why - disincentivizing innovation destroys innovation.

bruce511 2y ago

>> None of that is required to actually create software. Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.) >> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone. Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress, the existence of "intractable problems", work going unfinished creates significant stress up the ladder. In a perfect world the dev team is given a perfect spec, and a reasonable time to do it in, and after being "left alone" they deliver the finished product on time. Given that that world doesn't exist, given that the "money we're spending" may turn out to be completely wasted (because the spec was wrong, or because the problem us much harder than anticipated), the ideal case seems unlikely to happen. I say this not as a defense of crappy management processes, or even less as a defense of crappy managers, but rather in the spirit that understanding the problem goes a long way to solving it. And yes, many places have bad processes and bad middle managers. I don't envy you that. But finding a way to better solve the manager's problem typically improves the relationship.

Aeolun 2y ago
> Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.) You are essentially saying “Shit is bad, give up on it ever improving.”
- bruce511 2y ago
  Not at all. Quite the opposite. To improve the situation you first need to understand it. It seems to me that most devs don't understand the root problem, so they both don't understand, and don't constructively improve the current solution. Improvement is not "leave me alone". Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
  - ozim 2y ago
    I would not say most devs. I think ones that are against scrum are loud about it on the internet. When it comes to have their salary paid out they will not speak up for themselves to push back against shitty management. Like accepting ever increasing velocity until they burn out or accepting bad requirements because business is sayin “it needs to be done now” and working blind only to be scolded they did bad but requirements were bad in the first place.
  - relaxing 2y ago
    > Improvement is finding efficient ways to remove stress from higher-ups. How about gym memberships and mindfulness exercises? Is the rise of Agile tied to the demise of the three-martini lunch?
  - Viliam1234 2y ago
    > Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill. The stress at the bottom is there by design. If you start meeting the deadlines too reliably, the higher-ups will probably conclude that there are needlessly many people in the team, and will try to remove one and see what happens. Repeat until things start cracking apart.
    - bruce511 2y ago
      I guess that depends on your management. I've not experienced that myself, but I'm sure there are places where it happens.
      - Viliam1234 2y ago

ako 2y ago

Scrum/Agile is basically an answer for things that went wrong in the past. Building software has a long history of delays, running over time, running out of budgets, etc. As a stakeholder/customer, you need certainties up front: how long is it going to take, what is it going to cost? And if you think this isn't reasonable, just consider, would you hire a contractor to work on your house that can't tell you up front cost and duration? Anybody doing work needs to be able to estimate duration, progress, risk of delays, etc. Other people's work depends on your deadlines. Go/no go of a project depends on cost and duration. Insight and tracking is required. None of this was done any better before agile.

skydhash 2y ago
What is required is frank conversation with the stakeholder/customer, because there are so many trade offs decision to make. Devs don’t like to estimate tasks because there’s an exploration phase (which cost time an energy) to have the solution and the cost of time and energy for the implementation. And it’s recursive. Agile was basically saying, let the devs do their thing, but have a conversation every once in a while to discuss new directions to the projects based on new evidence found. And unless the team have already built the same project (with the same people involved), it will always be a bet. No amount of tracking or insight will remedy that.
- ako 2y ago
  Agile recognizes that software development is a design process with uncertainties and not a repeated tested manufacturing process (product development versus product manufacturing). With the uncertainty of a design process in mind, and the need for estimates, it suggests comparing similar tasks to get an empirical estimate. But since it's just an estimate, you regularly need to validate that the estimate is still considered correct.

Double_a_92 2y ago

Stories = Requirements Engineering Assigning Points = Roughly estimating how long it takes you to implement it Allocating Work = Well... allocating work Standups = Talking with your colleagues about the current work and clearing problems Reviews = Showing your results None of that seems unreasonable. The only thing that kinda sucks are the rigid sprints, because they just cause artificial stress by setting unnecessary deadlines.

skydhash 2y ago
They’re not unreasonable in themselves. What sucks is the process around them, because it impedes progress. Why because each tasks varies, and often it morphs while you’re working on it. So whenever a metric is fixed or something interrupts you repeatedly, it just sucks.
- perrygeo 2y ago
  Or worse than impeding progress, everyone adjusts their expectations to only that which can comfortably fit into a sprint. Big gnarly bugs, meaty technical problems, or innovative solutions - too risky. Better just take a few random tickets off the board and keep plodding along. The direct effect is organizations start systematically ignoring the forest and start obsessing over the trees, simply because trees are easier to measure. And then inevitably wondering aloud "why is velocity AND quality tanking?". Anyone with half a brain can see why - disincentivizing innovation destroys innovation.