5 ms·

I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement. Agile, Sc

I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement. Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance. I’m not sure what planet the OP is from, but this will never change. If you have a small team with a simple codebase, kanban is probably sufficient. In larger teams or complex solutions, the reporting just needs to happen.

015a 2y ago
I don't feel anything you've said is logical. The deliverable is, in the best case, what communicates progress and success. Short of that, tickets can do that, which is also not what the article is complaining about. The article also specifically attacks Agile/Scrum; Kanban is different and quite explicitly sidesteps a lot of the stress problems the article outlines.
BurningFrog 2y ago
> Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In the agile teams I've been on it's been to produce success. Getting good and useful software fast. Of course, just like there are hundreds of wildly different Christian sub-religions, there are now any number of "agile" interpretations. In the end belief systems can be pushed to do most anything you want.
gridspy 2y ago
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.
- 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.
nine_zeros 2y ago
Progress is important. That's why you plan for large milestones. There is no need for micro-ticket-story level updates, tracking, and overhead.
- ChicagoDave 2y ago
  Tell that to a large PM organization. They love tracking minutia.
SoftTalker 2y ago
Method 1? Wow talk about a blast from the past. Did you work for or with Andersen Consulting at some point?
mtrovo 2y ago
Yeah, I totally agree in theory, it doesn't really matter what methodology you use, at the end of the day dev management is just a means to an end. The real issue comes from middle management folks who conjure up buzzwords whenever they need to justify whatever they think the team should do. Don't know how to structure tasks but want to look like you're in control to the boss's boss? Just throw up a Kanban board with tiny tickets and a burndown chart trending down. Sprinkle in some Agile keywords in the management reports and call it a day. And let's not forget that by 'sprint' they often mean moving unfinished tickets from the last iteration to the current one, plus tacking on surprise urgent tasks that were not planned before because the product owner never shows up to share their vision and priorities.

015a 2y ago

I don't feel anything you've said is logical. The deliverable is, in the best case, what communicates progress and success. Short of that, tickets can do that, which is also not what the article is complaining about. The article also specifically attacks Agile/Scrum; Kanban is different and quite explicitly sidesteps a lot of the stress problems the article outlines.

BurningFrog 2y ago

> Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In the agile teams I've been on it's been to produce success. Getting good and useful software fast. Of course, just like there are hundreds of wildly different Christian sub-religions, there are now any number of "agile" interpretations. In the end belief systems can be pushed to do most anything you want.

gridspy 2y ago

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.
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.

nine_zeros 2y ago

Progress is important. That's why you plan for large milestones. There is no need for micro-ticket-story level updates, tracking, and overhead.

ChicagoDave 2y ago
Tell that to a large PM organization. They love tracking minutia.

SoftTalker 2y ago

Method 1? Wow talk about a blast from the past. Did you work for or with Andersen Consulting at some point?

mtrovo 2y ago

Yeah, I totally agree in theory, it doesn't really matter what methodology you use, at the end of the day dev management is just a means to an end. The real issue comes from middle management folks who conjure up buzzwords whenever they need to justify whatever they think the team should do. Don't know how to structure tasks but want to look like you're in control to the boss's boss? Just throw up a Kanban board with tiny tickets and a burndown chart trending down. Sprinkle in some Agile keywords in the management reports and call it a day. And let's not forget that by 'sprint' they often mean moving unfinished tickets from the last iteration to the current one, plus tacking on surprise urgent tasks that were not planned before because the product owner never shows up to share their vision and priorities.