IS THIS SOFTWARE DEV? | Prime Reacts
ฝัง
- เผยแพร่เมื่อ 5 เม.ย. 2023
- Recorded live on twitch, GET IN
/ theprimeagen
Original: • Reality of Software De...
Author: @bigboxSWE ( / @bigboxswe )
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord - วิทยาศาสตร์และเทคโนโลยี
agile is a ploy at getting non technical people into the tech industry but not knowing how to code
they will pretend to know code with chatgpt soon
@@jel1951 chatgpt will replace them sooner than us hopefully
I had a PO once who ocasionally dabbled in Python scripting and so felt qualified to weigh in on how long tasks should take us. We deal with a complex web of microservices, mind you. He would often come and tell us "Hey, this task that is taking you so long. Look, I wrote this script here that does just that, and I did it in a day", and he proceeded to paste his 20 line script. Lord have mercy
Dude… we started working with a low code platform, OutSystems, because management wanted to spend less in developers and introduce „citizen developers“.
They hired a 50-60 years old person with no coding experience because they thought low code means anyone can develop apps.
Needless to say, I hate OutSystems and anything „low code / no code“.
@@Titere05 holy shit man, this so much, one of the worst situations you can be in is having anyone above you in the hierarchy that's less qualified and either too proud to see it or malicious enough to actively sabotage you as a result
We found that sprint planning is harmful not just because of how long the meetings can take, but because it makes devs feel like they aren't allowed to spend time on things they instinctively know are valuable but failed to explain in the moment of the meeting.
Man...this hits hard.
By the time I've managed to put together an explanation of the problem I'd like to address with all the background necessary, come up with well structured and convincing arguments as to why it's important, had the discussion with the team, figured out how to break it up in to tasks, decided who's going to take on each task and how we'll communicate about it, put together estimates for each task, created all the tickets....
...I could have fixed that problem and 5 others
holy crap you named it and now it's real
if only devs were disciplined enough to fill in their sprint with tasks from backlog we would not need sprint planning
@@yuriib5483 "IM IMPORTANT I HAVE INPUT HEY HEY HEY HOW ABOUT THIS HUH HUH HUH GOD HOW COULD YOU GET BY WITHOUT ME"
In my company it's not a feeling it's a command from the PO that you don't work on anything technical, even if you've already finished every "feature" ticket you had for that sprint, they command us to go fetch other "feature" tickets from future sprints if we run out of work, any technical improvement is low priority automatically and postponed for the very end of the iteration (a set of 6-8 sprints) if you've already completed every feature ticket you had by that point
If someone enters a ticket to fix some code debt it'll be in the backlog for at least a couple of months till someone can tackle it, some times it'll be a year till someone looks at it again
If I have a 1 hour break between 2 meetings, I'll get absolutely 0 work done in that 1 hour. I need to be able to get in the flow and get my focus up, having distractions like that every once in a while breaks up my thinking process and gets me out of the flow. If you're gonna force me to be in some dumb meetings, please group them together to limit the number of distractions to the minimum. Same goes for useless slack messages, completely throws me off, I'm a god damn social media addict on rehab, it's already hard enough to stop myself from going on youtube every time i open a browser, but it's in my power to do it - useless meetings and getting spammed by irrelevant messages is something I cannot do anything about.
Get some help and stop complaining. It's your fault not everyone else.
Disable Slack alerts and respond to messages with a delay, once you went to get a snack or sth. Set up a range of times where you take meetings instead of getting them all day long. If this cannot be done, then maybe speak with your manager or sth
@@wiktorwektor123 have you considered that some people are more productive under different conditions? He's not blaming anyone and neither is he psychologically unwell for saying that certain things make it harder for him to be productive. Calm your tits.
@@wiktorwektor123 might as well say the same about half of prime's videos, "complaining about js being terrible? sounds like a you problem", it's a fundamentally wrong approach, plus what i described is not to my detriment, it's to the detriment of companies that adopt such practices
anyway, miałeś zły dzień że jesteś taki negatywny? xD jeśli na nic nie narzekasz to nie możesz oczekiwać żadnych pozytywnych zmian (+it's good fun to complain), nie jest to jednoznaczne z obwinianiem innym za swoje własne niedociągnięcia albo z poddawaniem się, ja znam swoje limity i jestem w stanie sobie z nimi poradzić, dzięki za troskę xD
Agile is designed to create tiktok brains.. who have adhd and absolutely zero concentration and attention span...
im currently self-learning... and reading some "best practices" of JS frameworks.. im like... why on earth would i split up code into so micro components... jumping one file to anothert all the time , i like Vue.. but im def not using best practice because they are dumb.
if i make Navbar, the navbar will be one file... not split it up like Nav,NavGroup,NavList,NavListItem... absolute idiocy.
Im better and reading 1000 lines of code, rather than jumping thru files like crazy dog on cocaine.. i dont have adhd or consume short-form content for years... i read books...
and thats how i prefer to read code too... obviously i split up things if it makes sense...
Sprints are trash. Sprint planning lets you know how much time you spent on planning.
best statement
I hate that people mix up agile and scrum. Sprint-based is the worst way to do agile
What about that part in sprint planning when somebody asks, "Wait, so what is this supposed to do?". How am I supposed to estimate this if it just says do X? What the hell is X?
@@JohnKerbaugh We still do some backlog refinement and tech discovery when needed
@@JeyPeyyI mean... Scrum is an implementation of agile, or an attempt of it
That chad Indian teacher saved me in algorithms class
hah, he saves everyone as i have been told
what is his channel?
@em29 a same as his name, Abdul Bari
Abdul has saved everyone of us here 😂
edited comment == bunk.
if your team actually talks to each other, you can pretty much throw away 90% of "agile" things.
but that's what the actual "agile" stood for, just frequent communication with other technical members, but it got corporatized
Agile is a replacement for actual management by actual managers doing their actual job.
@@LagMasterSam if it replaces hover managers in that company then it's a good start.
@@LagMasterSam why are you wording that like thats a good thing. I'd rather have sprints/daily 5 minute bs agile meetings than having to report to some manager breathing down my neck at every turn
d^^D
My team is made entirely of engineers of different levels. Our workflow is kanban inspired. We use a kanban board, we have a daily meeting in the mornings, a weekly "backlog grooming" meeting where we flesh out upcoming work. Then there is a monthly retrospective. So far this has been my favourite team process that I've participated in.
Sounds dreamy.
@@GeneraluStelaru Yeah. Took a long time to get to this point, though (4+ years simplifying away from scrum). We used to have full-time scrum masters "supporting" the team. They were all nice people and meant well, but generally they just complicated things because they were so focused performing ceremonies.
We also benefit from being a very technical team involved in platform/infrastructure. So product managers don't get very close to us.
"My team is made entirely of engineers" - of course you don't need and don't use agile
@@tedchirvasiu We still need to plan what we are doing and still value the ability to know what work is in progress etc.
As an aside, if I remember correctly, the Agile tenants were proposed by a group of engineers. Scrum and kanban are just attempts at implementing agile.
@@Muaahaa Of course, but planning and communication between technical people is easier and smoother than between technical and non-technical people. An Agile team includes the non-technical people too.
And I don't mean it's easier because technical people are superior, just simply because there is no translation that has to happen between business logic and technical stuff.
So for instance if your team is developing a CLI tool and the team only consists of devs, things will naturally go smoother communication-wise than if your team is developing an accounting software which has to work in accordance to the laws of multiple countries.
In the second example the engineers also need to include accountants, lawyers, translators, because the knowledge needed to develop the said software goes beyond just computer science.
I work in a really small company of 3/4 people and we all fully work from home. Every morning we have a standup that can last for 10 minutes where everyone is just talking about what they're doing/gonna do that day to an hour where we have to talk about stuff that involves all of us. Before we did these stand-ups i never really knew what everyone was working on at any time, but now i feel like everyone knows what's going on a lot better
I actually feel like I am getting a lot of value from these meetings and it made work a lot nicer.
I have a similar experience, I think it could be a lot more efficient from a meetings perspective but I've gotten tons of value from it
We started doing those meetings in text messages in slack. Each morning when we got to work we would write what we were gonna do this day, tag the people if it concerned them or you needed their input, and if needed a discussions would start in a thread under each message.
At the end of the work day each of us would write what was done. We would go on calls only if it was needed, for example you need help with something or if messaging would actually be slower. If we needed to do any meetings we would plan them first thing in the morning and get them out of the way, or move them to the end of the work day.
It was extremely productive environment. You would know what everyone was working on, after you read the messages in the morning you could give input on something that the other person didn't know and save them time, and throughout the day we would sync up through messages again, each in their own time so to not break focus. The team was in sync and very efficient.
We do something similar. A 10-30 minute standup every morning for 5 of us. I think it’s really helpful for everyone to have an idea what everyone else is working on. As a new hire, it has also let me get a good picture for how things work.
That's the ideal form of standup from my understanding. But once management gets involved it goes downhill. My company has a bloated dev team, manual testers, and ~3 manager-types all in standup. It's a miracle that we can keep it below 30 minutes. But at that point it's less about benefiting the devs and more about pleasing managers, sadly.
Also its quite Nice being able to talk about purerly dev things with someone, whats more efficient etc..
this video made me feel a little coconut oily
edit: thank you so much prime, I gasped when I saw this, huge fan and will forever be thankful to you for being my inspiration to create content and become a better dev
10 years of agile. I'm like WTF is this? My kids plan their 2 weeks better.
Dude, it's unbelievable. Those SCRUM guys don't even read their own process spec. 90% of the rituals are hallucinated 😂😂😂
Yes, it's pretty spot on. Deep in the bowels of the scrum factory, strange smells of burnt oil and piles of ruined time everywhere.
everywhere
I used to work in a small team of 5 people and we had a manager who would once a week give us the goals and let us brainstorm for solutions. It wasn't perfect but I had leeway and could focus on my work.
Then the company went to "restructuring" and our team consisted of me and a front-dev. We got a new manager and unlike the previous one, he insisted on having dailys, writing tasks on jira (and subtasks to those tasks) for every single thing, even for things like reading documentation and writing confluences, all with time estimates (yes, even the subtasks)!
My productivity plummeted. I would work 30% of the time, 60% be on meetings and the rest to try to refresh and come back to work. Our new manager didn't know much about the system we were developing and I was the only one left who understood and maintained the code (the other guy worked only on the front-end) so I had hours of meetings where I'd explain to him everything over and over, all of this while we were supposed to work on productization. I was given tasks that I wasn't supposed to have that revolved around DevOps and permissions (which I naturally didn't have). Management would make decisions without any consultation with us and frequently change them because they weren't close enough to the source material.
To try to "balance" the work load between me and the front-dev, I was given front-end work with React and the other guy had to learn the whole backend and microservices. Code reviews were me explaining code rather than being reviewed. I felt like a tutor rather than an engineer and now I'm looking for a new job...
They failed you.
When you said, it was you explaining the code, at that point they should have promoted you, and hire someone else, so you can be the tech lead.
Actually you sound like you were doing much of the tech lead stuff, but without the payment of a tech lead and the authorization of a tech lead.
That sucks, I'm glad you're not there anymore, I hope you got a job already.
Scrum is literally opposite to what agile is supposed to be.
Agility: “Individuals and interactions over processes and tools”
Scrum: “lets design processes, and host of tools (Jira 💀) to increase development speed.”
agility: “Working software over comprehensive documentation”
Scrum: “Lets have people have to painstakingly document *what* are they doing, *why* are they doing it, and *how* are they doing it. Let’s also define stupid templates and rules about how all this documentation should be written, because they’ll work better if we have them writing in prose instead of bullet points.”
agility: “Customer collaboration over contract negotiation”
Scrum:”Let’s create a figurehead (PO) so that *not a single developer* ever meets a client.”
agility: “Responding to change over following a plan”
Scrum: “Let’s create an artificial 2-3 weeks interval that will delay our ability to respond to changes, but will supposedly help us create metrics to *plan* the rest of the project”
The fact that people in management positions are shown the agile manifesto in trainings about Scrum and can’t see how the two can’t be more different is amazing.
"The Scrum Team [(Devs, PO, SM)] presents the results of their work to key stakeholders and progress toward the Product Goal is discussed." - Scrum Guide
"The Scrum Team [(Devs, PO, SM)] and its stakeholders inspect the results and adjust for the next Sprint." - Scrum Guide
-> communication between stakeholders and dev team is recommended!
Thank you @ondono for making this comment
Jesus! None of how you described scrum is anything like how scrum is described in the original source material for Scrum. If that has been your experience with what people are telling you what "scrum" is, then you have been lied to your whole career.
It's standard practice. Over my career I've seen the original OO analysis and design (in an iterative loop), then agile, both be adopted by companies that sell training (and crucially certification) - and its these people who seem to suck all the good ideas out in the interest of producing a standard process for development.
And we now know why the people who get into these positions get into these positions. They don't question. They mindlessly pretend to be busy.
Sprint planning is the dumbest thing. I hate the long meetings because someone always has to say something extra.
EVERY TIME
@@ThePrimeTimeagen then you have management that doesn't understand you're doing six other things. "How long do you think this is going to take?" I don't know Bob, about as long as I need it to take because I'm doing other shit too.
JQuery starting everything with a dollar sign, so prophetic.
Php knocks on the door…
In my experience Scrum meetings work the best on small teams. Having worked on a team of 30 Dev's, they basically were just a waste of time and all you were really listening for was your name to give your status update and they often lasted over 30 minutes. Questions rarely ever got answered and people rarely offered help. On my current team of 5 dev's theyre actually very productive and have saved our development team significant amounts of time.
True, meetings where everyone shares fundamentally don't scale. As soon as there's more going on on a team than everyone can mentally track or nobody is working on related tasks, it devolves into a frustrating time waster. Thankfully, my scrum meetings usually last 5-15 minutes because my current team is small and sane.
I don't think a team of 30 devs work well with literally anything lol.
that 30 people team should've been 6 or 7 teams instead
Well Scrum teams never meant to be big. Up to 10 people is max.
o.O 30 people ??? We ain't having so many. 4-8 people is the sweetspot. If it's less then 4 than just talk to each other no point in making specific meetings. If it's more then 8 you probably wasting the time of a lot of people as they can't contribute to the problem.
Step 1 to becoming a chad lead: get your food passed to you
facts
When I was at Amazon I got absolutely bricked by meetings like this. The day was for discussing the work to be done at night 😞.
so every big tech companies are like this? Just saw that video on Primeagen channel about a guy who did 400k/year in Google, he mentioned only 2 meetings per week as I recall 🤔
Wait that's nowhere near enough meetings. I just took a look into my calendar and I have sprint planning, sprint review, prep for sprint review, sprint retrospective, backlog refinement, stand up, catch up with manager
cross team dependency meetings (actually occasionally useful), and technical refinement (which we sometimes skip if we don't have anything making it the most useful meeting). I will often end up putting less than half my day down as actual development. I could also probably 1.5x to 2x the amount of time spent in meetings if I didn't skip all the optional ones.
And don't even get me started on the multiple solid days of quarterly meetings that we just had.
aww, you guys don't use the phrase "grooming" instead of "backlog refinement" ? lol
My experience with agile was way worse on a large team. Now that work for small business which is understaffed agile actually makes sense. The meetings only work when people are on the same page. As soon as someone is behind it becomes a nightmare.
i can totally see this. i definitely think there is a continuum of agile and its goodness vs its badness
Agile is essentially for start-ups. Enterprise wan to be "on the edge" and sell their customers they are doing agile with CD/CI etc. And then they com up with monsters like SAFE. Enterprise never will be fully agile as they are not willing to change their structure with number of useless business overwhelming roles.
Even the name "agile" doesn't fit at that point; "agile" implies light and flexible, not exactly how one would describe a large team
@@nieczerwonySAFE is the absolute worst! Holy crap it's so bad!
@@thebluriam Yeah. It's f****g disaster.
This is why I love my job. No manager standing over me, no meetings except once a week for an hour to discuss and show what we've done, and complete autonomy to do what we want. We have the mentality of you build it, you own it. We manage our own tickets in creating them as well as picking which ones to work on. We get to do it all. Add new features, fix bugs, etc. Front end and back end, doesn't matter, when we are working we do it all. Small team of 3, and it works beautifully. No micro management, no breathing down our necks, no hard deadlines or sprints. We have a Kansan board, but that's it. No scrum master, no daily stand ups. We are all experienced and are left to make our own choices on what we think is best. We get general direction like let's work on this new feature this year at some point but that's about it. So glad I don't have to deal with the BS of larger companies and red tape over best practices.
This vid could have been a 4 line mail.
To avoid overengineering my code, I don't engineer it at all and just yolo
The dr disrespect of the coding community 💯
For real, even looks like him
My company does 5 meetings:
1. Backlog Refinement - are we building the right thing/what tickets do we need to build the right thing/how many points
2. Sprint Retro - talk about your feels
3. Sprint Review - demo work to stakeholders
4. Sprint Planning - Literally the same as backlog refinement except you get assigned the tickets
5. Standup - blab about blockers and stuff
Scrum: Let's implement top down micromanagement in such a way that it is both maximally annoying and distracting, while being soul crushingly two-faced and hypocritical, while somehow also removing any possible strength of top down control by removing any responsibility from those up the chain to actually provide any written/formal planning so they can minimize their organizational responsibility.
I hate "proper" agile so hard. I was in a team were I was able to build a prototype with 2 colleagues in about 2 years which is now actually integrated in our core product. We planned stuff before of course, but in the sense of sponteanous calls to discuss the direction, defining basically stuff just on course grain story level and everybody was free to implement it how he wanted. All of us were ultra motivated and we pushed way beyond what should have been possible in this time. It was awesome, it was full of passion, it was fun, we did incredible progress too. We used of course our coding guidelines, code reviews and all the stuff which actually makes sense. Now we are integrated in a bigger team to transition our code to the core processes and end up having refinement meetings to discuss if a property's name abbreviation is justifyable or not and spend 15min on such a stupid topic with 7 people. And those meetings take up to 3h. It really hurts to work this way. It feels like I'm walking without feet
It's completely nonsensical.
At some point, they should just promote seniors so they can be the code reviewers and Pm/tech leads.
Agile makes no sense implemented that way, and a proper developer is able to make his own features in a maintainable way.
Reviewers and PM can give a direct feedback of why certain feature wasn't accepted.
It's really easy, to follow Kanban honestly, but some project managers are micromanager maniacs
this hits so close to home, like honestly i get excited when there is a critical big in prod or something cuz i get to do something unscripted and unmanaged in a milion meetings
geez... that hurts my soul to hear this! honestly, i love the mentality, the desire to do rather than to talk.
@@ThePrimeTimeagen yeah, like im a software engineer let me do the engineering mr. manager god damn it xD
This hits close to another thing that bothers me, that the more senior you are, the more bs you deal with and the less you code. It's like owning a football club and putting your best players to tend to the grass instead of playing. F**k that!
We don't do agile at work but do have daily standups that usually last 10-20 mins, which usually i don't mind, people flag up what they're working on, if someone's stuck they explain the issue and 9 times out of 10 one of the more senior guys on the team jumps in and says hey i think i know what to do, let's call after meeting etc.
I like stand ups. I like knowing what other people are doing in their work life. I don’t have any experience of people chit chatting about their private life in a standup. Sounds like a management problem
best part of planning is when you want the project to take half of time, you add another guy and it takes double the time :)))
nobody remembers the Mythical Man Month anymore, much less reads it
At my previous job I had 10 to 20 hours of meetings a week. God, I'm so glad I quit. We had two standups per day. TWO standups. I think I have a PTSD.
While my team lead was on holiday, I did away with estimation in plannings because it's useless for us. New requirements are added at least twice a week, changing the sprint scope, and my team doesn't really take estimation seriously (probably realized it's useless). So now we just look at the upccoming backlog and discuss what each task implies, so that everyone's on the same page. If a task seems too big we split it into subtasks. And that's it, no estimation effort other than splitting complex tasks. We're all happier for it, and we've been working exactly as we worked before, so the refactor was successful lol
Edit: Whether all tasks are finished or not by the end of the sprint has no impact on us, it doesn't matter as long as we hit the quarter objectives. I think kanban would be a better fit for us but corporate wants scrum because they read it was cool. We don't even do retros though
I work in a company where we do 100% remote work. We pretend to be in an office using a discord channel. And the truth is that for me, daily is very important. But not because it makes us more "agile" but because it is the closest thing to having a coffee with colleagues before starting to work. The most important benefit for me is that human interaction because (for better or worse) the whole team has become friends. So, it's nice. So... Many times it is just that, social interaction but when there is a blocker it is useful to discuss and plan how we are going to solve the problem. I understand that for some teams it's not a pleasant experience because they feel like they're wasting time or something like that. I guess it varies a lot depending on the values inculcated by the company where you work.
You don't need to go into an office to meet up with coworkers. You can have people over to your place or meet somewhere more interesting and accessible.
I feel the same way about daily scrums at my company.
Friends, or friendly?
Do you hang out in your free time voluntarily / non-job related? If so - that's nice, don't get me wrong. I just don't see being good acquaintances at work and being friends outside work as the same.
Very often workplace friends are not really your friends, it makes sense to be on friendly terms with them but very few will even keep in touch after you quit. I think having social interaction is great, but standup meetings are usually terrible because they're too formal and have a structure of a report, they're not a conversation. Instead, you can simply talk with your colleagues when having regular calls with them. If your team is small and your standup meeting is more of a catch-up, it's simply not a standup meeting.
@@DMSBrian24 Agree big time. Every second friday my team goes to the office and meet up. It's a bit more of an informal day, used for planning the next sprint and meetings with cross-cutting concerns (gamedev, so there's plenty of those).
Besides that, there's also just.. getting a coffee with people, asking if people want to go for a walk (if at office) or arranging breakfast together at the office and such things. Those all require intent and consent for the social nature of those arrangement. (can join breakfast just for a cup of coffee too!)
I'll not that I say consent not because I'm big on all the discussions around those these times, but because it just makes the situation a lot more natural, and people less misaligned on what the value of those meetings are. Sitting in meetings out of politeness is common, even when there's no reason for the person to stay around any longer, and so is people being frustrated about that over time. Some banter here and there doesn't hurt, but damnit sometimes you just want to get work done - and if a team of 5+ engineers all "sometimes" just want the meeting to be over to get work done, odds are, there'll be someone in nearly every meeting feeling like their time is being wasted.
In a medium sized software company I think the daily standup can be necessary to force people to voice their roadblocks and emergencies in production. Things a company the size of Netflix might boot deal with as much.
If the team is mostly self-managed it’s a nice way of splitting up features which could potentially take months to finish. Also 3 week sprints seems like a nice balance. I also like standups.
that is fine,
long as there isn't a bunch of standups :)
at my last 2 jobs we'd play games.. sounds fun.. it's not
Our team does 2-week sprints and daily "stand ups", but the standsups are just in written form in a slack channel. Works very well.
We get a lot of leeway though - if something planned for one sprint turns out to take longer, it just takes longer. If something gets done faster, we don't dally around, we start working on what's preliminarily in our next sprint (or prioritize issues that have cropped up during the sprint).
Essentially, I guess we're really doing something best described as "2+2" sprints, where the first two weeks are well-laid out, and the second two weeks are less laid out, and then there's the backlog.. :)
3 week sprints sounds like it could be nice, but with its own challenges in coordination.
@@ThePrimeTimeagen I hate standups, too, and I'm in manufacturing... not a Developer lol (WIP... goals, dreams yadda-yadda). And that shit about the Dog? *Fucking, nailed it*. 15 minute mandatory meeting every day at the start of shift... just to listen to a 5 minute summary of two emails we've had for weeks repeated over and over again... then 10+ minutes of our Supe bitching about her kids, whining about how we make her look bad to her boss... or "subtly" bragging about her new benz.
A+
Working in a company with 25+ Devs on our warehouse management systems (controlling real warehouses) in C#.
We don't do agile. We got 2 meetings a week, between 20-40min to get updates on the progress of important stuff. Like the team currently working on the processes to handle goods that can't go on our automated conveyor system ect. because it's the next thing we are contractually obligated to finish (milestone). And only first in broad stokes, the people relevant to a more detailed discussion stay, the rest goes and does their job. Meetings are in MS Teams most of the time so you can do other stuff while listening.
We also only use a Kanban Board (Jira + Confluence + Azure) and tickets get primarily created by senior Devs, but everyone can create Tickets with stuff that has to get done if they notice something. And time estimations are suggestions and nobody cares basically.
I think this is a good compromise.
I work for a smaller company and one of the hardest things I encounted is estimates. Sometimes I will get very little information to work with and it's one of those things I will know once I get into it. Sometimes I feel like I am being asked how long it's going to take me to run this marathon but the length of the marathon is unknown. Usually it's a 20 mile run with an expected completion of 20 minutes (metaphor people... metaphor)
This has always been my issue with agile.. estimation is almost impossible to do when dealing with a relatively complex project
We have to connect to a new API from the team X. The team hasn't decided yet what the API does or why they are building it, but we will integrate it on our system, how much effort will it be?
Just overexaggerate your estimates. Imagine the worst case scenario and say x2 of that for a time estimate when asked. Usually you can say "I don't know" in smaller companies though.
@@adriangodoy4610 something like that lol. I can't be too specific due to contracts lol. Hell this post if seen by wrong person could get me fired maybe lololol
@@twothreeoneoneseventwoonefour5 The Montgomery Scott method of project management. "How else are you going to keep your reputation as a miracle worker?"
I think most people are doing agile wrong... it should not be a step-by-step guide of what to do, but rather like a template that is changed to fit the team's needs. Take what makes sense and works for the team, continually improve on it and ditch all the rest. In my current dev team, we gave up estimating tasks and planning sprints. We kept standups and retrospective meetings (1 per month) plus a bi-weekly catch-up meeting with the team lead. In addition, we also have a bi-weekly meeting with the product owner and other interested parties. All meetings (besides standup) are planned for up to 1h but can be shorter. And standups are for fucking relevant topics and up to 15 min! Talk about your cute dog after the official part, if anybody is interested...
agile IS wrong
Except whenever you say I don't want planning or standups or retrospectives or demos you get shut down
I think people are doing communism wrong. See, communism is not wrong, it is just that one have implemented real communism yet.
My understanding of Agile is that it's SUPPOSED to break down large work into sprint-sized featuring which can be reviewed to say "Yes we're on track" or "No what we're doing isn't working." In terms of product lifecycle it's basically a form of Cyclic Development where you're limiting your resource investment while you have low certainty on the value of what you're creating.
So... it follows that for anything which has high certainty or which already requires basically no resource investment, you shouldn't be using Agile. Instead, if it's high certainty you should be making the process standardized with time estimates so you know how many people are needed to get it done in X time period, and if it's low resource people should just go do it.
@@williamfish1407 Well yeah that's the problem, companies don't run it right.
it's like hearing that salads make you healthier, so you start eating salads with a bunch of fatty dressing on it. Then you don't lose any weight at all, but still love to tell people about how you're totally dieting and living healthy.
That's what they do with "agile" they love claiming the buzzword but hate actually implementing it properly.
Honestly following the cadence of Agile is pretty good when sprints are long enough to deliver, I mean it works because it gives you rituality with the given weekly meetings, daily standups and biweekly releases.
The only main meeting is when you're meeting with a business user that is detailing out the feature that they want, and you can go back and forth with them. Its something a BA is supposed to do, but since half the BAs usually have no technical experience to get enough detail and what questions to ask about the product in question about, and what's needed to code for it. Active senior devs make much better BAs in my experience.
I'm usually fine with standups, because then I can actually bring up the most important stuff with managers / etc and making sure that items are in their focus that I need from them. Things in Emails from my experience can get lost, and there's a lot of places that are already too inundated with emails.
i wonder if we can compile ts/js .map() .filter() .forEach(). .sort() etc to 0 cost abstractions, like not aim for smaller bundle size but performance
We do agile and we have sprint-planning, (no dailys) and a retrospective (30mins) every two weeks. We are a team of 8 and it works beautifully. It's a minimal implementation and allows us to take a step back every 2 weeks from the low level implementation and decide what bigger feature/improvement/maintenance etc we want to implement in the next sprint. It gives us organisation and direction. IMO you have to make Agile work for you and really be aware of the pitfalls. Our team performs better now with this version of Agile than it did before when we had very little structure.
As engineering manager for about 6 years, I’ve learned to take simple approach of asking the Devs what they need and most my job is really dealing with the PM and upstream folks to not waste the devs time. Devs need clarity on business logic and priorities sometimes,but doesn’t require set in stone process or rituals. Usually when Devs “get” the requirements more fully they need very little from me. Velocity points, 2 week sprints, overly verbose Trello cards I’ve found don’t help output. Giving holistic view of what’s going on and then helping with specifics as needed does.
Periodic meetings are kind of fun.
Instead of doing any actual work you try to come up with an excuse of why the thing that should have taken 20 minutes of prompt engineering will now take 16 work hours and 15 "quick" meetings with other team members that will stretch to 2 hours each.
I had a co-worker who explained that the value of agile is that it lets Management know what developers are working on, so when the Pointy-Haired guy comes in and says "I just had a brief idea! You should work on this!" or "Oh, crap, Production crashed, what do we do now?" You can say "I'm working on this; if you switch me to that, this will necessarily be delayed" -- so that developers don't get buried under features and bug fixes, all of which need to be done YESTERDAY!!!!!11!!111
You don't really need "agile" and certainly not "scrum" to do that -- but it kindof says something cynical about software development that something like "scrum" or "agile" is needed to manage these expectations.
I mostly agree, especially about estimation, but how do you work in teams and how big is your team? How do you know roughly what your colleagues are working on, what's the process of ticket creation, etc? Honestly interested.
Estimation beyond tasks that you've already done some time before is impossible, I've been 3 months from blocker to blocker (all of them not mine) to add xml to the list of supported formats in a project
I like Agile. It's a set of principles. The closer your team and stakeholders hold to the principles, the better your experience as a dev. If your SCRUM master acts as an intermediary and stands up for your team, while holding you accountable for your work, then they are valuable. If your Product Owner actually writes meaningful ACs, then that's even better. It's a lot of "ifs," but I've tasted the sweet glory of good practices as a dev.
Agile (capital A) is business model. It is strictly a grift by content and training companies to shame the enterprise into thinking they are building software the wrong. Then sells content that shows companies how to build software the wrong way. Then you have companies that build tooling to support this bad practice. The tooling is used to drive metrics to track everything for the PMO and is used as CYA for requested changes. Agile tools are also be used to finagle numbers to justify the needs for head count to justify what is taking so long to get work done. It becomes a management accounting process disguised as an SDLC methodology. A decent dev manager along with a decent architect can decompose a system into meaningful segments and create a budget of time needed to get things done within a time block by developer. That time block being a day, a week, a month, or a year. Contrast the concept of "agile" (little A) as the process of getting the customer to try software as developers builds it. This assures that the software meets the customer's needs by having them use it instead of having developers spend 6 months creating documents and diagrams, another 6 months coding, then asking the customer "is this what you needed?" all to start over. Which strangely enough still happens. The duration has been shortened to 2 weeks now.
I've seen scrum work amazingly well. It was a contracting firm, and high up at the customer, they decided that incorrect work estimates were the worst possible outcome, and the second worst was inconsistent work throughput.
The result was that all tickets were made small enough that they could DEFINITELY be done in a week, then the time estimate of every single ticket was one week. The team would finish work by Tuesday, then have "meetings"... on Path Of Exile... for the rest of the week.
Sprint planning is mainly task prioritization and clearly defining what the end goal of work in the near term is... So if it's not helping, your situation would have to be something where this was somehow less immediately important - either in terms of how far out your deadlines are, or how much input you have in terms of what you should do in the nearer future vs later...
I remember watching a talk, I think it was a Unity conference or something, and the dude got the sublime buy it alert on stage. It was amazing.
The legend has it that management's involvement when estimating tasks (or them forcing devs to reduce the estimates) makes the team more productive. 😆
Standup and sprint plannings work well if your team is a 2-pizza team. Daily 15 min standup is helpful but any longer is painful. Our sprint planning usually takes only 1 hr because the TPMs have done the leg work so planning is rather painless
2-pizza team.. that’s good I’m stealing it
i don't know what you guys are doing for sprint planning but it's just a 15 minute meeting we have every two weeks to make sure the work on our jira board is doable, 90 minutes a week in PBR, we have product managers in PBR for if we need them to clarify something, they don't have any input on estimates
Sprint planning is important in my role because I need to report back to other people about when certain features are estimated to be done. I need to know who is doing what and how long they think the work will take, and I need to make sure the right things are prioritized.
Well that's the problem. Instead of the business empowering ownership and guiding what to focus on they just want dates. And usually they will be wrong. You get what you ask for
I feel like (Daily) Standups are really important when you have interns in your team and/or hybrid/part time workers. Keeping up with everyone via text is just really hard so having one set time where everybody quickly shares something they did, want to do and impediments really helps the team to calibrate. The other „ceremonies“ usefulness really depends on your type of organisation. Especially in environments with a lot of compliance/regulations stuff it is super important to have good refinements since a tasks needs to be really well defined or you risk doing things twice or even fines in some cases.
Agile literally advocates what you say is the best way to code - incremental progress, minimization of planning, elimination of processes etc. the problem is - no one actually does it. Scrum is the real issue here, it's an anti-pattern that attempts to make "agile" work in a more conventional business scenario by establishing new redundant, frustrating processes.
I think sprint planning is the most important meeting I attend, just barely ahead of retrospective. I work at a consultancy and I've been on the bench for the past couple of months. Without the structure of sprints and planning, I work much less and i am less focused with my work. With planning, I set my sprint up so that I challenge myself without overdoing it.
This is all highly dependent on the team you're on though, and all Agile meetings can easily be derailed by personal life talk.
My team is not achieving the sprint goals, and to fix that, they decide to put more meetings to create a check list of what to do in each task, I think is a just worse, if I need a checklist I create my own. But at least after arguing against one more meeting it was decided to grow the sprint planing time to accommodate that
i flunked my advanced programming course in college because they told me i have to do sprint planning on the group projects for grading reasons.
i ended up spending 2/3 of my time writing stories on google sheets only for my group to mess up or not doing their part of the spring boot project
A lot of these meetings are so dependant on how communications work at your company and the kind of work you're doing. Prime mentioned that stand ups are a waste because some admin person can't be bothered to read 7 emails. My current workplace we don't do emails, we barely do slack. In a team of 6 people we have a 15 minute standup meeting going around saying how it's going with work X and if there's any issues or blockers. And it really does last 10-15 minutes then the rest of the day is ours to manage how we want.
12:21 Which is the correct finger to press backspace with? I use my ring finger, but I didn't know there was some kind of a standard for it. I thought it was going to be about him not holding ctrl to delete the whole world with a single backspace press or something instead.
so regarding backspace
i seem to be using my ring finger for quick back spaces and my middle finger for holding it down
i guess i learned something new today
Depending on where my Hands are on the moment (moveing from Home, Del, Cursors or Numpad back to the left) I am using middle finger for backspace, too, I guess 🤣.
But I dont have specific fingers assigned to any buttons and never learned the "right" way of typeing, I am just typeing dynamically with the finger that is next to the key I want to use. And yes I can type blindley (at least for those characters I am using very often).
I can even type only with one hand (I once even had to for a few months, when one of my hands got operated).
The only value i get from spring planning as QA, is that i force my scrum master do add some bugs that need to be fixed that were like in backlog for a month and they are killing ux or bothering me. So all in all i use planning for personal use :D
The only useful part of sprint plannings in one of my recent companies was that it allowed me to point out the tickets that were not ready for development yet, but still were being pushed through by product managers
This was cathartic. My workplace heavily leans on Agile and I've felt like I'm crazy for questioning how useful it is to be in so many meetings.
That soy dev nearly killed my fun. I‘m learning Java and nailing every challenge so far. I love it.
I especially love the thinking part in coding.
to be honest the sprint planing is important where i work, because the decided and explain and distribute the task in it,but also i never paid attention (not intentionally and not willingly )
discussing and refining the crappy tickets that end up in your backlog seems often essential. but figuring out how many of the tickets you can complete in x number of weeks seems pointless.
@@handlechar568 true
I'm working at a company that actually has a really effective agile practice. There are things to criticize of course, like the reality that scrum is a panoptic schema to keep you always under the all seeing eye of the scrum team, but really otherwise they have a really slick process in place where sprint planning, estimation, and retros take very little time. I do feel like it mostly works well, other than a few devs that sort of misuse code reviews as an opportunity to micromanage.
If I were a manager the standups would be an email or a slack/teams message (no way we can automate this thing?), estimation would be at your own time (because the ticket should tell you enough about the thing to estimate it yourself, submit your vote somewhere and there you go, you don't understand the ticket? Get the author to update it.), and there'd be no sprint planning because we'd all do kanban and we'd periodically update the backlog with what needs to be prioritized. I really think all of this micromanaging is a way to show the blue blazers and veeps and c levels that 'velocity' is improving or not improving, but they never point out that 'velocity' is very much a product of the team wanting the team to look good rather than a true measure of how well the team is doing. But, I'm not a manager, and probably will never be one. So there you go.
Weekly standups at my old company were on mondays. The owner of the company also read traction, so he took the worst parts of agile and traction and as a result mondays were a fucking waste.
@4:25 Stand ups are not worthless. Every 2 days we have a stand up at 10 and it's the perfect alarm clock for me. It reminds me that I technically am a working individual and I have a job even though it doesn't feel like it. Basically stand ups remind me to get the hell up and get some work done. But yeah other than that it's a pointless meeting where everyone tries to speedrun with as little detail as possible what they're doing, so the only person who actually understands wtf everyone is doing is the lead who already knows it.
Damn. This video has been eye opening to me. See, I got my PhD in physics and couldn't get a job as a physicist or in academia in general, so I decided to try some software development. I'm not an expert but I thought I could try. I spent one and a half years working and it was the worst experience of my life. I never want to step into software development ever again! Daily meetings that take 30 minutes, weekly meetings that take 3 to 4 hours. It was awful. But now I realize that might not be the reality of the profession, not everywhere at least. Maybe I should give it another shot.
It may sound passive aggressive but it's your obligation to find an environment where you can perform well and get paid well while doing so. Best of luck!
@@Overcome808 oh yeah, I agree. But with that first job as my only experience I incorrectly assumed this was true everywhere.
We have this same issue at a hardware shop. Especially when crunch happens.
Deadlines are tight and the project is a dumpster fire? Obviously the solution is multiple daily meetings. /s
I've been part of the Sprint planning often. But that is what happens when you lay off people who had the BE knowledge and have to rope in FE to get estimates on what the BE should take.
Watching this while in sprint planning. Kinda answers the question to is it important
Take a drink every time you double-tap to fast-forward past the gaps of silence.
Our team recently moved to Agile as our HOD just changed.
I am attaching 10x meetings, have 5x headache and doing 33% less of actual development work.
I have never seen a person eats whole pepper in my life. That was a eye-opening experience. Thank you sir.
Every 3 weeks, the last thursday of that sprint, we spent the WHOLE day on sprint end/planning/start etc etc.
I don't mind a daily stand-up.
When they're done properly at like 10-15 minutes average.
No planning, no grooming? Talk about living the good life. 😂
99% of the problem with agile is when it is in any way commanded. The entire purpose of it is a developer driven thing and resembled more like extreme programming. Then when it actually caught on, management had to find a way to gen involved and take credit, all the while injecting crimes against humanity like SaFe and Spotify model and SCRUM and it all went to ass.
Agile is for teams that have normal distribution of devs ~5 jun 3 mid 1 senior or something like that.
I don't like sprint planning either but it seems it's more for the wider team so they can track project progress, than it is to help you plan out your tasks.
When it comes to the relationship of a developer to the whole agile process, I have a thought: instead of having the devs part of the whole 8-hour sprint planning, make the manager a buffer; as in, manager and team discuss whatever and value/pointing (manager already know what upper MGMT wants), then managers go to bat for team and team scrum masters should be humble, and if people are CAPABLE it should work out. Then manager buffers back to team. Issues get raised, escalated, resolved like normal/adults.
Standups are most useful meetings in agile. Allows team to synch progress and raise issues with least time required and no stupid emails.
Ahaahah this is now my favourite youtube channel
16:52 -> Ideal face for a new programming meme :D
SCRUM killed 80% of my productivity and causes enormous stress for me. 80% ticket pushing and endless meetings.
It is frustrating as hell to do things that takes a team weeks while I could do it in only a week all alone.
It can take longer pushing projects across the production board than actually programming them. We estimate a project will take 12 hours. I do it in 2. Not a big deal, many people also do from time to time. It takes me 3 hours constantly maintaining my branch for others to test, review, test again, review again. Now let’s say I finish 6 projects. I’m now spending all day just getting latest. Dealing with maintaining shit. Programming my own projects at home is so comfy.
hahaha your response to the task estimation meeting... yea same... same... there's another meeting
I literally have a standup that averages about an hour, and sometimes extends to 1.5 hours. No one is standing.
What is daily standup meetings became so widely adopted because they actually provided the value of short term consequences for undiagnosed ADHD people (which seems to be a lot of software devs if I go off my own career of knowing how many got diagnosed as an adult).
I work about 1 hour a day yes. sometimes I dont work for 4 days and then I make it up by working for a whole morning/afternoon. Sometimes theres slow weeks where I barely work, but there are also crunch weeks where I work most of the time.
Abdul Bari is such a legend for algorithms
I love the agile take that is not useful BUT going from complete chaos in a startup to another one where we do agile it does do a difference. Mind you all the agile is done by the dev team. Also I do agree that agile is best when done fast and efficiently so as long as meetings are short and sweet, agile is best, otherwise is just time wasting.
:)
Agile is useless then. If it's good with a good dev team and bad with a bad dev team, it has zero positive impact.
@@Asto508 So by that logic, C++ is useless too. When used properly is good when used poorly is crap, ergo zero positive impact...😐
@@arturfil I somehow missed that C++ is a project management paradigm. If you want to create analogies, try to compare at least within same categories.
@@Asto508 Doesn't matter, your argument is bad. Just because a tool or a "medium" is bad when poorly used, doesn't mean it can't be useful. It applies to any tool or medium.
Genuine question: what is the good alternative to SCRUM?
When people ask you to write docs, I think "...unit test much!"
Nobody reads the docs!