as a pretty old developer, when Scrum first hit, i was all in. no PM, ability to iterate, developers doing their own estimates, mandatory participation by the stakeholders, the ability to fail sprints if something goes off the rails ... hell yeah ! but what it turned into was "professional" Scrum "masters" and a daily meeting asking "are you done yet", zero requirements, and zero participation and accountability from the stakeholders.
we invented as a better interface to 'the business' The Business adapted, by getting even lazier, and re-inserting all of their "I take the designs, from the customer, to the engineer" people we shouldn't have bothered inventing agile in the first place- 'The Business' doesn't want to be saved, and can't be saved, from itself.
I've been working in a good agile place for a while, but they say what they mean and mean what they say, and they trust (for a large part) the teams to do the right thing. When we estimate a project, if the estimate is past a deadline then the conversation turns to scope, as it should. We can always release version 1.1 shortly after MVP if required. Our daily meetings are under 15min and not whether something is done but whether there are blockers, outstanding reviews, rough estimate if you think you'll be done today, etc. Oh and we don't have a dedicated scrum master to find busywork to justify their pay. There is one that floats around a few teams as required, but we only interface with him once or twice a week and he's legit good at helping to refine our process. It can be done well, but you need a team lead who's willing to push back hard on managers trying to justify their existence. Luckily in my org we don't have that many of them, so it's just my head of engineering that I need to push back on sometimes.
@@morosis82 sounds like a company that didn't want to follow the trend and decide to make sure they can actually deliver first. Lucky you! Hope it stays good for you there. It's drab out there, in most cases.
lol, yeah, on paper it sounds like a dream, but in practice I've not seen it survive "customization" by the business. It always ends up being agile in name only in order to sell it as a hot commodity to customers or upper management. I lmfao when I found the DoD's document about detecting fake agile bs. You know it's a problem when they need to make a document to catch people not actually following the key tenets.
My whole team has been sandbagging for years now, overestimating everything and barely working, but we keep getting paid by the customer. thanks scrum!
My first exposure to scrum: Me: But why? We've beat deadline every time and ship without any major bugs. Boss: Its apparently the new thing. Also, my wifes sister does it for a living and we just hired her. 3 month later, we have missed deadlines and shipped major bugs. Boss: I guess this is normal as a breaking in period but it will improve. Me: Imagine how much more work we could have done if we hired another dev over a scum master. Boss: Yeaaaaahhhh
The thing that bothers me the most is that scrum is just a way to rephrase classical top down hierarchical structure with the appearance of agile workflow Scrum has single-handedly given it's bad reputation to agile Scrum seller : We are an agile framework Me : How do you implement the principle of the agile manifesto Scrum seller : crickets
@@fabienso5889 For me, and it has always been the case, scrum is just a way to write some code without thinking first so that you can show "some progress" to some people. => "to show". It allows also people knowing nothing about IT to give some estimates on dev tasks. => "non IT guys working in IT" It means treating adults like kids (poker planning). It means dividing an interesting dev task into tiny ininteresting dev tasks that will be developped by several devs that won't have a clue of the big picture. Each one of them will rush to finish its tiny task which means later big refactorisation of the code => responsabilities dilluted. Endless meetings, people supposed to be thinking and writing code. You take a bunch of them, and for many hours in a week, they sat listenning. Scrum is a ceremony.
@@barryblack8332 For me, I've only really needed a daily or weekly standup in software dev when a) We were in a crunch period b) There were other communication issues, and c) As a result, we were losing time we needed to spend developing because people weren't communicating that they had problems. I've lost dev time because I updated the master branch, sent a notification to the test team that the branch was updated, and the team missed the notification and just didn't run anything. This WAS an issue, and it DID need a daily standup to fix. Status meetings are only necessary when the status is important to project completion. "My boss wants to know what % complete we are so he can tell HIS boss what % complete we are" is just not important to project completion, period. People knowing that the progress bar moved 5 pixels to the right this week has no tangible benefit for the organization. Status meetings should only convey these three things 1 - Are we done? Yes/No 2 - Are we stuck? Yes/No 3 - If we are stuck, why? Anything followup for why the team is stuck should be handled internally by the team, and doesn't need mommy scrum master and daddy project manager to supervise every action meeting, or say who is doing what. This DOES require your lead to communicate with your project manager to explain what is happening and why, but that does not require a dedicated meeting. It can be a direct message or a 1:1 conversation.
I like vertical monitor quite a lot for productivity. I just couldn't imagine using one as the monitor I'm working on. I think they're amazing if you've got stuff you want to reference, to look at or read through, like having docs or something open on the side. Or maybe you've got what the designer gave you open there if you're a frontend dev. But when I'm working on anything, no matter what, I'm not working in the vertical direction in any way where scrolling up or down isn't the better solution. And I can't imagine many people are.
About the posture. Folks, I had a neurosurgery on my spine 8 month ago because of hernia explosion. It was painful and I almost lost my leg (got partial paralysis in my feet). Now I am on rehab and 80% normal, but still feeling shitty. All the problems start from bad posture and lack of activity - sports. Be careful with your body, it becomes fragile under work routine pressure and inactivity.
daily reminder that scrum is for making suits feel involved and to protect programmers... it's not about productivity and never was. Without scrum it's this on a loop: 1) You: So, what is it that we can make for you boss? 2) Suits: All I want is (generalized notions without specific implementation nor understanding of requirements and scope). 3) You: Well, what about (specific considerations about implementations and known scope issues) 4) Suits: That's over my head and I wasn't listening at all... just make it happen, that's what I pay you the big bucks to figure out. 5) You work efficiently making a product that fits the requirements... it is wonderful in it's implementation and ease of use, and made with performance in mind. You get it done in record time because you're that good - you made good plans and you executed on them. 6) You show the work to the suits. 7) Suits: this is great, but I don't like this one little thing, it should act slightly different. 8) You: it looks like a little thing, but that's actually a foundational change and even though I write SOLID code, a change like that erodes at the core of this product. What if we... 9) Suits: don't care... that's what we pay you the big bucks for, just make it happen, it shouldn't take that long. 10) You spend any amount of time working on that change 11) Suits: Why is this taking so long! time is money!! This should be done by now... 12) You rush faster to smash and grab the parts of the code that could possibly be reused in this foundationally different product now... you don't have time to start over, so what was once beautiful and performant code, has been frankensteined with duct tape and bubblegum into a malperformant and confusing mess. Everything is unoptimized and all your creative solutions and beautiful systems are heaps of burning rubble. 13) You: Okay, I made the change you wanted... it was much more difficult and time consuming than it needed to be, in contrast with having all of the requirements in hand when I started... but here you go... 14) Suits: Oh, this is good... but we need to change this one little thing 15) Go back to step 8, and repeat the steps until you get fired for being incompetent as everything is obviously your fault aka 'not hitting specific performance metrics'. WITH scrum: 1) You (or the scrum master): Hey boss, lets talk conversationally about the product you want to make. 2) You write down what it actually takes to make said thing, then you dumb it down and put it on cards. 3) You (with or without the team) come up with how long each of those generalized notions on cards will take (in difficulty or time), you assign a point value to each card. 4) You give the deck of cards to the boss and tell them they have X points that they can spend each week and they can choose whatever cards that they want; If they want more points, they need to hire more devs, if they want less points they can fire more devs. 5) Suits play with the cards choosing which things that they want to see in front of them immediately. 6) Using the selected cards, you implement exactly what the suits wanted. 7) Suits: Hey, this is great, but can you make this little change? 8) You: Yeah, you'll get some more points to spend soon, you can spend it on that if you want. It's 100% up to you... 9) Suits: Well, maybe... I want to actually look at the cards again and be choosy with the changes I want to make. 10) Repeat 5 and the suits are once again happy/distracted and feel like they are making the product themselves and are proud of it. The problem that scrum tries to solve is: the money people generally have NO IDEA what they are doing, and they have a HUGE inferiority complex. This generally results in complaining about something small each time something is made, as to put their little thumbprint on it like "look at me, I'm helping", when it's always not the case and they are in reality a huge hinderance. It's so bad that MANY professionals build "thumbs" into their creations in order to artificially give the money something to complain about. (and it's been done that way for at least a century and likely longer, but it is cited as coming from advertising, where you make a poster for your product and it could be 1000% the best thing ever, but the suits will always complain and ask for something to be added to it, and because they are incompetent usually the change is garbage that ruins the final product and adds needless complexity - but they 'feel compelled' to be apart of it, so they toss out a little change just to feel not completely useless. People started "leaving specific and easy to remove defects" into their creative works (like in a photo, leaving the camera mans thumb in the picture) and that way when the money people see the picture they say "this is great, but can you take the thumb out of the shot" and you congratulate them on their keen eye and that you had totally and completely missed that... then you come back 5 minutes later with the thumb removed (aka the actual picture, without the thumb...) and when they see the result of their criticism then they simply love THEIR creation...). Additionally companies "don't know what they want, they only know what they don't like" is inevitable as well... and expecting a suit to have a thought further out than the tip of his nose is a big ask... so you'll constantly be revising and revising and revising some more. All the while the suits will get antsy about the costs and how much time it takes. SO scrum attempts fix these issues: suits feel important like they are directing the show in a 'totally real and not artificial way' and results in less anger and resentment suits can't complain about time restraints: they are the ones choosing what gets worked on and they can hire more developers if they want more points; they feel like their in control. suits feel more satisfaction in the resulting work: no need for thumbs in the shot... they already feel like they 'did something'. The problem that scrum creates is: meetings and meetings and meetings and meetings... wasted time and effort on stuff that LITTERALLY doesn't matter. slows down development across the board (in contrast to 'just doing it right the first time, and let the professionals do professional work'). makes the final code base inefficient (this is more of a gripe with 'solid' and 'modularity' in general... if you know 100% what you want the final product to be, you can make it really really strong and performant... the second things can 'just change whenever or whatever', then you either overengineer solutions or you make a huge mess - building crazy amounts of technical debt - and nothing is going to be performant or well built) And like said in this video, what actually happens is they just give you more work on top of the meetings... and it doesn't feel like they respect your time as most of that time is wasted needlessly. The endless treadmill thing is true too... hopefully less so if you understand the 'why' part of scrum... because it's intentionally a endless treadmill controlled by people that are not software engineers... you're literally a pawn in a card game... That said,... it's arguably better for developers in the long run with scrum... suits should make more reasonable requests (aka, they have a real time budget/allowance, or should in theory) and won't blame the developers so fervently... and granted it's an inevitability that companies will change their mind and add crud all the time randomly... at least this way you are given the breathing room to SOLID and try and make the codebase malleable and maintainable --- and that really should be factored into the time it takes to accomplish given tasks... but the constant meetings are screwed tbh It's 'cool' in theory and would be nice if it worked. I think many times people 'do scrum' and don't really understand the 'unsaid quiet parts' and they just treat it like a productivity tool for collecting performance metrics... but... when done right, usually the suits are happier at the end of the day and devs don't get constant flack because the suits are incompetent... because that's an inevitability that won't change anytime soon...
People tend to demonize agile methodologies without realizing what is really trying to solve, that is misscomunication between management and developers, I love prime but him being a tech influencer and a unicorn startup developer makes me not take most of his takes seriusly, he is out of touch of the reality of most companies, where developers aren't treated as kings and more as servants, and without a structure as an agile methodology the servant is treated more as a slave. That said, if your company have well trained and professional Product Owners/Business Analysts the problem of "little changes" gets blocked entirely by separating the stakeholder from desicition making, independently of the development methodology
Love your analysis of this. I enjoy scrum because I get to coast if I’m good. It lets me have great WLB and I’m happy. And I still deliver more than expected. It’s not all bad.
This is why business analysts are a required role in companies, their job is to translate and manage suit speak into a product and general pipeline for their staff. The suits and engineers can talk to each other at times, but the business analyst needs to be there, and that should be something initiated by the BA as they are the ones who should be in the meetings and bringing the engineers on for final confirmation of expectations and delivery
We've never done any "sprint catchup" anywhere I've been. If we did not make the things in the sprint, they were just moved to the next sprint and that sprint was adjusted accordingly. Sprints are never planned any further than the next sprint, and they are just the highest priority tasks from the backlog. I would absolutely refuse to do any overwork sprint catchup if asked, only thing I would do overwork for, would be critical production bugs, and I'm pretty sure most of the people I've worked with would be the same.
@@handlechar568sprints are good for one thing, if you have a good idea of your capacity (velocity) and you have a specific outcome that needs to be done in a particular time, then it allows you to lay out estimated tasks specifically for that thing, compare to capacity, and say yes or no, then force the scope discussion. I've done this a few times, and often there's a version where you can see you'll run over a tad and can negotiate a day 1 MVP with a plan to follow up with the most valuable extras nice and early.
The spinal condition is also called "tech neck". On my first Scrum job I voiced my surprise at the sheer amount and length of meetings. The response from the PM was "Let's have a huddle on the topic of whether there are too many meetings." On a more recent job my manager was like "Oh, I hate scrum, it's toxic, I never want to bring it here." Then it was "Let's just have retrospectives because I think they're useful." Then it was "Let's add story pointing to better estimate our time horizons." You guessed it -- sneaking Scrum in piecemeal through the back door and assembling it on site. By the time I heard talk of "sprints", I knew it was too late -- Sinistar had already been built.
you know the companies more worried about time estimates are the one that kill the most amount of projects, I wonder why. maybe if they were worried about producing value to their customers instead of trying to estimating work and doing useless busywork. I know you already have a burn-rate calculation, just tell me how long you can run, and I we go from that. it doesn't matter as they're already earning 10 times what the developers make either way, why does it matter much how long it'll take to build something, when its done, its done.
The bottom line is, every business has deadlines that must be met. Games have to come out before the Christmas holidays, or they will miss their sales targets. In our case, we had to have a new reporting feature ready to demo at some big big-data convention. The two eternal questions the business will ALWAYS ask are "how long is it gonna take?" and "how much is it gonna cost?" Whatever methodology you adopt, you'd better be prepared to answer them.
@@bitwize that's understandable, but you don't decide out of nowhere 2 months before christmas sales to just move buildings, and then come up with a 2 months deadline to any constructor company. But that's what they always do to software.
We recently had a sprint where almost half the items weren't completed, so we just skipped planning for next sprint and used it to complete the work. To go fast, you need to go slow. Also, people misunderstood the meaning of the agile manifesto when it says "over COMPREHENSIVE documentation". The idea was to create a better way to work than waterfall, which was all documentation up front. Architectural design up front is alright. You can spend time on it. Also, you can draw diagrams to validate your ideas. But you can also build some POC alongside with it. You can start fiddling away with some skeleton of an app that you might or might not discard. You can also document the thing while you're working, to enable everyone else to use it as well. There's nothing fun when you have a simple Lambda function that hasn't been updated on 3 years, nobody bothered to write a README, nobody bothered to write comments and it can't be redeployed because the tooling has been updated, and if you take down that lambda apprently your whole website shuts down. So now we have 20 engineers swarming to fix this problem. So document your stuff, people. Just don't write up a guidebook about your app before you write any code.
When the Agile Manifesto was written project documentation was prevalent and time consuming. THIS was the documentation they were talking about, not technical documentation. Technical documentation is as critical in an agile world and it has always been and will always be.
@@timgwallis I actually don't generally mind scrum that much. Though some people make it seem like they deal with hours of scrum rituals every day, and I haven't seen that yet. I have maybe 3 hours of meetings a week. But as someone who has had to maintain software that was written 10+ years ago where nobody remembers what the actual business requirements were, and the product management solutions changed two or three times so old discussions have been lost -- sometimes some more comprehensive product-level documentation would be nice... I don't want to write it though. :D
@@AaronPadenthe way I think about it is if I had to onboard someone, is there a set of documentation I can point them to that will help them understand what it is we're doing and why? That will be different for different products, like I've worked in financial systems where a reasonable level of documentation for the accounting parts was necessary because it's not implicitly obvious. If you're going to make any changes, you don't want to have to do a discovery piece with a bunch of accountants to understand how not to fuck up the financial ledgers. If you're doing crud methods with some validation, the required documentation threshold is much lower.
I've asked to implement a system at work whereby a project cannot be signed off as completed unless someone who hasn't worked on the project can deploy it without any help. Someone else should be able to look at your README and get shit running and deployed if they have a reasonable amount of dev knowledge
gonna tell you one - I was in the team when there were couple persons who were like "if we don't have daily standups online, we feel abandoned, like we don't have a team at all". Then we introduced some additional "coffee meet" - just a chit chat for teammates, and those two folks they were always silent. Once asked they simply said "Well we didn't mean to talk, we feel good in silence, but really need that atmosphere of discussion happening around"
I was in a company a couple of years ago where I was embedded with 6 development teams as an infrastructure engineer. If I missed a meeting i would hear about it immediately. 6 scrum meetings per day, needless to say there was just no possible way actual work could get done.
I feel you. As the only infrastructure (well we have more but none who manage k8s besides me) guy I have to cater to 30 devs organized in 5 (now 3 after a bit of reshuffeling) teams and everyone cries a river when I miss their stupid meetings.
That's crazy! We wouldn't include an external resources in ours unless there's a good reason. We do have outsiders join us from time to time, they typically get the general 5min updates and then we can have a bit of a chat at the end if necessary but it's not normal. Typically only when it's something like a dependency resource like infra where we need a bit more of a complex discussion re work and priority. That said, most of our comms at this level happen through dedicated channels (on slack) and at the leads level if necessary for planning reasons like we need some significant dedicated time in a couple of weeks or so.
I agree about the moving of the goal posts, or anything that feels like an endless marathon. I remember when we went remote, my teammate and I had at least one daily meeting to talk about the project, and while on the one hand that really motivated me to dig into the problems we discussed, it also burned me out. I felt the same being an engineering manager - I felt like there was never a break, even when there was. It was this constant state of anxiety about what you should be or could be doing when you're not doing it.
About 0.000...1% of this is from Uncle Bob. They kept a few of his words. They took Bobs molehill, shoved it aside and built a mountain in its place. There's just a few molecules left of the molehill under the mountain.
Been a game dev for 8 years, never had any major troubles in any friends team, a few time ago i joined some friends on a new project and he had this shitty thing going on, we had daily meetings and so on, and i was always thinking: "but we already deliver all the tasks in time, we can communicate through Discord properly, why do we need to lose our time on those meetings?", 1 week later and 2 friends had abandoned the team and i was the third one 2 weeks later 😅
I think the biggest problem with scrum and agile is the fact that greedy ladder-climbers could latch on to the buzzwords without actually following the process *on the business side*. I only ever saw it implemented as chunked-up waterfall without all of the up-front planning for waterfall to succeed. The main feature they actually used was sprints, and that's about it. No working builds/prototypes every sprint. No customer involvement as promised. It would have been much better if they had made some organization and license out the rights to use the terms. If they audit you and find you're not following the process? Boom, you can't say you use agile/scrum. Then we'd not have a thousand different understandings of the process with thousands of different people selling training. It's just too easy for the rest of the organization to force out any aspect of the process that doesn't fit their status quo.
Vertical monitors are fantastic. They are so much better for. websites, terminals, documents any sort of list based applications, so chat, spotify etc. I have one large monitor flanked by two vertical monitors and one smaller monitor/ drawing tablet and its ideal. When developing: Terminal on the left vertical, code on the main one in front of me, website/ application on the right and my task list on the smaller monitor then switch spaces for documentation/ the web or teams (ewww) etc.
Only being able to have 1 super long and thin "channel" instead of being able to have two to four regularly sized windows is just never worth it to me.
@@Sammysapphira Err you can divide up your screen how ever you want in any orientation. I have generally got 3-4 terminals vertically stacked on my left vertical monitor (or just using tabs if I want the full length for tail logging). When I am working on websites I have the website and then below it the dev tools for that website on my right vertical. My main screen (43 inch 4k) gets split normally into either 2 or 4 different code editing windows/tabs. The world is your oyster. To me this configuration is the optimal one. I could do with a little more resolution dpi on my main monitor. Maybe if it was a 5k it would be perfect but other than that I have no complaints about my 3 * 4k + 1 * 1080p real estate and configuration.
I agree, vertical monitors are fucking great for code. I feel more in control, if I got my vertical display on the left with main file of a project always open.
@denisblack9897 after hearing your endorsements I am now open to trying them. When I first saw them I thought they were ludicrous but now I like to try it out.
"SCRUM is based on the Agile Manifesto much like a hotdog is based on the concept of meat". It was at that moment that we knew that this guy was cooking bitter pills... I like vertical monitors, but for two specific uses only. Having my "console output" there and reading PDF's.
We started tracking time spent in meetings into separate tasks (marked as "urgent"). Еhe number of meetings and time on meetings was significantly reduced.
24:40 This is the honest truth being on a team with people that don't want to put in any effort to actually become great at their job makes the job miserable for those that are putting in that extra effort.
I also had the experience that scrum just added more work to my day. When I worked for one company, I organised my day so that all my meetings were before 2pm but I was still never finished before 7/8pm. My boss seemed to never believe that I had so much non-dev work to do and so expected that I'd be putting in 7-8 dev hours per day, despite being able to demonstrate I couldn't ad my continual bitching about being so busy - he just seemed to think I was lazy. That and covid lockdowns made me burn out really hard
bro nobody actively works 7-8 hours a day consistently on an 8 hour shift, it's just unsustainable. should be more like 4-6 productive hours a day anyway, rest is switching focus, communicating, taking breaks, etc
I enjoy hating on Scrum as much as the next guy but I don't like sniffing my own farts. "Annoyingly efficient" is not how I would describe most teams. Software development was a mess long before Scrum was a thing.
the problem isn't software development, its the MBAs full of crap entering a field that's super young and where everything is basically handcrafted and trying to manage it like an automated chair factory that produce the same chair 20.000.000 times. the entire idea of the agile manifesto was producing visible results instead of planning everything up-front or just doing stupid administrative busywork. We really need a get shit done manifesto instead. Just do it, and its done when its done. Also, software never is done, companies have fixed rate contracts, why do they care about deadlines ? it literally doesn't matter, take the cost of the team, then multiply by 3 and push to the client, work forever, isn't that what companies want ? forever making money ? why having an end date ? do they put end dates to their business too ? of course not. deadlines, what a ludicrous concept. software is not a product, it is a service.
Got a sit-standing desk frame from IKEA (i know...) but built my own surface so my monitor sits straight in front of me, both when sitting down or standing up. The tangent about bad posture fucking up your back all the way down to your feet is so true. But you gotta keep remembering that even good posture is never sedentary, you gotta move from time to time, get a bouncy ball or something (they stow easy too) Also, I once heard someone say that everything that separates your body from the floor is worth investing in. I invested in my bed, sofa, shoes, office chair, bouncy ball, ... and it does help a lot. Don't underestimate the importance of your physiology and don't cheap out on it, especially in an office profession. Last but not least, go for walks, go to the gym, go swimming, ... the younger you start doing this, the more thankful your older self will be. Edit: forgot to mention split keyboards!
Start and end the day with movement (yoga routines, mobility programmes). Strengthen your hamstrings, ass, and lower back. These two approaches should mean you pretty much don’t have to worry about posture. Exercise is by far the best thing you can do for yourself.
In my experience Scrum ceremonies start pretty easily regressing into repeating the same meeting all over again with a different title. Planning: let's go through the unfinished tickets we have and tickets we are hoping to work on. Dailies: let's go through the tickets we worked yesterday and that we are hoping to work on today. Grooming: let's pour over the tickets. Retro: let's go through how we are happy we managed to finish the tickets we finished and again how there where these tickets we failed to finish. Although there is a variant of this process where dailies are used for a different purpose: discussing which meetings we had yesterday and which we are expecting to have today.
Though you are mostly correct and I do agree, you did not describe a retro. The only useful thing of Scrum to me is the retrospective. What you described is the review. Retrospective is bringing up any issues there have been during development, or discussing things that can progress the development further. Could be that there has been a lack of clear communication between the team, which need addressing for obvious reason. If there has been no issues, the meeting is done.
Retro means a lot of different things to a lot of people. For me it should mainly be about process improvement, figuring out if we did something suboptimally and if we should take lessons from the period at stake. But instead of that I have quite often seen retros degrade into just talking about the tickets. When that happens the completed ones get mentioned into the "what went well pile", and the ones that were not completed go to the "to improve pile or did not go well pile".@@TheMathias95
@@TheMathias95 Yeah retro for us lives in a vacuum. You're free to say things critical of choices that was taken, complain of stakeholders and stupid shit the company is doing to ruin our daily work. The key is to not bring that outside of the meeting of course. And also use the retro to change your working process. Think dailies take too long? Suggest reducing it. Reviews boring? Say so.
Three minutes in and I got more use out of this video than I expected Looked up Silicon Valley Syndrome and realized that I have shown symptoms of it for over a year from improper posture Found a neck and back specialist near me Thanks!
This must be toxic workplace stuff. Scrum is a very simple framework for self-organizing teams to work efficiently. It should not take up much time or have much bureaucracy. Biting off two weeks of work from the planned project, deciding how to get it done, and making sure to ask for help if you're stuck in the morning is quite a decent framework, honestly. Please tell me what is wrong with that.
It’s a matter of who’s doing what whom. If developers decide to adopt scrum, it will meet the needs of devs. If management decides to adopt scrum, it will serve the needs of management. It’s easy to pervert a process. To make a process work, you need people to agree on what’s valuable and use the process to achieve that. What people are upset about are asymmetric power dynamics that create toxic workplace cultures.
As someone who has been a professional software engineer for 15 years and has to go to physical therapy and OT for all kinds of pain, watching you ban someone for saying posture doesn't matter made my damn day
I am so glad we have scrum to make it so people who don’t know a thing about writing software can make all of the important decisions about how companies write software
Portrait-orientation monitors made a ton of sense in a particular point in time, until about 5 years ago when giant 2160x1440 and 4k monitors became affordable. A 21" IPS monitor turned on its side is just fantastic for looking at code in your primary screen. But once the top of the monitor gets outside of your vertical peripheral vision the ergonomics stop making sense. Nowadays you get almost the same amount of usable screen real estate on a 27" 4k monitor with two code panes side by side.
You’re spot on with having to do more work. I spend my time in meetings and then end up trying to code late on in the evening after a day filled with nonsense.
You should watch some Allen Holub stuff. He outlines nicely how scrum and agile were ruined. But it's basically how you say. Scrum and agile should've been a way to fine-tune XP and interfacing with management to the needs, abilities and preferences of each team individually, not a one-size-fits-all unchangeable process.
I always push on the scrum master to keep all the meetings minimal and when people came out with personal stuff I told the SM to cut that out in the stand up we should organize a team build up meeting on fridays in the last hour so we can play, talk or something.
I found vertical monitor setup good for frontend work, where you have a browser in full screen on it and have the devtools open in the bottom half. This gives you a roughly normal aspect ratio for the actual viewport.
Neck story: Remote for about 10 years. Previous apartments I had no good desk setup, hunched over with laptop; sucked balls. Moved to house, good desk setup, but still had keyboard and monitor stupidly setup. Started doing jiu jitsu, 6 months in, neck got cranked and bam: 4 herniated discs. 2 months of horrible pain, radial shooting pain down the arm, physical therapy, massages, etc. Before the incident, a physical therapist was working on my posture; we suspected that years of bad posture is really what caused the neck injury in BJJ. So.. You may not know you have a posture problem, but a car accident or sport injury, whatever, down the road could make an incident far worse. More specific details: Something like being hunched over, for example, overworks your chest muscles, but weakens back muscles. Weakened back muscles means traps have to be overworked for support, and increase strain on chest muscle means front of neck is stronger than the rear. All of this sets up for putting pressure on the discs in the spine from one side to the other, causing bulging discs. In an extreme event, a bulging disc can then become herniated or ruptured. Tip: I also found that getting a 32" 4k monitor, but increasing the zoom size to 125% or 150% still gives you tons of screen real estate, but really helped me with subtly lurching forward trying to focus on the screen
Pulling weeds was an epic comment and comparasont. First, you reach certan age when you find find weeding even enjojable and do it voluntary. I myself wonder about this phenomenon: maybe with age we want to get used to the soil, where will we end up? Second, agree that progress along the shortest rather than the longest line or along individual areas is more visible and motivating.
25:10 100%. When you're relying on somebody that lets you down because they couldn't be bothered to do their job, it makes everything worse. Either you're delayed from hitting your tagets, or you have to do their job as well as your own.
I very strongly believe that promising / talented juniors should be thrown at hard and isolated problems and given lots of time to solve them. It may not be as nicely designed as a senior's nor will it be done as quickly however that junior will learn vastly more than he would by smashing out a bunch of tiny features.
I like this idea. Hard doesn’t have to mean technically difficult, either. I changed from banking data software to GIS, so even in the same tech stack I was completely new to the business domain, and certainly the 30 year old codebase and workflows. I’ve learned a lot by being given large tasks and allowed to take my time and immerse myself in them to learn about all those aspects. A lot of companies seem to have a ton of red tape even to add simple things.
Have the misfortune of having been put into Scrum for the past 4 weeks. I already hate the constant meeting massacre. And since I am part of multiple projects... I will have even more meetings.
The point about firing is really underrated. Sometimes you just gotta let people go. This is not an american thing, it's a do-you-want-the-project-to-actually-work thing.
Just a comment about: "You have no product" This is actually good, you don't need something to make money or even to solve a real problem, most of the problems in the world can be solved using an excel file, and that's not bad. But that nothing usually grow into something, and then is where the "product" start to exist, and there is where Unit testing, documentation, etc etc is worthy.
I definitely think there is a version of Scrum that works, because I've been on a team that judiciously followed the process and it did work. But I've also been on projects where Scrum really became an anchor dragging us down. It's really easy to get Scrum wrong. One of the big problems is that a lot of people selling Scrum act like you can tailor the process or pick and choose bits to adopt. That's not really true, it it should be done as a last resort. Stand-ups should be 5 minutes. Sprint planning should be no more than an hour. Sprint retrospective 30 minutes. There should be actually be design meetings and requirements gathering before you start your first sprint. Breaking down user stories into achievable tasks during sprint planning is also important. Also, committing to the amount of work you agreed to get done is a big part of it and you should be empowered to argue your case and downsize the deliverables of a sprint so your team is on board and committed.
12:00 In psychology, there is a well-known bias-though I can't recall its specific name-where presenting the positive aspects first and then the negative ones tends to make the person feel unhappy. Conversely, if you present the negative aspects first and then the positive ones, the person will generally feel happier, and think you are more sencire. On a related note, I find planning poker to be quite frustrating.
planning poker can actually be fun if you bet the estimations are wrong or that the requirements will change before the sprint is over (and that bet is gonna win most of times)
One thing that I have heard in defence about planning poker is that it's more about the conversations that it causes instead of the result. Basically, if someone rates it out of how everyone else rated it, then they might have noticed something different and that may be important.
(Non-industrialized) Scrum is a fairly great framework when the team is overall more junior or inexperienced, sometimes even as a starting point for more senior teams. In all other cases it’s just 20%+ overhead and / or a requirement which cannot be negotiated
We are mostly remote. So we have "makabre" which means mandatory coffee break. Where we just talk about personal stuff. So we get to know the colleagues. Then we don't block stand-ups with it. 30 min a week.
Very hot take, planning poker is fine, if you use it with the primary goal of rectifying differences in assumptions and identifying when tickets don't have enough detail to make any sense. If you can't get through about a month of work for the whole team in like 30 minutes, maybe skip it/try to improve it.
Re: vertical monitors and posture: vertical monitors are best positioned lower, so that the extra space goes off the bottom instead of the top. You don't have to look up if the tops of your monitors are aligned. This also means that vertical monitors should be smaller than your main horizontal monitor(s), considering similar aspect ratios. Looking up is definitely bad for your neck but that alone shouldn't be the cause for bashing vertical monitors.
Scrum/SAFe has total ultimate value on two fronts: compliance and incompetence. If you MUST make guarantees (not delivery dates) against certain considerations for your product and its supporting org, then it's great. If you have a workforce you have to maintain and want to upgrade them, then it's great, because you can work in spikes of various kinds... If you're a tight group of four or five people who are highly aligned and put data protection and general operational ok practice first, then you can probably get away with a few sticky notes... Or you can be like Google and just be able to afford the lawsuits and fines. Easy. If you collect any kind of pii you are in a fairly-maybe-definitelt-highly-regulated industry. This isn't the 90's. There is no code red. You aren't getting a jet from pepsi. Seadoo won.
I am a project manager, and here is the real issue: 90% of the project managers want to micromanage the team. I am usually among the 10%, but the most common situation is that some manager above is pushing to micromanage the team, because they and to "know how is the progress" And this sucks for good PMs that know how to give the team the space they need to do their work
If your company has those big catchup efforts because theyre falling behind, then theyre not using velocity to plan appropriately. if you guys commit 60 but only get 40 done then the next sprint youre not supposed to go above 40. Part of the problem is that management will say they want scrum, but only introduce like half of the pieces. In scrum, the dev team is supposed to communicate a deadline to management based on how quickly they can accomplish tasks. If management is giving the team a deadline then its not scrum. A quote that stuck with me in scrum training was "Scrum is a lot like chess. If you play chess with half the pieces and ignore some of the rules, then you're not actually playing chess and you're not going to enjoy the experience."
Interesting 11:00 I'm remote right now, and my team has a dedicated session in the week for just chatting and getting along... we only see each other once a year. I think it works because we don't waste time in the daily (or other scrum meeting)
I never use multi monitor when I code. I use one screen and always full screen. And normally one VS project at one time. That way I am more focused on the code, and if I need 2 editors open at the same time then something is wrong in my code. The code you see in one screen should explain everything by itself. Sometimes you need to jump into that code, but when you go back the code should be clear. If it is not clear then modify the code so it becomes clear. That way 10 years from now you get your code back, it is still easy to understand just old syntax.
5 місяців тому
I was working in real scrum once. It took us half year to jump in but after this time we delivered everything and much faster than teams working without scrum. But it was only one time when scrum worked, mostly because it was implemented correctly
I love my vertical monitor, but the editor generally goes on my primary (horizontal) monitor, the vertical monitor is for terminals and debuggers and documentation.
at my job at [big tech adjacent] thats commonly hated because of scrum (in my mind), we don't do scrum, standups are 8 minutes if not in slack text 3 times a week, and we do virtually no scrummy rituals. even we know it's shit and slows you down, and software is used to enable it daily.
According the question from Prime in minute 6:43. Exactly every sprint at my old job was that way. We had so much meetings, that there were not a single chance to even believe to achive every task we hat committed to. But every single Manager was coping that next time we would get the target and we would plan again as if we could work normal hours coping to our selfs that this might happen this sprint. Btw. there is an even worse form of Scrum out there it is called SAFE. SAFE can be boiled down to Scrum * 2. You have the the normal scrum meetings + the occasional SAFE backlog refinement but every x weeks you are effectively rendered useless because then you have Scum meetings with and for all the Scum teams which are working on the Project.
Banning a guy for talking about shit he doesn't know anything about, even if he has 999+ messages. Chef's kiss edit: saves me from using the /block feature on twitch edit2: damn, unbanned him smh
I have only been on one team where scrum was effective and that is when I worked for a small company. Imo, scrum can work, though usually it turns into what I think of as scrum waterfall. This is where management wants everything planned out and micromanaged as if you were following a traditional waterfall process while using scrum buzzwords to pretend they are trying to be agile. Scrum honestly only really works when you have a consistent team, the team buys into the philosophy, the team makes its rules based on its own governance, and the people you are reporting to actually stops micromanaging the team. Also the team is allowed to accept the fact that shit doesn't always happen on schedule and you stop the BS of trying to always play catch-up in the next sprint. Instead companies tend to see the stand-up as a status meet. Planing and retrospective meetings turn into blame game meetings about why we aren't on schedule. And then nobody on the team wants to have any accountably because they are just constantly treated like incompetent fools. I honestly get bitter cause I did get to experience one good scrum team at a previous company. Then the two places I worked after thay and hearing about how scrum was used at friends companies', it makes me hate it so much. It made me realize big management really can't let anything nice stay nice. If they aren't micromanaging they feel they aren't doing their jobs right.
i have realized that all the pain i have in my whole body is because i have used my body wrong from top to toe, and now i have wasted 10 years off my life which i could have done something with a long time ago. listen to the man.
Scrum is great if you have big project and devs have major say on how it is run. Also, it seems like people who don't appreciate proper project management are the rock-stars working mostly solo on 1k line modules, not on design, delivery and ops of enterprise level solutions.
The monitor position is fine. The trick is to slouch in your chair so you have to look up. Also, if you doing in 3d character modeling, the vertical monitor is the way to go. Also good for previewing phone apps.
Do you want to stay ahead of the curve? Do you want to blissfully sit at your computer all day in a Z-position without breaking? This one simple trick is your key to salvation! Exercise.
The guy who talks about his dog is probably one who doesn't give a f about the standup and about everyone else's tasks, because they are unrelated to his task and he doesn't give a f about how complicated Jerry's task was
Screen placement is important, but a moderate size vertical screen for things like Slack/Teams/Spotify/reading a PDF is perfectly fine... as long as you don't have to move your neck up and down to read it all.
I wish all unit test libraries that are included with the language should include mutation testing, because this would improve the tests and might actually give better meaning to coverage. There have been many solutions to better testing, but then you to create twice the code for tests.
Vertical monitors in an office are a sign the coding guidelines has a col width limit of 80 still being applied from 1972 cause the original founder uses emcas
1000x agree with Prime. Aside from truckers, programmer posture issue are so underappreciated. They are so much worse on your body than expected. Humans are not built for this biologically.
Think about a vertical monitor like this: It mimics the form factor of a cell phone screen. Should all programmers have one? No. But the programmers who would benefit already understand my point.
7:49 And someone is walking behind you dropping weed seeds. That person is a product manager. 8:42 inb4 "BDUF, LOL. Do you use punch cards or paper tape or do they go mushy in the waterfall, ROFLhundredeleventyoneoneone." 13:59 I've never seen a not-side tangent.
Prime: * quits actually working as a SWE * Suddenly Prime: " Yo guys, all of a sudden I feel that scrum is actually awesome" I think those two things might perhaps be related...
And then there's my company where leads don't lead jack sh*t and forcing them to use a scrum approach actually straightened the quality of our products and the overall productivity. Now we define the technical requirements properly, we define scopes properly, we discuss about issues and initiate actual tangible fix attempts and learn from those. Except that team of leads who were against it and work in their own bubble. I don't even know if they produce anything valuable these days... Scrum has its place in companies that are yet to understand how to be organized. Some people just think they are so smart, they don't need structure. Then they fuck up the company they work for. Almost no time in meetings too. Straight to the point, no bullshit then back to work meetings. Like it should.
to be fair, sales/marketing who works with customer also has a dilamma, they want to keep customer happy they need to work with customer that only understand stupid logic, very dumb words, buzz words, and empty promises, but most importantly, they want a date. They want everything that engineer hated.
I find that a lot of the points here are for waterfall. Plan out 12 months is definitely not agile or scrum! The last bit about fire fast is honestly the key to a proper agile team. If you all have that bit of fire under you, then talking and making sure things gets done is way more simple. The bit about retro, if you don't fix what's broken it will be broken!
The biggest scam is thinking people separate out libraries from the application instead of just making an unholy amalgamation that is impossible to parse by someone not there for five years.
Scrum is just an abbrevation for Scrotum. The letters o and t are in a meeting, so they couldn't show up.
I found them: en.wikipedia.org/wiki/Operating_Thetan
Do one for agile
Agile DEEZ NUTS
Yes, because what's better than a Scrum meeting? A hairy scrum meeting.
Somebody just made a typo when they where to write "scum"
as a pretty old developer, when Scrum first hit, i was all in. no PM, ability to iterate, developers doing their own estimates, mandatory participation by the stakeholders, the ability to fail sprints if something goes off the rails ... hell yeah ! but what it turned into was "professional" Scrum "masters" and a daily meeting asking "are you done yet", zero requirements, and zero participation and accountability from the stakeholders.
we invented as a better interface to 'the business'
The Business adapted, by getting even lazier, and re-inserting all of their "I take the designs, from the customer, to the engineer" people
we shouldn't have bothered inventing agile in the first place- 'The Business' doesn't want to be saved, and can't be saved, from itself.
I've been working in a good agile place for a while, but they say what they mean and mean what they say, and they trust (for a large part) the teams to do the right thing.
When we estimate a project, if the estimate is past a deadline then the conversation turns to scope, as it should. We can always release version 1.1 shortly after MVP if required.
Our daily meetings are under 15min and not whether something is done but whether there are blockers, outstanding reviews, rough estimate if you think you'll be done today, etc.
Oh and we don't have a dedicated scrum master to find busywork to justify their pay. There is one that floats around a few teams as required, but we only interface with him once or twice a week and he's legit good at helping to refine our process.
It can be done well, but you need a team lead who's willing to push back hard on managers trying to justify their existence. Luckily in my org we don't have that many of them, so it's just my head of engineering that I need to push back on sometimes.
@@morosis82 sounds like a company that didn't want to follow the trend and decide to make sure they can actually deliver first. Lucky you! Hope it stays good for you there. It's drab out there, in most cases.
lol, yeah, on paper it sounds like a dream, but in practice I've not seen it survive "customization" by the business. It always ends up being agile in name only in order to sell it as a hot commodity to customers or upper management.
I lmfao when I found the DoD's document about detecting fake agile bs. You know it's a problem when they need to make a document to catch people not actually following the key tenets.
Yes!
My whole team has been sandbagging for years now, overestimating everything and barely working, but we keep getting paid by the customer. thanks scrum!
Exactly
"our velocity is great!"
ah yeah, scrum, the perfect process to punish ambitious people while rewarding the lazy cunning ones
Exactly 😂 seen it inevitably happen on every team. 5 min task becomes a 5 point task worth 2-3 days
My first exposure to scrum:
Me: But why? We've beat deadline every time and ship without any major bugs.
Boss: Its apparently the new thing. Also, my wifes sister does it for a living and we just hired her.
3 month later, we have missed deadlines and shipped major bugs.
Boss: I guess this is normal as a breaking in period but it will improve.
Me: Imagine how much more work we could have done if we hired another dev over a scum master.
Boss: Yeaaaaahhhh
So what do you propose? I would really like to know
The thing that bothers me the most is that scrum is just a way to rephrase classical top down hierarchical structure with the appearance of agile workflow
Scrum has single-handedly given it's bad reputation to agile
Scrum seller : We are an agile framework
Me : How do you implement the principle of the agile manifesto
Scrum seller : crickets
@@fabienso5889 For me, and it has always been the case, scrum is just a way to write some code without thinking first so that you can show "some progress" to some people. => "to show".
It allows also people knowing nothing about IT to give some estimates on dev tasks. => "non IT guys working in IT"
It means treating adults like kids (poker planning).
It means dividing an interesting dev task into tiny ininteresting dev tasks that will be developped by several devs that won't have a clue of the big picture. Each one of them will rush to finish its tiny task which means later big refactorisation of the code => responsabilities dilluted.
Endless meetings, people supposed to be thinking and writing code. You take a bunch of them, and for many hours in a week, they sat listenning.
Scrum is a ceremony.
there are 2 different things here: doing scrum, and needing a dedicated hire to run it. The former is reasonable, the latter isn't imo.
@@barryblack8332 For me, I've only really needed a daily or weekly standup in software dev when
a) We were in a crunch period
b) There were other communication issues, and
c) As a result, we were losing time we needed to spend developing because people weren't communicating that they had problems.
I've lost dev time because I updated the master branch, sent a notification to the test team that the branch was updated, and the team missed the notification and just didn't run anything. This WAS an issue, and it DID need a daily standup to fix.
Status meetings are only necessary when the status is important to project completion. "My boss wants to know what % complete we are so he can tell HIS boss what % complete we are" is just not important to project completion, period. People knowing that the progress bar moved 5 pixels to the right this week has no tangible benefit for the organization. Status meetings should only convey these three things
1 - Are we done? Yes/No
2 - Are we stuck? Yes/No
3 - If we are stuck, why?
Anything followup for why the team is stuck should be handled internally by the team, and doesn't need mommy scrum master and daddy project manager to supervise every action meeting, or say who is doing what. This DOES require your lead to communicate with your project manager to explain what is happening and why, but that does not require a dedicated meeting. It can be a direct message or a 1:1 conversation.
Vertical monitors have their very productive uses, like virtual pinball and spaceship shooters.
Also almost all text based content is alligned vertically
I'm thinking documentation, code, documents in general, messages, emails, CSV files.
Imagine playing galaga or tetris like this
dont forget java call stacks
It's all use case based. I read lots of journal articles and write code, and a vertical monitor is perfect for me
I like vertical monitor quite a lot for productivity. I just couldn't imagine using one as the monitor I'm working on. I think they're amazing if you've got stuff you want to reference, to look at or read through, like having docs or something open on the side. Or maybe you've got what the designer gave you open there if you're a frontend dev. But when I'm working on anything, no matter what, I'm not working in the vertical direction in any way where scrolling up or down isn't the better solution. And I can't imagine many people are.
About the posture. Folks, I had a neurosurgery on my spine 8 month ago because of hernia explosion. It was painful and I almost lost my leg (got partial paralysis in my feet). Now I am on rehab and 80% normal, but still feeling shitty. All the problems start from bad posture and lack of activity - sports. Be careful with your body, it becomes fragile under work routine pressure and inactivity.
daily reminder that scrum is for making suits feel involved and to protect programmers... it's not about productivity and never was.
Without scrum it's this on a loop:
1) You: So, what is it that we can make for you boss?
2) Suits: All I want is (generalized notions without specific implementation nor understanding of requirements and scope).
3) You: Well, what about (specific considerations about implementations and known scope issues)
4) Suits: That's over my head and I wasn't listening at all... just make it happen, that's what I pay you the big bucks to figure out.
5) You work efficiently making a product that fits the requirements... it is wonderful in it's implementation and ease of use, and made with performance in mind. You get it done in record time because you're that good - you made good plans and you executed on them.
6) You show the work to the suits.
7) Suits: this is great, but I don't like this one little thing, it should act slightly different.
8) You: it looks like a little thing, but that's actually a foundational change and even though I write SOLID code, a change like that erodes at the core of this product. What if we...
9) Suits: don't care... that's what we pay you the big bucks for, just make it happen, it shouldn't take that long.
10) You spend any amount of time working on that change
11) Suits: Why is this taking so long! time is money!! This should be done by now...
12) You rush faster to smash and grab the parts of the code that could possibly be reused in this foundationally different product now... you don't have time to start over, so what was once beautiful and performant code, has been frankensteined with duct tape and bubblegum into a malperformant and confusing mess. Everything is unoptimized and all your creative solutions and beautiful systems are heaps of burning rubble.
13) You: Okay, I made the change you wanted... it was much more difficult and time consuming than it needed to be, in contrast with having all of the requirements in hand when I started... but here you go...
14) Suits: Oh, this is good... but we need to change this one little thing
15) Go back to step 8, and repeat the steps until you get fired for being incompetent as everything is obviously your fault aka 'not hitting specific performance metrics'.
WITH scrum:
1) You (or the scrum master): Hey boss, lets talk conversationally about the product you want to make.
2) You write down what it actually takes to make said thing, then you dumb it down and put it on cards.
3) You (with or without the team) come up with how long each of those generalized notions on cards will take (in difficulty or time), you assign a point value to each card.
4) You give the deck of cards to the boss and tell them they have X points that they can spend each week and they can choose whatever cards that they want; If they want more points, they need to hire more devs, if they want less points they can fire more devs.
5) Suits play with the cards choosing which things that they want to see in front of them immediately.
6) Using the selected cards, you implement exactly what the suits wanted.
7) Suits: Hey, this is great, but can you make this little change?
8) You: Yeah, you'll get some more points to spend soon, you can spend it on that if you want. It's 100% up to you...
9) Suits: Well, maybe... I want to actually look at the cards again and be choosy with the changes I want to make.
10) Repeat 5 and the suits are once again happy/distracted and feel like they are making the product themselves and are proud of it.
The problem that scrum tries to solve is: the money people generally have NO IDEA what they are doing, and they have a HUGE inferiority complex. This generally results in complaining about something small each time something is made, as to put their little thumbprint on it like "look at me, I'm helping", when it's always not the case and they are in reality a huge hinderance. It's so bad that MANY professionals build "thumbs" into their creations in order to artificially give the money something to complain about. (and it's been done that way for at least a century and likely longer, but it is cited as coming from advertising, where you make a poster for your product and it could be 1000% the best thing ever, but the suits will always complain and ask for something to be added to it, and because they are incompetent usually the change is garbage that ruins the final product and adds needless complexity - but they 'feel compelled' to be apart of it, so they toss out a little change just to feel not completely useless. People started "leaving specific and easy to remove defects" into their creative works (like in a photo, leaving the camera mans thumb in the picture) and that way when the money people see the picture they say "this is great, but can you take the thumb out of the shot" and you congratulate them on their keen eye and that you had totally and completely missed that... then you come back 5 minutes later with the thumb removed (aka the actual picture, without the thumb...) and when they see the result of their criticism then they simply love THEIR creation...).
Additionally companies "don't know what they want, they only know what they don't like" is inevitable as well... and expecting a suit to have a thought further out than the tip of his nose is a big ask... so you'll constantly be revising and revising and revising some more. All the while the suits will get antsy about the costs and how much time it takes.
SO scrum attempts fix these issues:
suits feel important like they are directing the show in a 'totally real and not artificial way' and results in less anger and resentment
suits can't complain about time restraints: they are the ones choosing what gets worked on and they can hire more developers if they want more points; they feel like their in control.
suits feel more satisfaction in the resulting work: no need for thumbs in the shot... they already feel like they 'did something'.
The problem that scrum creates is:
meetings and meetings and meetings and meetings... wasted time and effort on stuff that LITTERALLY doesn't matter.
slows down development across the board (in contrast to 'just doing it right the first time, and let the professionals do professional work').
makes the final code base inefficient (this is more of a gripe with 'solid' and 'modularity' in general... if you know 100% what you want the final product to be, you can make it really really strong and performant... the second things can 'just change whenever or whatever', then you either overengineer solutions or you make a huge mess - building crazy amounts of technical debt - and nothing is going to be performant or well built)
And like said in this video, what actually happens is they just give you more work on top of the meetings... and it doesn't feel like they respect your time as most of that time is wasted needlessly.
The endless treadmill thing is true too... hopefully less so if you understand the 'why' part of scrum... because it's intentionally a endless treadmill controlled by people that are not software engineers... you're literally a pawn in a card game...
That said,... it's arguably better for developers in the long run with scrum... suits should make more reasonable requests (aka, they have a real time budget/allowance, or should in theory) and won't blame the developers so fervently... and granted it's an inevitability that companies will change their mind and add crud all the time randomly... at least this way you are given the breathing room to SOLID and try and make the codebase malleable and maintainable --- and that really should be factored into the time it takes to accomplish given tasks... but the constant meetings are screwed tbh
It's 'cool' in theory and would be nice if it worked. I think many times people 'do scrum' and don't really understand the 'unsaid quiet parts' and they just treat it like a productivity tool for collecting performance metrics... but... when done right, usually the suits are happier at the end of the day and devs don't get constant flack because the suits are incompetent... because that's an inevitability that won't change anytime soon...
People tend to demonize agile methodologies without realizing what is really trying to solve, that is misscomunication between management and developers, I love prime but him being a tech influencer and a unicorn startup developer makes me not take most of his takes seriusly, he is out of touch of the reality of most companies, where developers aren't treated as kings and more as servants, and without a structure as an agile methodology the servant is treated more as a slave.
That said, if your company have well trained and professional Product Owners/Business Analysts the problem of "little changes" gets blocked entirely by separating the stakeholder from desicition making, independently of the development methodology
Love your analysis of this. I enjoy scrum because I get to coast if I’m good. It lets me have great WLB and I’m happy. And I still deliver more than expected. It’s not all bad.
This is why business analysts are a required role in companies, their job is to translate and manage suit speak into a product and general pipeline for their staff. The suits and engineers can talk to each other at times, but the business analyst needs to be there, and that should be something initiated by the BA as they are the ones who should be in the meetings and bringing the engineers on for final confirmation of expectations and delivery
We've never done any "sprint catchup" anywhere I've been. If we did not make the things in the sprint, they were just moved to the next sprint and that sprint was adjusted accordingly.
Sprints are never planned any further than the next sprint, and they are just the highest priority tasks from the backlog.
I would absolutely refuse to do any overwork sprint catchup if asked, only thing I would do overwork for, would be critical production bugs, and I'm pretty sure most of the people I've worked with would be the same.
Yep, and I would expect that overtime to turn into time off the next week.
So, basically Kanban? :P
sprints are so dumb. just plan enough ahead so as to not run out of tickets, that's it.
We don’t have sprints where I work. My manager decides what the next set of tasks is for each of us and we give him regular updates on our progress.
@@handlechar568sprints are good for one thing, if you have a good idea of your capacity (velocity) and you have a specific outcome that needs to be done in a particular time, then it allows you to lay out estimated tasks specifically for that thing, compare to capacity, and say yes or no, then force the scope discussion.
I've done this a few times, and often there's a version where you can see you'll run over a tad and can negotiate a day 1 MVP with a plan to follow up with the most valuable extras nice and early.
The spinal condition is also called "tech neck".
On my first Scrum job I voiced my surprise at the sheer amount and length of meetings. The response from the PM was "Let's have a huddle on the topic of whether there are too many meetings."
On a more recent job my manager was like "Oh, I hate scrum, it's toxic, I never want to bring it here." Then it was "Let's just have retrospectives because I think they're useful." Then it was "Let's add story pointing to better estimate our time horizons." You guessed it -- sneaking Scrum in piecemeal through the back door and assembling it on site. By the time I heard talk of "sprints", I knew it was too late -- Sinistar had already been built.
"better estimate our time horizons" I want to know why are companies so worried with estimatives, they're going to kill the project anyway.
you know the companies more worried about time estimates are the one that kill the most amount of projects, I wonder why.
maybe if they were worried about producing value to their customers instead of trying to estimating work and doing useless busywork. I know you already have a burn-rate calculation, just tell me how long you can run, and I we go from that.
it doesn't matter as they're already earning 10 times what the developers make either way, why does it matter much how long it'll take to build something, when its done, its done.
The bottom line is, every business has deadlines that must be met. Games have to come out before the Christmas holidays, or they will miss their sales targets. In our case, we had to have a new reporting feature ready to demo at some big big-data convention. The two eternal questions the business will ALWAYS ask are "how long is it gonna take?" and "how much is it gonna cost?" Whatever methodology you adopt, you'd better be prepared to answer them.
@@bitwize that's understandable, but you don't decide out of nowhere 2 months before christmas sales to just move buildings, and then come up with a 2 months deadline to any constructor company.
But that's what they always do to software.
When you're 20 ergonomics is 'bullshit'. When coming up on 50 it's the first thing you consider after where the bathroom is.
We recently had a sprint where almost half the items weren't completed, so we just skipped planning for next sprint and used it to complete the work. To go fast, you need to go slow.
Also, people misunderstood the meaning of the agile manifesto when it says "over COMPREHENSIVE documentation". The idea was to create a better way to work than waterfall, which was all documentation up front. Architectural design up front is alright. You can spend time on it. Also, you can draw diagrams to validate your ideas. But you can also build some POC alongside with it. You can start fiddling away with some skeleton of an app that you might or might not discard. You can also document the thing while you're working, to enable everyone else to use it as well.
There's nothing fun when you have a simple Lambda function that hasn't been updated on 3 years, nobody bothered to write a README, nobody bothered to write comments and it can't be redeployed because the tooling has been updated, and if you take down that lambda apprently your whole website shuts down. So now we have 20 engineers swarming to fix this problem.
So document your stuff, people. Just don't write up a guidebook about your app before you write any code.
When the Agile Manifesto was written project documentation was prevalent and time consuming. THIS was the documentation they were talking about, not technical documentation. Technical documentation is as critical in an agile world and it has always been and will always be.
Somehow, in 10 years, nobody will even guess what you mean by "lambda"
@@timgwallis I actually don't generally mind scrum that much. Though some people make it seem like they deal with hours of scrum rituals every day, and I haven't seen that yet. I have maybe 3 hours of meetings a week. But as someone who has had to maintain software that was written 10+ years ago where nobody remembers what the actual business requirements were, and the product management solutions changed two or three times so old discussions have been lost -- sometimes some more comprehensive product-level documentation would be nice...
I don't want to write it though. :D
@@AaronPadenthe way I think about it is if I had to onboard someone, is there a set of documentation I can point them to that will help them understand what it is we're doing and why?
That will be different for different products, like I've worked in financial systems where a reasonable level of documentation for the accounting parts was necessary because it's not implicitly obvious. If you're going to make any changes, you don't want to have to do a discovery piece with a bunch of accountants to understand how not to fuck up the financial ledgers.
If you're doing crud methods with some validation, the required documentation threshold is much lower.
I've asked to implement a system at work whereby a project cannot be signed off as completed unless someone who hasn't worked on the project can deploy it without any help. Someone else should be able to look at your README and get shit running and deployed if they have a reasonable amount of dev knowledge
gonna tell you one - I was in the team when there were couple persons who were like "if we don't have daily standups online, we feel abandoned, like we don't have a team at all". Then we introduced some additional "coffee meet" - just a chit chat for teammates, and those two folks they were always silent. Once asked they simply said "Well we didn't mean to talk, we feel good in silence, but really need that atmosphere of discussion happening around"
Haha bunch of clowns
Women in the workplace...
@@anthonylancer had many men like this as well. big wtf
@@anthonylancerlol wtf dudes tend to be way more antisocial in the workplace than women... wtf are u on about
@@anthonylancerincel spotted btw
I was in a company a couple of years ago where I was embedded with 6 development teams as an infrastructure engineer. If I missed a meeting i would hear about it immediately. 6 scrum meetings per day, needless to say there was just no possible way actual work could get done.
I feel you. As the only infrastructure (well we have more but none who manage k8s besides me) guy I have to cater to 30 devs organized in 5 (now 3 after a bit of reshuffeling) teams and everyone cries a river when I miss their stupid meetings.
That's crazy! We wouldn't include an external resources in ours unless there's a good reason. We do have outsiders join us from time to time, they typically get the general 5min updates and then we can have a bit of a chat at the end if necessary but it's not normal. Typically only when it's something like a dependency resource like infra where we need a bit more of a complex discussion re work and priority.
That said, most of our comms at this level happen through dedicated channels (on slack) and at the leads level if necessary for planning reasons like we need some significant dedicated time in a couple of weeks or so.
@@xAtNighti feel you! The same for me, as the only Platform Engineer with experience in k8s
I agree about the moving of the goal posts, or anything that feels like an endless marathon. I remember when we went remote, my teammate and I had at least one daily meeting to talk about the project, and while on the one hand that really motivated me to dig into the problems we discussed, it also burned me out. I felt the same being an engineering manager - I felt like there was never a break, even when there was. It was this constant state of anxiety about what you should be or could be doing when you're not doing it.
About 0.000...1% of this is from Uncle Bob. They kept a few of his words. They took Bobs molehill, shoved it aside and built a mountain in its place. There's just a few molecules left of the molehill under the mountain.
Been a game dev for 8 years, never had any major troubles in any friends team, a few time ago i joined some friends on a new project and he had this shitty thing going on, we had daily meetings and so on, and i was always thinking: "but we already deliver all the tasks in time, we can communicate through Discord properly, why do we need to lose our time on those meetings?", 1 week later and 2 friends had abandoned the team and i was the third one 2 weeks later 😅
Man, making half an hour reaction from 5 min vid is pure talent. Love you prime
I think the biggest problem with scrum and agile is the fact that greedy ladder-climbers could latch on to the buzzwords without actually following the process *on the business side*. I only ever saw it implemented as chunked-up waterfall without all of the up-front planning for waterfall to succeed. The main feature they actually used was sprints, and that's about it. No working builds/prototypes every sprint. No customer involvement as promised.
It would have been much better if they had made some organization and license out the rights to use the terms. If they audit you and find you're not following the process? Boom, you can't say you use agile/scrum. Then we'd not have a thousand different understandings of the process with thousands of different people selling training.
It's just too easy for the rest of the organization to force out any aspect of the process that doesn't fit their status quo.
Vertical monitors are fantastic. They are so much better for. websites, terminals, documents any sort of list based applications, so chat, spotify etc.
I have one large monitor flanked by two vertical monitors and one smaller monitor/ drawing tablet and its ideal.
When developing: Terminal on the left vertical, code on the main one in front of me, website/ application on the right and my task list on the smaller monitor then switch spaces for documentation/ the web or teams (ewww) etc.
But yeah poor posture is a killer.
Only being able to have 1 super long and thin "channel" instead of being able to have two to four regularly sized windows is just never worth it to me.
@@Sammysapphira Err you can divide up your screen how ever you want in any orientation.
I have generally got 3-4 terminals vertically stacked on my left vertical monitor (or just using tabs if I want the full length for tail logging).
When I am working on websites I have the website and then below it the dev tools for that website on my right vertical.
My main screen (43 inch 4k) gets split normally into either 2 or 4 different code editing windows/tabs.
The world is your oyster.
To me this configuration is the optimal one. I could do with a little more resolution dpi on my main monitor. Maybe if it was a 5k it would be perfect but other than that I have no complaints about my 3 * 4k + 1 * 1080p real estate and configuration.
I agree, vertical monitors are fucking great for code. I feel more in control, if I got my vertical display on the left with main file of a project always open.
@denisblack9897 after hearing your endorsements I am now open to trying them. When I first saw them I thought they were ludicrous but now I like to try it out.
"SCRUM is based on the Agile Manifesto much like a hotdog is based on the concept of meat". It was at that moment that we knew that this guy was cooking bitter pills...
I like vertical monitors, but for two specific uses only. Having my "console output" there and reading PDF's.
Each squeak of his chair(?) made me think he was gonna start playing the sad violin from spongebob as a sound effect.
Now having SCRUM with remote teams, now thats another dimension of horror.
And of course the execs end up blaming remote and not scrum.
Once had a team of 25 people with 3 or 4 remote in wildly different timezones. Those were fun standups.
i have done daily standups 100% remote with 20 people on a call that lasted for 45 + mins, made me want to smash the screen with my head
@@josevargas686 we had a team of 4 and they took 45+ minutes plus every single day. It was hell
We started tracking time spent in meetings into separate tasks (marked as "urgent").
Еhe number of meetings and time on meetings was significantly reduced.
24:40 This is the honest truth being on a team with people that don't want to put in any effort to actually become great at their job makes the job miserable for those that are putting in that extra effort.
He has a superpower that allows him to turn video that's 4 minutes into 27 minutes
I also had the experience that scrum just added more work to my day. When I worked for one company, I organised my day so that all my meetings were before 2pm but I was still never finished before 7/8pm. My boss seemed to never believe that I had so much non-dev work to do and so expected that I'd be putting in 7-8 dev hours per day, despite being able to demonstrate I couldn't ad my continual bitching about being so busy - he just seemed to think I was lazy. That and covid lockdowns made me burn out really hard
bro nobody actively works 7-8 hours a day consistently on an 8 hour shift, it's just unsustainable.
should be more like 4-6 productive hours a day anyway, rest is switching focus, communicating, taking breaks, etc
@@caminhaodelixo2 yeah, he also didn't believe that focus switching required time
@@CaptainToadUK we gotta just point blank call these people retards at this point. if it loses my job so be it. far too much stupidity going around
Replace Scrum with JEDI, Just Effin Do It.
I enjoy hating on Scrum as much as the next guy but I don't like sniffing my own farts.
"Annoyingly efficient" is not how I would describe most teams. Software development was a mess long before Scrum was a thing.
the problem isn't software development, its the MBAs full of crap entering a field that's super young and where everything is basically handcrafted and trying to manage it like an automated chair factory that produce the same chair 20.000.000 times.
the entire idea of the agile manifesto was producing visible results instead of planning everything up-front or just doing stupid administrative busywork.
We really need a get shit done manifesto instead. Just do it, and its done when its done.
Also, software never is done, companies have fixed rate contracts, why do they care about deadlines ? it literally doesn't matter, take the cost of the team, then multiply by 3 and push to the client, work forever, isn't that what companies want ? forever making money ? why having an end date ? do they put end dates to their business too ? of course not.
deadlines, what a ludicrous concept. software is not a product, it is a service.
Got a sit-standing desk frame from IKEA (i know...) but built my own surface so my monitor sits straight in front of me, both when sitting down or standing up. The tangent about bad posture fucking up your back all the way down to your feet is so true. But you gotta keep remembering that even good posture is never sedentary, you gotta move from time to time, get a bouncy ball or something (they stow easy too)
Also, I once heard someone say that everything that separates your body from the floor is worth investing in. I invested in my bed, sofa, shoes, office chair, bouncy ball, ... and it does help a lot. Don't underestimate the importance of your physiology and don't cheap out on it, especially in an office profession.
Last but not least, go for walks, go to the gym, go swimming, ... the younger you start doing this, the more thankful your older self will be.
Edit: forgot to mention split keyboards!
Same it's expensive but so is physical therapy and time spent unable to work
Start and end the day with movement (yoga routines, mobility programmes). Strengthen your hamstrings, ass, and lower back. These two approaches should mean you pretty much don’t have to worry about posture. Exercise is by far the best thing you can do for yourself.
Here to solve problems you didn’t know you had. Tag line for a ton of enterprise software
In my experience Scrum ceremonies start pretty easily regressing into repeating the same meeting all over again with a different title.
Planning: let's go through the unfinished tickets we have and tickets we are hoping to work on.
Dailies: let's go through the tickets we worked yesterday and that we are hoping to work on today.
Grooming: let's pour over the tickets.
Retro: let's go through how we are happy we managed to finish the tickets we finished and again how there where these tickets we failed to finish.
Although there is a variant of this process where dailies are used for a different purpose: discussing which meetings we had yesterday and which we are expecting to have today.
Though you are mostly correct and I do agree, you did not describe a retro. The only useful thing of Scrum to me is the retrospective. What you described is the review.
Retrospective is bringing up any issues there have been during development, or discussing things that can progress the development further. Could be that there has been a lack of clear communication between the team, which need addressing for obvious reason.
If there has been no issues, the meeting is done.
Retro means a lot of different things to a lot of people. For me it should mainly be about process improvement, figuring out if we did something suboptimally and if we should take lessons from the period at stake. But instead of that I have quite often seen retros degrade into just talking about the tickets. When that happens the completed ones get mentioned into the "what went well pile", and the ones that were not completed go to the "to improve pile or did not go well pile".@@TheMathias95
@@TheMathias95 Yeah retro for us lives in a vacuum. You're free to say things critical of choices that was taken, complain of stakeholders and stupid shit the company is doing to ruin our daily work. The key is to not bring that outside of the meeting of course. And also use the retro to change your working process. Think dailies take too long? Suggest reducing it. Reviews boring? Say so.
Three minutes in and I got more use out of this video than I expected
Looked up Silicon Valley Syndrome and realized that I have shown symptoms of it for over a year from improper posture
Found a neck and back specialist near me
Thanks!
Scrum was the beginning of the exit from the agile manifesto and back to old school code waterfall dogmatic process.
This must be toxic workplace stuff. Scrum is a very simple framework for self-organizing teams to work efficiently. It should not take up much time or have much bureaucracy. Biting off two weeks of work from the planned project, deciding how to get it done, and making sure to ask for help if you're stuck in the morning is quite a decent framework, honestly. Please tell me what is wrong with that.
It’s a matter of who’s doing what whom. If developers decide to adopt scrum, it will meet the needs of devs. If management decides to adopt scrum, it will serve the needs of management. It’s easy to pervert a process. To make a process work, you need people to agree on what’s valuable and use the process to achieve that. What people are upset about are asymmetric power dynamics that create toxic workplace cultures.
As someone who has been a professional software engineer for 15 years and has to go to physical therapy and OT for all kinds of pain, watching you ban someone for saying posture doesn't matter made my damn day
Scrum - Some Comically Ridiculous Useless Meetings
That’s a pretty nice 15-minute standup you got there, could we turn it into a 1-hour status meeting?
-Management
Backlog and Time Boxing are actually useful things.
"Poker is supposed to be filled with cigars, and old fashions, and betting and all the fun things" --prime, 2024
I am so glad we have scrum to make it so people who don’t know a thing about writing software can make all of the important decisions about how companies write software
Portrait-orientation monitors made a ton of sense in a particular point in time, until about 5 years ago when giant 2160x1440 and 4k monitors became affordable. A 21" IPS monitor turned on its side is just fantastic for looking at code in your primary screen. But once the top of the monitor gets outside of your vertical peripheral vision the ergonomics stop making sense. Nowadays you get almost the same amount of usable screen real estate on a 27" 4k monitor with two code panes side by side.
You’re spot on with having to do more work. I spend my time in meetings and then end up trying to code late on in the evening after a day filled with nonsense.
You should watch some Allen Holub stuff. He outlines nicely how scrum and agile were ruined. But it's basically how you say. Scrum and agile should've been a way to fine-tune XP and interfacing with management to the needs, abilities and preferences of each team individually, not a one-size-fits-all unchangeable process.
I always push on the scrum master to keep all the meetings minimal and when people came out with personal stuff I told the SM to cut that out in the stand up we should organize a team build up meeting on fridays in the last hour so we can play, talk or something.
I found vertical monitor setup good for frontend work, where you have a browser in full screen on it and have the devtools open in the bottom half. This gives you a roughly normal aspect ratio for the actual viewport.
Neck story:
Remote for about 10 years. Previous apartments I had no good desk setup, hunched over with laptop; sucked balls. Moved to house, good desk setup, but still had keyboard and monitor stupidly setup.
Started doing jiu jitsu, 6 months in, neck got cranked and bam: 4 herniated discs. 2 months of horrible pain, radial shooting pain down the arm, physical therapy, massages, etc. Before the incident, a physical therapist was working on my posture; we suspected that years of bad posture is really what caused the neck injury in BJJ.
So.. You may not know you have a posture problem, but a car accident or sport injury, whatever, down the road could make an incident far worse.
More specific details: Something like being hunched over, for example, overworks your chest muscles, but weakens back muscles. Weakened back muscles means traps have to be overworked for support, and increase strain on chest muscle means front of neck is stronger than the rear. All of this sets up for putting pressure on the discs in the spine from one side to the other, causing bulging discs. In an extreme event, a bulging disc can then become herniated or ruptured.
Tip: I also found that getting a 32" 4k monitor, but increasing the zoom size to 125% or 150% still gives you tons of screen real estate, but really helped me with subtly lurching forward trying to focus on the screen
Pulling weeds was an epic comment and comparasont. First, you reach certan age when you find find weeding even enjojable and do it voluntary. I myself wonder about this phenomenon: maybe with age we want to get used to the soil, where will we end up?
Second, agree that progress along the shortest rather than the longest line or along individual areas is more visible and motivating.
"Silicon Valley spine" - I haven't heard that one.
Otherwise known as plain old "bad ergonomics".
But I do 100% agree.
25:10 100%. When you're relying on somebody that lets you down because they couldn't be bothered to do their job, it makes everything worse. Either you're delayed from hitting your tagets, or you have to do their job as well as your own.
I very strongly believe that promising / talented juniors should be thrown at hard and isolated problems and given lots of time to solve them. It may not be as nicely designed as a senior's nor will it be done as quickly however that junior will learn vastly more than he would by smashing out a bunch of tiny features.
I like this idea. Hard doesn’t have to mean technically difficult, either. I changed from banking data software to GIS, so even in the same tech stack I was completely new to the business domain, and certainly the 30 year old codebase and workflows. I’ve learned a lot by being given large tasks and allowed to take my time and immerse myself in them to learn about all those aspects. A lot of companies seem to have a ton of red tape even to add simple things.
Have the misfortune of having been put into Scrum for the past 4 weeks. I already hate the constant meeting massacre. And since I am part of multiple projects... I will have even more meetings.
The point about firing is really underrated. Sometimes you just gotta let people go. This is not an american thing, it's a do-you-want-the-project-to-actually-work thing.
"Everyone has fun with the PP, nobody has fun with pee" - ThePrimeTime
Just a comment about: "You have no product" This is actually good, you don't need something to make money or even to solve a real problem, most of the problems in the world can be solved using an excel file, and that's not bad. But that nothing usually grow into something, and then is where the "product" start to exist, and there is where Unit testing, documentation, etc etc is worthy.
I definitely think there is a version of Scrum that works, because I've been on a team that judiciously followed the process and it did work.
But I've also been on projects where Scrum really became an anchor dragging us down.
It's really easy to get Scrum wrong. One of the big problems is that a lot of people selling Scrum act like you can tailor the process or pick and choose bits to adopt. That's not really true, it it should be done as a last resort. Stand-ups should be 5 minutes. Sprint planning should be no more than an hour. Sprint retrospective 30 minutes. There should be actually be design meetings and requirements gathering before you start your first sprint. Breaking down user stories into achievable tasks during sprint planning is also important. Also, committing to the amount of work you agreed to get done is a big part of it and you should be empowered to argue your case and downsize the deliverables of a sprint so your team is on board and committed.
12:00 In psychology, there is a well-known bias-though I can't recall its specific name-where presenting the positive aspects first and then the negative ones tends to make the person feel unhappy. Conversely, if you present the negative aspects first and then the positive ones, the person will generally feel happier, and think you are more sencire. On a related note, I find planning poker to be quite frustrating.
My man's such a high level Rustacean he has to weed his garden sideways
planning poker can actually be fun if you bet the estimations are wrong or that the requirements will change before the sprint is over (and that bet is gonna win most of times)
One thing that I have heard in defence about planning poker is that it's more about the conversations that it causes instead of the result. Basically, if someone rates it out of how everyone else rated it, then they might have noticed something different and that may be important.
(Non-industrialized) Scrum is a fairly great framework when the team is overall more junior or inexperienced, sometimes even as a starting point for more senior teams. In all other cases it’s just 20%+ overhead and / or a requirement which cannot be negotiated
We are mostly remote. So we have "makabre" which means mandatory coffee break. Where we just talk about personal stuff. So we get to know the colleagues. Then we don't block stand-ups with it. 30 min a week.
Very hot take, planning poker is fine, if you use it with the primary goal of rectifying differences in assumptions and identifying when tickets don't have enough detail to make any sense. If you can't get through about a month of work for the whole team in like 30 minutes, maybe skip it/try to improve it.
Re: vertical monitors and posture: vertical monitors are best positioned lower, so that the extra space goes off the bottom instead of the top. You don't have to look up if the tops of your monitors are aligned. This also means that vertical monitors should be smaller than your main horizontal monitor(s), considering similar aspect ratios. Looking up is definitely bad for your neck but that alone shouldn't be the cause for bashing vertical monitors.
Scrum/SAFe has total ultimate value on two fronts: compliance and incompetence. If you MUST make guarantees (not delivery dates) against certain considerations for your product and its supporting org, then it's great. If you have a workforce you have to maintain and want to upgrade them, then it's great, because you can work in spikes of various kinds... If you're a tight group of four or five people who are highly aligned and put data protection and general operational ok practice first, then you can probably get away with a few sticky notes... Or you can be like Google and just be able to afford the lawsuits and fines. Easy.
If you collect any kind of pii you are in a fairly-maybe-definitelt-highly-regulated industry. This isn't the 90's. There is no code red. You aren't getting a jet from pepsi. Seadoo won.
I am a project manager, and here is the real issue: 90% of the project managers want to micromanage the team.
I am usually among the 10%, but the most common situation is that some manager above is pushing to micromanage the team, because they and to "know how is the progress"
And this sucks for good PMs that know how to give the team the space they need to do their work
If your company has those big catchup efforts because theyre falling behind, then theyre not using velocity to plan appropriately.
if you guys commit 60 but only get 40 done then the next sprint youre not supposed to go above 40.
Part of the problem is that management will say they want scrum, but only introduce like half of the pieces. In scrum, the dev team is supposed to communicate a deadline to management based on how quickly they can accomplish tasks. If management is giving the team a deadline then its not scrum.
A quote that stuck with me in scrum training was "Scrum is a lot like chess. If you play chess with half the pieces and ignore some of the rules, then you're not actually playing chess and you're not going to enjoy the experience."
Interesting 11:00
I'm remote right now, and my team has a dedicated session in the week for just chatting and getting along... we only see each other once a year.
I think it works because we don't waste time in the daily (or other scrum meeting)
I never use multi monitor when I code. I use one screen and always full screen.
And normally one VS project at one time.
That way I am more focused on the code, and if I need 2 editors open at the same time then something is wrong in my code.
The code you see in one screen should explain everything by itself. Sometimes you need to jump into that code, but when you go back the code should be clear.
If it is not clear then modify the code so it becomes clear. That way 10 years from now you get your code back, it is still easy to understand just old syntax.
I was working in real scrum once. It took us half year to jump in but after this time we delivered everything and much faster than teams working without scrum. But it was only one time when scrum worked, mostly because it was implemented correctly
I love my vertical monitor, but the editor generally goes on my primary (horizontal) monitor, the vertical monitor is for terminals and debuggers and documentation.
at my job at [big tech adjacent] thats commonly hated because of scrum (in my mind), we don't do scrum, standups are 8 minutes if not in slack text 3 times a week, and we do virtually no scrummy rituals. even we know it's shit and slows you down, and software is used to enable it daily.
Scrum has some good parts. Those are the first to be removed when implementing it in the office.
According the question from Prime in minute 6:43.
Exactly every sprint at my old job was that way. We had so much meetings, that there were not a single chance to even believe to achive every task we hat committed to. But every single Manager was coping that next time we would get the target and we would plan again as if we could work normal hours coping to our selfs that this might happen this sprint.
Btw. there is an even worse form of Scrum out there it is called SAFE. SAFE can be boiled down to Scrum * 2. You have the the normal scrum meetings + the occasional SAFE backlog refinement but every x weeks you are effectively rendered useless because then you have Scum meetings with and for all the Scum teams which are working on the Project.
Banning a guy for talking about shit he doesn't know anything about, even if he has 999+ messages. Chef's kiss
edit: saves me from using the /block feature on twitch
edit2: damn, unbanned him smh
Jeera ticket one Laugh in a crowd, the rest are silent, then the whole crowd laughs as the man shakes his head
@16:00 - ok, this is just so true. Honestly, it's not a hot take in my book. Thank you
I have only been on one team where scrum was effective and that is when I worked for a small company. Imo, scrum can work, though usually it turns into what I think of as scrum waterfall. This is where management wants everything planned out and micromanaged as if you were following a traditional waterfall process while using scrum buzzwords to pretend they are trying to be agile.
Scrum honestly only really works when you have a consistent team, the team buys into the philosophy, the team makes its rules based on its own governance, and the people you are reporting to actually stops micromanaging the team. Also the team is allowed to accept the fact that shit doesn't always happen on schedule and you stop the BS of trying to always play catch-up in the next sprint.
Instead companies tend to see the stand-up as a status meet. Planing and retrospective meetings turn into blame game meetings about why we aren't on schedule. And then nobody on the team wants to have any accountably because they are just constantly treated like incompetent fools.
I honestly get bitter cause I did get to experience one good scrum team at a previous company. Then the two places I worked after thay and hearing about how scrum was used at friends companies', it makes me hate it so much. It made me realize big management really can't let anything nice stay nice. If they aren't micromanaging they feel they aren't doing their jobs right.
i have realized that all the pain i have in my whole body is because i have used my body wrong from top to toe, and now i have wasted 10 years off my life which i could have done something with a long time ago. listen to the man.
Scrum is great if you have big project and devs have major say on how it is run. Also, it seems like people who don't appreciate proper project management are the rock-stars working mostly solo on 1k line modules, not on design, delivery and ops of enterprise level solutions.
The monitor position is fine. The trick is to slouch in your chair so you have to look up. Also, if you doing in 3d character modeling, the vertical monitor is the way to go. Also good for previewing phone apps.
looking up like that literally gives you tech neck
Do you want to stay ahead of the curve? Do you want to blissfully sit at your computer all day in a Z-position without breaking? This one simple trick is your key to salvation! Exercise.
The guy who talks about his dog is probably one who doesn't give a f about the standup and about everyone else's tasks, because they are unrelated to his task and he doesn't give a f about how complicated Jerry's task was
Just let it out....yes you're in a safe place, gd poker thing
Screen placement is important, but a moderate size vertical screen for things like Slack/Teams/Spotify/reading a PDF is perfectly fine... as long as you don't have to move your neck up and down to read it all.
I wish all unit test libraries that are included with the language should include mutation testing, because this would improve the tests and might actually give better meaning to coverage. There have been many solutions to better testing, but then you to create twice the code for tests.
Vertical monitors in an office are a sign the coding guidelines has a col width limit of 80 still being applied from 1972 cause the original founder uses emcas
1000x agree with Prime. Aside from truckers, programmer posture issue are so underappreciated. They are so much worse on your body than expected. Humans are not built for this biologically.
Your neck nerves are tied to the rest of your body. If you mess up your neck, the rest of the body will follow.
Think about a vertical monitor like this: It mimics the form factor of a cell phone screen. Should all programmers have one? No.
But the programmers who would benefit already understand my point.
You've sold me on the vertical monitor 👍
"back log grooming" fantasti-moco!
The part about the 17:30 where every bit you do has to be documented for HR XD
FYI: they teach correct posture and ergonomics in German Software Development curriculum. It's often a really important part of the finals!
I love my vertical monitor. How dare you.
Single horizontal monitor gang
@@ficolas2 LOL!
7:49 And someone is walking behind you dropping weed seeds. That person is a product manager.
8:42 inb4 "BDUF, LOL. Do you use punch cards or paper tape or do they go mushy in the waterfall, ROFLhundredeleventyoneoneone."
13:59 I've never seen a not-side tangent.
Prime: * quits actually working as a SWE *
Suddenly Prime: " Yo guys, all of a sudden I feel that scrum is actually awesome"
I think those two things might perhaps be related...
And then there's my company where leads don't lead jack sh*t and forcing them to use a scrum approach actually straightened the quality of our products and the overall productivity.
Now we define the technical requirements properly, we define scopes properly, we discuss about issues and initiate actual tangible fix attempts and learn from those.
Except that team of leads who were against it and work in their own bubble. I don't even know if they produce anything valuable these days...
Scrum has its place in companies that are yet to understand how to be organized.
Some people just think they are so smart, they don't need structure. Then they fuck up the company they work for.
Almost no time in meetings too.
Straight to the point, no bullshit then back to work meetings. Like it should.
So wholesome to see the kids at the end hehe!
to be fair, sales/marketing who works with customer also has a dilamma, they want to keep customer happy they need to work with customer that only understand stupid logic, very dumb words, buzz words, and empty promises, but most importantly, they want a date. They want everything that engineer hated.
I find that a lot of the points here are for waterfall. Plan out 12 months is definitely not agile or scrum! The last bit about fire fast is honestly the key to a proper agile team. If you all have that bit of fire under you, then talking and making sure things gets done is way more simple.
The bit about retro, if you don't fix what's broken it will be broken!
The biggest scam is thinking people separate out libraries from the application instead of just making an unholy amalgamation that is impossible to parse by someone not there for five years.