|
Outrail posted:That's why firing the bozos is step one. While I agree with this, I've been in the corporate world for over 20 years and I can safely say that there are not enough competent people on the planet to fill all roles in every company and do the work competently. I wish this wasn't the case but every place basically has to have morons. Even if someone could come in and accurately identify wasteful activity, people, and roles and get rid of them, there are simply not enough good workers to fill all the remaining jobs. Sucks 
|
#
?
Oct 26, 2021 18:38
|
|
|
|
| # ? Jun 8, 2024 09:06 |
|
|
Motronic posted:It's almost like if you estimate things in hours over time you can tell how many hours of stuff generally gets done in a given amount of time and plan only that much work for the week. True, you could do that, but at that point the number of hours you can complete are basically points with a different name, since they don’t really have any relation to the number of hours in a week. Using points encourages thinking in terms of the relative difficulty of tasks, which is easier to estimate than the actual time each task will take. They’re also intended to be the same for everyone, whereas the number of hours something will take will vary depending on who actually does the work. I’m not an agile evangelist or whatever, I just like points or t-shirt sizes for estimating instead of hours. There’s lots of articles about the pros and cons out there if you’re interested in the potential merits.
|
|
#
?
Oct 26, 2021 18:40
|
|
|
Motronic posted:Very much so. Agile proponents in particular seem to have a religious-level zeal about how it is the Only Correct Way* to do things. lmao none of this is true
|
|
#
?
Oct 26, 2021 18:44
|
|
|
chglcu posted:True, you could do that, but at that point the number of hours you can complete are basically points with a different name, since they don’t really have any relation to the number of hours in a week. So estimating how long tasks will take is going to be far more useful than some arbitrary difficulty score.
|
|
#
?
Oct 26, 2021 18:58
|
|
|
They are called points because it's one weird trick to get PMs off their case about missing a target because points are made up but hours are real. This is an admiralty scrum, you hold no jurisdiction here.
|
|
#
?
Oct 26, 2021 19:08
|
|
|
I took a class in project management and I have no idea what any of you are talking about
|
|
#
?
Oct 26, 2021 19:10
|
|
|
kntfkr posted:I took a class in project management and I have no idea what any of you are talking about It's not project management it's Sigma-level Agile Scrumming, idiot.
|
|
#
?
Oct 26, 2021 19:12
|
|
|
Outrail posted:So estimating how long tasks will take is going to be far more useful than some arbitrary difficulty score. If it could be done accurately, perhaps. In my experience, software developers are absolutely terrible at accuracy, largely due to there being lots of unknowns inherent in the process. Points measuring relative difficulty, combined with tracking velocity (points completed per time period) gives a decent estimate without requiring hour estimates that are usually wrong. It seems to work reasonably well.
|
|
#
?
Oct 26, 2021 19:13
|
|
|
How often does the term synergy get used in a Sigma-level Agile Scrumming workplace?
|
|
#
?
Oct 26, 2021 19:14
|
|
|
Zil posted:How often does the term synergy get used in a Sigma-level Agile Scrumming workplace? Depends if you've optimized your project for flexibility or eliminating waste.
|
|
#
?
Oct 26, 2021 19:18
|
|
|
chglcu posted:Using points encourages thinking in terms of the relative difficulty of tasks, which is easier to estimate than the actual time each task will take. They’re also intended to be the same for everyone, whereas the number of hours something will take will vary depending on who actually does the work. This is exactly the opposite of what agile says it should be. They are a difficulty estimate, meaning more senior people should be able to perform more difficult tasks faster than a junior person. And then when Jira spits out a report of how many story points each engineer completed during a sprint and getting poo poo about "less than last sprint" it leads to the obvious: everyone rushing to cherry pick stories to make number go up. Motronic fucked around with this message at 19:44 on Oct 26, 2021 |
|
#
?
Oct 26, 2021 19:42
|
|
|
Motronic posted:This is exactly the opposite of what agile says it should be. They are a difficulty estimate, meaning more senior people should be able to perform more difficult tasks faster than a junior person. From my understanding, they do that by accomplishing more points, not by having tasks take fewer points. So your seniors will be providing more capacity to the team, not altering the point values themselves.
|
|
#
?
Oct 26, 2021 19:48
|
|
|
Motronic posted:This is exactly the opposite of what agile says it should be. All I keep hearing is that every example of agile being used is not actually agile. Im starting to think that agile doesn’t actually exist except as a set of buzzwords and jargon that people say to convince everyone they know what they’re talking about and if you question it they can claim you don’t have a sufficiently agile mindset
|
|
#
?
Oct 26, 2021 19:49
|
|
|
Outrail posted:It's not project management it's Sigma-level Agile Scrumming, idiot. oh yeah? 
|
|
#
?
Oct 26, 2021 19:50
|
|
|
So Agile is like Unitarianism?
|
|
#
?
Oct 26, 2021 19:51
|
|
|
HenryJLittlefinger posted:So Agile is like Unitarianism? I think Unitarians generally get along with each other.
|
|
#
?
Oct 26, 2021 19:53
|
|
|
Scientastic posted:All I keep hearing is that every example of agile being used is not actually agile. Your customer tells you they want an app with fifteen features. You tell them to rate the features from most important to least important. Your dev team develops some sort of minimum viable product, something that could actually be called a working program (it'll probably only have a few of the fifteen features the client expects). Your team slowly adds the remaining features to the application while showcasing their work to the client so that you don't spend a year making a program the client doesn't like/doesn't work the way they expected it to/doesn't look the way they wanted it to/no longer meets their needs. The whole point of having constant contact with the client is that requirements frequently can and do change mid-development, and catching them early means it's less of a headache addressing them later. The problem is that lovely clients think "agile" means they can come in without a solid idea of what it is they want, can change things whenever they want for whatever reason they want, refuse to say what features are more important than others, often ask for too many features to be implemented in not enough time, and then bitch rear end managers just bend over backward to accommodate them.
|
|
#
?
Oct 26, 2021 19:58
|
|
|
Fleet superintendent bouncing back a requisition on the grounds of cost and berating us about needing to tighten our belts the same day they sent out the quarterly financial results showing we are up about 60 percent to something like 14 billion in revenue. The requisition? 20 pillow cases and some plates because we haven’t got enough for 23 people to eat at the same time.
|
|
#
?
Oct 26, 2021 19:59
|
|
|
Also project managers don't like doing work that's why I became one. I just bamboozle bosses with buzzwords. Samuel L. Hacksaw fucked around with this message at 20:04 on Oct 26, 2021 |
|
#
?
Oct 26, 2021 20:01
|
|
|
chglcu posted:From my understanding, they do that by accomplishing more points, not by having tasks take fewer points. So your seniors will be providing more capacity to the team, not altering the point values themselves. Yes, that is how it's accomplished. Let's go back to the post I responded to: chglcu posted:Using points encourages thinking in terms of the relative difficulty of tasks, which is easier to estimate than the actual time each task will take. They’re also intended to be the same for everyone, whereas the number of hours something will take will vary depending on who actually does the work. Maybe I'm not understanding what you mean by the bolded part. How are they "the same for everyone" while "the number of hours something will take" depends on who does it? I think we agree on the way it's supposed to work: more senior people can complete more "story points" in the same given amount of time as a junior person. This then furthermore leads to a bunch of unintended consequences, like the aforementioned cherry picking. It also doesn't address grunt work that simply takes a long time to do but isn't difficult at all, and sometimes that's just something that needs to happen. So now you either give that more story points or your pretty graphs spit out of Jira show someone losing story point velocity. The whole thing is a perfect example of engineers making an overcomplicated system to do a simple thing. A system that outputs dubiously useful metrics, which are then treated as a way to rate employees. Rather than, you know......having competent managers who are actually rating employees based on actual performance. Turns out this is perfect for the tech industry, where most line managers are engineers/tech leads who got promoted and given no management training at all because it was "the next promotion available". Batterypowered7 posted:Your customer tells you they want an app with fifteen features. You tell them to rate the features from most important to least important. Your dev team develops some sort of minimum viable product, something that could actually be called a working program (it'll probably only have a few of the fifteen features the client expects). Your team slowly adds the remaining features to the application while showcasing their work to the client so that you don't spend a year making a program the client doesn't like/doesn't work the way they expected it to/doesn't look the way they wanted it to/no longer meets their needs. The whole point of having constant contact with the client is that requirements frequently can and do change mid-development, and catching them early means it's less of a headache addressing them later. Iterative development has been a thing long before agile and in no way requires it. It's always had the same strengths and weaknesses, whether it's being organized as an agile project or not.
|
|
#
?
Oct 26, 2021 20:05
|
|
|
Motronic posted:Yes, that is how it's accomplished. Let's go back to the post I responded to: I probably just didn't state this clearly. I meant that a task will be worth the same number of points no matter who actually does it. If the same task was estimated in hours, the number of hours required would change depending on who ended up performing the task. Motronic posted:I think we agree on the way it's supposed to work: more senior people can complete more "story points" in the same given amount of time as a junior person. This then furthermore leads to a bunch of unintended consequences, like the aforementioned cherry picking. It also doesn't address grunt work that simply takes a long time to do but isn't difficult at all, and sometimes that's just something that needs to happen. So now you either give that more story points or your pretty graphs spit out of Jira show someone losing story point velocity. I agree with all of this, pretty much. I find points useful for estimating tasks, not for anything beyond that. In fact, I recall hearing somewhere that the originators of agile expressly stated they shouldn't be used for anything else due to these sorts of problems (no idea where I heard that, though). But managers gonna manage, I guess.
|
|
#
?
Oct 26, 2021 20:12
|
|
|
Motronic posted:Yes, that is how it's accomplished. Let's go back to the post I responded to: I don't know how you would phrase "mansplaining" for this, but that's exactly how it feels listening to this. quote:Look at you 'engineers', you don't actually know how to do you're jobs so you need a pretend fairy system to follow. Why don't you just use hours instead???
|
|
#
?
Oct 26, 2021 20:16
|
|
|
Arguments about Story Points have wasted way more time than Story Points have ever saved
|
|
#
?
Oct 26, 2021 20:21
|
|
|
Volmarias posted:I don't know how you would phrase "mansplaining" for this, but that's exactly how it feels listening to this. Sorry to bruise your agile ego.
|
|
#
?
Oct 26, 2021 20:26
|
|
|
How many more pages about management cults before we get back to the stories about workplaces that suck?
|
|
#
?
Oct 26, 2021 20:30
|
|
|
Whoa whoa whoa, we're right on the pulse of why workplaces suck here.
|
|
#
?
Oct 26, 2021 20:31
|
|
|
Motronic posted:Dumb poo poo your work does - Sorry to bruise your agile ego.
|
|
#
?
Oct 26, 2021 20:42
|
|
|
Manager dragged feet for half a year and failed to post role for dept until far too late for me to train anyone. Got only one applicant and manager is rushing them through application process as surely they are good enough. Browsing their resume not seeing relevant experience but looks like the right person if we demanded extensive high school Christian club training.
|
|
#
?
Oct 26, 2021 20:47
|
|
|
Hyrax Attack! posted:More stories from the amazon fulfillment center please Here's a story everyone here might be familiar with: higher level management loving with workers' poo poo because of metrics. So one of the apps I use at my problem solve job is "Move Items", which is a simple, effective, powerful tool. I select a source container, move the virtual items in it one at a time to a new destination container. This was an excellent way to solve when the pickers pulling poo poo out of inventory would gently caress up as the most common fuckup is called an "improper tote transition". What that means is they switch totes on their pick station without letting the sensor scan the new one. Sometimes it's due to a damaged label on the tote, usually they just slam the new, big/heavy item through so fast the sensors can't keep up. Either way I end up with a physically full tote that's virtually empty. No biggie: research the item, find the tote it's most likely in. Move the virtual listing to match what I physically have in hand. Well that obviously causes an event to be registered each time. So some day some C-level looked at BIG NUMBER and went "Huh, we're sure fixing a lot of defects. Oh! I know: Reducing the defects we fix will get me a bonus/promoted! What's the easiest way to reduce this number? Why that's genius, I'll hobble the tool!" So one day I go in to move an item and get "Error: exceeded customer shipments limit of 0". In short if I'm moving tranship (being sent to another facility) or problem solve around I'm good. However the moment I try to move something that's being packed out I run into that error. I raise a ruckus and learn: 1) It's being passed off "to prevent theft" despite the fact that the tool leaves clear, concise footprints. It shows what virtual container an item was moved from and to, the login of whomsoever did it, and the timestamp. If you can't catch a supposed thief from those you're not trying since the system separately records the locations and times the container was seen at as well on the same page. 2) it's network wide and above the local managers' ability to fix/fight 3) it's a change so stupid even day shift was pissed off. These days when I train someone new on the tool (it still has uses) and I just explain its limitation as "It made numbers that gave someone the sads." I feel that more or less is the amount of respect/effort that sort of thinking deserves. That same sort of thinking struck again on another of our tools in the last couple months. Sometimes we'd get a tote with a virtual listing in it despite being empty. So using the "empty tote" tool we'd virtually empty it. Sanitize the tote (again it creates a record so its not like its hard to find out if someone's pulling shenanigans), and send it back to have more items put into it. Only apparently someone higher up didn't like those metrics and heard of this one edge case where you delete a tote's inventory and then find the item 5 minutes later. Something that happens to me maybe once or twice on a busy week while I have literally hundreds of totes full of bad data I need to clear every shift. So what did this c-level due? Well now "Empty Tote" will "de-list" a tote's inventory. Good news: much like deleting the inventory before this will send orders to pick replacement items if these are shipments. Bad news: the tote still has all of those items in its virtual inventory as "Sellable: unowned". Why? So us Problem Solvers can spend precious minutes and hours of our time sleuthing around for said items to put back into the tote to put them into inventory. Precious work-hours wasted on such silliness when we're already dealing with staffing shortages. This is compared to our usual SOP of just checking stuff back into inventory as we find it. No they want us to actively go searching for these items. Joke's on them: we found workarounds in about 2 days and it fills the system's records with even more garbage data. Doesn't even record who did what, just records "aft-ps" (Amazon Fulfillment Tools- Problem Solve) as the user.
|
|
#
?
Oct 26, 2021 20:52
|
|
|
Every hosed up warehouse management system feature is because of 1 of 2 reasons: the requester has never been in a warehouse and is asking people who have never been in a warehouse to implement it. Or else everybody involved has been in a warehouse and they are now being abused to make shrink Somebody Else's problem.
|
|
#
?
Oct 26, 2021 21:01
|
|
|
Not only that, but sometimes managers with too much downtime will find an issue that becomes personal to them for some reason, a pet issue they get stubborn about forcing a process for. I can practically hear that manager mumbling 'well it shouldn't be getting that far along without the items being scanned properly! How can we force them to do it right the first time???' and thinking hobbling your ability to fix it after-the-fact will force people to adapt into being more careful during picking Just lol
|
|
#
?
Oct 26, 2021 21:11
|
|
|
Hyrax Attack! posted:Manager dragged feet for half a year and failed to post role for dept until far too late for me to train anyone. Got only one applicant and manager is rushing them through application process as surely they are good enough. Browsing their resume not seeing relevant experience but looks like the right person if we demanded extensive high school Christian club training. Is that not an in-demand skill?
|
|
#
?
Oct 26, 2021 21:15
|
|
|
StrangersInTheNight posted:Not only that, but sometimes managers with too much downtime will find an issue that becomes personal to them for some reason, a pet issue they get stubborn about forcing a process for. I can practically hear that manager mumbling 'well it shouldn't be getting that far along without the items being scanned properly! How can we force them to do it right the first time???' and thinking hobbling your ability to fix it after-the-fact will force people to adapt into being more careful during picking Which creates new problems as we find work-arounds! Because of my unique position in the building I have both inbound and outbound problem solve tools and I can use another one (in an incorrect/cheesy fashion I may add) to delete any "unowned" listings. However the changes now leave me unable to clear out empty totes heading to tranship so I just have to send those down to the shipdock and they deal with the empties down there instead of me clearing them out and having the defect fixed faster. Any virtual Problem Solve listings? I now have multiple stacks of totes next to my workspace because I can't clear them out and all we can do is wait for them to evaporate after 72 hours. Efficiency!
|
|
#
?
Oct 26, 2021 21:25
|
|
|
Short of stapling notes to people's hands, is there any way to emphasize 'If you are given a task you are responsible to make sure it is complete. You cannot just ignore it and hope it goes away because I will find out after the due date and then we, and therefore you, will be properly hosed.'? I seem to be having trouble making people understand this. Is it too complicated a concept? Should I start threatening people?
|
|
#
?
Oct 26, 2021 22:13
|
|
|
Sounds like a job for Lean Agile. E. Oh right you're allergic aren't you? Maybe you could try this idea someone up thread had Outrail posted:Seems like firing the useless fuckers and hiring competent people who can do the job would be quicker, easier and more cost effective. And also rid the company of dead weight, coz you know they're not just making life hard for the people they have to work with directly.
|
|
#
?
Oct 26, 2021 22:18
|
|
|
Alkydere posted:Sanitize the tote This sounds like code for the order Jeff Bezos gives to his corporate kill team
|
|
#
?
Oct 26, 2021 22:24
|
|
|
Is this where I complain about Scrumm masters? So in a large IT org, we had roughly 12 PMs. I, as a lowly senior sysadmin, was generally annoyed by them but they serve a purpose (to make me not have to talk to other people). Anyways, the org went into the deep end of Kanban, and decided every department needed a dedicated Scrumm master. Well who do you think applied to the SM jobs? I started a new, fairly large, multi department project last week and was told there were no PM hours available. Umm, wtf. Apparently 10 of the 12 previous PMs are now Scrumm masters. As such they are unable to fill any PM duties and now my low level manager is my acting PM who basically delegated all tracking/contact duties back to me, the main implementer of the project. Shoot me. Also I still do not know what a Scrumm master does differently besides waste post its.
|
|
#
?
Oct 26, 2021 22:33
|
|
|
Meydey posted:Is this where I complain about Scrumm masters? They set up a meeting and invite all the devs at the start of a sprint so they can all do this: https://www.planitpoker.com/
|
|
#
?
Oct 26, 2021 22:46
|
|
|
Mr Teatime posted:The requisition? 20 pillow cases and some plates because we haven’t got enough for 23 people to eat at the same time.  Meydey posted:Is this where I complain about Scrumm masters?
|
|
#
?
Oct 26, 2021 22:47
|
|
|
|
| # ? Jun 8, 2024 09:06 |
|
|
MagusofStars posted:Based on your story, "what a Scrumm Master does differently" is being more effective at avoiding work. drat. Good on them then. Pretty sure they all got pay scale bumps also.
|
|
#
?
Oct 26, 2021 22:50
|
|