>> 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.
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.
> 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.
In one of my previous jobs, I worked on a software project that frequently got the following two kinds of comments from the managers:
"Wow, this is the only project in our company that works reliably. There are no major bugs ever; and all the small bugs are fixed within a day or two. I wish other projects worked like that."
"You have five developers working on one project? Isn't that too much?"
Seemingly none of them was able to connect the dots and conclude that maaaaaybe these two things are somehow related. That maybe the fact that we are not understaffed somehow allows us to write automated tests, refactor when necessary, etc., so we can keep adding new features as required and the project keeps working ok.
So they started removing the developers one by one, moving them to other projects. The last guy left on the project felt overloaded and quit.
The project still worked okay for a few years without new updates, and was gradually replaced by several new projects (because it had a lot of functionality). But the new projects only had two developers each on average, so at least the managers didn't feel like they were wasting money.
Hmm, while I get what you are saying, I feel like dealing with that is _literally_ their job.
It'd be nice if we could remove stress from leadership, but I don't think that's a thing that should be my responsibility as a dev. Of course it'd actually improve the life of everyone if did, so it feel like something you should do regardless.
But then I'm taking the managers job in addition to being the developer, and then what's the point of the manager in the first place?
> Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
Good luck with that because higher-ups have even-higher-ups until you reach the top. The bigger the pay packet, the more inflated the lifestyle and the associated stress of missing on the ever ballooning target. It is self-inflicted and never-ending; sacrifices of the lowly soldier will never quench that thirst.
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.