|
We use SAFe here at work and the big difference from waterfall is that instead of saying "this entire application will be done a year from now", instead you get "this set of features will be done 2 weeks from now". Estimating work with points and velocity are huge huge metrics. All this leads to devs breaking up features into bullshit stories and bloated estimates so that we look good on our metrics. It also gives us cover to do things the right way with minimal interference since our velocity doesn't look off. Welcome to SAFe where the points are made up and the actual work doesn't matter.
|
#
?
Feb 25, 2019 19:43
|
|
|
|
| # ? May 25, 2024 20:31 |
|
|
CPColin posted:Yep! Both places went "beep boop we're Scrum now" and didn't actually solve any of the problems that made everybody realize a change was necessary. 90% of scrum organizations.txt
|
|
#
?
Feb 26, 2019 01:15
|
|
|
Vulture Culture posted:User stories and tasks are separate things, and both are necessary but not sufficient for shipping product in a user-focused way. Stories should be how new work is prioritized and scoped, in order to ensure a complete, functioning unit of improvement is shippable to a user before the dev team starts working on other tasks associated to a different user story. Each task should have a Directly Responsible Individual, but the DRI for the story doesn't need to be any of the engineers involved—it can be the product owner, PM, a team lead, or any other stakeholder responsible for keeping an eye on the tasks and making sure they all gel together into a completed feature. Many organizations use completely separate product backlogs and sprint backlogs to ensure people keep their eyes on which is which. It depends on the context, but it is definitely possible (and even desirable imo) to have user stories small enough that you don't need tasks. The term "user story" and the "as a <user> I..." format are useful to remind us that user stories are more than just tasks, but people get too hung up about every story needing to deliver direct visible value for an end user. I think "as a developer, I..."-stories are legitimate if they're about stuff like improving the build pipeline or paying off technical debt. The product mindset means you're not just developing a system for a user today, but you're also investing in the ability of the system to evolve tomorrow. It's all work and it all needs to be prioritized. I've seen teams trying to obscure this reality by having horrible stuff like separate backlogs for "business" stories and "technical" stories.
|
|
#
?
Feb 26, 2019 08:35
|
|
|
My Rhythmic Crotch posted:our users will only use something if it slices, dices, and makes toast. They give no fucks about agile, release cadence, stories, etc. They want a 100.0% functional thing or it won't get used. Oh hey, do we work together? See specifically: Users: “Ingest a shitload of data and present it to us” Dev: “Here’s some of the data, is it right so far?” Users: “We’re not going to look at an incomplete data set.” ~months pass~ Dev: “Here’s all the data” Users: “Some of this is wrong, why did you do this wrong?”
|
|
#
?
Feb 26, 2019 13:47
|
|
|
Messyass posted:It depends on the context, but it is definitely possible (and even desirable imo) to have user stories small enough that you don't need tasks. I also agree that not all stories need to deliver direct visible value. The amount of user focus versus engineering focus will differ greatly depending on the scale and product maturity of what you're developing. When you're starting out, and everything is an experiment in actual vs. perceived value, it's extremely important to keep focused on what the hypothesis is that you're trying to test. The "as a _____, I want to _____ so I can _____" story format is very helpful here because it forces you to keep revisiting how well you're executing on your goals. As a project matures, and more development work becomes focused on architecture, scalability, sustaining engineering, and platform-building, there are different and less user-centric lenses to view this sort of work through, like SLOs or OKRs. Separate task backlogs are a definite bad smell, and they indicate a lack of communication or cooperation between product design and product implementation teams. Rather than mutual priority-setting, cooperation, and trust, they rely on ideas like "we need to dedicate one quarter of every sprint to eliminating technical debt." It sounds fine on the surface, but it invariably breaks down when you need to spend 100% of a delivery cycle rewriting something for scale or eliminating a large-scale security problem. Internal customers are a thing. It's valid to target internal customers with user stories, but developers should be cautious of how often the internal customers are themselves.
|
|
#
?
Feb 26, 2019 15:23
|
|
|
raminasi posted:Oh hey, do we work together? I perceive a great deal of risk telling users to use an application that's not minimally functional. I get the concept of incremental releases, but that's not what I'm being asked to do by management. Management wants the production version released, let's say, 2 months early, meaning it will not have the minimum required functionality to be useful in a production setting. Experience has shown that releasing early like that will result in severe blowback - people won't be able to do their jobs with an incomplete tool - in fact the blowback might be severe enough that we have to completely scrap the entire project, because people are so negative towards it. Yet that's what I'm asked to do with every big thing I work on - manager always wants the old version retired and replaced with the new version 2 months before it's really mature. She would rather risk losing all the work that went into the new version, simply to see if we can get it out there "early". I need something catchy to call this... a "spreadsheet victory" maybe? That's the point of all of this: to turn a box green in her spreadsheet when she presents it to upper management. Project is pointless since no one can use it? Who cares! It's "done" in the sense that it's in production! Since I fight this same loving battle on every big project here, I've started adding on 2 additional months to every estimate.
|
|
#
?
Feb 26, 2019 19:25
|
|
|
I'll go ahead and suggest "premature release"
|
|
#
?
Feb 26, 2019 19:45
|
|
|
Vulture Culture posted:Separate task backlogs are a definite bad smell, and they indicate a lack of communication or cooperation between product design and product implementation teams. Rather than mutual priority-setting, cooperation, and trust, they rely on ideas like "we need to dedicate one quarter of every sprint to eliminating technical debt." It sounds fine on the surface, but it invariably breaks down when you need to spend 100% of a delivery cycle rewriting something for scale or eliminating a large-scale security problem. Internal customers are a thing. It's valid to target internal customers with user stories, but developers should be cautious of how often the internal customers are themselves. At my company we have asked the product team to be involved in overall priority setting so that we have a single backlog to pull from. They have outright refused, saying that they are responsible for the "product priorities" and we are responsible for the "infrastructure/dev priorities." The official product owner, ostensibly the person who's supposed to be the last word on all this poo poo, is a sales engineer first and when he's tried this in the past he's consistently dropped any and all dev priorities into oblivion regardless of urgency. As devs we're basically in the position of making a judgement call between the two backlogs each time we pull in a new piece of work and just weather the inevitable complaints and pressure from product when we tell them we aren't working on this quarter's three #1 feature priorities. Is there a way to make this situation not terrible without the cooperation of product? I suspect the answer is no, but if there is one I want to know it.
|
|
#
?
Feb 26, 2019 22:10
|
|
|
Stop doing product work and pay down tech debt until they start asking questions. Then tell them what they want isn't important.
|
|
#
?
Feb 26, 2019 22:50
|
|
|
"I'm actually doing work for <feature> but I can't make progress to demo at least until <debt> is solved. I understand that's not what you want to hear but this is the fastest way forward."
|
|
#
?
Feb 27, 2019 01:05
|
|
|
https://twitter.com/PPathole/status/1100406765156327427
|
|
#
?
Feb 27, 2019 06:16
|
|
|
The problem with that is that the provided cup is not sturdy enough to push the lever back so it crumbles in your hand and your pants get wet too. The design is fine, it is user hardware that causes the problem. Or turned around: the design did not take user hardware into account. It is only intuitive on the developers powerhouse machine. To necromance the headphone chat: thanks so much for the tip on the app being able to regulate noise cancellation, this seriously improved my life and makes me love my overprices Bose QuietComfort 35 more. Pretend I put an affiliate link here.
|
|
#
?
Feb 27, 2019 08:23
|
|
|
Che Delilas posted:At my company we have asked the product team to be involved in overall priority setting so that we have a single backlog to pull from. They have outright refused, saying that they are responsible for the "product priorities" and we are responsible for the "infrastructure/dev priorities." The official product owner, ostensibly the person who's supposed to be the last word on all this poo poo, is a sales engineer first and when he's tried this in the past he's consistently dropped any and all dev priorities into oblivion regardless of urgency. As devs we're basically in the position of making a judgement call between the two backlogs each time we pull in a new piece of work and just weather the inevitable complaints and pressure from product when we tell them we aren't working on this quarter's three #1 feature priorities.
|
|
#
?
Feb 27, 2019 14:01
|
|
|
We have now officially begin the process to remove Mongo from our system. Again. Let’s hope it takes for good this time - I will have to be the one to advocate for it now.
|
|
#
?
Feb 27, 2019 17:12
|
|
|
Pollyanna posted:We have now officially begin the process to remove Mongo from our system. Again. Let’s hope it takes for good this time - I will have to be the one to advocate for it now. Oh no, you will stop being Web Scale.
|
|
#
?
Feb 27, 2019 17:37
|
|
|
I need to take some PTO. Feel like I have been working on the same poo poo and any time I need help from anyone else people are just sandbagging me and trying to make me feel like I'm doing something wrong. For example - I needed help figuring out why a SQL script that should be running automatically is not. I don't have permissions to run the script by hand, so I asked the DevOps team, who oversees the servers to run it. I explained that it should be running but the things it should be updating weren't, so I wanted someone with SA access to run it to check if it's a problem with the automatic part of it or the script itself. They won't budge even after I explain that it should already be a part of the process, and running it will fix problems and not cause them. So I guess I have to fall back to the SAFe methodology and sit in my scrum team and yell "I'M BLOCKED" until the scrum master escalates and something happens. Agile!
|
|
#
?
Feb 27, 2019 18:30
|
|
|
Protocol7 posted:so I wanted someone with SA access to run it to check if it's a problem with the automatic part of it or the script itself.  Unless your organization is totally hosed you should be able to troubleshoot this yourself. That one statement raises so many questions. - Why aren't there logs available? - Why isn't the script running in a lower environment? - Why can't you test the script on a local or dev environment? - If the script is failing, why isn't it failing the automation? There should be no reason to involve someone with SA access on a database server to start ruling things out.
|
|
#
?
Feb 27, 2019 20:33
|
|
|
It is a lower environment. Just a QA one though. For some reason we don't have dev servers, which would be amazing for fixing this issue timely. No way to test on my own since I execute the script manually building it from source code. 6 years ago the SA passwords were handed out like candy. They're just QA servers. No problem. Everyone was nice enough to not gently caress everything up. Then corporate implemented SAFe, and we got new machines that were locked down to poo poo. The passwords and everything changed and now your own account needs to be granted access (with ticket paper trails). I make well over twice as much as I did 6 years ago which is why I am staying around but, y'know, I'm keeping my eyes open for other opportunities too. Macichne Leainig fucked around with this message at 20:41 on Feb 27, 2019 |
|
#
?
Feb 27, 2019 20:38
|
|
|
Protocol7 posted:It is a lower environment. Just a QA one though. For some reason we don't have dev servers, which would be amazing for fixing this issue timely. No way to test on my own since I execute the script manually building it from source code. That doesn't explain why there's apparently a total informational black hole. Why can't you review logs? Why can't you review the automation to see what it's doing? Why doesn't your automation fail with something resembling diagnostic information if something isn't happening that's supposed to be happening?
|
|
#
?
Feb 27, 2019 20:56
|
|
|
Making computers black boxes is not what anyone besides incompetent control freaks or the job insecure want to do to developers, especially in a non-production environment. Sure, maybe you have a farm of hundreds of thousands of code monkeys and you’re afraid of someone doing something awful to the company, but trust is variable and giving some means to debug what’s going on in a remote set of computers is generally not a problem that’ll compromise security.
|
|
#
?
Feb 27, 2019 21:53
|
|
|
Vulture Culture posted:I'm assuming the product organization is underneath the CEO, and the dev organization is under the CTO? It's really the CTO's job to be aware of this tension and lack of clarity and sort it out. Close enough. The CTO's position is more or less that we as devs decide what we work on. But we have a hard time making the "right" decision because the CEO will come charging down to the dev rows if we aren't devoting enough people to enough of the multiple #1 product priorities. So yeah I guess the CTO isn't doing enough there.
|
|
#
?
Feb 27, 2019 22:20
|
|
|
New Yorp New Yorp posted:That doesn't explain why there's apparently a total informational black hole. Why can't you review logs? Why can't you review the automation to see what it's doing? Why doesn't your automation fail with something resembling diagnostic information if something isn't happening that's supposed to be happening? Because they designed it poorly in a day and "it's supposed to work" is too common a phrase, unfortunately. For a company as large as we are, we are held together by duct tape.
|
|
#
?
Feb 27, 2019 22:47
|
|
|
Protocol7 posted:Because they designed it poorly in a day and "it's supposed to work" is too common a phrase, unfortunately. For a company as large as we are, we are held together by duct tape. Id like to see examples of large companies that are not held together by duct tape. Say 5k+ employees as the bar for "large"
|
|
#
?
Feb 28, 2019 17:53
|
|
|
downout posted:Id like to see examples of large companies that are not held together by duct tape. Say 5k+ employees as the bar for "large"
|
|
#
?
Feb 28, 2019 20:29
|
|
|
I deal with industrial electronics and a ton of manufacturing facilities are built on electronics from the 60s, various replacement bits, and a shitload of duct tape. And no-one on staff knows how it works or how to do anything.
|
|
#
?
Feb 28, 2019 20:33
|
|
|
downout posted:Id like to see examples of large companies that are not held together by duct tape. Say 5k+ employees as the bar for "large" I mean, it isn't that large. About 500 employees. But i joined when it was like 80 so it's large to me.
|
|
#
?
Feb 28, 2019 22:27
|
|
|
My Rhythmic Crotch posted:Who cares! It's "done" in the sense that it's in production! I've definitely seen this attitude (both from management and from developers) and a way I've tried to fight it is to emphasize "a feature is not done until your target audience is making use of it, or you have determined they never will." In production simply means you deployed the change to production, not that the work is done. This will be challenging when business and development are highly segregated and driven by rigid contracts or ego/avarice, but well... try to not work at places like that.
|
|
#
?
Mar 1, 2019 01:19
|
|
|
Lord Of Texas posted:I've definitely seen this attitude (both from management and from developers) and a way I've tried to fight it is to emphasize "a feature is not done until your target audience is making use of it, or you have determined they never will." In production simply means you deployed the change to production, not that the work is done. I try to frame it this way: If a user story was done before the work still in the backlog, it's because people agreed that it was the most important thing, right? Otherwise, it wouldn't have gotten prioritized. So why would this value-add stop being important just because there's something less important behind it in the queue? Well, okay, you expected this change to work out a certain way for the product's users, and add a certain amount of value. Did it? If you think it didn't, but it should, then this story should still be the top thing on your product backlog, because your design was a blocker bug. If you think you misjudged the market, but there's still some potential for it to add value, figure out how to pick up better signals on who's using it, why, and what they want from it. Iterate on it normally in your backlog. If you think it was a total miscalculation and there is literally no one interested even conceptually in the thing you built, kill the feature and figure out how to do your next MVP without wasting weeks of product and engineering time.
|
|
#
?
Mar 1, 2019 01:33
|
|
|
Oh man, it was so great a few jobs ago when my PM and I got pissed at the bullshit that kept coming down the pipe and started banging the Agile drum by offering to put out MVP's and see if anybody actually used poo poo before committing to giant projects. Because of course we were "Agile," but giant blobs of projects were still falling in our laps.
|
|
#
?
Mar 1, 2019 03:43
|
|
|
CPColin posted:Oh man, it was so great a few jobs ago when my PM and I got pissed at the bullshit that kept coming down the pipe and started banging the Agile drum by offering to put out MVP's and see if anybody actually used poo poo before committing to giant projects. Because of course we were "Agile," but giant blobs of projects were still falling in our laps. That's pretty much exactly how my product owner and I operate - we've been burned too often on massive investments that are rejected by our userbase or never needed to be built in the first place. That said, "MVP" has become so pervasive at my company that I feel like I have to remind folks there is a "V" in minimally viable product... if you haven't done the basic groundwork to understand your userbase before throwing poo poo that doesnt do anything at the wall, you burn out the userbase's confidence in the product. quote:If a user story was done before the work still in the backlog, it's because people agreed that it was the most important thing, right? Otherwise, it wouldn't have gotten prioritized. So why would this value-add stop being important just because there's something less important behind it in the queue? Pretty much. We added an "in production" column to our JIRA board, between "ready for release" and "done" to emphasize the fact that just because we released feature X to production, doesn't mean our focus should completely shift to the next thing. Paying attention to APM, logging, taking time to quantify realized impact... all just as important as coding for the first release.
|
|
#
?
Mar 1, 2019 04:11
|
|
|
The CEO gave a little speech this week to the dev team about how we need to be more passionate, because when he walks down to the dev rows at 5:00 most people are gone. He linked these two ideas. Please give me ideas for passive-aggressive ways to indicate how "passionate" I am.
|
|
#
?
Mar 8, 2019 23:47
|
|
|
Submit a very enthusiastic resignation letter.
|
|
#
?
Mar 9, 2019 00:50
|
|
|
Che Delilas posted:The CEO gave a little speech this week to the dev team about how we need to be more passionate, because when he walks down to the dev rows at 5:00 most people are gone. He linked these two ideas. Life-sized cardboard version of yourself, left in your seat whenever you're elsewhere.
|
|
#
?
Mar 9, 2019 02:47
|
|
|
Che Delilas posted:The CEO gave a little speech this week to the dev team about how we need to be more passionate, because when he walks down to the dev rows at 5:00 most people are gone. He linked these two ideas. Ask him to show more passion in paying his employees. Maybe you can have a series of meetings about it, where most of the stakeholders just don't show up each time.
|
|
#
?
Mar 9, 2019 03:08
|
|
|
Volmarias posted:Ask him to show more passion in paying his employees. Maybe you can have a series of meetings about it, where most of the stakeholders just don't show up each time. Alternatively ask how much passion does he pay his mortgage with
|
|
#
?
Mar 9, 2019 03:19
|
|
|
Hughlander posted:Alternatively ask how much passion does he pay his mortgage with Lol if you think he has a mortgage
|
|
#
?
Mar 9, 2019 03:24
|
|
|
Che Delilas posted:The CEO gave a little speech this week to the dev team about how we need to be more passionate, because when he walks down to the dev rows at 5:00 most people are gone. He linked these two ideas. The CTO at my previous company decided that an effective motivational tactic was to e-mail a picture of empty dev desks to the developer distribution list, asking them if they thought that [COMPETITOR'S NAME HERE]'s developers didn't come in until 10 AM (the answer, without even knowing the company, is yes). He decided to do this on a day when NYC received like 2 inches of rain and half the subway system was shut down, so most people couldn't even make it to the office anyway. For most people, this is when he went from being just annoying to actively nefarious, and people deciding they were tired of this lovely company started to snowball soon afterward. I found out later he had tried to use the same tactic at his last company, where I assume it went over about as well.
|
|
#
?
Mar 9, 2019 04:00
|
|
|
Volmarias posted:Lol if you think he has a mortgage If he’s walking around the peons he’s not as high and mighty as you think
|
|
#
?
Mar 9, 2019 04:03
|
|
|
Volmarias posted:Ask him to show more passion in paying his employees. Maybe you can have a series of meetings about it, where most of the stakeholders just don't show up each time. truth, also VV pay your mortgage with passion. My bank said they don't accept that at this time. Hughlander posted:Alternatively ask how much passion does he pay his mortgage with
|
|
#
?
Mar 9, 2019 05:54
|
|
|
|
| # ? May 25, 2024 20:31 |
|
|
Just to add constructive conversation: Today a coworker and I had a very productive conversation about Agile and the fact of the matter is agile to us is just being more efficient in our space, in our development team, in our world. This isn't every team's world but maybe some of it is relative. We are agile every day with or without scrum, with or without sprints, with or without a lot things that are seem to be required to be agile. For our team, agile or not, our success and efficiency are closely tide to adequate, dare I say good, requirements gathering, specifications, definition of scope, clear stories that make dependencies explicit from the onset. Unfortunately, I've yet to be a part of a team that does any of these well. Maybe one or two, but never all. Executives, clients, owners never seem to understand that these pieces make us more efficient. And then complain when timelines are missed or features are missing or incomplete. I feel better now. Ignore as necessary.
|
|
#
?
Mar 9, 2019 06:10
|
|