100% agree. It's about agency. Most companies I've worked at haven't strictly followed agile, and definitely haven't allowed devs much say in prioritizing bugs.
My current thought is product companies might have more of a vested interest in quality, but I'm not positive.
Does anyone have any suggestions here? The only thing I've seen is most people move into management, which I'm thinking is likely the only way out from the long hours and homework/almost constant self-study.
Who prioritises your bugs then? For my teams we've almost always done bugfixes outside the sprint effort with developers' own initiative. We follow crash reports and prioritise ourselves with never even telling the PO we fixed something. Product owner is left with feature ownership and doesn't have to know about the day-to-day operations except for the metrics that have business impact.
tl;dr: Management should be a supporting role, but because it's closer to the business (and usually staffed by "Idealists" as described here: https://leanpub.com/developerhegemony), it's given a more powerful position, and does whatever it can to execute as needed by the business. Of course everyone (managers included) also want to keep the power they have and gain more power/money over time.
Developers' time isn't respected because managers have more power and building software is hard, so rather than building partnerships and supporting everyone as needed, then just squeeze harder, treat people lower on the org chart as lower worth as humans, and generally don't shield or abstract things away as much as they should (often not at all). From the article:
> The goal of most software projects is to deliver to deadlines and budget of the plan. The real goal of a software project is to create the right software, but instead decisions focus on the meeting the plan not creating software.
The plan is focused on instead of the software because the plan is the artifact of the more important people, the managers. They're higher up on the ladder because they're more loyal to the company. Even when this isn't the case they're still higher up because it's safer to have them in power rather than devs who can change stuff.
I don't understand how to handle this. In my experience this is what happens:
- You start with a PM/PO/Someone handing out tasks
- You learn the system
- You start doing more work
- They start giving you harder work
- They start asking you to manage the tasks/trace down AC for new tasks
- They start asking you to fix bugs or change AC mid-sprint
- No amount of logic gets through
We can have discussions all day about the three variables, or agile, or maintenance, but at the end of the day if it's just a free for all it's up to how much they like you/how much you can delegate/how much you can say no effectively (and on an ongoing basis) to.
We have agile/jira/all these systems. Why not use them? Why not plan 2 weeks of work... and do 2 weeks of work? Why do they always need to try to squeeze more? It's exhausting and unnecessary and annoying.
Edit: I've worked extremely hard to do everything management asks, and I think this is the problem. I always do. How do you say no? Is it in private? Does the "scope talk" work? Do you do it for every story? Do you end up doing a lot of the planning work and always know what's on your plate as things are added so you aren't overloaded?
I really don't want to be the "make a ticket" guy, but it seems management can handle little less.
Manipulation, passive aggression, telling you that your jobs on the line, … the chapter plays through a few realistic dialogues in the context of a developer providing an estimate the manager doesn’t like and the ways the manager tries to persuade the developer that they’ve guesstimated wrong.
He rounds out the short chapter with an appeal to professionalism.
This is something I've never learned how to defend against. I've always tried to stay professional... but I'm a chronic under-estimator, and also find it difficult to say no, which is a recipe for disaster.
Unfortunately people usually don't work like the team they purport to be (managers shielding their ICs, POs tracking down AC)-- they just see your willingness to work and exploit it for as much as you'll do, rather than trying to make a system that hums forward quickly. They demand speed, but don't want to improve process to get that, they just want you to work more and harder.
Is there a way to build trust or consistently set boundaries or protect your time? Some of my co-workers say "I'm almost out of hours for this week", which I think is one of the only things they understand, but then you really have to close the chat client and not help other devs, lest you miss your "estimates".
We’re all chronic under-estimators by default so I wouldn’t beat yourself up over that one! The old planning fallacy is very well studied and documented. Humans are terrible at estimating by default unfortunately :-( but it’s not that hard to be conscientious about getting more accurate. For me, the secret is to just delegate to a tool that gives me estimates based on my past performance. The cost to me is nothing more than logging an estimate up front and recording what it ended up after the fact. Doing that for a few weeks rapidly steers you to breaking your work into small chunks because it’s too hard to make the recording work otherwise. Turns out small chunks of standalone useful outcomes are optimal anyway for 1001 other reasons.
As for saying no - one way could be to find a role model somewhere close around you, it should be easier to copy what they do if they’re in the same org structure and facing the same struggles. You can’t just assume to flick a switch and behave like them, everyone around you has an expectation of how you behave right now, so you have to be fairly active about signalling to people they should update their perceptions.
My current thought is product companies might have more of a vested interest in quality, but I'm not positive.
Does anyone have any suggestions here? The only thing I've seen is most people move into management, which I'm thinking is likely the only way out from the long hours and homework/almost constant self-study.