it finally happened, PM/PO/SM is now also dev シ

each standup he now also gives update about his work in progress, with his diligently designed subtasks, perfectly sticking to the daily script, like a good well-behaved employee boi. it's weirdly cute

devs can't await to review his first PR. feeling the strong urge to spank his ass for each minor coding style issue or poorly-named variable...

Wait - did they really pull in the clown also into development instead of doing it the other way around?!

Employee Boi, worst superhero ever

@Fast-Nop i think it's just a temporary measure to increase manpower so we can deliver our first poc faster. but my initial thought was that maybe this was a strategic decision so he can be a "role model" for other devs in the team and scrum team cohesion (between him and rest of the team) is improved in a way. but probably he didn't spend so many thoughts on this 😅

@soull00t Given his track record of being a "role model" sheds some doubt on that decision. Or maybe it's "how not to lead, given by bad example". ^^

@soull00t let's hope with him involved in the development poc doesn't stand for piece of crap

Not that bad an idea to have everyone at least get a shallow taste of each others' work. It helps when management has some feeling about what everyone does and when devs know how other departments actually work.

Sometimes there actually is too much disconnect between departments.

Oh, please keep us updated when the pr finally comes trough! This is hilarious

@TheCommoner282 after what period of time do you usually create a pull request? i mean if it's still a work in progress for a story that takes a whole sprint and there's nothing to show / discuss yet, there's no need for a PR, or is it?

@rarboot yeah agree, these subtasks are fucking retarded

@TheCommoner282 hmm... well, at the moment i don't work on tasks that would require several PRs a day or after 2 days... they are not small enough.

our team is currently working on a module for an embedded system prototype and my tasks also have this prototyping nature, stories involve whole libraries or data models... of course this is poor story composition, which i already criticized, but PM arguments that during prototyping, it is hard to specify everything beforehand, so stories might turn out more complex than initially thought. (i think, they are still poorly designed, but it's getting better^^)

anyway, for these types of tasks, imo it doesn't make so much sense to have such a high frequency of PRs.
also consider that every single PR involves time that other team members have to spend, keeping them from working on their tasks.
since we don't push anything to prod, we don't need this level of quality assurance yet.
we use PRs, but rather after some days or maybe a week.

@TheCommoner282 don't get me wrong, I agree that code reviews are a good thing. ^^ but i also think that you can't prescribe a fix frequency (e.g. 2 days) that applies for every content, type of software/code, use case and project phase ^^

@Jifuna it might take a while ^^
https://devrant.com/rants/5715846/...