|
toiletbrush posted:that feeling when at the end of interviewing a candidate you are told that you're not interviewing to find a replacement for the other dev, who's leaving, you're interviewing to replace yourself, because you're replacing the lead, because his contract isn't being renewed, while he's there. And the other dev is still leaving. Your reasons for wanting to leave are valid and your friends will understand. It was rude of your boss to bait-and-switch you like that. Your new hire may feel the same way.
|
#
?
Apr 11, 2018 23:02
|
|
|
|
| # ? May 22, 2024 09:34 |
|
|
toiletbrush posted:also that feeling when you were going to start looking for another job anyway but now your hand has been forced and you've no idea what to do You do what you were going to do anyway and look for a new job. In thread title news I just interviewed at a place that unironically called their process "a combination of Agile, Waterfall, and Scrum".
|
|
#
?
Apr 11, 2018 23:47
|
|
|
toiletbrush posted:that feeling when at the end of interviewing a candidate you are told that you're not interviewing to find a replacement for the other dev, who's leaving, you're interviewing to replace yourself, because you're replacing the lead, because his contract isn't being renewed, while he's there. And the other dev is still leaving. Get a new job. The bait-and-switch of "hey your superior is leaving/fired and we need you to take over all their responsibilities but you don't get the proper raise/promotion to go with it!" is a really common way that employers abuse their employees, and it's an extremely clear indicator that they don't care about you.
|
|
#
?
Apr 12, 2018 02:33
|
|
|
toiletbrush posted:that feeling when you know if you stay you'll never have a life outside of work ever again, and you're already lead on other things so you won't get a change in title or raise, but if you leave, the project will die - no-one will lose their job, but people you like will be affected - and you'll feel like a pussy/rear end in a top hat. If you leaving immediately is a problem and your employer has you under an at-will contract then that's on them, not you. Employees do not owe loyalty to a company that doesn't show any loyalty to their employees.
|
|
#
?
Apr 12, 2018 06:01
|
|
|
It’s amazing how much you won’t ever give a poo poo again as soon as you walk out those doors for the last time.
|
|
#
?
Apr 12, 2018 06:12
|
|
|
Iverron posted:It’s amazing how much you won’t ever give a poo poo again as soon as you walk out those doors for the last time. Xerophyte posted:If you leaving immediately is a problem and your employer has you under an at-will contract then that's on them, not you. Employees do not owe loyalty to a company that doesn't show any loyalty to their employees. God I can't loving emphasize either of these enough. To add my own: if the management is refusing to invest in the project appropriately (whether that be an investment of people, money, tools, infrastructure, marketing, direction, or any other reason), and that project fails, that is on the management, not because you didn't put in extra loving elbow grease. Co-worker who you actually want to keep on your good side will put the blame where it belongs. I'll add one more thing. Managers who've managed tech people absolutely know that we don't like to leave work unfinished, that we like solving problems and making poo poo better. Many of them will shamelessly take advantage of that inclination in us to cause situations just like the one you're now facing. They're rolling the dice that you won't leave even though they're loving you. That's one reason why "ownership" is a "core value" of so many companies... if you feel you have ownership of a thing, you'll be less likely to take an action that will damage it. Also there's the fact that people in general, if they aren't sociopaths, don't like to cause pain or trouble for others who they have even a casual relationship with (like co-workers). Even if management types don't know what that feels like, they can recognize and take advantage of it in the people they manage. Che Delilas fucked around with this message at 07:14 on Apr 12, 2018 |
|
#
?
Apr 12, 2018 07:05
|
|
|
Ownership also means sovereignty and not being limited to other, distant, possibly dumb people's decisions in that particular segment. Dealing with people whom your project is dependent on, but who have no interest in your project's success, is the worst.
|
|
#
?
Apr 12, 2018 10:00
|
|
|
You have no ownership of code you produce for a corporation unless they seriously screwed up their employment agreements.
|
|
#
?
Apr 12, 2018 14:01
|
|
|
leper khan posted:You have no ownership of code you produce for a corporation unless they seriously screwed up their employment agreements. Nobody means ownership in the sense that you own the copyright here dude. https://www.scrum.org/resources/what-is-a-product-owner
|
|
#
?
Apr 12, 2018 14:09
|
|
|
"Ownership" in this context has always meant, in my experience, "it's your responsibility to see <project> or <feature> you're working on through to completion." I don't manage the QA department but if code I wrote has been languishing in QA, it's expected that I'm the one who should be talking with the QA people, getting updates and making sure they have everything they need to do their job. Also it can mean "If you touched it last, you get to answer questions about it or update it forevermore" but ymmv.pigdog posted:Ownership also means sovereignty and not being limited to other, distant, possibly dumb people's decisions in that particular segment. Dealing with people whom your project is dependent on, but who have no interest in your project's success, is the worst. True, it can mean that as well and it's real nice when I can make actual decisions about the thing I'm building or fixing. In the bad places, under bad managers, it doesn't mean this at all, it's just a psychological tool to get you to work harder for less.
|
|
#
?
Apr 12, 2018 15:52
|
|
|
Xerophyte posted:If you leaving immediately is a problem and your employer has you under an at-will contract then that's on them, not you. Employees do not owe loyalty to a company that doesn't show any loyalty to their employees. It's a shame, because our team has always been made up of really strong people - and the business were on board with us. It's just a few old-school middle-management lifers with territory to protect, loving it up for everyone. Anyways, thanks for all your input, gonna head to the interviewing thread!
|
|
#
?
Apr 12, 2018 22:18
|
|
|
Thinkin' about subjecting myself (and the rest of the department) to another round of Scrum training so my boss can hear from somebody else how bad it is to give one developer five projects at once. She just asked me to respond in some email thread I've been ignoring because I thought the outgoing developer was handling it and when I told her I hadn't looked at it because I was focused on a task for a different project, she said to just dig deep and keep at it. Great, thanks for listening.
|
|
#
?
Apr 13, 2018 22:05
|
|
|
If you have five projects to yourself, your manager has a deeper misunderstanding of how to work effectively than a bit of scrum training will solve.
|
|
#
?
Apr 13, 2018 22:45
|
|
|
Oh, I know; I just need to put a crack in the shell. Or convince her to hire an actual Product Owner. Or like four more devs. Or I need to go crawl in a hole and drink heavily.
|
|
#
?
Apr 13, 2018 23:10
|
|
|
Get yourself a nice visible pinboard or magnetic thing. Put a vertical queue of things you have been told to work on. Makes it nice and visible that only one thing can be the top priority, and moving one thing up moves everything else down.
|
|
#
?
Apr 13, 2018 23:28
|
|
|
CPColin posted:Oh, I know; I just need to put a crack in the shell. Or convince her to hire an actual Product Owner. Or like four more devs. Or I need to go crawl in a hole and drink heavily. I find myself constantly annoyed by POs but then think about all the stuff I'd have to do if we didn't have any.
|
|
#
?
Apr 14, 2018 14:51
|
|
|
I mostly like the idea that they're the last word in priorities. If even some of the other management respects the fact that this one person is who they go to when they have the "why isn't MY pet project being worked on???" complaint, that takes pressure off me (pressure I can resist just fine, but still pressure I don't need).
|
|
#
?
Apr 14, 2018 20:10
|
|
|
Mega Comrade posted:I find myself constantly annoyed by POs but then think about all the stuff I'd have to do if we didn't have any. This is the best quote about agile I seen in a while.
|
|
#
?
Apr 15, 2018 06:42
|
|
|
I wasted basically all of yesterday trying to diagnose why all of my integration tests that hit a certain API on Test were failing. The problem was compounded by my random inability to RDP to the server listening for API requests. We figured out that problem and all I could find was the same error messages the outgoing developer had already shrugged about. Finally, I resorted to restarting the server process, at which point the API requests started succeeding. I explained why I'd accomplished nothing yesterday to my boss, who wondered if this had something to do with the hardware failure that [SysAdmin] had to diagnose and fix Monday morning. I speculated that hardware failure was also why a server on Production had randomly failed, then wondered if any other servers we have may have blown up. (I bit back the part where I wondered why [SysAdmin] didn't have a disaster recovery checklist of servers to verify. Or why we apparently have no heartbeat monitoring in place, etc.) My boss said something like, "It's just so tough when [SysAdmin] is the only one who can fix this stuff." I waited for her to come to the realization, "We should expand our team so we're not 100% dependent on single people!" but the realization never came. I wonder if she'll come to that realization when I inevitably get sick of being 100% depended on, with no other developers in the building, and decide to leave. Probably not!
|
|
#
?
Apr 18, 2018 15:40
|
|
|
My team is the absolute best at sprint planning.
|
|
#
?
Apr 18, 2018 16:23
|
|
|
Because dev work is 100% measurable and predictable up front
|
|
#
?
Apr 18, 2018 17:38
|
|
|
*moves giant PBI into sprint on day 2* Guys, our numbers aren't looking good, step it up.
|
|
#
?
Apr 18, 2018 17:49
|
|
|
Watch it drop on the last day because your team didn't update their tasks.
|
|
#
?
Apr 18, 2018 17:50
|
|
|
Pedestrian Xing posted:*moves giant PBI into sprint on day 2* Guys, our numbers aren't looking good, step it up. oh hey neat you work with me
|
|
#
?
Apr 18, 2018 17:51
|
|
|
Your burndownchart has a heartbeat, means the process is alive but on life support. The last team I worked at also had this, sprint after sprint. Not sure how it is now, I guess the same.
|
|
#
?
Apr 18, 2018 18:08
|
|
|
Keetron posted:Your burndownchart has a heartbeat, means the process is alive but on life support. The last team I worked at also had this, sprint after sprint. Not sure how it is now, I guess the same. Yeah I just laugh because this is the third sprint now where we have more points than we started with halfway through. We're having a recurring QA problem where bugs are slipping through constantly and we had 2-3 hotfix releases a day for a while. It's not minor poo poo like missing a weird corner case, I'm talking not testing the core functionality of a new feature at all; e.g. one story was about fixing image orientation for uploads, and it broke the ability to even upload an image.....so wtf did QA even test (or that dev who said it was ready for testing...)? It's about to plummet this afternoon now that all my PRs that have been scaring people are finally merged in. I changed our docker deployment process and no one else understands it so they've been afraid to touch it.
|
|
#
?
Apr 18, 2018 18:39
|
|
|
BaronVonVaderham posted:We're having a recurring QA problem where bugs are slipping through constantly and we had 2-3 hotfix releases a day for a while. It's not minor poo poo like missing a weird corner case, I'm talking not testing the core functionality of a new feature at all; e.g. one story was about fixing image orientation for uploads, and it broke the ability to even upload an image.....so wtf did QA even test (or that dev who said it was ready for testing...) Does your team have a codified dev process? What are the steps taken from the point the developer receives the work to the point where the work is shipped into production? Do you have any reviews or automated tests along that path? What sort of accountability exists? For a dev to have even been able to get crap like that into prod is a sign that your team has far more fundamental process issues than planning a sprint.
|
|
#
?
Apr 18, 2018 19:25
|
|
|
BaronVonVaderham posted:It's not minor poo poo like missing a weird corner case, I'm talking not testing the core functionality of a new feature at all; e.g. one story was about fixing image orientation for uploads, and it broke the ability to even upload an image.....so wtf did QA even test (or that dev who said it was ready for testing...)? Time to file a PBI to add "Upload an image" to your integration tests, imo.
|
|
#
?
Apr 18, 2018 19:36
|
|
|
BurntCornMuffin posted:Does your team have a codified dev process? What are the steps taken from the point the developer receives the work to the point where the work is shipped into production? Do you have any reviews or automated tests along that path? What sort of accountability exists? You already know the answer.
|
|
#
?
Apr 18, 2018 20:25
|
|
|
Volmarias posted:You already know the answer. You're right. I'm trying to manipulate the poster into thinking about the things he should say during the sprint retro every time a dumb bug surfaces in prod, citing how much time was lost during each incident as a result, not to mention product reputation and effects on users. I've been in similar situations, and I've found that effective at forcing the team to discuss the problem and bringing them around to discussing governance.
|
|
#
?
Apr 18, 2018 21:20
|
|
|
BurntCornMuffin posted:You're right. I'm trying to manipulate the poster into thinking about the things he should say during the sprint retro every time a dumb bug surfaces in prod, citing how much time was lost during each incident as a result, not to mention product reputation and effects on users. We just had a retro last Thursday and most of this came up. I kind of kicked off a massive effort to document all of our processes in Confluence when I started a few months ago because I kept asking everyone for docs on everything and nothing existed. I wrote the document on how to spin up your local test servers myself after flailing around to get it to work in my first week (and I also rewrote poo poo to use docker-compose to make it easier). I just have a sneaking suspicion QA was kind of slacking and trusting that the devs were submitting code that worked and not actually testing EVERY story that passed through their queue. I think they're spinning up checklists for testing this week to have more accountability and clarity, since devs finally spoke up and called them on it.
|
|
#
?
Apr 18, 2018 21:46
|
|
|
BaronVonVaderham posted:My team is the absolute best at sprint planning. I'm troubled by the fact this chart even does have Saturdays and Sundays on it.
|
|
#
?
Apr 18, 2018 22:34
|
|
|
They’re gray for a reason?
|
|
#
?
Apr 18, 2018 22:58
|
|
|
Yeah, and those days do exist, and sometimes people do work on the weekend for their own reasons, and there's a checkbox to turn them off. It's the least horrible thing about that graph.
|
|
#
?
Apr 18, 2018 23:01
|
|
|
I'm the dedicated QA team whose process is guessing that there are no bugs in something and then not even having to fill out a checklist.
|
|
#
?
Apr 18, 2018 23:06
|
|
|
My boss just emailed us asking if we could have made use of our deactivated Experts Exchange account while trying to fix whatever problem happened over the weekend. I want to reply with either, "I had an employee account for ten years and never got a useful answer," or "Account sharing is against the TOS."
|
|
#
?
Apr 18, 2018 23:36
|
|
|
I don’t think I can remember the last time I had a sprint that didn’t have a ton of work added throughout it. It’s pretty rare that I see one that ends with fewer points than it started with too. I wonder if we have any problems with our processes. e: that graph above looks like >90% of the burndown charts I’ve seen in the last 6 months from 5 different teams. It didn’t strike me as strange or wrong at all. The Leck fucked around with this message at 00:18 on Apr 19, 2018 |
|
#
?
Apr 19, 2018 00:15
|
|
|
IME having points added to sprints occasionally is pretty normal but if it's regular or lots of points it points to a problem in the process. Whether it's requirements not being well defined, requirements changing, or stories not being sized properly due to the aforementioned problems or unexpected code changes that need to be done to properly complete the story. Or last minute hotfix situations where things aren't pulled from the sprint when bugs and things get added. Edit: mobile typos withoutclass fucked around with this message at 01:35 on Apr 19, 2018 |
|
#
?
Apr 19, 2018 01:24
|
|
|
withoutclass posted:IME having points added to sprints occasionally is pretty normal but if it's regular or lotd of points it points to a problem in the process. Whether it's requirements not being well defined, requirements changing, or stories not being sized properly due to the aforementioned problems or unexpected code changes that need to be done to properly complete the story. Or last minute hotfix situations where things aren't pulled from the spring when bugs and things get added. Yeah I think all of that's normal. I have NEVER had a sprint where we finished everything. We're just not even coming close, because every day has been spent on emergency hotfixes for dumb poo poo QA missed. The only things getting done are little 1-pointer copy changes, zero features getting done. A normal sprint has plenty of added subtasks or bugs, but we usually hit at least 50% of the target. But I'll give my team credit, they do recognize all of this as a problem and are working to correct things (we just hired a new scrum master, and my team lead was fired a couple weeks ago...unsure if that was related, but kind of feels like it is). Today, at least, testing served its purpose....kind of. We caught a major bug caused by a one line tweak to a local settings file that should never be imported anywhere else (but is). Ironically, it would not have been a bug in production, since it would have overwritten the inherited problematic variable.
|
|
#
?
Apr 19, 2018 01:31
|
|
|
|
| # ? May 22, 2024 09:34 |
|
|
I guess I’ve been lucky to see mostly downward-trending sprints so far with less than 15% of the points being brought in after sprint start. We also try to leave some slack for other work that comes in (hot fixes after a release, new customer onboarding that’ll add a lot of stress to systems, etc) when we’re suspecting something will come up. On the other hand, I’ve been pulling 100+ hour weeks for months because I get stuck with full workloads in multiple sprint boards so there’s something wrong in the metrics saying I had about enough points for a full 40 hours / week (hint: I wind up in meetings or pull request review 80% of my days leaving no room for actual engineering work at the office, so 80 hours becomes implied). We try to point in the expected hours a meeting would take at least.
|
|
#
?
Apr 19, 2018 01:31
|
|