Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "sprint review"
One of our dev teams has a tradition: after each post-sprint review one of the devs tells a wood joke. The lamer, the better.
So far the winner is:
Q: What did Batman say to Robin before Robin got in the car?
A: Robin, get in the car
It's so dumb it's actually somehow even funny :)31
Client: we are using Scrum. Next week we have sprint review organized by the project manager.
Me: it’s not Scrum.
Client: in the next sprint we work on a mockup not releasable in production.
Me: it’s not Scrum.
Client: sprint backlog is changed again, at the end we must do everything that is written in the contract with that fixed amount of money.
Me: definitely not Scrum.
Client: we are using Scrum.
So my company hired this very old guy. The oldest developer I have worked with. I feel they took him just because of diversity.
Because he was absolutely incompetent.
Nothing he wrote ever worked, he got in conflict with everyone, made stupid jokes at meetings, asked the dumbest questions. His stories would hang for weeks, hopping sprint over sprint. Once he delivered something, his code had to be re-written from scratch. A code review couldn't even be applied as the code was worthless, so it just made sense to reassign his tasks to someone else and move on.
So after much drama he was let go. It was maybe two years ago and I recently connected with him on LinkedIn. He's changed four or more jobs since then. Prior to coming to our company he also job-hopped all the time (but most likely he was actually fired every time). His average job duration was like 6 months. Apart from that, he had a 20+ year stay with some government agency.
I fail to grasp how he ever gets hired anywhere with all the red flags. Over two decades with some govt agency (in my country they are all crap). Then change jobs every half an year or so. Then the asshole attitude. And finally, they probably never asked him any technical questions, because he knew nothing. Our interns who were just one month into the job were better by a WIDE margin.6
Wrote a feature that took a week plus to complete that was reviewed, approved, merged and already in production.
Guy who approved comes in and says to make changes now with 1 day to end of sprint saying to refactor stuff. It won't make a difference other than some logging changes but I found the effort to be large plus the QA would need to retest everything.
When I brought up my concern, he tells me it is very easy and to get it done.
Now am feeling so stuck rushing on this work cos he called it 'easy' and I don't want to look like a fool...
Why review and approve code only to come back last minute asking for changes.. Not the first time and always last minute followed by calling it easy. I am almost forming a phobia to merge approved code..4
I finished a story of my sprint in VueJS, which is new to me, with occasional help from colleague A. I put it through to code review, and colleague B refuses to approve it before I rebuild half the codebase of my story to improve it. In a framework I am still very much learning. The sprint ends in two days. There isn't enough coffee for this. Fml. Help.9
The company I work at sends their developers out to other companies to help them work on projects and help them in other ways (advice when communicating to customers of on demand software for example).
While not on a project you are working in house training trainees and interns. Part of that is teaching them to show initiative and treating them as full developers. The 30 interns all discussed a git flow and code format.
During the third sprint (two weeks sprints) a team messaged me if I wanted to check their merge request for the sprint.
It took me a glance at the first file to know they didnt do any review themselves. I used my flywheel to check all their changes and without being able to read the code I saw indentation was all over the place, inconsistent bracket placements etc. I let them know I wouldnt check their code until it was according to their own standards.
Two days later I got the message to check it again. At first glance the indentation was fine so I started reading the code. Every single thing was hardcoded, not made to support mobile (or any resolution other than 1920×1080).
A week later they improved it and still not good. Gave them a few pointers like I would for any colleague and off they went to fix things. The code became worse and indentation was all over the place.
I told them the next time it shouldnt be a quick glance to be able to reject it again. By this time other teams came to me asking why it wasnt merged yet and I explained it to them. One of the teams couldnt do anything u til this was merged so I told them to implement it themselves. I was surprised that 4 teams came to me asking about a merge request, that was every team except the team whose pull request it was.
4 weeks after the intitial sprint the other team made a merge request and I had three small comments and then an hour later it was merged.
The other team messaged me why their merge request did went through (still havent seen any of their team in person, Im sitting 10 meters away from them behind a wall)
They also said that it was easier for them because they started from scratch. Thats when I called them in to discuss it all and if they were not interns but full time developers they would have been fired. I told them communication is key and that if you dont understand something you come in person to ask about it. They all knew I like teaching and have the patience to explain a single thing ten times, but the initiative should be theirs.
One of the team members is my current coworker and he learned his lesson by that. The others stopped with their study and started doing something completely else.
Merge request is open for 4 weeks, in the end another team started from scratch and finished it within a week. The original team didnt ask me questions or come to me in person, where other teams did.
DISCLAIMER: some of you might find it harsh, but in our experience it works the best for teaching and we know when people don't dare to ask questions and we help them in that too. It's all about the soft skills at our company.4
When your sprint review is turned into a 5 hour argument about how to effectively do scrum and all you want to do is code.1
Biggest teamwork fail? This is the general way we do business where I work right now:
My boss didn’t want to be the kind who hovers, always micromanaging. He also hates the idea of taking programmers away from their work for meetings. Sounds great, right? This has resulted in:
• All non-lead devs being excluded from all meetings other than scrum (including sprint planning and review meetings). Nobody ever knows what the hell is going on. They don’t think we “need to know.” This means most of our day is spent trying to figure out what needs to be done, rather than getting anything done.
• Our remote boss making dozens of important decisions about our platform, never telling us, and blaming us for not forcing our lead to be more communicative.
• Pull requests staying open for weeks, sometimes months, because nobody has definitively decided what version we’re actually supposed to be working on. This means our base branch could be any of them, and it means PRs that have been opened too long need to be closed, updated, and re-opened on the false promise of someone actually looking at it.
Just ranting here... but I think our biggest teamwork fail is happening right now, with all of those things ^3
When the PO asks for a last second code change right before the sprint review, and now it's your turn to demo2
Just came back from vaccation yesterday. During sprint retrospective today I hear my team was having trouble dealing with the API layer (which was mostly written by me). Suggestion was a session where I sit and explain the application to the team ,which I have no problem with.
One of my teammates asserts that it's written in such a way that "only the person who wrote it can modify it".
Agree to disagree but whatever. This thing goes through code review everytime I push changes to it. If there was a problem I don't know why he's just discovering it 6 months into the project. I assure you there's no rocket surgery going on. The problem is that I have been doing everything on that side of the project and nobody was curious enough to give it a read sometime. In fact I dont think anything needed to change while I was on vacation, they just didn't have me to troubleshoot every problem for them like usual 😤
Currently I feel like the personification of the term "thrown into cold water"
After I finished my bachelors degree, I started working on first of april. The first full-time job I had. Therefore I had some training in the first 2 weeks and after that I joined a project after easter. Fast forward two sprints:
Currently I am the only dev in that project, tomorrow is sprint review with the clients and I have to present like 5 tickets of the 10 planned for this sprint. Of my 8 working hours a day, 4 are planned for my self-training and 4 for tickets. Actually its more like 6 for training/reading/understanding the code, because its mostly a whole CRM I am supposed to develop... PM said another dev will join the project in one or two weeks. I hope the client didn't slay me till then..2
So the company decided to go agile. I am now a scrum master. And we have the local product owners and all. They made us do daily stand-ups.
I don't know what is a scrum master. Nobody knows what the hell is a stand-up. It seems to be an akward 30 minutes every day, when local product owner asks questions and demands status reports.
I did some googling and it seems that the scrum master is supposed to just support the team and solve problems. In our version the scrum master finds out the system architecture and requirements, fills the backlog, does the system design and reports to the project manager(s). Also reports to the clients about the general project status in an executive meetings. I also do the sprint planning, in which we fit the vague features that we are told into time tables with ready told dates.
Oh yeah, the team is just 2 guys. One of them is me. And the other guy relies completely on me to daily tell what to do, review the work and also answer all the project and company level questions that pop into his mind. He gets angry if he doesn't receive ready-thought solutions to all problems, since "you're the boss and it's your job to tell us what to do".
This is going to be a great year.4
Management in big corp I collaborate with has decided they want intermediate releases every 4 weeks. That's kinda OK, we work in two week Scrum sprints.
However, not this sprint. Because of Easter it's three weeks. And because the 4 weeks rule is absolute, the one after that is only one week. Which implies we do the whole review-presentation-planning ceremony twice in a row. That's fucking absurd. But when management agrees on a plan, it's reality that needs to comply, right? Argh.2
Been on a fairly large project for the past two months. Been getting more and more productive and confident with each sprint! Always informed that I’m doing fine. Left a four hour task in progress for a day or so while tending to a PR which had been pending for a week and a half and was currently under review. Removed from the project due to issues with velocity.1
I am pissed at the way the our current SDLC is happening . i have been giving builds every 2 or 3 days since last week and their have been no major bugs. but just today, thursday, a day before final build, we get a million bugs, most of which are as follows, alongside my inner thoughts:
- requirement changes : "The design showed that there is a new ui for textbox, it didn't showed how much lines should it take. I am not an idiot to change it to 1 instead of 2 from the old design, out of my own mind QA karen!"
- lack of requirement understanding of the requirement : "Dear QA dave, I made the code using same ticket that you used for testing. how come i understood and made it and you couldn't? Why should you be asking me about this and not the PM?"
- lack of understanding of old behavior: "Dear QA dave, I spend fucking 2 days licking the boots of seniors to understand how the code work. I had just 3 days to provide first build. you had 7 days to understand the story. you should have licked someone's dick too to understand the story!
- miscommunication: "Deary karen. i appreciate your female balls to get even the story changed , even though you are a QA and not PM, and the way you did it oh so strongly by calling me 2 hours after the office hours with PM kim in the meeting. I will gladly do the changes now you got so many witnesses. but its not my fucking job to inform other devs to make changes. you or kim should be doing that and informing ios/web/embedded or all the fucking townhall !"
- bugs from old code: "dear karen, that's very nice of you to revisit old code and suddenly find a bug. but keep in mind that yours and dave's stupidity has also causes my ticket numbers to flood. I have to identify the valid bugs out of these, comment on your stupid shit , break out of all the current logics and stuff running in my mind in regards to current sprint and then i could look into this"
- reporting same bug again and again : "Deary karen. that's a very good thing that you caught an already known bug , clappings!! but we have said it once and we will say it again: if you wanna get it fixed, keep it for 1 particular sprint where i will be focusing on researching the root cause and possible solution. if i couldn't , then fuck this bug. STOP acting like a sales person trying to reach your targets by raising stupid shit as bug , before the release"
- lack of better testing and validation of code before merging: Dear TL John ,I respect you as the most awesome, reliable person of this ... company. you have been in this game for years before i even got my computer. i am just a humble out of school guy in front of you, with a tiny inch of knowledge. I took all the knowledge from you regarding the code, but i may have missed some paritcular thing, that you already would know.then why are you not mentioning those in review? even I, the guy with just an year of experience building apps, will politely inform you that you missed setting a fallback image while making this call, but you won' tell me that i missed updating my list somewhere? are you trying to intentionally get me into QA's shit??
- someone else's bugs on me: ugh.. senior bro randy... you seem so calm, and i always have peace when we are both working on some stuff. but why the hell team tries to discuss your bugs with me? can't you jump in even after i try to tag you a million times? and once again dear TL john, I am making PR to randy, not vice versa. i don't know any shit he added in code, don't think i can handle his bugs when he is celebrating holiday for their local festival . even you would know more as you reviewed both of our codes as a single branch before merging.
Now if i have to play blame games , i can easily point 1 finger at our QA team, 1 finger at our reviewer and remaining fingers at myself for getting into this situation. But I am lowly junior fresher dev who just started seeing decent money for the first time in life.
So instead i yield and show up my bare ass to them to fuck and make me sit on laptop for 14-15 hours even after the office hours10
I just got an email from the project manager:
Please make sure to review the 7/12 sprint requests for (x project). Please add your estimates even if the requirements are ambiguous. Thank you."3
Context: This team has been constantly behind on deliveries, ignoring advice from other teams or more experienced colleague, making mistake after mistake and now, just revealed they have major performance issues, as warned...
So, in the most recent Sprint review they were, once again, criticized for their bad approach and inability as a team to receive feedback and work on that feedback, resulting in mediocre development...
As I left the room I heard one of them say:
"We make this huge rocket that most wouldn't be capable of doing and they cry that it's blue and not green... Others make a ls on a command line and everybody applauds"
Now, this is for everyone to whom the shoe fits...
Listen here you little entitled snotty prick, where do you think you are!? Yes most should not make a rocket when the requirement was a bike! That's overengineering and besides that most of your decisions were arguably wrong!
I will never applaud you or anyone else for doing your fucking job and being mediocre about it... What we applaud is value added! Value to the project, to the process or to the team... Bring value and I will applaud, do your job and you get a salary. Be a snotty childish dipshit and you might find yourself forcefully searching for new professional challenge!
I fucking hate 1 week sprints that include review, planning, and retrospective, so technically the sprint is 4 days.1
Long story ahead
I recently started a job in a smallish startup doing web development in a mostly js stack as an entry-junior engineer/dev. I’m the only person actively working on our internal tools as my Lead Engineer (the only other in house dev) is working on other stuff.
Now I was given a two week sprint to rebuild a portion of our legacy internal app from angular 1.2 with material-ui looking components with no psd’s or cut-outs of any kind to a React and bootstrap ui for the front end and convert our .net API routes into Node.js ones. I had to build the API routes, SQL queries (as there were plenty of changes and reiterations that I had to go through to get the exact data I needed to display), and front end. I worked from 9am until 11pm every day for those two weeks including weekends as our company has a huge show this upcoming week.
I finish up this past sunday and push to our staging environment. The UI is 5.5/10 as we’re changing all of our styling to bootstrap and I’m no ui expert. The api has tests and works flawlessly (tm).
So we go into code review and everything is working as expected until one tab that I made erred out and was written down as a “Needs to be fixed.”
This fix was just a null value handler that took three minutes and a push back to staging, but that wasnt before a stupendous amount of shit being flung my way for the ui not looking great and that one bug was a huge deal and that he couldnt believe it slipped through my fingers.
Honestly, I’m feeling really unmotivated to do anything else. I overworked myself for that only to be shit on for one mistake and my ui being lack-luster with no guides.
Am I being a baby about this or is this something to learn from?1
me:task assigned is a small fix.Gonna finish Early sit back relax this sprint.
mail(next day):we've moved to microservices.setup as easy as gulp landscape:start
me:cool!shinny new stuff!seems easy!!
project:npm failed..please check module xxx..
after long mail chain
project:npm failed unknown file not found
after hours of googling and little github issue browsing
project:server running @ portxxx
me:yay finally happy life!!makes chnages, sent for review.
reviewer:code needs refactoring!!
me:make all changes..waits for faceless reviewer from another timezone!
me:i will make it in time!!!yes!!
me:no still i wont give up...
debug finds out new bugs caused by unrelated code...make new PR the end is near,one day more will definitely merge!!!
mail:jenkins down for maintenance!
me:nooooo....waits till last minute gets thumbs up for merge, finally merged in the last second!!
all for 12 lines of code change.
Having a meeting to decide, when to have other meetings...
Scrum, scrum of scrums, workstream, planning, pm ,design review, architecture review, Sprint review on and on....on and on on...why can't i simply code:(4
So we had a sprint review earlier. There were like 20 bosses who attended, head of this, head of that. We spent 5 mins to demo our application, and another 55 minutes discussing the "delivery date" 🤯2
Had a four hour retro/review yesterday. Plus a mini demo I had to put together. Three hour sprint planning session today.
And they still wanted me to go to some "company values" meeting tomorrow, aside from the weekly call I have to report progress. Fuck that shit.
I feel like I got nothing done this week. Monday and Tuesday were fine for the most part, but since it's been just complete idling.
I mean, I love my company, great coworkers, good management, and just all around great experience. But man, it gets frustrating when you lose so much development time... I wanted to sprinkle in some extra goodies for the next sprint, but it doesn't look like that's gonna happen.2
Demo driven development.
Did a simple search for TODO Statements in the code and almost fucking spilt my coffee.
And the best part, they will demo most of this in Sprint review as done.. WTF.
Done means "Ready to Release" not "Ready to Demo".2
Estimates.. First, part of the team makes "high-level" estimates which are based on informal, incomplete, still-evolving specs and an unstable back-end. The project people report the estimates to the client and elevate the status of these inaccurate estimates to that of commitments.
Then, before the "sprint", we review our initial estimates *ahum commitments* in greater (technical) detail. Because there are still a lot of unknowns, we tend to estimate more buffer here (back-end is often not ready, always ping-pong between project people and dev-team about unclear specs, more work than originally expected, and often late modifications to the original spec).
When an estimate becomes more than 50% extra time at the "refinement", we are told: "sorry, we gotta do it in less" and when it doesn't work out, we're kindly asked to spend part of our weekend catching up at 100% pay rate (legally it's 150-200%).
FUCK THIS SHIT
*quotes used abundantly because these terms belong to "agile/scrum" terminology but we're only pretending
Meetings have the ability to slow you down like nothing else. The moment you feel you are about to crack the problem you have been working on.. ding! there comes a notification for the next meeting.
Currently my team has a mid sprint review meeting, an end sprint meeting, a let's plan the next sprint meeting, a team meeting, but the one I have absolute hatred for are daily standups.1
So I was reading Scrum for my exam all I can see was Meeting.
Product backlog meeting for 15 mins;
Enters to the office 5 mins meeting;
Sprint review meeting for 10mins;
Daily scrum 2 times meetings;
Sprint planning 3 hours of meeting;
Starting the next Sprint 30mins meetings;
Managing releases 45 min meeting;
Sprint Retrospective 45 mins of meeting;
Wtf? Do they do any work there?4
Mid hackathon reviews.
It kills the excitement that a judge might have seeing the thing for the first time in the final review.
Instead the final review becomes - "Hey, what did you improve from the last time?"
**Its not a fucking sprint**1
What is wrong with these people!!!
Last minute changes are pain in the ass... the design team review gives a go ahead but then pm team doesnt agree and and you have to get the changes suggested done in a day??!!!
In half a day you have to get ux review, peer review, module owner review, architect review, pm review and then merge publish bump and test in ci?!!end of sprint is today...
Ugh!!!every sprint!!every fuckin sprint!!!
I hate so much all those sprint related meetings. They literally take one day totalled (every 2 weeks).
Review, dry run demo, actual demo, planning, daily hourly meetings.... so much talking.8
Group project at uni, we're learning how to do scrum sprints. So here's a small story about all the ways it can go wrong.
We assign scrum master and product owner roles, what do those do? "We want to do design tho" they say two weeks later.
I end up doing the organization part and structuring the backlog.
"Alright, you guys will be the frontend team, your tasks are X and Y"
One day before the review I ask again
"So, what's the status" (well knowing that they didn't do shit so far)
They start scrambling around, and manage to do like 30% of their tasks at best, I end up doing most of the work for them.
Next week, new sprint, our tutors somehow don't notice that literally 95% of the code has been written by me so far.
"Alright team, hopefully you will do better this time, so and so will be your subteam leader since he knows this stuff"
Some guys start working on independent things without collaborating with each other, sometimes replicating stuff I already did (but obviously worse).
So that's the situation so far, I really would rather kill myself than keep working with these guys, jeeesus1
How does your organisation and team balance PR comments demanding changes and dev time?
Here, while fixing PR comments we sometimes end up wasting as much time as we took in actually developing the feature... As a result, almost every major user story overshoots the estimation and almost every sprint gets delayed.
Yes, to each his own; but talking in general, why do you think this time wasting happens?
Do you think that happens because some of us are not as experienced as the others, the existing code not being up to the mark giving a bad example, or just a skewed review process?2
Why do they demand 12-month goals when we use Agile Methodologies?
If we do it right, we don't know what we are working on next sprint, let alone 12 months.
Our goals are to work on the highest priority stories. We are not to work on stuff "in the background", so how can we have any long-term goals?
The only things we can plan are outside of our actual jobs (like conferences, training, pilot programs/hackathon projects, etc.) So the only things we can review at the end of the year are not the most important things we do.
Poor managers love numbers and checklists to hide behind.2
Ok the sprint review is tomorrow, there are lots of work to do and qe are half slept, this gonna end well :)
I wonder if we will have a sprint review meeting for 2016. You know to prevent the shit storm that happened to continue ...