Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "squads"
-
Ok, so we have the Spotify Agile Model now (tribes, squads, chapters, etc). I have seen it implemented in a few large companies, and they seem to be doing ok.
It's just... doesn't anyone worry about the product that came out of this great way of working?
Spotify is great as a service, but it has to have one of the worst usability/success ratios of any modern mobile / web app. You can almost feel the various squads doing their own thing, not thinking about the whole experience.
Doesn't the product count when considering using someone's way of working? Is the Spotify Agile Model the project management equivalent of Twitter's Bootstrap?5 -
I got assigned to work on a new project a couple of weeks ago. We got the POC code handed off from senior management, since he came up with the idea over the weekend. The project concept is hella exciting, but the dev manager and PO I have to deal with make life unbearable to say the least.
We have only 2 devs (including me) and 1 QA on this supposedly very important project. Of course, management announced the project to the clients already, so now we have to deliver ASAP cause it adds “sizzle”.
The MVP deadline is... no one knows when, either July 30th or September 1st. The MVP requirements are... unknown. I swear if someone saw the list of tasks and issues attached to “MVP” Epic, they would call us nuts trying to fit it all in.
To make things better, each PR requires 2 reviewers, so we end up adding manager as a reviewer just cause we need him to hit that “approve” button. So in attempt to make life easier, we requested to have a third developer. We are getting another developer, but that guy doesn’t know how to unit test a pure function...
Current priorities are... unit testing with coverage of 95% and if we want to refactor code, we have to add area to the list in a Google Doc. As a result, we are not tackling big things like risk of SQL injections not to mention big features like i18n (5-6 languages to support by the way and yes, it’s part of MVP as well as SSR no one knows why). Currently, I spend 2-3 hours a week in calls with the team just to figure out what the hell MVP is, what we have to do and why we have to do it. Last time we spent an hour refining 1 spike and breaking down one story into 3.
Oh, we also don’t have a deployment plan, not even to test environments since DevOps team was not aware of this project at all. Thus, QA cannot create any test suites and have to test everything manually which eats a lot of their time.
This whole project is a big hot mess and I’m considering leaving it all together especially since I’m working on two squads at the same time. I love the project, I love the idea, but management makes it unbearable, so I’m not even motivated to work on that.3 -
The best part of being a developer is that you can work and develop at the same time without conflict. Even when you're not on the team.
-
I'm a dev lead. I'm trying to consolidate a squad. There's a senior in it preaching the dream of career climbing and LinkedIn optimization.
Now all interns want to switch squads. I'm all for personal growth... but now everyone wants to be everything at once and productivity stalled. The job descriptions for our squad were perfectly clear, there's tons of different tech stacks... We can build a lot of cool things in this scope, and now no one can see them because Data Science or Data Engineering or Front-end is suddenly sparkling.
I'm tired.3 -
Being victim of an arbitrary worplace's culture on dev experience and documentation makes me a very frustrated dev.
Often I do want to document, and by that, I don't mean laying an inline comment that is exactly the function's name, I mean going full technical writer on steroids. I can and WILL get very verbose, yes, explaining every single way you can use a service - no matter how self explanatory the code might look.
I know developers (and me included) can, and sometimes will, write the best variable and function names at the time, wondering if they reached the peak of clean, DRY code that would make Robert Martin have a seizure and piss himself, only to find weeks later after working on something else that their work is unreadable. Of course.
I know the doc's public, it's me, and I've done this.
But then again explain for the people in the back how the FUUUUCK are we meant to suggest improvements, when we are not the ones who are prioritising features and shit WITH the business?
Just email me when the fucking team recycles, and no new team member knows how to even setup the IDEs because this huge piece of monumental shit called CompanyTM is also run by VPN. Fuck, no one wants to access that garbage, you have no docs.
I once tried setting up a culture for documentation. I did an herculean amount of work studying what solutions were internally homologated, how steep the learning curve would be from what we had at the moment (NOTHING, WE HAD FUCKING NOTHING, jesus christ, I even interviewed SEVENTEEN other squads to PROVE they FUCKING NEED
DOCS
TO WORK
You know what happened to that effort?
It had a few "clap" reactions on a Teams meeting and it never reached the kanban.
It didn't even made it to backlog.
I honestly hope that, someday, an alien fenomenon affects the whole company, making their memories completely reset, only to have the first one - after the whole public ordeal on why our brains became milkshake -, to say: "oh, boy, I wish we had documented this".
Then I will bring them to the back and shoot them. -
do you have a CV driven software engineer(s) in your team/squad?
if yes, how do you deal with their dramatic changes in codebase every quarter?13