The literal handbook on agile says standups should be max like 15min. If everyone says they're good with work on slack, you shouldn't even meet. Everything else is bad management.
Have to say for ours we started way below our capacity as we didn't know how much we could achieve, we've slowly ramped up and now have a consistent capacity which does not change upward, only down when people are off or ill.
Exactly. You are told that agile is about moving fast. And that quality doesn't matter. But the horrible quality of the app is why you can't move fast.
For me it is spending way too long on one thing. Shift requirements, rewrites, complications with tech stack, etc. It all builds up. At some point you just want that thing you are working on out of your life.
@@MC--- I just want people who introduce unneeded dependencies and abstraction because they are worried about something they don't even know if it is real and wont listen when you have a known solution to existing problems.
@@fulconandroadcone9488 You just reminded me of how a company I worked for used a 400kB time/date library for just a single method I rewrote in 20 minutes, saving all that bandwidth on each page load (if you don't account for caching)... Funny the developer's life is indeed...
I have not yet met a person who didn't agree with me on the fact that people in the IT industry should not only take, but be forced to take 1-2 week vacation every at least 2-3 months. You would be surprised by how much the productivity jumps due to this seemingly waste of time from the corporate perspective. As it turns out, people work 2 or even 3 times better when have the energy to work... Who would figure? And generally that energy coming from frequent breaks easily offsets the time off due to how much better your employees feel.
I have a little over 5 years of experience. I have tons of passion for the software engineering but technical debt is QUICKLY draining me. I often feel like I'm one of the only people on the team who actually gives a shit. Every time I hack something together in 2 hours, I get high praise. When I take my time and craft an elegant and bugless solution over the course of a week or more, I get asked why it took so long. It drives me fucking insane.
@@bedtimestories1065 the disconnect between developers and management is insane. They want a house built as fast as possible even if it means the house collapses from a bad foundation and lack of proper load bearing.
@@shapelessedlooks like contemporary managers don't know basics of work force recovery. It was the thing in 1900 to improve productivity of workers. Also hobbies did the same effect. All these scrum, agile and etc look as reinventing a wheel with different names.
I'm caught in the opposite hell currently. We have a massive deadline but due to the inefficiencies of scrum has I don't find myself being as productive as I should be in order to get this God damn job done. Meanwhile all my managers and team lead are acting calm like everything is fine that it's okay that I have a massive task stuck in PR review and I'm stuck waiting anywhere from a few hours to entire days for someone to review it so I can merge it and move on and hit the ground running on the next task. And when I tell them how fucked that is given the deadline coming up I get gaslit by my managers that it's fine And it's not anyone's fault. I've finally decided and say fuck it and complete the other stories by myself and have them setup in queue to be merged without giving a damn about the sprint cadence cause shit needs to get done and I'm sick of scrum holding back productivity. I swear I was way more productive at work when I was new grad / junior when I was simply allowed to fly by the seat of my pants first and then have a senior tell me what I'm doing right and wrong. Now that I'm a senior working with a team of other seniors I still have the same drive and initiative as when I was junior but it's just constantly held back by rigid protocols and this now overtly dogmatic approach to Scrum and project management. And if I break away from that dogma even in the most necessary extreme cases like this deadline coming up it's going to reflect poorly on myself because I'm a senior dev and should know better according to my managers and team lead.
I would be curious for Prime to do a whole video drawing out the whole process from start to finish on what is his ideal way of delivering software. A lot of these articles announce problems but still do not give a full picture from beginning to the end of the journey. From business to the deployment.
whatever his general ideal is, it might be close to good enough, but it still wouldn't work. The true perfect way of working depends on the team. Each person is different, therefore each team is different. Even teams have different phases. The wrong thing about these one-size-fits all systems is exactly that.
@@LangorithmicExactly this. IME every team does agile differently. Most do away with most of the ceremony, but some teams will actually add to it (say, a second daily standup) when they have problems with e.g. keeping people in sync. Some do it really well, and some are an absolute disaster… but IME when a team is an absolute disaster, it’s usually symptomatic of deeper issues. Regardless of methodology, IMO a team should ideally start off pretty strict/formal and gradually relax/remove steps until they’ve found the minimum amount of structure they need.
@@Langorithmic I used to be a manager at fedex. and the biggest thing I had to teach new managers was, as long as the workers are doing their job and doing it safety, your biggest goal is not to get into the way and prevent your boss from getting into their way. be their for them, protect them and they will get the work done. thats not to say you dont double check their work. but. dont freeking get in their way and always be available when they need it. that is the key to good management. be findable when needed, verify that the work is done well and prevent stuff from getting in the way. now, at fedex do to the physical nature, we did have daily scrums to help cover streaching and warm ups. but overall, if it was not for the streaching. I rarely had extra info, just the daily safety mention and listing any new postings for them to go after. basicly it.
100% confirm when you have regular standups, people wait till standup instead of just talking to you. We ditched daily standups and communication opened up. Chat on slack a lot, make adhoc meetings when there's tough decisions, plan goals once in a while. No artificial time windows or recurring rituals.
waiting for stand ups does reduce interrupting people who are in their flow state, but of course, if you cannot progress at all without input, then do ask
@@TomNook. Ideally it’s a daily planning conversation. No recap needed - the team developers talking about how they’re going to approach the day. Who can help with what, what’s getting in the way, etc. Unfortunately managers look at them as status updates. Ugh.
@@TomNook. Stand up is a status meeting for most folks. It's not about devs for devs. It's about devs for managers (who shouldn't be there but they always are because nobody can kick them out).
People forget Agile was a reaction to waterfall where you have planned 2 years spirals that would typically take 3 to 5 years. First 3 months was gather requirements, next 3 months design software architecture, 12 months develop, 3 months QA, 3 months integration that typically had issues.... Then if everything meets checklist, release the software and find out the users funny use it because their needs are now different or wasn't articulated correctly at the beginning....
You just described incredibly BAD waterfall management. That project was structured by an idiot. Agile is just codifying what good PMs were doing anyway, and the problem with that is that people then follow it slavishly, which ruins any semblance of 'good'. *Exactly* like waterfall. Good project management is about having a plan, regularly reviewing the plan, ensuring critical paths are ongoing and - crucially - reporting regularly upwards to a board that consists of user, supplier and sponsor reps. The thing that's always missing - agile or waterfall - is actual training / skillset / expectations / clear responsibilities for the exec board so they actually grasp their job. So if you're purely designing software, you ought to be regularly engaged with your user rep and testing / feedback cycles with their users. Waterfall does not stop you doing that. Idiocy stops you doing that. When designing software, going slavishly waterfall or slavishly agile are equally stupid choices. And this is why companies always pick one over the other - their executives are stupid, and always looking for a silver bullet instead of accepting that there are hard yards, you need to employ people you trust to do those hard yards, and your job as the exec if you want success is to monitor progress and back those people up by giving them clear things to aim for and space to do those hard yards rather than applying more and more pressure.
Waterfall is when the requirements were fully analyzed and the BAs understand it very well. Agile is when the POs do trial and error because they didn't understand what the users want.
I was happy to see sprints get adopted in my startup. For me, they were not for developer communication. They served two main purposes: 1 - gave management insight and a window into what is going on 2 - insulated the development team from chaotic changes Prior to sprint, it was not uncommon to having shifting priorities every day and burn out was a real problem. Adding sprints to the equation and getting buy in from the PO added a buffer to the chaotic changes.
I agree with 1 but object to 2. Dragging developers through standups is bad for morale. Insulating developers is up to the skill of the PM, not the methodology.
Agree. Part of it is the pact with the managers/rest of company not to come ask for new important work at random times. That they can understand that they can submit and it will get reviewed at the start of next sprint for priority by the dev team.
A good product manager should remove the need for the standups. A core part of my job is communicating with stakeholders on progress and shielding the devs from needless interruptions and change
from a new hire’s perspective, standups have helped me very quickly understand many different parts of the product without having to bother people with questions. it’s nice to be able to absorb information passively when in standups rather than having to constantly ask for help
I'd even argue that one person on the team, or a rotating group spending 15 - 30 minutes per day (2 people for that time) just talking things through with you is infinitely more valuable than stand-ups (5 - 10 people all spending that much time)
@@BrianFeister The "bigger problem" often being having a non-trivial application, with like, 10+ years of history. Then your approach would bring a developer up to speed in about, say, 3 years. That's given the expectation that the current team's knowledge covers the whole codebase, so probably add something like 2 years on top of that for additional research needed. Or you could have some kind of thing where people, like, meet up. Something where the current things being worked on are discussed. Wouldn't that be nice
@@raphaelschmitz4416😂 WUT?! Perhaps you misunderstood me to be saying that this onboarding should cover every line in the code base. I don't think anyone would recommend that. I'm certainly not
3:20 yes, sprints exist because we do not communicate and will disappear for 6 months and never talk to anyone if given a choice. EDIT: This was a great video and article
This is basically why I don't mind a twice-weekly standup Teams call. When I kind-of sort-of need to talk to a colleague, and especially when I don't know exactly whom, I know the occasion is coming in the next day or two when I can get that sorted, rather than having to defend my decision to interrupt someone. Others who are less socially inept may not see that as a benefit, but it's been a godsend for me.
@@glarynth For me I love a chatroom standup - like a standup meeting it's daily but it's just a message in a team chatroom that everyone knows to check daily so everyone knows what is coming up/what's blocking and help out if they have the knowledge, but unlike a scheduled meeting it doesnt hinder anyone and works asynchornously so international teams can pitch in together as well
Scrum was created because companies took too long to get feedback from customers. Then Jeff Sutherland wrote the book “Agile: Doing twice the work in half the time” and the downward spiral of misinformation began. A well run scrum team is actually amazing. Unfortunately we’ve had two decades of developers who have never experienced one. So their reaction to its usefulness is (understandably) takes like this.
Exactly. It’s amazing when it works: devs have more input into planning, estimates are more useful, users are happier, everyone has more visibility into the actual progress of the project, and the process saves more time then it consumes. But it requires everyone to take it seriously, at least one person who really understands it, and some tweaking to best fit the unique character of the team. If you impose too little of it, it just becomes an annoying time waster. If you dogmatically impose it all as a mindless ritual or article of faith, it becomes an oppressive burden. Really, it’s like anything else in software, any programming paradigm or design pattern or whatever: you have to understand how it actually works (and how it doesn’t!) and you have to pay attention to how it’s actually working for you in practice.
Prime, I think you need to see a corporate non-tech job to see to what point what you do is not what most people do. The idea that your boss is going to let you organize yourself, choose your tools, and act in a supporting role and protect the team is SO rare outside of tech. Lots places micromanage and direct top-down, and leave very little autonomy to individual workers. There were valuable things from agile, but Scrum is not one of them because Scrum is not agile, Scrum is Agile™. If agile development is electronic music, Scrum is Skrillex. It has very little to do with the rest of the bunch, it annoys everyone involved, and it gives very bad press to anyone related.
This is why I'll always say this about him. He's great if you want to learn about programming. He's awful for anything else. He's got no idea how anything works beyond FAANG, and even then only Netflix.
Some fields, mainly one that requires craftmanship, do works like that. Most of the constraint come from standardization, which in effect requires you to work with certain methodology and using certain tools. Beyond that, and for specialist role, AFAIK his description still applies for "good job".
You'd be surprised how normal that is for culture within a business, we have guidance that if there is no visible value to the meeting we don't have to attend, so the people learnt very quickly to get to the point as we have more important stuff to deliver.
That's so true that hurts! When things go bad: 1- we first need to talk with each other to understand the problem, make a plan and try to make a time estimation, then we go to the manager to explain the situation in corporate, and lastly there will be the real status report meeting with the client. There was a time when 1/4 of my hours where about meetings
We have meetings about upcoming meetings, where we discuss what we want to discuss in the actual third meeting that concludes with nobody knowing what to do because the team lead is just complaining about losing their face while making promises to the customer which all of us tell him won't be possible to achieve.
Burnout is often the result of the stress that you experience when your expectations don't align with the actual results of your work. At some point your body starts telling you, that this is pointless and you should stop doing this. Now if your whole work environment is implying you're moving fast and all you actually do is running in circles, this will burn you out. If the approach would be more relaxed, this will align the expectations with the reality of software development being a slow, iterative process and most people will be able to cope with that way better. Also, on that note, the amount of hours is not necessarily a source for burnout, however, if what you're doing with your time misaligns with your expectations of what you want to do with that time and you'd rather do something else instead of working another hour, this can and at a certain point will lead to burnout. Burnout isn't about the quantity of work, it's about how you perceive the outcomes of your time and energy investment.
This is a very astute and accurate description of what burnout is. I'd not thought of it in this way. We value our time and our professional identity such that we expect outcomes of ourselves that matter...and when the system we're in actively /prevents/ or just enedlessly frustrates, burnout and dissatisfaction, then existential crisis occurs quickly.
Scrum loves Burnout though. Everytime you have a successful sprint you raise the velocity. And if a sprint fails you have hours of tiring meeting on what went wrong and how we all can do better and that it is actually Coronas fault. The fun thing about Dailies is that no one is listening anyway.
That's not how it should work though, the velocity is meant to work out what your teams capacity is at a consistent rate, and once it stops increasing you've found the sweet spot. The metric is meant to be used to account for illness, holidays etc... so you know how much your team is capable of, not just something they can keep upping. The business will have misused this as a metric for delivery, it happened with my company for a period till they learnt the hard way that's not how it works. There is only so much a team can achieve so it's impossible to keep increasing the velocity. If you are not listening in dailies then a discussion needs to be had about what needs to change to add value to them, the whole point is to remove anything that isn't adding to the value and improve where there can be value added.
What fascinates me is that all need to do scrum these days but nobody knows how to do it. You have story points that are well known when you work a long time in a team and reflects the time of a ticket with a factor. So you give the tickets story points... when atlassian tells you the sprint is full, then it is FULL. Cramming extra tickets in it does put you up for desaster. And throughput is the uncertainty factor that is 0.7 (consider IT issues, sicknesses, unpaid leave because of "reasons", etc.)in an average team and 0.9 in a team full of extreme experts that work perfectly together and all are having a blast (at the same time). In reality because of management it is more 0.6 to 0.5. So time-needed = (sum of story points)/ velocity / throughput = time-of-sprint. But management will always try.
@@EdwinMartin As if that ever happens.I have been to retros where peoiple have all listed their complaints, then voted on them and the low voted copmplaints were just discraded. I also have been to retros where a problem was correctly identified, an hour was talked about it, a new meeting was scheduled about the Problem. And nothing changed.
@@Nickname863As a team decides other problems are more important, then those problems should be addressed first. If you have a meeting about a problem, then it should end with a solution. If that's not done then that is not "Scrum"s fault. And you can always expose the problem again (or the fact it isn't resolved right).
It depends on the work environment if scrum works. About using slack over standups: that only works if your team members can context switch quick. If someone can not or is easily distracted by it, then using slack is terrible. I also worked in a company where nobody knew what the other guy was doing and i was like: i miss something like a standup
All of your arguments hold true if you're working with mostly experienced developers. If you've got many juniors and/or your experienced people are introverts that don't want to manage juniors, then you need some sort of rules to make sure people won't dissapear for two weeks and get nothing done, because they don't ask anyone when they get stuck. I've seen it happen many times. Also yes, SCRUM comes from a time before Slack/Teams/Discord. It's a framework for teams with *no other method of communication*.
I've been saying this for years now. With modern communication tools Scrum is outdated. We have chatting apps, video conferencing apps, live shared files like Google docs wanna and Office 365
It is extremely hard to develop a complex product with pure anarchic principles. You get a lot of going in circles and design-by-committee, and there is rarely a strategy for resolving blockers. When everyone is the owner, nobody is the owner. When everyone is accountable, nobody is accountable. I'm not sure I know the answer, because it is honestly a very hard problem to solve. Typically you just start with the brightest and best visionaries at the top, and the genius will trickle down until the org is so large that it becomes diffuse. The age old problem is this: who get's do decide who is the brightest and best visionary? Most people fancy themselves brighter and better than they really are.
My problem is dealing with other developers and testers that encounter what they believe is a bug but somehow is only occurring on their machine and not others.. yet start fires without smelling smoke or check the door knob to see if it’s hot. I have witnessed countless time people on my team just say crazy assumptions about the very platform they’re supposed to know. Also will immediately jump to - ‘I think we’ve been hacked’.. and I have to explain to this fools why all the things they are pointing to are confined issues.. and most of the time it’s their browser loaded with extensions causing problems in JavaScript or become the extension is trying to get access to a protected field.. My day feels more like a daycare than dealing with experts.
It's comments like these that I feel like more and more people should spend a year in support to gain an understanding of how to properly troubleshoot situations, understand client behaviours, identify differences in client expectations vs designer expectations, and basic communication skills. There's always a source of truth to start at. Don't start at where the person says the problem is at, because that's just looking at the end result. Look at the data being sent, if it's validating correctly, if it's being sent correctly, then finally you should understand why a thing is happening. Currently going back and forth with a client who claims we're spamming their customers with emails trying to get an example of the email they claim we're sending. None of the data on our end says we're doing such a thing.
The number of supposedly experienced devs who refuse to read error messages is really shocking. I often end up needing to walk to their cube and see the error in person because getting them to actually tell me what the error says is such a pain.
Burnout is working 10+ hours unpaid overtime a week to try to keep a project on track because I deeply believe in it (it's a rewrite, it's a long story) and sacrificing all code quality and maintainability concerns to meet a customer-imposed deadline that is only an issue because the entire team was redirected onto a different dumpster fire of a project that meant this one (and even any maintenance on what it is replacing) was delayed for 2 whole years, then getting berated every week in the company-wide project status call because we're slipping because I underestimated the work to an extent, but mostly how long it would take the rest of the team to get up to speed. I shipped our first early-access to the customer this week, woke up the next morning (the UK just started a long weekend) knowing that the first day back will be another project status call where we will still be slipping. Both my manager and manager's manager will both be on annual leave so I'll have basically no support in front of the new CTO who spends most of his time questioning why the project even exists and is on a total crusade against any and all project slippage. A switch flipped in my head and now I'm updating my CV considering leaving software development altogether.
I'd say Agile's usage can accelerate burn out when you have very short sprints for the type of work and you feel like you don't have a second to breathe. You get a lot of "look we'll come back to it we don't have time."
One problem I see is that research / proof of concepts aren't being offered as valid "deliverables", nor partial or fake implementations. Also, people are too afraid to say "I don't know, we'll look into it". The "sprint" naming was stupid, should have been "iteration" or "cycle", and is a cause for a lot of this. The whole "sprint" concept should not even be visible outside the team, only some demo sessions.
I lived my whole life in Utah and am an avid skier and I can tell you for a fact that the ski resort where the Agile Knobs got together required you to be a pretentious douche. And that is the place where those Legends would form the skidmarked, toilet paper of a document, called the Agile Manifesto.
I disagree with article. I am no SCRUM or Agile evangelist. I really hate when people buy into those frameworks too much. I just think sprints are a "somewhat" useful tool. Sprints in my head is much more like what Prime described at 08:25. That is my preferred development structure as well. So while I think I am much more positive to Agile than Prime is, I don't think I disagree with him. I like sprints. I like sprint goals. Conceptually I like to compare software development with mathematical optimization. Optimization wants to find the optimal solution. Engineers want to find the optimal solution to a use case. In mathematical optimization a well used algorithm is gradient decent. Part of that algorithm is to choose a step size. In the development comparison, that step size is the sprint - a given time you take before you reevaluate. In Prime's example that is a week long. I personally prefer maybe 3 week long sprints. Tomatoes, Potatoes. As engineers we prioritize everyday and try to work with what is most important. But you don't want to have to update everyone around the team with changes in priority every day. Do that every now and again. Call that length the sprint. Update on what has been done, issues that has appeared, changes in priority, take input from outsiders/stakeholders - then move along. Saying that it is much more than that is unnecessary. It is not that much more than a recurring meeting in your calendar where others than the dev team is invited. It is just to save the time of ME - the guy in the team that the PO and Managers and all others come and ask all the time how something is going. Lets just do that once every now and then. It should not be longer than 30 min every 3 weeks or so. That is how it is for us atleast. And we avoid burnout by giving reasonable deadlines, good prioritization, interesting work and good teammates. It has nothing to do with sprints or agile imo. The important thing is that the result of a sprint needs to be able to change. It should be normal that you didn't reach your goal 100%. Maybe something you hadn't thought about appeared or took much longer than you had planned. Maybe the whole team had to switch prio and work with something really crazy that pooped up. What is important is that you update on these changes. If this only happens a few times maybe it won't affect the overall time plan. If goals are not fulfilled often then others around the team probably need to replan. That is a good thing, not a bad thing! As one of the more experienced developers in my team I need to be able to see if things are sliding way off from our planned course. I don't do this so that I can "pressure my teammates to work harder". I do this to be able to tell stakeholders as early as possible what results they can expect when. If they then go and ask for more things earlier, then fu-- em. Not to say a team shouldn't be responsible of that they are working effectively. A team should collaborate and work towards achieving the goal of the sprint. In my world that has nothing to do with sprints - That has to do with building good teams that work well together and create good things. (Btw I also hate tasks and stuff like that. You don't need to break things down more than what is needed for the dev team to know that they are not working on the exact same thing at the same time)
Your beef with agile is about the "ceremony" around it. But the underlying principles are great: - MVP: deliver something usefull soon rather then the "complete" product at the end of the contract. - Sprints: Only promise what you know you can deliver within a realistic time. You don't know how long you need for a big task and it's also not clear what that big task actually is. - Kanban: So everybody is literaly on the same page. Instead of defining interfaces at the start and then every group working for themselves. I am using this in SW and HW development, it's great. About your example with the roadblocks: sure in person would be better then waiting and wasting others time in the meeting. But there is also the worse option: Working around the roadblock in some fashion. Or having to escalate it because the roadblocker would not move. A fixed meetingslot to discuss issues can also be a benefit. Does not mean you should wait everytime of course but setting up a meeting with all involved can also take long. Escpecially if one party is not coorporating and declines.
I like agile but don't agree with daily's. The team should be working in an open office where they can just ad-hoc communicate all day. If you need to bridge teams, then have team lead meetings. Avoid rituals.
"Only promise what you know you can deliver within a realistic time" Sure, although it's usually better for the business relationship if you consistently underpromise and over-deliver!
The worst thing in programming is Agile being equated with Scrum, and even Scrum recommends individualization (which "agile coaches" have turned into "do these additional things", so they can sell their training sessions).
Kinda disagree with the code is docs part. Not being able to find out what is going on from business perspective by reading the code is super frustrating. Especially if you are looking at some Kitchen Nightmares spaghetti. The functional behavior of code does not always reflect its intended workings in the real world. Docs are not always necessary if the code is fairly clean, modular and well-named, but that is unfortunately not always the case.
@@mattymattffs Exactly, docs are for everyone else. Typical developerbrain not caring about anyone else and "busywork" and just wanting to mash out spaghetti code all day.
@@mattymattffs You are mixing up different kinds of documentation. This is obviously about code documentation and not about -documentation. The latter should also not be done by developers unless it's an API documentation for other developers. In all other cases, code documentation should be obsolete due to good code. Documentation for non-developers should not be done by developers.
Hot take, and I may write an article about this, agile is decent. Agile is the worst method for developing software except for all the others that have been invented. Engineers with above average technical skills, and specially so those that occupy senior non-management positions, are very critical with agile. However, imo it is the best way to manage an average software engineering team at the average company.
imo peoples problems with systems like this usually actually come down to good boss vs bad boss. good bosses are few + far between but dang when you get one it is eye opening
So I'm in my first software job and I'm shocked my how accurately XGH describes how people work there. I thought it was just "the real world" vs what I thought was ideal, but now I know people just don't care and are living out this meme😂
Same for me. Funny to find such a perfect description of our process. You will soon come to realize how much of a "big-tech bubble" Prime's takes come from compared to enterprise software development.
We have a daily stand up that exists to determine delays, blockers, and if they don't have anything to work on. It feels pointless, but it makes it easier for the person that organizes this. It's 15 minutes at most. It's so the person can determine if the roadblock is something that must be prioritized or not. Delays let them know when customer expectations need to be tempered or managed. Shifting work is easier when you have everyone responsible for the task there. It's an ok meaning and starts the day. I don't love it or hate it. I accept it.
Similar here. But in my experience daily standup up is most useful of all meetings (grooming being second). Standups prevented so many blockers and reworks in my experience that I would need many extra fingers to count them all.
I think they're most useful to find that dev that's been working on the wrong thing the wrong way. You can't show up and just say nothing, and if you say you're doing the same thing every day, or you're doing a second thing without the first being pushed prior start asking questions.
See the issue I always see from people critiquing agile or scrum is his take of “ I will just work with the people I need to work with and get stuff done” the issue with that is it assume high performing individuals. As software has scaled, there are now more C players than A players. Agile isn’t for the A players, it’s to squeeze out as much value out of the C players. I also find the C players are the ones with Dog stories.
It's also assuming that every person you are interacting with is not a single point of failure, the silo of knowledge and that they can spare you the time. The business delivery and capacity has to match that ideology too. I think it's about leveraging what works for you and your team and not bad mouthing on stuff you don't agree with just because it didn't work for you.
Do you really get that much more value off of C players by having them waste 5 hours a week on pointles stand ups and having requirements constantly change under their hands every 2 weeks?
Scrum is a natural outgrowth of the man-month fallacy. Software dev doesn’t really scale that well to begin with, so you usually get microservices matching the organizational structure rather than a cohesive monolithic system. One a system gets big, the temptation is to hire more people, but you have diminishing returns of each hire. Then the thought enters that maybe more management will help to extract more value from each dev, when the real problem was that you could never possibly have the cohesion necessary from a team that large. Software development cannot move faster than a certain speed (we’ll call it c)
@@martintvrdik1655 why does everyone come back with 5 hours of stand ups? They are meant to be 15 minutes, if you're doing 5 hours they are not stand ups they are meetings. Requirements change no matter what you implement, we have it that if it changes then it either gets kicked out and delivered later or we deliver what is agreed and the change happens later.
Burnout happened to developers when the person introduced scrum or agile has no idea how bad it is and when the dateline or quality not met, they blame the developers.
I'm so glad I'm not the only one who saw eerily valid approaches in some of the axioms! And it comes from someone who's on the more analytic/structured/maintainable/clean side (love code for the sake of code) - I just refactored a perfectly working, single purposed, embedded script last Thursday because I couldn't stand it was relying on global state.
We need less silos! Collaboration is the key to velocity! 1 month later... we are missing too many commitments due to all the distractions! People aren't managing their time properly!
@@isodoubIetI didn't say you need to do things quickly to make gambiarras, I said if you're being completely reckless it's going to happen. Doesn't mean it's the only way to make them.
6:15 all of this you mentioned "and you are constantly never making progress" is great for some devs that want to be code monkeys. You just churn your tickets at a steady pace and don't care about anything. Some people enjoy that they don't have to think and can constantly give like 70-80% of their effort. Nobody is getting punished for anything because clearly tickets on the board are being resolved, so work is being done. The fact that project isn't moving, nobody cares about that because "clearly" work is being done because tickets are moving on the board and going into different statuses. I got partially burned out because I worked in such an environment and I was a 110% effort dev, not 70-80% effort one.
7:00 - "Scrum is an implementation of Agile - an attempt to codify Agile into a set of things people can do." This is true, but literally the first point in the Agile Manifesto is "Individuals and interactions over processes and tools", so Scrum (with it's focus on rigid ceremonies/processes) is a pretty piss poor attempt at codifying Agile. In fact, codifying Agile at all kinda goes against Agile. Self-organizing would be preferable.
This guys gets it. Very few people actually do. Even the most staunch agile advocates are typically dogmatic, uncompromising and are really just fanatics of their 'one true agile methodology'. It's entirely understandable why so many people hate agile, because when people apply it ritualistically without actually understanding the purpose for why they are hand-waving, then it certainly does seem like it's a shitshow, because it is. It is especially bad when a manager who only knows waterfall decides that the team should switch to agile, and because they don't know shit about it except buzz, they just force the team to implement scrum, because that is the only thing they ever heard about agile.
I’m listening to this while doing chores. This sounds like a bad trip fever dream. And yet it sounds just familiar enough that my brain is trying to follow along 😵💫
If you're waiting for a meeting to bring something urgent up, then that is just going to slow your team down. If something is not urgent, then just put it in an issue tracker or send someone an email that they can check when they're not in the middle of working on something. Problem solved with no unnecessary meetings.
Me: "Hey, I am stuck with X, can you help me out?" Teammate: "Sure but I am busy now. I will ping you when I am done, probably within the next 30-60min." Problem solved.
What I just love is these agile frameworks popping up "scaled agile" SAFe I think... Let's all get certified in busywork. Maybe before scaling it up you'd want to make sure it even works. I've heard mythical tales of it working, for me the project just goes best when the team is equipped with the autonomy, budget and resources to achieve a goal. Adding beancounters never created any more beans.
This article reads as so sardonic you can tell the author just hates how their company is managed. That's not necessarily Agile's fault. But I'm aware that I might just be peddling the No True Scotsman. I just happen to have worked at a company where Agile seemed to work somewhat well.
1:00 i disagree with you. In our team that was the definition of agile, our scrum master was a developer, so he knew what made no sense. Our agile mentality was not to just ship new stuff every 2 weeks, it was to set small term goal, and focus on small piece without trying to make big breaking changes. The small set goals allowed us to react to the users's feedbacks and to new bugs that get discovered (also to made the stakeholders happy, we know that is agile goal lol).
I like stand-ups when they're done well / correct: Everyone is there, and you just say I am working on this ticket, and will need this person today/will block me. These meetings are like max 15 minutes for 5 people (our norm is ~10 minutes including random off-topic chat the first two minutes as wait to join and just confirming days meetings). All it's there for is to guarantee everyone is on at the same time so one sync meeting for the day so everyone knows what teams needs are there and can plan for when needed (work full flexi time, so everything is async, have people start at 6am, others at 10am, just have to be there 10-12 window and if meetings for design that day, 1.30-3pm, so at least 4-5 hours overlap if needed). Bad stand-ups are when it's a status report meeting for PO/PM, usually don't even have them in the meeting if can avoid. Those end up as 30 minute meetings each morning, worse is if it's your tech lead that's doing that, who then makes stand-up into a planning session. Just write a message that will do planning after at e.g. 10:30, everyone can go prep for it / finish off task they are working on.
I once had a project where I had to be in two stand up meetings aday. Both would last an hour. The 1st one was for my main team. No one else on the team was working on my project. The 2nd one was not just for my project but other related projects that I didnt work on. When I tried to give short descriptions of what I did. Both my PM and Team Manager wanted me to be more expansive when I talked. Besides 45 secs, I did 15+ mins. It was not fun
The problem is beyond the methodology, it's that project management was designed with the intention of making it easier to develop good software but has been co-opted by non-technical leadership who are suspicious of developers because they don't understand the work and don't care about quality, they just want to to smash something together which makes the bottom-line more presentable.
Do that. See how many interruptions you will get reading that. Then keep it, but add standups. In my experience standups often solves blockers before they happen and saves time on reworks when implementation goes of the rails.
I'd love to be part of 15 minute sprint meetings. Ours take like 1h 30 minutes as everybody has to present their progress during the sprint as well as the current problems and challenges and then discussions arise how to solve those. While PMs usually ask for a time estimation on certain issues, they then assign certain time for tickets on their own and so an issue that was evaluated to take like 2 days is then given 6 hours to complete (usually with the hint to add proper tests later on and just focus on the quick and dirty implementation). PMs then often wonder why so many issues are delayed. Oh, not sure if this is common to us only, but most of us devs work on 2-3 different projects during sprints side by side each with their own PMs and time schedules. We are supposed to work 40 hours a week and each of the projects assigns you work for 20-25 hours per week on that sprint. Stuff you can't do within your 40 hours of work are expected to get done during off-hours (and basically unpaid). I've seen therefore some colleagues who went on to quit and start somewhere else. Sprint reports at times also end up in a blaming and shaming contest as no one wants to take the blame for certain shortcomings or bugs, which mostly occur due to a lack of time and the requirement to deliver quick and dirty solutions that aren't really maintainable over time. This didn't help to improve the mood within the team TBH and I mostly blame PMs here as they have their own "tight" schedules and requirements which they just pass on to the remaining team and at times if feels like they think we (gu)estimate time on certain issues with a lot of wiggle room and otherwise lean back and enjoy life. Don't get me wrong, IMO the #1 reason why so many software projects fail is due to a lack of proper communication and not everyone having the same idea of what to do. Sprint reports at least force you to talk and listen to others. But IMO it is still a waste of time, at least the way we do it. I could be more efficient if I just write the guy responsible for a certain component that I need a change or that I created a MR which s/he needs to go through as part of our peer-review policy and that no-unreviewed code is allowed to get merged. But even with sprint reports some of the MRs on important flagged issues sit there for weeks waiting for others to review it and it is then my duty (instead of the PM) to ask those people to review the changes, request changes or apply it to their codebase. That usually stems from a fact that everybody is constantly working on various projects which are considered high-value by the PMs and no time is actually planned for reviewing others work. At times PMs seem to estimate that a proper code review only takes 1-2 minutes and can be done while taking a short break from the actual work. I even had a discussion with a PM who didn't want to accept that code reviews are actual work. He claimed that this can be done during off-working hours and shouldn't be done during paid time ...
"Agile" is a buzzword like crypto or AI right now. Bad managers say "we do Agile" to make shareholders happy. I just had a manager blow easily 20 hours in a single sprint on planning meetings. That's not Agile. That's jot waterfall. That's just incompetence. This manger basically said, we're not going to get proper planning, so just do something this sprint and we'll work more next sprint. That's like telling a construction worker don't worry we know nobody poured a foundation, but we're going to build anyway. Don't blame Agile when this project fails. It was bad management. I've also abaolutely caught them dragging out Friday meetings to 5pm even if they have to run one meeting for 4 hours. Not like they're pretending to work so they can clock out. No they're managers. So ovviously this time is necessary.
We introduced sprints to reduce external noise. It is a bandaid to a bigger managerial problem, but it helped reduce the stress from constant input from every angle, where the people who scream loudest gets their issues looked at that day. With sprints we block out 2 weeks at a time and anything coming in is just added to the backlog. It has made working a lot more manageable.
The main problem with agile and scrums is assuming that this is for programmers. BS. It's for business, for delivery value over time and not at the end where you realise that this is not even close to perfect. Nobody wants to pay programmers for code that is beautiful and elegant, just for code that works. Decrease tech debt, refactoring legacy/shit code, tests, pipelines all this Quality of Life for programmers things must be achieved inside of the team, you must communicate with each other and with management this needs. Nobody will do this for you.
Sprints are mini-projects, not simple timeboxed discrete pieces of work. Whether or not it makes sense to split a project into mini-projects determines whether or not Scrum is a good fit for you. Scrum is not an implementation of agile. I blame agile coaches and scrum coaches for the current state of "agile" and that people like Prime have no idea what they are talking about.
I like the stand ups. We have those team chats on slack, which the PM has access to....but it's still nice to have a short get together in the morning.
2 minutes in and a fully agree. It’s what i always say: “in the 90e we just agreed upon what we wanted to deliver and we worked on it. Of things were unclear or we got stuck we just walked over and discussed it. If it meant dropping or changing a feature we would inform the manager. Perhaps he came up with new ideas if not fine” we were hellishly more efficient and effective than all these idiotic set out processes like waterfall or agile. It’s just common sense
We have stand ups, because it makes us have conversations and realize things much earlier than we otherwize would. Also, it's nice to force eveyone to stand for 15 minutes a day. Also, development of solutions for a customer, is like 70% discussion anyway, it's not a waste of time, as long as real discoveries are the goal, and not just getting through a seremony. Anything good will always turn into just seremony in most places. The most important part is that one constantly evaluates what one is doing, and wether it works, first and foremost if it works to make a good workplace where people enjoy participating, and secondly wether it speeds up or speeds down progress towards the business goal.
Holy shit, this is what the company I'm at is doing and we're migrating legacy code, is my ship sinking? we don't test, we don't document and we don't do agile crap, and we have hundred thousands of people using our system.
No tests at all is probably a bit much. Having at least a few "smoke detector" tests let's you throw code together without wasting time running through the major parts to avoid being embarrassed that you broke everyone. Making it a requirement for a feature is pretty dumb.
Agile sucks. You have to pretend to guess the timeframe of every task. We never go over 10 points per sprint in case of unpredictable occurrences, but even so I'd say easily 9 out of 10 times our roadblocks lie outside of our control, like firewall rules or lack of permissions for whatever. We can't pretend to predict how long that's going to take to solve, especially when you have to waste time opening a support ticket and also starting an email chain to have more visibility and scream HIGH PRIORITY so that the people in charge of clearing the roadblock would actually do their job. Not to mention your QA team, even if I spend time a great deal of time detailing all of the changes, carefully explaining how to debug with screenshots if needed, I'll still get the "How do I test this?" during standups. Granted I have no problem jumping into a call to explain, but at least don't wait a few days to notice you've been tagged for QAing shit, basically jeopardizing the stupid useless predictability score. We obviously have to finish our work diligently, however there's also a lot of downtime if some of the team members are in different time zones, for which Agile doesn't give a shit about. /rant
The problem is in Agile everything becomes a HIGH PRIORITY for the exact same reason you mentioned and when everything is HIGH PRIORITY then NOTHING is.
Just a note: agile does not require tasks, or pretty much anything people associate with it; it's just about working code first, documentation second, and about communicating with people, especially the customer / user (you can go read the Agile manifesto online). In fact, one of the tenets is "people over processes", which the corpo mindset of "Scrum everywhere" works against. I do like tasks / User Stories myself, simply as a somewhat well defined list of TODO tasks, but estimating them is pointless. The only estimation that has any value is "can I maybe do this in 2 days?". if the answer is not, then split the task (e.g. to research and PoC tasks). Velocity tracking, etc. is also pointless; if management wants to know how long something will take, you can do a projection based on tasks completed / created after a few weeks. QA should not be a separate team, they should be your "pair programmer". Automated tests are for regression testing, QA is for exploratory testing.
@@errrzarrr LOL. Thats about the exact opposite of what Agile is about. You should be ruthlessly prioritizing based on market or customer need if you’re going to be effective. In fact, in the Scrum (one Agile framework) Focus is a stated value. Cant focus on everything!
1:00 yikes this is where agile has gotten to? OGs remember that this was what agile came to supplant SDLC for...3:20 it was a reaction to a really heavy development stream where people would deliver even *less* and talk about the plan even *more* before writing code. i remember writing pages of technical documentation to be reviewed by my peers weeks, maybe months, before i wrote down a line of code, let alone checked it in...
If you only work on small kinds of problems, it is possible to make progress in a sprint. But hard problems just don't fit into sprints, I don't care how long you make them. The hard problems are the more important ones. People like sprints because it feels good, some people like checkboxes. But software developed to checkboxes is very horrible indeed.
@@username7763 You split big hard problems into smaller ones. It sounds like most of problems people have with sprints are incompetent scrum masters/analysts.
@@lifebarier Absolutely best to split problems where possible. The longer it takes to make a big change the riskier it will be. But lots of problems just don't split well into sprints. Trying to make them fit causes more problems.
first of all brazil mentioned LETS GOOOOOOOOOOO second of all the way prime says gambiarra is actually so funny, it makes it sound like something fancy
You know who creates the tickets in Kanban/Sprints for the Team to work on? The Team itself, i.e. Developers + PO. At least, that's how we do it. Developer says X needs some work with high prio? It's discussed and probably goes in the next sprint. The process is there for the team. Not for the customer. Not for the management. If management does insist on regular status updates, you can call them "Sprint Reviews" or "Bi-Weekly Status update" - does not matter.
Regarding your final question - He's comparing what Agile should be against what it usually becomes. It should be a flexible way of writing code that can adapt to changes in demand. What it usually ends up is a bunch of ritual crap that then devolves into blunderbussing the problem repeatedly until it turns into some semblance of a shippable product and either that works or it sinks. And it's usually the latter, because jumping ship mid project becomes a must if you want to survive.
When your product owner is on PTO and not having to give an update feels like a vacation day…
for me it's my efin manager that breaks my balls. every. day.
The literal handbook on agile says standups should be max like 15min. If everyone says they're good with work on slack, you shouldn't even meet. Everything else is bad management.
The standup is not to inform the PO on status. It is by and for the devs.
@@-Jason-L Some of us are not so lucky my friend
What a relaxing day at work! Instead of working, I finally was productive and shipped some code! Feels great! 😅
The best way to run a marathon is starting the race at 100% of your max speed and slowly over time increasing the pace
Have to say for ours we started way below our capacity as we didn't know how much we could achieve, we've slowly ramped up and now have a consistent capacity which does not change upward, only down when people are off or ill.
That doesn't make sense. Maybe you're being sarcastic
@@Steel0079 no way, sarcasm is a conspiracy theory and doesn't exist. Don't believe everything you read online.
@@flflflflflfl I did a sarcasm once in the 90s. It got old real quick.
I also wonder if this is a sarcasm?
Standups are there to make sure people get out of their beds and start working
Facts lmao
Look my sleep schedule is broken ok I do get work done but not really between 9-5
100% - I gotta wakeup to just make standup.
That, or it's to make sure they worked on at least something the day before (or current day if standup is in the afternoon)
Still waste of time
Rule of thumb: The first 80% of work take 100% of the time and the last 20% take just 100% of the time again.
“If the code compiles, that’s enough”
RUST MENTIONED
That's what I thought too 😂
I would put burnout simply.
Burnout happens when you're constantly moving fast, but you don't feel like you're moving anywhere...
It’s running on a treadmill until you get exhausted but someone else has the “off” switch.
Exactly. You are told that agile is about moving fast. And that quality doesn't matter. But the horrible quality of the app is why you can't move fast.
For me it is spending way too long on one thing. Shift requirements, rewrites, complications with tech stack, etc. It all builds up. At some point you just want that thing you are working on out of your life.
@@MC--- I just want people who introduce unneeded dependencies and abstraction because they are worried about something they don't even know if it is real and wont listen when you have a known solution to existing problems.
@@fulconandroadcone9488 You just reminded me of how a company I worked for used a 400kB time/date library for just a single method I rewrote in 20 minutes, saving all that bandwidth on each page load (if you don't account for caching)...
Funny the developer's life is indeed...
5:14 technical debt due to "moving fast" is a major contributor to burn out.
I have not yet met a person who didn't agree with me on the fact that people in the IT industry should not only take, but be forced to take 1-2 week vacation every at least 2-3 months.
You would be surprised by how much the productivity jumps due to this seemingly waste of time from the corporate perspective. As it turns out, people work 2 or even 3 times better when have the energy to work... Who would figure? And generally that energy coming from frequent breaks easily offsets the time off due to how much better your employees feel.
I have a little over 5 years of experience. I have tons of passion for the software engineering but technical debt is QUICKLY draining me. I often feel like I'm one of the only people on the team who actually gives a shit. Every time I hack something together in 2 hours, I get high praise. When I take my time and craft an elegant and bugless solution over the course of a week or more, I get asked why it took so long. It drives me fucking insane.
@@bedtimestories1065 ah reminds me of me fixing a bug by reverting a file in a way that you can follow the flow just to fix another bug along the way.
@@bedtimestories1065 the disconnect between developers and management is insane. They want a house built as fast as possible even if it means the house collapses from a bad foundation and lack of proper load bearing.
@@shapelessedlooks like contemporary managers don't know basics of work force recovery. It was the thing in 1900 to improve productivity of workers. Also hobbies did the same effect. All these scrum, agile and etc look as reinventing a wheel with different names.
The most shocking part of this clip is the fact prime is sitting on a dining chair. That blew my mind, can we donate the man a desk chair.
I have a wooden chair. Have to stay uncomfortably focused like in a fast food restaurant to write code fast af
It might be worth checking if he wants one. Someone like me will sit on all sorts of things, even with a desk chair available.
On some stream he mentioned that it's the most comfortable way for him.
He had a fitness ball but he popped it.
Sitting in uncomfortable chairs or standing up is part of XGH, you're so much more productive that way
Every Agile process, under pressure, becomes Extreme Go Horse.
Like a diamond really.
I'm caught in the opposite hell currently. We have a massive deadline but due to the inefficiencies of scrum has I don't find myself being as productive as I should be in order to get this God damn job done. Meanwhile all my managers and team lead are acting calm like everything is fine that it's okay that I have a massive task stuck in PR review and I'm stuck waiting anywhere from a few hours to entire days for someone to review it so I can merge it and move on and hit the ground running on the next task.
And when I tell them how fucked that is given the deadline coming up I get gaslit by my managers that it's fine And it's not anyone's fault.
I've finally decided and say fuck it and complete the other stories by myself and have them setup in queue to be merged without giving a damn about the sprint cadence cause shit needs to get done and I'm sick of scrum holding back productivity.
I swear I was way more productive at work when I was new grad / junior when I was simply allowed to fly by the seat of my pants first and then have a senior tell me what I'm doing right and wrong. Now that I'm a senior working with a team of other seniors I still have the same drive and initiative as when I was junior but it's just constantly held back by rigid protocols and this now overtly dogmatic approach to Scrum and project management. And if I break away from that dogma even in the most necessary extreme cases like this deadline coming up it's going to reflect poorly on myself because I'm a senior dev and should know better according to my managers and team lead.
@@MrIndiemusic101do stacked diffs, present them one by one and everyone is happy
@@MrIndiemusic101 that's where you get a second job a use the "spare" time to make double the income
I would be curious for Prime to do a whole video drawing out the whole process from start to finish on what is his ideal way of delivering software. A lot of these articles announce problems but still do not give a full picture from beginning to the end of the journey. From business to the deployment.
whatever his general ideal is, it might be close to good enough, but it still wouldn't work.
The true perfect way of working depends on the team. Each person is different, therefore each team is different. Even teams have different phases.
The wrong thing about these one-size-fits all systems is exactly that.
@@LangorithmicExactly this. IME every team does agile differently. Most do away with most of the ceremony, but some teams will actually add to it (say, a second daily standup) when they have problems with e.g. keeping people in sync. Some do it really well, and some are an absolute disaster… but IME when a team is an absolute disaster, it’s usually symptomatic of deeper issues.
Regardless of methodology, IMO a team should ideally start off pretty strict/formal and gradually relax/remove steps until they’ve found the minimum amount of structure they need.
@@nw42 That's a good perspective, I like it. I extended my ideas in my own comment, look for it sorting by Newest First
@@Langorithmic I used to be a manager at fedex. and the biggest thing I had to teach new managers was, as long as the workers are doing their job and doing it safety, your biggest goal is not to get into the way and prevent your boss from getting into their way. be their for them, protect them and they will get the work done. thats not to say you dont double check their work. but. dont freeking get in their way and always be available when they need it. that is the key to good management. be findable when needed, verify that the work is done well and prevent stuff from getting in the way. now, at fedex do to the physical nature, we did have daily scrums to help cover streaching and warm ups. but overall, if it was not for the streaching. I rarely had extra info, just the daily safety mention and listing any new postings for them to go after. basicly it.
100% confirm when you have regular standups, people wait till standup instead of just talking to you. We ditched daily standups and communication opened up. Chat on slack a lot, make adhoc meetings when there's tough decisions, plan goals once in a while. No artificial time windows or recurring rituals.
Waiting for the stand ups is weird. They are there for recapping, not spilling out problems and questions
Nice tip.
waiting for stand ups does reduce interrupting people who are in their flow state, but of course, if you cannot progress at all without input, then do ask
@@TomNook. Ideally it’s a daily planning conversation. No recap needed - the team developers talking about how they’re going to approach the day. Who can help with what, what’s getting in the way, etc. Unfortunately managers look at them as status updates. Ugh.
@@TomNook. Stand up is a status meeting for most folks. It's not about devs for devs. It's about devs for managers (who shouldn't be there but they always are because nobody can kick them out).
People forget Agile was a reaction to waterfall where you have planned 2 years spirals that would typically take 3 to 5 years. First 3 months was gather requirements, next 3 months design software architecture, 12 months develop, 3 months QA, 3 months integration that typically had issues.... Then if everything meets checklist, release the software and find out the users funny use it because their needs are now different or wasn't articulated correctly at the beginning....
You just described incredibly BAD waterfall management. That project was structured by an idiot.
Agile is just codifying what good PMs were doing anyway, and the problem with that is that people then follow it slavishly, which ruins any semblance of 'good'. *Exactly* like waterfall.
Good project management is about having a plan, regularly reviewing the plan, ensuring critical paths are ongoing and - crucially - reporting regularly upwards to a board that consists of user, supplier and sponsor reps. The thing that's always missing - agile or waterfall - is actual training / skillset / expectations / clear responsibilities for the exec board so they actually grasp their job. So if you're purely designing software, you ought to be regularly engaged with your user rep and testing / feedback cycles with their users. Waterfall does not stop you doing that. Idiocy stops you doing that.
When designing software, going slavishly waterfall or slavishly agile are equally stupid choices.
And this is why companies always pick one over the other - their executives are stupid, and always looking for a silver bullet instead of accepting that there are hard yards, you need to employ people you trust to do those hard yards, and your job as the exec if you want success is to monitor progress and back those people up by giving them clear things to aim for and space to do those hard yards rather than applying more and more pressure.
Waterfall is when the requirements were fully analyzed and the BAs understand it very well. Agile is when the POs do trial and error because they didn't understand what the users want.
@@jezlawrence720 sorry but I strongly disagree, I have not seen a good waterfall in my entire life it was always like the description above.
@@demotics2005 the users themselves most of the time are not sure about what they want ... that is the real problem.
you haven't seen bad agile. bad waterfall can be a money sink. bad agile is a company disaster.@@SuliXbr
I was happy to see sprints get adopted in my startup. For me, they were not for developer communication. They served two main purposes:
1 - gave management insight and a window into what is going on
2 - insulated the development team from chaotic changes
Prior to sprint, it was not uncommon to having shifting priorities every day and burn out was a real problem. Adding sprints to the equation and getting buy in from the PO added a buffer to the chaotic changes.
I agree with 1 but object to 2. Dragging developers through standups is bad for morale. Insulating developers is up to the skill of the PM, not the methodology.
Agree. Part of it is the pact with the managers/rest of company not to come ask for new important work at random times. That they can understand that they can submit and it will get reviewed at the start of next sprint for priority by the dev team.
A good product manager should remove the need for the standups. A core part of my job is communicating with stakeholders on progress and shielding the devs from needless interruptions and change
from a new hire’s perspective, standups have helped me very quickly understand many different parts of the product without having to bother people with questions. it’s nice to be able to absorb information passively when in standups rather than having to constantly ask for help
Well that's one of the biggest things stand-ups are meant to do, bring the other team Members up to date as briefly as possible
If your team doesn't have enough time to mentor and onboard you with these things one on one, you have a bigger problem than stand-ups
I'd even argue that one person on the team, or a rotating group spending 15 - 30 minutes per day (2 people for that time) just talking things through with you is infinitely more valuable than stand-ups (5 - 10 people all spending that much time)
@@BrianFeister The "bigger problem" often being having a non-trivial application, with like, 10+ years of history.
Then your approach would bring a developer up to speed in about, say, 3 years. That's given the expectation that the current team's knowledge covers the whole codebase, so probably add something like 2 years on top of that for additional research needed.
Or you could have some kind of thing where people, like, meet up. Something where the current things being worked on are discussed. Wouldn't that be nice
@@raphaelschmitz4416😂 WUT?! Perhaps you misunderstood me to be saying that this onboarding should cover every line in the code base. I don't think anyone would recommend that. I'm certainly not
3:20 yes, sprints exist because we do not communicate and will disappear for 6 months and never talk to anyone if given a choice. EDIT: This was a great video and article
This is basically why I don't mind a twice-weekly standup Teams call. When I kind-of sort-of need to talk to a colleague, and especially when I don't know exactly whom, I know the occasion is coming in the next day or two when I can get that sorted, rather than having to defend my decision to interrupt someone. Others who are less socially inept may not see that as a benefit, but it's been a godsend for me.
Really? How was that a great article? It was mostly a waste of time. I agree with your view on scrum though.
@@glarynth For me I love a chatroom standup - like a standup meeting it's daily but it's just a message in a team chatroom that everyone knows to check daily so everyone knows what is coming up/what's blocking and help out if they have the knowledge, but unlike a scheduled meeting it doesnt hinder anyone and works asynchornously so international teams can pitch in together as well
The mans constantly talking about ergonomics of his keyboard and then you see the chair he is sitting in 2:49
haha. now that you mention it
You do know he used to sit on a ball and also a real office chair, right?
@@XDarkGreyX so he downgraded now?
Scrum was created because companies took too long to get feedback from customers. Then Jeff Sutherland wrote the book “Agile: Doing twice the work in half the time” and the downward spiral of misinformation began.
A well run scrum team is actually amazing. Unfortunately we’ve had two decades of developers who have never experienced one. So their reaction to its usefulness is (understandably) takes like this.
Exactly. It’s amazing when it works: devs have more input into planning, estimates are more useful, users are happier, everyone has more visibility into the actual progress of the project, and the process saves more time then it consumes. But it requires everyone to take it seriously, at least one person who really understands it, and some tweaking to best fit the unique character of the team.
If you impose too little of it, it just becomes an annoying time waster. If you dogmatically impose it all as a mindless ritual or article of faith, it becomes an oppressive burden.
Really, it’s like anything else in software, any programming paradigm or design pattern or whatever: you have to understand how it actually works (and how it doesn’t!) and you have to pay attention to how it’s actually working for you in practice.
Prime, I think you need to see a corporate non-tech job to see to what point what you do is not what most people do. The idea that your boss is going to let you organize yourself, choose your tools, and act in a supporting role and protect the team is SO rare outside of tech. Lots places micromanage and direct top-down, and leave very little autonomy to individual workers.
There were valuable things from agile, but Scrum is not one of them because Scrum is not agile, Scrum is Agile™.
If agile development is electronic music, Scrum is Skrillex. It has very little to do with the rest of the bunch, it annoys everyone involved, and it gives very bad press to anyone related.
This is why I'll always say this about him. He's great if you want to learn about programming. He's awful for anything else. He's got no idea how anything works beyond FAANG, and even then only Netflix.
Some fields, mainly one that requires craftmanship, do works like that. Most of the constraint come from standardization, which in effect requires you to work with certain methodology and using certain tools. Beyond that, and for specialist role, AFAIK his description still applies for "good job".
You need to update your electronic music references, everyone loves Skrillex these days.
@@Oglokoog you know what they say “All my homies hate Skrillex”
I agree with everything except the Skrillex part 😉
Scrum masters are the marriage counselors of dev teams. I have yet to see a good one that needs it.
I like that one. It is up there with the 'f' in communism is for "food."
I've yet to see a bad one that was helped by one either. YMMV on if that makes the analogy better or worse ...
Scrum masters are not supposed to be a durable part of the team normally anyway
I swear sometimes though my team members are like "lets have a meeting about having a meeting".
You'd be surprised how normal that is for culture within a business, we have guidance that if there is no visible value to the meeting we don't have to attend, so the people learnt very quickly to get to the point as we have more important stuff to deliver.
That's so true that hurts! When things go bad: 1- we first need to talk with each other to understand the problem, make a plan and try to make a time estimation, then we go to the manager to explain the situation in corporate, and lastly there will be the real status report meeting with the client.
There was a time when 1/4 of my hours where about meetings
I am absolutely not joking when i say we have Sprint Planning Pre-Planning meetings at work...
Sometimes you get to have a meeting about a past meeting to discuss what future discussions need to be had.
We have meetings about upcoming meetings, where we discuss what we want to discuss in the actual third meeting that concludes with nobody knowing what to do because the team lead is just complaining about losing their face while making promises to the customer which all of us tell him won't be possible to achieve.
Burnout is often the result of the stress that you experience when your expectations don't align with the actual results of your work. At some point your body starts telling you, that this is pointless and you should stop doing this.
Now if your whole work environment is implying you're moving fast and all you actually do is running in circles, this will burn you out. If the approach would be more relaxed, this will align the expectations with the reality of software development being a slow, iterative process and most people will be able to cope with that way better.
Also, on that note, the amount of hours is not necessarily a source for burnout, however, if what you're doing with your time misaligns with your expectations of what you want to do with that time and you'd rather do something else instead of working another hour, this can and at a certain point will lead to burnout.
Burnout isn't about the quantity of work, it's about how you perceive the outcomes of your time and energy investment.
This is a very astute and accurate description of what burnout is. I'd not thought of it in this way. We value our time and our professional identity such that we expect outcomes of ourselves that matter...and when the system we're in actively /prevents/ or just enedlessly frustrates, burnout and dissatisfaction, then existential crisis occurs quickly.
"Sprint" and "Engineering" just do not fit in the same sentence in my world.
Scrum loves Burnout though. Everytime you have a successful sprint you raise the velocity. And if a sprint fails you have hours of tiring meeting on what went wrong and how we all can do better and that it is actually Coronas fault.
The fun thing about Dailies is that no one is listening anyway.
That's not how it should work though, the velocity is meant to work out what your teams capacity is at a consistent rate, and once it stops increasing you've found the sweet spot. The metric is meant to be used to account for illness, holidays etc... so you know how much your team is capable of, not just something they can keep upping. The business will have misused this as a metric for delivery, it happened with my company for a period till they learnt the hard way that's not how it works. There is only so much a team can achieve so it's impossible to keep increasing the velocity. If you are not listening in dailies then a discussion needs to be had about what needs to change to add value to them, the whole point is to remove anything that isn't adding to the value and improve where there can be value added.
What fascinates me is that all need to do scrum these days but nobody knows how to do it. You have story points that are well known when you work a long time in a team and reflects the time of a ticket with a factor. So you give the tickets story points... when atlassian tells you the sprint is full, then it is FULL. Cramming extra tickets in it does put you up for desaster. And throughput is the uncertainty factor that is 0.7 (consider IT issues, sicknesses, unpaid leave because of "reasons", etc.)in an average team and 0.9 in a team full of extreme experts that work perfectly together and all are having a blast (at the same time). In reality because of management it is more 0.6 to 0.5. So time-needed = (sum of story points)/ velocity / throughput = time-of-sprint. But management will always try.
So you have some complaint and then you complain about the meeting where your complaint can be addressed? 🤔
@@EdwinMartin As if that ever happens.I have been to retros where peoiple have all listed their complaints, then voted on them and the low voted copmplaints were just discraded.
I also have been to retros where a problem was correctly identified, an hour was talked about it, a new meeting was scheduled about the Problem. And nothing changed.
@@Nickname863As a team decides other problems are more important, then those problems should be addressed first. If you have a meeting about a problem, then it should end with a solution. If that's not done then that is not "Scrum"s fault. And you can always expose the problem again (or the fact it isn't resolved right).
I hate standup meetings. My team spends 90 mins on meetings a day - plus an extra 8 hour weekly meeting.
8 hour weekly meeting? What?
LOL what? I think all of my meetings for a week or a sprint are not 8 hours
That’s not a standup meeting, that’s just “meeting”, it has nothing to do with scrum and agile
That has a to be a typo surely lmao @@Pico141
mine aren’t 90 mins, but easily close to 45 minutes every day. All just to update a project manager who doesn’t understand what were doing.
My team at Vercel runs a daily update thread instead of a synchronous stand up meeting. Saves so much time.
As shown to me by a previous employer, Agile is a fantastic tool for lousy managers to gaslight engineers.
I've read this as "sprintf() - the Biggest mistake of software"
Hey, its me!
Now Prime is primed about gambiarra and Go Horse and won't be lost when coming to Brazil.
Also: Brazil Mentioned! #huehueBR
It depends on the work environment if scrum works. About using slack over standups: that only works if your team members can context switch quick. If someone can not or is easily distracted by it, then using slack is terrible.
I also worked in a company where nobody knew what the other guy was doing and i was like: i miss something like a standup
All of your arguments hold true if you're working with mostly experienced developers. If you've got many juniors and/or your experienced people are introverts that don't want to manage juniors, then you need some sort of rules to make sure people won't dissapear for two weeks and get nothing done, because they don't ask anyone when they get stuck. I've seen it happen many times. Also yes, SCRUM comes from a time before Slack/Teams/Discord. It's a framework for teams with *no other method of communication*.
I've been saying this for years now. With modern communication tools Scrum is outdated. We have chatting apps, video conferencing apps, live shared files like Google docs wanna and Office 365
It is extremely hard to develop a complex product with pure anarchic principles. You get a lot of going in circles and design-by-committee, and there is rarely a strategy for resolving blockers. When everyone is the owner, nobody is the owner. When everyone is accountable, nobody is accountable.
I'm not sure I know the answer, because it is honestly a very hard problem to solve. Typically you just start with the brightest and best visionaries at the top, and the genius will trickle down until the org is so large that it becomes diffuse.
The age old problem is this: who get's do decide who is the brightest and best visionary? Most people fancy themselves brighter and better than they really are.
you could just replace being paid by the hour with achievement based pay. Putting rewards on tasks completed.
Standups are about group accountability, and to manage folks who don't actually reach out and get help when they are stuck.
Sprints and Scrum literally drove me out of software engineering. Corporate malaise is a blight upon software.
what did you switch to?
@@lifelover69 after-school tutoring part-time is my current job.
Then you weren't made for se. The methods before were much worse even. Waterfall anyone?
Same. Saved some during COVID being over employed and now unemployed. Resigned due to scrum (it was literally on my resignation letter).
@@vorrnth8734 There are plenty of companies that don't use any of these gimmick workflows in se, they just aren't FAANG or FAANG-adjacent.
Im kinda lucky my department leader watches you and agrees to most stuff. So no useless standup meetings for me. Nice
My problem is dealing with other developers and testers that encounter what they believe is a bug but somehow is only occurring on their machine and not others.. yet start fires without smelling smoke or check the door knob to see if it’s hot. I have witnessed countless time people on my team just say crazy assumptions about the very platform they’re supposed to know. Also will immediately jump to - ‘I think we’ve been hacked’.. and I have to explain to this fools why all the things they are pointing to are confined issues.. and most of the time it’s their browser loaded with extensions causing problems in JavaScript or become the extension is trying to get access to a protected field..
My day feels more like a daycare than dealing with experts.
It's comments like these that I feel like more and more people should spend a year in support to gain an understanding of how to properly troubleshoot situations, understand client behaviours, identify differences in client expectations vs designer expectations, and basic communication skills.
There's always a source of truth to start at. Don't start at where the person says the problem is at, because that's just looking at the end result. Look at the data being sent, if it's validating correctly, if it's being sent correctly, then finally you should understand why a thing is happening.
Currently going back and forth with a client who claims we're spamming their customers with emails trying to get an example of the email they claim we're sending. None of the data on our end says we're doing such a thing.
The number of supposedly experienced devs who refuse to read error messages is really shocking. I often end up needing to walk to their cube and see the error in person because getting them to actually tell me what the error says is such a pain.
Burnout is working 10+ hours unpaid overtime a week to try to keep a project on track because I deeply believe in it (it's a rewrite, it's a long story) and sacrificing all code quality and maintainability concerns to meet a customer-imposed deadline that is only an issue because the entire team was redirected onto a different dumpster fire of a project that meant this one (and even any maintenance on what it is replacing) was delayed for 2 whole years, then getting berated every week in the company-wide project status call because we're slipping because I underestimated the work to an extent, but mostly how long it would take the rest of the team to get up to speed.
I shipped our first early-access to the customer this week, woke up the next morning (the UK just started a long weekend) knowing that the first day back will be another project status call where we will still be slipping. Both my manager and manager's manager will both be on annual leave so I'll have basically no support in front of the new CTO who spends most of his time questioning why the project even exists and is on a total crusade against any and all project slippage.
A switch flipped in my head and now I'm updating my CV considering leaving software development altogether.
Bro, don't leave, just leave that job.
If a manager/CEO/anyone thinks any Software Engineer can reasonable estimate, then they are the real dumb dumb.
21:15 I’m with you on embracing the chaos and not trying to rewrite every project I join.
I'd say Agile's usage can accelerate burn out when you have very short sprints for the type of work and you feel like you don't have a second to breathe. You get a lot of "look we'll come back to it we don't have time."
One problem I see is that research / proof of concepts aren't being offered as valid "deliverables", nor partial or fake implementations. Also, people are too afraid to say "I don't know, we'll look into it". The "sprint" naming was stupid, should have been "iteration" or "cycle", and is a cause for a lot of this. The whole "sprint" concept should not even be visible outside the team, only some demo sessions.
Sprints: running towards your own destruction
XGH: abstractions bad just write code
Midwit: we need to abstract everything!
Grug/Sr Dev: abstractions bad just write code
This man never highlights the first or last letter of what he's highlighting. Nonstop off-by-one errors.
I lived my whole life in Utah and am an avid skier and I can tell you for a fact that the ski resort where the Agile Knobs got together required you to be a pretentious douche. And that is the place where those Legends would form the skidmarked, toilet paper of a document, called the Agile Manifesto.
Amen, snowbird sucks.
I disagree with article. I am no SCRUM or Agile evangelist. I really hate when people buy into those frameworks too much. I just think sprints are a "somewhat" useful tool. Sprints in my head is much more like what Prime described at 08:25. That is my preferred development structure as well. So while I think I am much more positive to Agile than Prime is, I don't think I disagree with him. I like sprints. I like sprint goals.
Conceptually I like to compare software development with mathematical optimization. Optimization wants to find the optimal solution. Engineers want to find the optimal solution to a use case. In mathematical optimization a well used algorithm is gradient decent. Part of that algorithm is to choose a step size. In the development comparison, that step size is the sprint - a given time you take before you reevaluate. In Prime's example that is a week long. I personally prefer maybe 3 week long sprints. Tomatoes, Potatoes.
As engineers we prioritize everyday and try to work with what is most important. But you don't want to have to update everyone around the team with changes in priority every day. Do that every now and again. Call that length the sprint. Update on what has been done, issues that has appeared, changes in priority, take input from outsiders/stakeholders - then move along. Saying that it is much more than that is unnecessary. It is not that much more than a recurring meeting in your calendar where others than the dev team is invited.
It is just to save the time of ME - the guy in the team that the PO and Managers and all others come and ask all the time how something is going. Lets just do that once every now and then. It should not be longer than 30 min every 3 weeks or so. That is how it is for us atleast.
And we avoid burnout by giving reasonable deadlines, good prioritization, interesting work and good teammates. It has nothing to do with sprints or agile imo.
The important thing is that the result of a sprint needs to be able to change. It should be normal that you didn't reach your goal 100%. Maybe something you hadn't thought about appeared or took much longer than you had planned. Maybe the whole team had to switch prio and work with something really crazy that pooped up. What is important is that you update on these changes. If this only happens a few times maybe it won't affect the overall time plan. If goals are not fulfilled often then others around the team probably need to replan. That is a good thing, not a bad thing!
As one of the more experienced developers in my team I need to be able to see if things are sliding way off from our planned course. I don't do this so that I can "pressure my teammates to work harder". I do this to be able to tell stakeholders as early as possible what results they can expect when. If they then go and ask for more things earlier, then fu-- em.
Not to say a team shouldn't be responsible of that they are working effectively. A team should collaborate and work towards achieving the goal of the sprint. In my world that has nothing to do with sprints - That has to do with building good teams that work well together and create good things.
(Btw I also hate tasks and stuff like that. You don't need to break things down more than what is needed for the dev team to know that they are not working on the exact same thing at the same time)
Your beef with agile is about the "ceremony" around it. But the underlying principles are great:
- MVP: deliver something usefull soon rather then the "complete" product at the end of the contract.
- Sprints: Only promise what you know you can deliver within a realistic time. You don't know how long you need for a big task and it's also not clear what that big task actually is.
- Kanban: So everybody is literaly on the same page. Instead of defining interfaces at the start and then every group working for themselves.
I am using this in SW and HW development, it's great.
About your example with the roadblocks: sure in person would be better then waiting and wasting others time in the meeting. But there is also the worse option: Working around the roadblock in some fashion. Or having to escalate it because the roadblocker would not move. A fixed meetingslot to discuss issues can also be a benefit. Does not mean you should wait everytime of course but setting up a meeting with all involved can also take long. Escpecially if one party is not coorporating and declines.
Nice take! 👍
10000% agreed. I'm surprised prime is against this, I've been on dozens of projects and they are fantastic for all if done properly.
I like agile but don't agree with daily's. The team should be working in an open office where they can just ad-hoc communicate all day. If you need to bridge teams, then have team lead meetings. Avoid rituals.
"Only promise what you know you can deliver within a realistic time"
Sure, although it's usually better for the business relationship if you consistently underpromise and over-deliver!
The worst thing in programming is Agile being equated with Scrum, and even Scrum recommends individualization (which "agile coaches" have turned into "do these additional things", so they can sell their training sessions).
Kinda disagree with the code is docs part. Not being able to find out what is going on from business perspective by reading the code is super frustrating. Especially if you are looking at some Kitchen Nightmares spaghetti. The functional behavior of code does not always reflect its intended workings in the real world. Docs are not always necessary if the code is fairly clean, modular and well-named, but that is unfortunately not always the case.
But if code isn't yours then don't touch it: See 22
Code is not docs. Docs are docs. That's what the consultants and support and sales people need. You want them reading code?
@@mattymattffs Exactly, docs are for everyone else. Typical developerbrain not caring about anyone else and "busywork" and just wanting to mash out spaghetti code all day.
@@mattymattffs You are mixing up different kinds of documentation. This is obviously about code documentation and not about -documentation. The latter should also not be done by developers unless it's an API documentation for other developers. In all other cases, code documentation should be obsolete due to good code.
Documentation for non-developers should not be done by developers.
@@Asto508 code documentation being obsolete because of good code is a myth. Anyone that says that is lying. They just want the easy way out.
Hot take, and I may write an article about this, agile is decent. Agile is the worst method for developing software except for all the others that have been invented. Engineers with above average technical skills, and specially so those that occupy senior non-management positions, are very critical with agile. However, imo it is the best way to manage an average software engineering team at the average company.
imo peoples problems with systems like this usually actually come down to good boss vs bad boss. good bosses are few + far between but dang when you get one it is eye opening
So I'm in my first software job and I'm shocked my how accurately XGH describes how people work there. I thought it was just "the real world" vs what I thought was ideal, but now I know people just don't care and are living out this meme😂
Same for me. Funny to find such a perfect description of our process. You will soon come to realize how much of a "big-tech bubble" Prime's takes come from compared to enterprise software development.
We have a daily stand up that exists to determine delays, blockers, and if they don't have anything to work on. It feels pointless, but it makes it easier for the person that organizes this. It's 15 minutes at most.
It's so the person can determine if the roadblock is something that must be prioritized or not.
Delays let them know when customer expectations need to be tempered or managed.
Shifting work is easier when you have everyone responsible for the task there.
It's an ok meaning and starts the day. I don't love it or hate it. I accept it.
Similar here. But in my experience daily standup up is most useful of all meetings (grooming being second).
Standups prevented so many blockers and reworks in my experience that I would need many extra fingers to count them all.
I think they're most useful to find that dev that's been working on the wrong thing the wrong way. You can't show up and just say nothing, and if you say you're doing the same thing every day, or you're doing a second thing without the first being pushed prior start asking questions.
To be clear, I'm often that dev 😅
Agile has been bastardised; the English Ceremony analogy was perfect
See the issue I always see from people critiquing agile or scrum is his take of “ I will just work with the people I need to work with and get stuff done” the issue with that is it assume high performing individuals. As software has scaled, there are now more C players than A players. Agile isn’t for the A players, it’s to squeeze out as much value out of the C players. I also find the C players are the ones with Dog stories.
What about myself, the F people?
It's also assuming that every person you are interacting with is not a single point of failure, the silo of knowledge and that they can spare you the time. The business delivery and capacity has to match that ideology too. I think it's about leveraging what works for you and your team and not bad mouthing on stuff you don't agree with just because it didn't work for you.
Do you really get that much more value off of C players by having them waste 5 hours a week on pointles stand ups and having requirements constantly change under their hands every 2 weeks?
Scrum is a natural outgrowth of the man-month fallacy.
Software dev doesn’t really scale that well to begin with, so you usually get microservices matching the organizational structure rather than a cohesive monolithic system.
One a system gets big, the temptation is to hire more people, but you have diminishing returns of each hire. Then the thought enters that maybe more management will help to extract more value from each dev, when the real problem was that you could never possibly have the cohesion necessary from a team that large. Software development cannot move faster than a certain speed (we’ll call it c)
@@martintvrdik1655 why does everyone come back with 5 hours of stand ups? They are meant to be 15 minutes, if you're doing 5 hours they are not stand ups they are meetings. Requirements change no matter what you implement, we have it that if it changes then it either gets kicked out and delivered later or we deliver what is agreed and the change happens later.
Embracing the chaos is a lesson learned from a project I recently attempted to clean up.
Brazil mentioned 🏖🎉
So what?
The talk about Bootsies the dog literally spoke to my soul.
Earned a sub off that alone.
Burnout happened to developers when the person introduced scrum or agile has no idea how bad it is and when the dateline or quality not met, they blame the developers.
I'm so glad I'm not the only one who saw eerily valid approaches in some of the axioms! And it comes from someone who's on the more analytic/structured/maintainable/clean side (love code for the sake of code) - I just refactored a perfectly working, single purposed, embedded script last Thursday because I couldn't stand it was relying on global state.
We need less silos! Collaboration is the key to velocity!
1 month later... we are missing too many commitments due to all the distractions! People aren't managing their time properly!
Meetings will continue until time is managed properly!
@@adama7752 We need to have a meeting about time management. I'll put one on everyone's calendar for Tuesdays and Thursdays for an hour.
Agile is the word for not working efficiently. Managers and developers hide behind the word: Agile.
"Go horsie go"! That's where the term comes from. Just going as fast as you can with reckless abandon.
You also call this break-neck development... the outcome is in the name 😁
That's very weird though because "gambiarra" means absolutely nothing like that.
@@isodoubIetif you're "fixing" things with reckless abandon you're gonna make lots of gambiarras.
@@JohnDoe-bu3qp A gambiarra can be done slowly too. The term just means to find a janky solution with the tools you have available
@@isodoubIetI didn't say you need to do things quickly to make gambiarras, I said if you're being completely reckless it's going to happen. Doesn't mean it's the only way to make them.
6:15 all of this you mentioned "and you are constantly never making progress" is great for some devs that want to be code monkeys. You just churn your tickets at a steady pace and don't care about anything. Some people enjoy that they don't have to think and can constantly give like 70-80% of their effort. Nobody is getting punished for anything because clearly tickets on the board are being resolved, so work is being done. The fact that project isn't moving, nobody cares about that because "clearly" work is being done because tickets are moving on the board and going into different statuses.
I got partially burned out because I worked in such an environment and I was a 110% effort dev, not 70-80% effort one.
7:00 - "Scrum is an implementation of Agile - an attempt to codify Agile into a set of things people can do." This is true, but literally the first point in the Agile Manifesto is "Individuals and interactions over processes and tools", so Scrum (with it's focus on rigid ceremonies/processes) is a pretty piss poor attempt at codifying Agile. In fact, codifying Agile at all kinda goes against Agile. Self-organizing would be preferable.
This guys gets it. Very few people actually do. Even the most staunch agile advocates are typically dogmatic, uncompromising and are really just fanatics of their 'one true agile methodology'.
It's entirely understandable why so many people hate agile, because when people apply it ritualistically without actually understanding the purpose for why they are hand-waving, then it certainly does seem like it's a shitshow, because it is.
It is especially bad when a manager who only knows waterfall decides that the team should switch to agile, and because they don't know shit about it except buzz, they just force the team to implement scrum, because that is the only thing they ever heard about agile.
I’m listening to this while doing chores. This sounds like a bad trip fever dream. And yet it sounds just familiar enough that my brain is trying to follow along 😵💫
Having a dedicated time when issues can be brought up is in some ways better than having people interrupt each other at random times
If you're waiting for a meeting to bring something urgent up, then that is just going to slow your team down. If something is not urgent, then just put it in an issue tracker or send someone an email that they can check when they're not in the middle of working on something. Problem solved with no unnecessary meetings.
My experience was having both a dedicated time and random interrupts.
Me: "Hey, I am stuck with X, can you help me out?"
Teammate: "Sure but I am busy now. I will ping you when I am done, probably within the next 30-60min."
Problem solved.
What I just love is these agile frameworks popping up "scaled agile" SAFe I think... Let's all get certified in busywork. Maybe before scaling it up you'd want to make sure it even works. I've heard mythical tales of it working, for me the project just goes best when the team is equipped with the autonomy, budget and resources to achieve a goal. Adding beancounters never created any more beans.
This article reads as so sardonic you can tell the author just hates how their company is managed. That's not necessarily Agile's fault. But I'm aware that I might just be peddling the No True Scotsman. I just happen to have worked at a company where Agile seemed to work somewhat well.
I love how he was seriusly evaluating a meme with a serious face part way in.
1:00 i disagree with you. In our team that was the definition of agile, our scrum master was a developer, so he knew what made no sense. Our agile mentality was not to just ship new stuff every 2 weeks, it was to set small term goal, and focus on small piece without trying to make big breaking changes. The small set goals allowed us to react to the users's feedbacks and to new bugs that get discovered (also to made the stakeholders happy, we know that is agile goal lol).
Once, I saw "Extreme Go Horse" at the Whisky-a-go-go. Great show! 😛
Agile and sprints are designed to show points getting done and imply progress to management when you don’t know what you’re doing.
I'm glad someone finally said what we are all thinking but told we can't say
It's a cult.
I like stand-ups when they're done well / correct: Everyone is there, and you just say I am working on this ticket, and will need this person today/will block me. These meetings are like max 15 minutes for 5 people (our norm is ~10 minutes including random off-topic chat the first two minutes as wait to join and just confirming days meetings). All it's there for is to guarantee everyone is on at the same time so one sync meeting for the day so everyone knows what teams needs are there and can plan for when needed (work full flexi time, so everything is async, have people start at 6am, others at 10am, just have to be there 10-12 window and if meetings for design that day, 1.30-3pm, so at least 4-5 hours overlap if needed).
Bad stand-ups are when it's a status report meeting for PO/PM, usually don't even have them in the meeting if can avoid. Those end up as 30 minute meetings each morning, worse is if it's your tech lead that's doing that, who then makes stand-up into a planning session. Just write a message that will do planning after at e.g. 10:30, everyone can go prep for it / finish off task they are working on.
I once had a project where I had to be in two stand up meetings aday. Both would last an hour. The 1st one was for my main team. No one else on the team was working on my project. The 2nd one was not just for my project but other related projects that I didnt work on. When I tried to give short descriptions of what I did. Both my PM and Team Manager wanted me to be more expansive when I talked. Besides 45 secs, I did 15+ mins. It was not fun
Again, it’s not agile nor scrum, it’s a usual bureaucracy wrapped into a “scrum” terminology because it’s hype and new. Cargo cult
Bad management can ruin everything. Nothing is safe
The problem is beyond the methodology, it's that project management was designed with the intention of making it easier to develop good software but has been co-opted by non-technical leadership who are suspicious of developers because they don't understand the work and don't care about quality, they just want to to smash something together which makes the bottom-line more presentable.
The day i lead a project, I'll make this "igotfked" slack channel.
Do that. See how many interruptions you will get reading that.
Then keep it, but add standups.
In my experience standups often solves blockers before they happen and saves time on reworks when implementation goes of the rails.
Not surprised this article is on Medium
Prime reads manifesto; unironically derives sane version from it.
Extreme No Horsing
I'd love to be part of 15 minute sprint meetings. Ours take like 1h 30 minutes as everybody has to present their progress during the sprint as well as the current problems and challenges and then discussions arise how to solve those. While PMs usually ask for a time estimation on certain issues, they then assign certain time for tickets on their own and so an issue that was evaluated to take like 2 days is then given 6 hours to complete (usually with the hint to add proper tests later on and just focus on the quick and dirty implementation). PMs then often wonder why so many issues are delayed. Oh, not sure if this is common to us only, but most of us devs work on 2-3 different projects during sprints side by side each with their own PMs and time schedules. We are supposed to work 40 hours a week and each of the projects assigns you work for 20-25 hours per week on that sprint. Stuff you can't do within your 40 hours of work are expected to get done during off-hours (and basically unpaid). I've seen therefore some colleagues who went on to quit and start somewhere else.
Sprint reports at times also end up in a blaming and shaming contest as no one wants to take the blame for certain shortcomings or bugs, which mostly occur due to a lack of time and the requirement to deliver quick and dirty solutions that aren't really maintainable over time. This didn't help to improve the mood within the team TBH and I mostly blame PMs here as they have their own "tight" schedules and requirements which they just pass on to the remaining team and at times if feels like they think we (gu)estimate time on certain issues with a lot of wiggle room and otherwise lean back and enjoy life.
Don't get me wrong, IMO the #1 reason why so many software projects fail is due to a lack of proper communication and not everyone having the same idea of what to do. Sprint reports at least force you to talk and listen to others. But IMO it is still a waste of time, at least the way we do it. I could be more efficient if I just write the guy responsible for a certain component that I need a change or that I created a MR which s/he needs to go through as part of our peer-review policy and that no-unreviewed code is allowed to get merged. But even with sprint reports some of the MRs on important flagged issues sit there for weeks waiting for others to review it and it is then my duty (instead of the PM) to ask those people to review the changes, request changes or apply it to their codebase. That usually stems from a fact that everybody is constantly working on various projects which are considered high-value by the PMs and no time is actually planned for reviewing others work. At times PMs seem to estimate that a proper code review only takes 1-2 minutes and can be done while taking a short break from the actual work. I even had a discussion with a PM who didn't want to accept that code reviews are actual work. He claimed that this can be done during off-working hours and shouldn't be done during paid time ...
"Agile" is a buzzword like crypto or AI right now. Bad managers say "we do Agile" to make shareholders happy.
I just had a manager blow easily 20 hours in a single sprint on planning meetings. That's not Agile. That's jot waterfall. That's just incompetence. This manger basically said, we're not going to get proper planning, so just do something this sprint and we'll work more next sprint. That's like telling a construction worker don't worry we know nobody poured a foundation, but we're going to build anyway. Don't blame Agile when this project fails. It was bad management.
I've also abaolutely caught them dragging out Friday meetings to 5pm even if they have to run one meeting for 4 hours. Not like they're pretending to work so they can clock out. No they're managers. So ovviously this time is necessary.
We introduced sprints to reduce external noise. It is a bandaid to a bigger managerial problem, but it helped reduce the stress from constant input from every angle, where the people who scream loudest gets their issues looked at that day.
With sprints we block out 2 weeks at a time and anything coming in is just added to the backlog. It has made working a lot more manageable.
The main problem with agile and scrums is assuming that this is for programmers. BS. It's for business, for delivery value over time and not at the end where you realise that this is not even close to perfect. Nobody wants to pay programmers for code that is beautiful and elegant, just for code that works. Decrease tech debt, refactoring legacy/shit code, tests, pipelines all this Quality of Life for programmers things must be achieved inside of the team, you must communicate with each other and with management this needs. Nobody will do this for you.
Our sprint ceremonies were great - PM always got food for us whilst we were going through the agenda
win em over with snacks
Sprints are mini-projects, not simple timeboxed discrete pieces of work. Whether or not it makes sense to split a project into mini-projects determines whether or not Scrum is a good fit for you. Scrum is not an implementation of agile. I blame agile coaches and scrum coaches for the current state of "agile" and that people like Prime have no idea what they are talking about.
Ok...
I like the stand ups. We have those team chats on slack, which the PM has access to....but it's still nice to have a short get together in the morning.
2 minutes in and a fully agree. It’s what i always say: “in the 90e we just agreed upon what we wanted to deliver and we worked on it. Of things were unclear or we got stuck we just walked over and discussed it. If it meant dropping or changing a feature we would inform the manager. Perhaps he came up with new ideas if not fine” we were hellishly more efficient and effective than all these idiotic set out processes like waterfall or agile. It’s just common sense
Cowboy coding is the best.
(that's agile btw)
@@ChrisBensler but without the corporate bollocks of meetings, stories, story points and all that crap.
@@CallousCoder none of those things are actually agile.
@@ChrisBensler yes I fully agree those processes are anything but agile.
"Use Slack instead": literally suggested it in my last retro. We ran out of time to discuss it 😂
Just gamify software engineering and everyone will be excited again. Let me earn points for working!!!
We have stand ups, because it makes us have conversations and realize things much earlier than we otherwize would. Also, it's nice to force eveyone to stand for 15 minutes a day. Also, development of solutions for a customer, is like 70% discussion anyway, it's not a waste of time, as long as real discoveries are the goal, and not just getting through a seremony.
Anything good will always turn into just seremony in most places.
The most important part is that one constantly evaluates what one is doing, and wether it works, first and foremost if it works to make a good workplace where people enjoy participating, and secondly wether it speeds up or speeds down progress towards the business goal.
Holy shit, this is what the company I'm at is doing and we're migrating legacy code, is my ship sinking?
we don't test, we don't document and we don't do agile crap, and we have hundred thousands of people using our system.
No tests at all is probably a bit much. Having at least a few "smoke detector" tests let's you throw code together without wasting time running through the major parts to avoid being embarrassed that you broke everyone.
Making it a requirement for a feature is pretty dumb.
I switched from doing biweekly sprints to getting stuff done last year myself 😎
Why would you test it? Everything worked until you tested it
Hearing him say Gambiarra in the way he did was physically painful.
Agile sucks. You have to pretend to guess the timeframe of every task. We never go over 10 points per sprint in case of unpredictable occurrences, but even so I'd say easily 9 out of 10 times our roadblocks lie outside of our control, like firewall rules or lack of permissions for whatever. We can't pretend to predict how long that's going to take to solve, especially when you have to waste time opening a support ticket and also starting an email chain to have more visibility and scream HIGH PRIORITY so that the people in charge of clearing the roadblock would actually do their job. Not to mention your QA team, even if I spend time a great deal of time detailing all of the changes, carefully explaining how to debug with screenshots if needed, I'll still get the "How do I test this?" during standups. Granted I have no problem jumping into a call to explain, but at least don't wait a few days to notice you've been tagged for QAing shit, basically jeopardizing the stupid useless predictability score. We obviously have to finish our work diligently, however there's also a lot of downtime if some of the team members are in different time zones, for which Agile doesn't give a shit about.
/rant
The problem is in Agile everything becomes a HIGH PRIORITY for the exact same reason you mentioned and when everything is HIGH PRIORITY then NOTHING is.
Just a note: agile does not require tasks, or pretty much anything people associate with it; it's just about working code first, documentation second, and about communicating with people, especially the customer / user (you can go read the Agile manifesto online). In fact, one of the tenets is "people over processes", which the corpo mindset of "Scrum everywhere" works against.
I do like tasks / User Stories myself, simply as a somewhat well defined list of TODO tasks, but estimating them is pointless. The only estimation that has any value is "can I maybe do this in 2 days?". if the answer is not, then split the task (e.g. to research and PoC tasks). Velocity tracking, etc. is also pointless; if management wants to know how long something will take, you can do a projection based on tasks completed / created after a few weeks.
QA should not be a separate team, they should be your "pair programmer". Automated tests are for regression testing, QA is for exploratory testing.
@@errrzarrr LOL. Thats about the exact opposite of what Agile is about. You should be ruthlessly prioritizing based on market or customer need if you’re going to be effective. In fact, in the Scrum (one Agile framework) Focus is a stated value. Cant focus on everything!
1:00 yikes this is where agile has gotten to? OGs remember that this was what agile came to supplant SDLC for...3:20 it was a reaction to a really heavy development stream where people would deliver even *less* and talk about the plan even *more* before writing code. i remember writing pages of technical documentation to be reviewed by my peers weeks, maybe months, before i wrote down a line of code, let alone checked it in...
The other half of the "Value" of sprints is that it makes it easy for managers to track the (fake) progress of development.
disagree on '(fake)' part. It does help with release planing and adapting to blockers/delays in development.
If you only work on small kinds of problems, it is possible to make progress in a sprint. But hard problems just don't fit into sprints, I don't care how long you make them. The hard problems are the more important ones. People like sprints because it feels good, some people like checkboxes. But software developed to checkboxes is very horrible indeed.
@@username7763 You split big hard problems into smaller ones. It sounds like most of problems people have with sprints are incompetent scrum masters/analysts.
@@lifebarier Absolutely best to split problems where possible. The longer it takes to make a big change the riskier it will be. But lots of problems just don't split well into sprints. Trying to make them fit causes more problems.
"what's my purpose?"
"you pass the butter"
extreme Go Horse mentioned!
first of all brazil mentioned LETS GOOOOOOOOOOO
second of all the way prime says gambiarra is actually so funny, it makes it sound like something fancy
You know who creates the tickets in Kanban/Sprints for the Team to work on? The Team itself, i.e. Developers + PO. At least, that's how we do it. Developer says X needs some work with high prio? It's discussed and probably goes in the next sprint.
The process is there for the team. Not for the customer. Not for the management. If management does insist on regular status updates, you can call them "Sprint Reviews" or "Bi-Weekly Status update" - does not matter.
Regarding your final question - He's comparing what Agile should be against what it usually becomes.
It should be a flexible way of writing code that can adapt to changes in demand. What it usually ends up is a bunch of ritual crap that then devolves into blunderbussing the problem repeatedly until it turns into some semblance of a shippable product and either that works or it sinks. And it's usually the latter, because jumping ship mid project becomes a must if you want to survive.
I sprinted to click on this video
When you’re expected to make daily. standup and explain why you haven’t progressed the sprint - while on holidays