It’s time to move on from Agile Software Development (It's not working)

I came across a study which found that software engineering projects have a 268% HIGHER failure rate when agile methods are used. And even though it might be biased, we can’t ignore the fact that there are some serious problems with Agile Software Development.
www.engprax.com/post/268-high...
Timeline
00:00 Introduction
01:03 The real issue is not with agile itself
01:22 The amount of meetings
04:23 The Agile Project manager might be the problem
08:55 So what can software engineers do?

[@awesomeworld557]

It's failing, because agile is being used to micro-manage people

[@matswessling6600]

but that is not a fault with agile or scrum.

[@awesomeworld557]

@@matswessling6600 yes you are right, agile methodologies for self management has been hijacked by managers to micro manage hours

[@user-vr2rq5hl6l]

@@matswessling6600 If a team can use agile/scrum without management access to tracking tools, that is certainly right. However, any methodology endorsed and enforced by management will have tracking tools. Personally, I wish managers would go back to GANT charts and PERT charts and let programmers use agile/scrum per the manifesto.

[@paradoxicalcat7173]

BINGO! Totally the situation where I currently work. PM doesn't know sh*t about writing software, and insists on meetings every 3 days. F*ing useless.

[@awesomeworld557]

@@paradoxicalcat7173 we have exactly similar situation. It's even worse, THE PM makes everyone 29+ stuck in an hour long daily scrum asking everyone status, completely useless

[@rccc5806]

We're at the time when Agile isn't anymore a tool for the team to self-organize but a tool for management to impose micromanagement. On the grand scheme, the gain of productivity was lost. It's just the illusion of measurability that stuck.

[@user-vr2rq5hl6l]

I found agile to be a way for management to micro-manage since anyone could follow us in Jira & Rally.

[@stevecarter8810]

​@@user-vr2rq5hl6lyeah and that kind of visibility was unheard of when extreme programming and the first scrum guide were written. They used paper tickets, and only the team sees the sprint backlog. Real self organisation. Hell I was doing fine with magnetic whiteboards and post its before management broke my co located team. We could write anything we needed on a ticket and rewire our board on a whim using a marker or a piece of tape. This ticket has 50 tests and we discovered a problem when reviewing the 20th? Make a new kanban board for re-review of the tests, Job is good. Now I have to write to an admin to add a custom field.

[@gzoechi]

The problem is, that just because the management calls what they do "Agile" doesn't mean it has anything to do with "Agile". Blaming Agile in such a case is just stupid. It's like making a vacation in Greenland and then complaining that it's cold at the equator. It doesn't make any sense.

[@rccc5806]

@@gzoechi "Agile" lost its meaning. That's why there is a difference between Agile and agile. "Agile" is just marketing ploy now and agile, the attained quality, where at least some of the verdicts from the Agile Manifest are upheld, is rare.

[@gzoechi]

@@rccc5806 Only to you, because you accept the nonsense. This is why we have to find new words for old things all the time. Just because a lot of idiots misuse a word, doesn't make it mean anything different. When we start using a new word the game begins again and again ... We just need to teach what Agile means instead of letting the bad people redefine our words.

[@eramires]

I was "fired" once, because the "PO" said I was slower as a Senior than an Entry level dev. I laugh, cause nothing I ever coded came back bugged, opposed to what the Entry level guy used to make. I only said: Suit your self, if quality is not the priority here, then I agree, I should go. And then I left, smiling. :)

[@SpaceCadet4Jesus]

Did they provide a cost analysis of total time spent with entry level guy vs. doing the job right the first time with senior man? I'll assume you'll say, NO.

[@eramires]

@@SpaceCadet4Jesus Yeap. NO. 😞

[@seraphinberktold7087]

I was in that very same situation back there in the mid-1990s in Germany. The customers of the company I worked for were afraid to get updates. Except for updates I had been coding - and testing, I might add. Yes, that took way longer than the usual development processes at that company but it was definitely worth it. The differences are that I was not fired for developing properly and, well, the development back then was not really agile.

[@eramires]

@@seraphinberktold7087 Sure yes, but yeah it's not like we are dragging the development, we just want to deliver once and with quality, thats all. 😞Make sure all the exception paths are handled, etc, etc.

[@airman122469]

I said basically this exact thing. The junior devs “produced” code, but it was always garbage. And the overall architecture was so horrendous that touching one file caused ripple effects in multiple classes, and in some cases forced major changes in the unit tests. Absolute madness.

[@kylek29]

I've worked in the role of manager and I have a personal policy -- have the least amount of meetings possible. I swear many middle-management people schedule meetings (in all industries, not just software development) to give the "illusion" that they have a lot of work they need to do, it's corporate theater. How often have you been in a meeting where the relevant portion for you or your team is a 5-minute block somewhere within that 1 hour timesuck? I imagine it's a lot.

[@MikeKalil]

There are so many jobs that didn’t exist, and never needed to exist, that are the result of automation during the last several decades. People worry about AI taking their jobs but they shouldn’t. New jobs will be created and if history is an indicator a lot of them will be nonsense roles. I know there are good middle managers but a lot of them spend most their time trying to justify their own existence to management. So all they really want from the people they manage is PPT slides and meetings to fill their calendars for the illusion of being busy.

[@TheSilverGlow]

@@MikeKalil, when did you start in IT? I've been at this game since 1979, and believe me, there are far less people required in IT now than in the olden days when I started. My dev team does the same work of 6 times more people required to develop in the old days...less QA too now because much of testing is automated, scripts, etc...perhaps we have too many middle managers now...

[@SpaceCadet4Jesus]

@kylek29 That's not true. I don't believe you. Let's set up a meeting to discuss that, okay? 😅😉 You'll get a chance to give your side somewhere in the hour meeting, .....OH...and bring us donuts and coffee, okay. 🤣

[@canadiannomad2330]

Daily Scrum meetings sucks my will to live, and the only way to complain about it is to a person who's entire job is dependent on "making it work".

[@johndescy7904]

Yes. So tell him. Find a way to make it work for you.

[@phillipsparks9690]

Maybe thet are conducted incorrectly

[@thisisnotajoke]

@@phillipsparks9690 They certainly are....

[@errrzarrr]

Ironically, advertised as the framework meant to empower devs. _"By devs, for devs."_ Yeah, right, it never was.

[@johndescy7904]

@@errrzarrr It is. But that means you have to let the devs do it. Like I wrote elsewhere: For instance, management has no business in attending the Daily. And that includes the Scrum Master.

[@petebrown6356]

I started coding in the '80s - used to kick out (good) code like crazy, I can't imagine writing a lot of code today - these processes strip all the joy out of the process.

[@joelholdbrooks6729]

Hilariously, the relentless emphasis on the MVP has created a world of developers who "respond to change over following a plan" by cutting corners. They never actually learn how to write code that is architected to anticipate change. They've been trained to focus only on the moment. 😞

[@wora1111]

Started in the late seventies, but I have to agree. Still writing code though - but I am self-employed, so most of the meetings are with myself. But my colleagues from the 80s do agree with you, we had a very different work culture at that time. The boss told us his wishes about the time schedule, we did some bickering and found common ground.

[@TheSilverGlow]

It depends upon the development group, the team members, the management...if they are decent, then coding today is freakin awesome...if not, you experience various levels of hell...think Dante's inferno...

[@benochang7888]

Oh my. guys been coding here since the 70s and 80s.. hats off

[@rreiter]

​@@joelholdbrooks6729 This is a great comment. I studied computer science in the '80's and then wrote code for many many years. I'll admit that expediency, schedule pressure and short-sightedness often prevent writing robust, well commented, extensible code (management along the lines of "why design and code for something we're not getting paid for"). Over the years I've seen so many fashionable coding idioms and paradigms come and go that when I see some current Best Practices guru spout mantra I just roll my eyes. Next time you hear someone talk REST ask them what it stands for and have them explain the underlying principles and theory. Bet you they don't know.

[@RexTorres]

My problem with agile is that you're given a certain amount of time to finish something. Then your boss comes and tells you to do so many other stuff on top of your actual task and still expects you to finish your actual task in the original time frame.

[@leonauswien]

Oh my dude this is THE problem of the industry. Managers and bosses that don't understand that "do more" takes more time are sooo annoying...

[@lynoure]

They already are breaking their own rules with that one

[@lynoure]

Any popular term at some point becomes vacuous buzzword. They realized at some point that developers liked agile, then hired project managers to be Scrum masters. Fake agile became a business in itself and now the term is more nonsense than not. Would love to talk more on this topic!

[@Ravenx217]

true and real brother.

[@dandi8]

I'm sorry, but that's not agile.

[@user-vr2rq5hl6l]

There were two things I did to survive “bureaucratic” agile. First, since our overbearing project manager came to the retrospective, we couldn’t voice our real concerns. To combat this, we had a secret retrospective afterwards without the manager so we could talk openly. Second, when it came to estimating, I always estimated as high as possible without breaking out laughing. The manager hated it but had to admit that our customers were happy because we always ended up delivering on time.

[@DavidAdediran]

"Second, when it came to estimating, I always estimated as high as possible without breaking out laughing" This is actually sound advice. I prefer not to estimate but if I have to, I will do this.

[@jacobmeetsworld6812]

i am a product manager and i actually do and expect the exact same, you shouldn't have to do a secret retro. I always want my team to estimate as high as possible. I prefer always delivering less on time than promising more and not being able to deliver. It works, team is happy, stakeholders are happy, end of story.

[@TheSilverGlow]

Amatuers estimate high...true pros estimate within 10% of how long a story will actually take. People that estimate high on purpose should get fired off the team!

[@TheSilverGlow]

@@jacobmeetsworld6812, it is against Agile to estimate high on purpose, and its also anti-Agile for the product owner to attend the retro. It sounds like you are not using Agile, nor do you know how it works. Its always a good policy to under-promise, over-deliver, but to do it with corrupt means is simply unprofessional. This is what 45 years of development has proven to me...when done correctly, Agile is the best way to produce and maintain products.

[@user-vr2rq5hl6l]

@@TheSilverGlow Ah, but you probably didn’t have a project manager who would argue for the smallest possible estimate when we never had a chance to look at the code to determine how much effort was actually needed.

[@martincronje5242]

Businesses seems to associate speed and agile with each other. Instead agile works great in a condition where we need to learn a lot. Waterfall works great when we know what works. My personal opinion is that we should stop taking the frameworks so serious and start to work out how to best deliver business value instead.

[@HonkletonDonkleton]

Correct! These frameworks are for people who shouldn't be working on projects

[@stevecarter8810]

Yes when the bosses say they want agile they mean they want short lead times and the ability to change their minds whenever. But agile is hard. Scrum doesn't work unless the team is more or less doing xp level engineering. Scrum is also supposed to make the team sovereign and shield them so they can protect the improvements they need to make quality flow. But this doesn't work if product management wants to come to the stand ups and ask why developer x doesn't seem to have any real work to do.

[@TheSilverGlow]

I disagree, 45 years of development has taught me that Agile is always the best way to go. Even if you know what needs to be done, do not need to "learn a lot", Agile provides transparency to all team members, provides expectations of when this and that get done, and it provides a fantastic communication platform to share, to learn from other team mates, and to mentor. If done wrong, Agile can be far worse than water fall. If Agile is not working for you, you're doing it wrong.

[@TheSilverGlow]

@HonkletonDonkleto, is sounds like you do not understand Agile. You mock it because you don't have the experience to appreciate it. You still in college?

[@stevecarter8810]

@@TheSilverGlow I used to have a team member who railed against all the agile. Back at my old employer, he'd say, we just got the requirements and wore the code, we didn't have to stop every two weeks and integrate, or update the tests with every ticket. And did the code work? I asked Nope!

[@James-eg3nf]

I feel like this is finally being recognized in the industry but the real problem is that Agile software has evolved to the point that it can be used to micromanage developers and obtain metrics for evaluating performance, and leadership loves this. I recently had a conversation with my project manager in which he said that he thought tickets could be written to account for activities as little as 15 minutes so that developers’ entire days can be accounted for. I didn’t use the word “micromanage” but I did use a bunch of corporate double-speak to tell him that exactly what he was doing and in no way that would possibly be productive or encouraging. Not only is that demoralizing, but it’s a very wasteful use of a developer’s time because of the overhead cost. Sometimes we need to stare out of the window and think through a solution for some time. We are not robots.

[@alphalunamare]

I would get ansy with anyone asking me how many days.

[@youtubeplaylist6374]

Macrosnooping 😂 Also, it takes time to create all these observable tasks which probably do not factor into the overall ‘productivity’ time calculation. Leading to an expectation that people work as many hours needed to get the job ‘done’. 6 hours vs 10 makes no difference to the company... Except, it does, loss of focus, context switching, hyper-communication of intention but reduced time to deliver, all negatively impact the company, and so more initiatives are used to manage and control. It’s a way to deskill (by devaluing) the worker so that the company can think of and treat them like replaceable resources, rather than integral, because would the board think if your workforce were integral? 😮 I think ultimately, business don’t have a way of thinking about their knowledge workers, they aren’t competitors (but they could run off with all your inside secrets) they aren’t customers (although you constantly try to sell them the idea that this company is the best xyz, or we’re family) so companies kind of have their workforce as hostile but necessary partners to deliver a goal and there’s just no good model out there which bucks this trend and delivers (whatever ’delivers’ means to a company + the knowledge workers). BTW knowledge worker, doesn’t just mean tech, it’s anyone who has specific knowledge to carry out tasks to achieve a goal. And those goals drive revenue for a business.

[@alphalunamare]

@@youtubeplaylist6374 Heart felt and well understood. I am pretty shit hot at what I do but management forcing it to tiny pots for no good reason never made any sense to me. The last little tin pot hitler couldn't even to be bothered to come to my retirement sighn off. I think Industry / Business is pretty nasty everywhere, stuff like agile just gives the incompetents something to hit you with. Owners buy into Agile not Workers who do the actual graft. Would you et the brady bunch choose team leaders? But they do because of belief in bull , weak will and just pure incompetence, which is for why their companies fail. Show me a company appointed team leader and I will show you a failed project.

[@adirmugrabi]

i (a software dev) now work in a company where the upper management wants the software division to use Agile, but no one in the software division wants it. this is a nightmare. since the upper management knows nothing about Agile, and the ones tasked with implementing it, hates it. we are forced to do everything wrong, and are afraid to tell anyone.

[@danhugo]

I worked at an internet news magazine one time, one of the founders came back from a sabbatical and said something like, “Maybe we should switch to Ruby on Rails, that seems really popular.” It was ten years old at that time, and it was clear from the many disparate components and lack of any real design much less documentation that this actually had a chance of getting attention! What was it Jobs said, allegedly… “It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.”

[@errrzarrr]

Tell 'em you are doing what they wish. Meanwhile, do what better fits you. Afterall, that's the _Agile Manifesto._

[@dimebagdonny]

The fools want to 'do Agile'. You can't do an adjective. As usual these idiots want to mandate that which they know nothing about because it's trendy.

[@TheSilverGlow]

Hmmm...the best software developers I've work with (45 years experience) prefer Agile...perhaps your company is not doing it right...the least experienced tend to not like it because it holds them accountable, forces them to more transparency, and dates matter.

[@TheSilverGlow]

@@errrzarrr, the Manifesto is actually anti what you suggest...but the point is well taken...management is wrong to demand Agile without the team buying in...if most of the team hates it, then one of two things: (a) they have little experience doing Agile correctly, or (b) too many juniors on the team, or (c) they are afraid to expose their lack of competence, lack of skill, or lack of drive...such people hate accountability, transparency, and being held responsible...or (d) management sucks.

[@imagiro1]

I remember, when I first heard about agile and asked what it means (about 10 years ago), my conclusion was: I was doing it (developing software in small iterations) my whole developer life anyway. Now my last project (a European airline) I rage-quitted, and I'm still recovering after almost a year. I already had a burnout (before agile), so I know what it feels like. The description Dee gave fits like a glove. So my advice: If you have a SM who attended a 2-week-seminar, run as fast as you can. Otoh I experienced Safe as working almost perfectly when we had an experienced agile coach. She did not buckle and took everyone to task, also, and especially the stake holders. Once they understood that we (the devs) setup the pace, things started to work. Most important lesson I learned (and anyway suspected right from the start): Do it like evolution does it: Mutate, evaluate, select, repeat. Try things, keep those that work, abandon things that don't work. Forget about "frameworks", they can only provide suggestions, not paths to follow.

[@ChiTheAesthete]

Agile isn't really the problem it's how businesses apply it

[@fltfathin]

agreed, the meetings could've been just an email or some sort

[@mecanuktutorials6476]

@@fltfathinit’s not that simple. Roles are unnecessarily divided up into things like program manager, product manager, project manager/scrum master. This complicates the actual management of everything. It could be much simpler …

[@flflflflflfl]

Communism isn't really the problem, it's how societies apply it

[@PeterBriersPlus]

Communism isn't really the problem, it's how people misuse it ;)

[@virtue.learning]

Well, if anybody does it wrong, it might be sound good on paper but cannot be mass implemented.

[@EricMuranoAU]

To get back to real Agile, we have to call it something else. Then we'll have 5 years of good times until the PMS ruin that too :)

[@i_might_be_lying]

Managerial-type people will always try to make themselves "relevant".

[@charlesd4572]

LOL - what like communism.

[@stephane6730]

😂😂😂

[@joanvallve7647]

Like all evil things, they survive because of morons saying 'you did it the wrong way. Now let's try it again, but this time, the right way, ok?'

[@itoibo4208]

@@joanvallve7647 dumb people love things that simplify into a set of rigid rules that, when followed, they think will produce the best results. Religions, economic theories, etc., are all designed to make a complicated world simple. Trying to apply one thing to everything is a sure way to do the wrong thing.

[@MilMike]

I have been a dev for over 20y and a year ago started to work for a company which does the scrum stuff. Your video exactly shows how I feel about it. Biggest problems are the constant meetings. When I started and I saw my calendar, I thought it was a mistake. It looks like I am a some kind of busy business man with million of meetings. I feel burned out. Already searching for a new job, but most of the companies nowadays use "scrum", which is depressing.

[@DanielGutowski]

In my 6 years of working as ux designer, I was baffled by the resistance to do even a 'simple' ux research such as interviews or observations with a target group at the beginning. And Agile was one of the main reasons for such a mindset. No wonder the products we worked on later failed miserably. And I ended wirh burnout.

[@charlesd4572]

Because the worst people to get detailed requirements from are the users. Believe you me, beyond the basic functionality, they don't know or care about what they want until you actually give them something. Then all of a sudden they know - and always did apparently - exactly what they wanted. If you're doing this on a routine basis you'll never get anything finished.

[@FinnGamble]

In my 25 years as a developer, and most recently as CTO, I can tell you that it's a huge waste of time. The users are terrible designers and will make a lot of bad suggestions. It's much better to simply ask them what they need on a non-technical level, and then design it yourself. Once they get to actually use the UI, they'll be able to tell you what they find inconvenient, and you can iteratively improve it.

[@DanielGutowski]

@@FinnGamble well, that's what I meant. Of course you don't ask users to design the product literally.

[@chickenbroski99]

Agile should be called rigid. Anyways how hard is UI anyways we literally have 30 years of examples to take inspiration from from games to apps to websites. Find some you like and use them. Nobody is going to give good feedback unless theyre more intelligent and capable than you.

[@charlesd4572]

@@FinnGamble exactly. I've been in this game for nearly 20 years and I couldn't agree more.

[@sarahjanelara8046]

I can’t even agree with this enough. The amount of meetings we attended were just ridiculous. I probably only had about 1 or 2 hours per day to do any development work.

[@TheMathias95]

Well tbf that is the oppoaite of agile work. So your company really wasn't following an agile progress

[@mllenessmarie]

@@TheMathias95 A lot of companies do not follow the real agile, that's the thing.

[@user-vr2rq5hl6l]

My worst agile experience include pointing sessions (with official pointing cards), estimating meetings, daily standup meetings (where we were required to stand up), “ceremonies” where everyone did a presentation of progress, and the retrospective. Also, there were project meetings with team members to discuss what actually needed to be done. All we really needed were the project meetings and updates to Jira.

[@Neopitpit]

Same. Constant meetin. Standup, prepare planning, discuss with team to help them to finish their ticket. Validate each step with QT, UX, PM. Changing the color of a button takes more than a day!!!!!

[@SR-ti6jj]

The spy observation was on point. You're not paranoid, just aware

[@MelroyvandenBerg]

I can conform that this is exactly what is happening to me.

[@sanguineel]

I already quit software development because Agile is actual hell. Switched back to cyber and not looking back.

[@mllenessmarie]

They force agile now in cybersec too unfortunately... Which obviously works terrible as one may think.

[@TheoWerewolf]

Excellent summation, but I'd like to add a few more issues. The original problem Agile was designed to solve was for consulting...having a design team meet with the customer, get all the specs, lay out a plan usually waterfall), build the product in camera then hand it to the customer only to discover that it's not what the customer wanted. This happens because real world end uses often don't really know what they want until they see it. So Agile baked that in by having a design team draw up a "big design" plan, then iterating the design on a two week schedule and showing the customer chunks of the final product to get dynamic feedback. THAT works. Where things went off the rails was the assumption that this works for all development when in fact, it really doesn't. Example: if your Agile team has no customers, or almost as bad, a in-team customer representative who represents the customer but works for the dev company, you're not doing Agile. (Pigs and chickens as we used to say). Worse, somehow Agile changed from a productivity tool to a productivity MEASURING tool and external managers became "chickens" along with the customers (if you even have any of those), creating a conflict in goal. The managers' goal is to get the product done as fast as possible and make money off the work invested. The customers' goal is to get exactly what they're paying for. See the problem? Things like "velocity" weren't part of the original idea either. It was added as a way to check progress and see if there were bottlenecks. Now it becomes a "success" metric on its own merit. I can't tell you how many scrum plans have been rearranged in mid-process just to get velocity numbers up higher. Or how often after a sprint plan is locked, someone in management changes direction and blows the entire plan out the door. (And then complains about OUR velocity...) Oddly to me, this relates to git or "blame-based source code management" where finding the goats when something goes wrong is more important than just getting the mistake corrected and educating the team. Fear-based development also rarely works. Agile has a place, but somehow it's turned into a religion and a surprisingly rigid one at that given its actual name.

[@vlad-rs8pb]

I don't really think we should move from agile as the title suggests, but as you say in the video, we should move away from over-zealous implementations of SCRUM. In my team Agile works and is not overwhelming with meetings. We do have them, but they don't get in the way of day to day work and we have a reasonable approach to it. But SCRUM in other teams is a messy burden that makes use of three different project management tools and has their members sitting in meetings all day. In other cases, some teams just have waterfall disguised as Agile. At the end of the day, agile methodologies are a lot like programming patterns - tools that can help you do your job if applied correctly. But as with programming patterns, if you follow them dogmatically and don't properly assess your actual situation at hand to see what fits best, you end up making things harder for you.

[@L1vv4n]

Yes. We need a better management culture and for managers to actually understand what they manage, not moving on from agile. Agile is an instrument, not a silver bullet. A lot of "agile" I've seen was a combination of worst attributes of agile and waterfall. You have a two week long spring, 1 hour daily meeting with 15-people team and everyone talks about everything but nobody offers any help to others (it's too long already), documentation is not done at all, there is not sprints or tasks for tech debt, budget and features are per-planned for half a year, nothing ever gets removed from any sprint, and any extension of time goes with increase in scope.

[@Mikkelzu]

the primeagen has a better solution in his recent video about agile being dog doodoo. Id rather just GSD than sit in random meetings.

[@vlad-rs8pb]

​​@@MikkelzuI think I remember watching his video on the topic but don't remember the details. His videos are hit or miss for me in terms of how agreeable I find them. But your summary doesn't sound good either tbh. "Getting shit done" without catching up with colleagues regularly is also a recipe for disaster in my opinion. A good team is aware of the work as a whole and its status and can react appropriately. A lot of the times it happens that I hear something on a SCRUM that I know something about which then allows me to provide input. To me that's healthy. Our stand-ups are rarely longer than 15 minutes of the work day, so I hardly consider it to be a barrier in the way of GSD. As with most things, it's all about balance

[@vlad-rs8pb]

​​@@MikkelzuWorth noting is that my impression is that Primegean is a very code oriented person, but being an engineer extends way beyond how many words per minute you can type and how efficient you are with VIM. Most of the work in my experience is discussing and understanding requirements and making sure you got them correctly, so meetings are a necessary evil

[@Mikkelzu]

@@vlad-rs8pb Same for me on his videos. My take on GSD being better is a bit nuanced but overall I agree with some aspect. I think a standup is fine (as long as it doesnt devolve into chatter), and periodic review periods as a team to check if the direction is still right etc is also good. However I dont believe that sprints, retros, refinements and the whole shebang is necessary at all. I think if a developer has a blocker or needs help that the first case should be low barrier communication to ask for help. Now, at my work at least, most people just wait 3 days for the 2 hour long refinement thats planned in when they have a blocker of some kind instead of asking me or another senior for help. GSD with periodic communication and letting the bureaucrats do the bureacracy is to me much more productive than forcing a group of developer to spend almost 35% (if we look at the example in the video by Dee, the reddit dude with 13 hours of meetings) of their work week on meaningless meetings. I will concede and say i am a certified agile/scrum hater and I will probably never see the appeal of it after having worked with it in such a misappropriated way

[@jim90272]

Waterfall is soooo much easier. The basic idea is that you write the documentation before you write the code. You might have to revise the documentation several times before you are happy with the design. But revising documentation is vastly easier than revising code. And when you get to the point of writing code, your job is easy and fun because all the technicalities of have been well thought-out.

[@lmoelleb]

Can't say I have ever worked on something so simple waterfall really worked. Documentation was hundred pages+ and it always became a hell of changes after a few months due to changes of requirements as well as additional knowledge gained doing development.

[@joanvallve7647]

Waterfall had many issues. But I agree it was not evil like Agile is. It is evil from it's conception. Agile manifesto is on some extent BS because it focuses on developer's empowerment while ignoring the fact that software is just a tool wich serves purposes developers mostly donesn't understand and doesn't have to know either.

[@lmoelleb]

@@joanvallve7647 what is evil in agile? What makes you think it is focused on the developers? And why do you think developers do not need to know what they are building? Personally I think the biggest problem with agile is that it is not there to give the business the information they really would like to have: what they get, when they get it, and what it will cost. It is a methodology to give business a way to steer development accepting that this can't be estimated with any precision. Unfortunately many think it is a methodology meant to answer these questions - and then it goes terribly wrong.

[@DeckerCreek]

@@lmoellebI can tell you that I work on medical devices and iterative waterfall is the way to go. You cannot deliver safety and quality in 2 week sprints. You can call it stretched - out agile, call it FRED, call it whatever you want. You've got to do up front design, documentation, prototyping, BEFORE showing to customer. Especially if customer is an MD or surgeon. They tend to be high ego people and surprisingly ignorant of the effort involved in making a safe and effective product, unless they've done it before. "It's got to be easy to use" they say over and over again, as if we don't know that. But it's got to be safe as well, and that costs time and money. Testing, unit tests, CI/CD, static analysis. You can sort of stuff this into a scrum framework, but get rid of the word sprint. Because if you sprint! You're likely to fall and twist you ankle....

[@2mbst1]

I'm working for a very small team inside of a huge enterprise that *claims* to be "agile". In that team we practice *actual* agile, bottom-up, continuous reflections, no standups, one scheduled meeting per week. And we're moving *fast*. Faster than anyone thought would be possible. And I understand why a lot of managers hate agile without one of those frameworks: their position becomes questionable. Who should a manager manage if the developers manage themselves? The other reason is: true agile works best when you have devs who are mostly senior and/or passionate. So what do managers do? Hire juniors, who are cheaper and need guidance. Thus managers add scrum/safe to have pretend-guidance, and keep their jobs. A huge W for managers.

[@George-W-Jenson]

Agile is the ultimate job security for PO and SM

[@BenFiesta]

I'm happy to hear at least someone is doing actual agile..

[@austecon6818]

100% agree. Good Sr devs make managers worse than redundant. It puts managers in the position of getting in the way, slowing everything down and being one more mouth to feed (useless pay check that could go to more or better Sr Devs)

[@austecon6818]

My dream company would be the inverse of this top heavy clown world where there are like 2 highly productive developers for every 8 useless people... it should be mostly a company of Architects at the top, then senior Software engineers... and a small sprinkle of HR people for recruiting top talent and paying them very well so they want to stay and are self-managing and passionate. Architects can do the job of project manager but the Sr Devs should make it light work because they're self organizing. Tech leads are also good to have a clear chain of command to resolve disputes quickly. I'd run a lean company so that the budget can be spread amongst a smaller number of highly productive team mates rather. Quality over quantity... large dev teams don't scale anyway!

[@austecon6818]

By the way... I am now living in Brazil where living costs are cheap. If you want a good worker for cheap - I'd gladly leave the shitshow I currently work at... I have 5 years experience as a SWE.

[@mariocueva8700]

As a former Scrum Master, I have written many essays on the pros and cons of scrum in the workplace. Suffice it to say that whilst the framework is not perfect, it is the best method we have to date for software development. The problem is most companies do not understand what makes Agile or Scrum tick - oftentimes creating a dysfunctional work environment which does not embrace the core principles of the framework.

[@DIN_A8]

Exactly!

[@RaMz00z]

Have you tried XtremProgramming or just Kanban ? Because they both work better than Scrum :) No framework is even better imo

[@joejoe-lb6bw]

This is the “no true Scotsman” fallacy. Scrum sucks. Get over it.

[@paulromsky9527]

I disagree, Scurm is like Communizum, it's looks good on paper but when implemented it pretty much fails. I do not use Scrum, Agile, Kanban, Jira, or any "trendy" management frameworks. I hire engineers that are innovative, bright, hard working, dedicated, sign up to cost/scope/schedules and meet them, and deliver high quality, well documented products and services. In fact, the degree if any is low on the list. I don't drag them into meetings or micro manage them. They agree to the task (giving me feedback on what they need and negotiating a goal). Then I set them off to their task and ask for a weekly update of their progress. If they fail to deliver, they better have a very good reason or they risk no merit raise next year. It's simple. I also give each engineer a simple cubicle with 7 foot high walls, a desk, over head, L shaped desk and a guest chair... an engineering cockpit. None of that low walled "collaboration" style nonsense - we are not a boiler room company! Engineers need privacy to concentrate. They often collaborate over lunch, almost always as a team. Yes, we all stick together: at work and after work too.

[@rfichokeofdestiny]

@@paulromsky9527Communism doesn’t even “look good on paper.” It’s like astrology: a superstitious worldview based on a primitive and flawed understanding of how reality functions. And just like astrology, its advocates are so committed to it that it’s almost impossible to get them to snap out of it.

[@estebanperalta59]

I agree 100% with this, agile is not the problem, is how 95% of bussiness implement it, and it comes to this: Bro reads agile manifesto and it says "Individuals and interactions over processes and tools", bro flips it and it goes like "processes and tools over Individuals and interactions ". Scrum master is indeed the herper of agile, because is the perfect plan to enter the tech industry without knowing a crap of it, Just give to an SM a team of devs so he can micromanage them and get paid for it, profit without writing a single line of code.

[@charlesd4572]

Please can someone tell me what "Individuals and interactions over processes and tools" really means in any material sense. It's like saying "you must go down before going up". That's the problem with agile it really has no meaning. Development of any product of any meaningful size has always been done in cycles. The Waterfall method is just something dreamed up to justify agile and subsequent consulting.

[@estebanperalta59]

@@charlesd4572 The agile manifesto is really a compendium of best practices to any given project of any nature, is not strictly reserved to software engineering, that why is so ambiguous, but if you want to narrow to what devs do on agile teams it's not complicated to understand: for example, "individuals and interactions over processes and tools" in SWE is really putting devs needs over the ceremonies of, let's say scrum, that in practice means "we don't need your freaking meetings, let me do my freaking job". Like the video said, one of the main issues of scrum is that there is too many (ofter useless) meetings, and maybe you can skip some meetings that aren't that necessary, more if you're short of time to meet your sprint goals. Some SM and managment evangelize so much scrum that they don't care if meetings took 40% of your time and still you're asked to meet your sprint goals, that's why almost every dev hates scrum. The framework should adapts to the teams needs, maybe we should make that daily meeting twice a week (change the name if you want tho), maybe that 1 on 1 is not neccesary, Jira can do the backlog grooming automatically and maybe we don't need that meeting either. Frameworks adapts to devs and not backward, "but we need to have those meetings if not we're not doing scrum", well, we're not then, and screw scrum and screw the SM and screw managment, I need to do my freaking job so bother someone else with your little meetings.

[@Codetutor-DemystifyCoding]

You hit the nail on it's head. I have almost two decades of experience in Software development. I have not yet met a developer who cherishes or looks forward to going to in to these meetings. That says a lot how developers feel about these blood sucking, life expectancy diminishing meetings.

[@acasualviewer5861]

Ironically Agile was invented to cure the annoying "status meetings" that existed pre-Agile

[@michaelk.jensen1611]

I think its a huge issue that developers, look down on meetings and communication as much as a HUGE portion does to day , also lack of documentation and want to work all the time like at home making a small hobby project for themselves. Tje resistance to whow their work and sometimes even sabotage is part of why the meeting size and numbers grow because there is a huge culture of unprofessionalism and even antagonism. It makes an impenetrable wall that makes it hard to work as a unit and even harder to make a good org that is more than its parts.

[@acasualviewer5861]

​@@michaelk.jensen1611 there are developers that have to high of a sense of value for themselves.. and also a developer that refuses to communicate is one that will soon have no job. But on the other hand the excess of meetings can cut into valuable development time. Can't get that feature done if you keep talking to me.

[@michaelk.jensen1611]

@@acasualviewer5861 what I'm thinking is that part of what creates a lot of meetings is this culture and dislike for meetings and communication. Then as a consequence of that, meetings increases because people feel they are walled out and not in the loop , or other ways. So I believe that mindset actually might be part of why there are more meetings. So in effect the dislike (that I think often are kneejerk like reactions) of meetings and communication is a significant factor in creating even more meetings.

[@acasualviewer5861]

@@michaelk.jensen1611 interesting perspective. I do agree that sometimes rather than looking through a PR for hours in Github, it might be easier to just have a call with the developer and have him explain the code to you. Saves everyone a lot of time. Being too afraid to have face to face contact is not healthy.

[@CelloSounds1]

Thanks for having the courage to raise this! I’m a PM who hates scrum and is also afraid at times to voice that as the IT industry has an obsession with scrum. There are two main issues I have with scrum 1. Sprints - the idea that everything is done inside a timebox is, frankly, insane! Where else in life do you find this? 2. Agile does not address the single most important factor of delivering work; managing WIP. WIP management has been in manufacturing for eons and is central to product delivery outside of IT. It focuses on small batches of work (1 hour or less), stop starting and start finishing, and the theory of constraints (ToC). I’m very passionate about changing this in the industry, and have started developing my own delivery framework. If you’d like to meet up virtually and discuss, I’d be happy to.

[@AntenainaLand]

I've seen one company that went bankrupt because of bad management. and I think scrum played a big silent role in this.

[@A_Saban]

I dont agree with the title but I do agree with what you say in the video, Agile is the way to go imo but if the management misuse it and doesn't implement it right it will hurt the productivity,

[@joneskiller8]

YES, Yes, yesssssssss!!!!! Finally, someone is speaking out.

[@PjStekhovenSmith]

Liked and subscribed. I work in the creative industries (and have worked in creative departments of major tech companies) - this dysfunctional ‘agile’ PM style now permeates every discipline in large corps. Can relate (unfortunately) to this way more than I would like.

[@ToyKeeper]

My last job was great until they switched to Agile and Scrum. Then lots of people left, the ones who remained were miserable, projects failed, and eventually upper management blamed the issues on the developers and laid off nearly the entire engineering staff, a third of the company. But they kept the managers who caused the issues in the first place.

[@virtue.learning]

Wait - Scrum Masters with programming background actually exist?

[@stephane6730]

😂😂😂😂😂😂like for real😅😅😅....

[@George-W-Jenson]

😂😂😂

[@virtue.learning]

@@George-W-Jenson I mean why should you be a Scrum Master if you can program? It is like rejecting being a Wizard for pursuing a career in Data Entry

[@BenFiesta]

The role of the SCRUM master should best be carried out by the dev team. The SCRUM master HAS to be part of the team, if not, its bullshit. The role is very simple and small, certainly not more than 20% of full time.

[@debabhishek]

ha ha.. .. scrum master.. really .. ha ha..

[@boomergames8094]

In the last 12-15 years, I've seen many agile teams, and had agile forced on my team a couple times. I've never seen agile work. I don't think I've ever seen it done following the manifesto properly either. We've kept a few of the ideas but changed them. We don't do daily scrum. Weekly. Sprints are a quarter. Sprint planning and grooming are done annually. What do we do when work comes in and needs done sooner? Manager decides priority. We also do a weekly status report. That report takes a few hours because its not really just a report, it is a weekly presentation to the exec management. They want to see 50-100 of these each week, and go through them quickly finding blockers, issues, and who is doing actual work vs. pretending. Every "Agile" project I've seen goes about 268% longer than planned.

[@alindorindicu3732]

I've been working in the same company in the R&D department for close to 8 years. R&D started using agile/scrum in 2012. We've celebrated the 300th sprint in March 2024. R&D grew up from 40 to 200+ during those 12 years. Functional and technical complexity has gone as also increased. We're still delivering product increments every sprint.

[@TheLastEmperorXiXinPig]

Same experience, I hate agile, I hate SCRUM, I hate SAFe Agile, I hate PM's, I hate Scrum masters, I hate grooming meetings, I hate retrospective meetings, I hate it all. Will never go back to those type of companies.

[@Martial_Monkey]

I agree... But 95% of companies want you to do Scrum and SAFE. That sucks. I miss the good old days working with waterfall approach (no meetings at all).

[@krakulandia]

I love agile. I hate Scrum and SAFe and all the other processes that claim to be agile but are the complete opposite to what agile actually is.

[@paulhammond8583]

Agile isnt scrum or safe.

[@TheMathias95]

You have some validity in most of those opinions. You also have to keep in mind that if you hate reflecting on how you can do better or mistakes you have made, ie retospective, are truly an engineer?

[@JeanPierreWhite]

Sounds like you hate your job.

[@WorldandSumeet]

I am a Scrum master. It was going good in my company and developers were happy with the sprints. But one day the company implemented Agile 2.0. Since then we are just following scrum ceremonies for the sake of it and micromanagement is at peak. Burnout seems a very small word to me.

[@jamessullenriot]

It's not going anywhere. There is too much tied up in consulting.

[@DanielHeeris]

Great breakdown, first time on your channel and now a subscriber. You really managed to capture the frustrations I've had with scrum and agile as they were implemented.

[@ruffianeo3418]

I worked in automotive industry, supplying devices to car manufacturers. And I was in the lucky position of a) There was no Agile nonsense around at that time. b) Me and 1, 2 others defined our development process ourselves. Such an automotive project is characterized by: 1. The OEM (customer) is still designing features and structure of their end product, while the supplier already work on the respective devices (which are all interconnected via various field buses). They have one fixed and unchangeable end date. The day, when the car production line starts. Which is typically 2-3 years after the device suppliers got their order. During that time span, there are 3 major (and common) and a few more flexible and state-of-affairs-driven minor milestones. In total, it comes down to OEM supplier interaction and integration of the devices every few months early and every other month or so towards the end. 2. Since those are embedded devices, the supplier has their own milestone planning to coordinate the mechanical, electrical and software parts. 3. Next to functional requirements, there are also industry and OEM driven quality requirements and documentation requirements. 4. The functional requirements change (sometimes A LOT) as the OEM does their job and gains insights and re-writes specifications. What we ended up with, was to negotiate a 6 weeks iteration pace with the customers. Changed/Revised/Bug fixed requirement specifications of the OEM would be reviewed and then a release plan for the next 2 such iterations was negotiated with the customer, so they know, which features they can expect in the upcoming releases and to coordinate with the (like 20) other supplier companies to make sure, the OEM has a set of devices which work together. It became quickly clear, that Defects (Bugs in our software and changed requirements from the OEM) can be treated rather in the same way. After each 6 weeks iteration, there was a PLANNED follow up release 2 weeks later, which is fixing show stoppers. Those 2 weeks overlap with the next 6 week main iteration, should it happen. And yes, it all was based on iterative waterfall. With that 6+2 iteration in mind. There were NO Sprints, no Neurosis, no slave driving. This was just the framework everyone knew, how it works. The SW project leader made calls for estimation of working packages from the developers and made sure, both bug and feature tracking was working well. And we did quite a few projects, doing this same process successfully over and over again. - Try to MINIMIZE ritualized communication. - Invite as FEW team members as possible to meetings. - Let people focus on their work. There is no need to monitor below working package level. (Which usually took 1-2 weeks). The estimation of a working package by the DEVS also means they should COMMIT to that time frame. If they underestimated the effort needed - that is what overtime is for. If DEVS cannot hold their commitments i.e. don't care - well that is bad and they need to go. - We had flexible work plans. So, if one working package took overtime (surprises happen, variance is real), the DEVS could chill a bit and take some time off, when they were making faster progress with other working packages. (if estimates are good, it should not always take longer or always end faster, right? Should be 50 50). - A working package included: 1. Source code 2. Unit tests 3. Documentation 4. Release Notes. - Integration (for those 6 week iterations) was done as working packages got ready (by the test department, in charge of a more gray/black box testing of the release), even before the time for the "official integration" was up. DEVS who had working packages affecting multiple modules, also pre-integrated and made sure it all made sense before they deliver. - DEVS count in a project ranged from 2-20. All in all, it was fun to work in such a framework. As a DEV it felt FAIR (in contrast to being abusive). Taking commitments and living up to it was key. It was an agreement and not just a huge tsunami coming your way. If OEM requirements turned out to be wrong (happens, OEMS are also only human), DEVS could also enter those problems into he bug tracking system and escalate towards project lead and OEM to resolve it. OEMs knew what to expect when, DEVS could plan their own workload. It felt like (team) work, not war. So, no idea what AGILE is and SCRUM and all that crap. Or maybe that is just what we did all along?

[@user-jg7qw6bn1t]

Spies!!! I never thought about it that way! Your video speaks volumes! Keep up the great work! Subscribed!

[@MartinBlaha]

Thank you, I appreciate your thoughts! Agile is not the holy cow. A process must support the business - it's not about using blindly a methodology. If your process doesn't work, change it, reflect, adopt, repeat. I don't think there is a one-size-fits-all methodology. As PM I'm always trying to force the business side to come up with concepts which are well-thought through because one of the issues I see is that we loose planty of time in requirements discussions once we started coding. The business side is often misinterpreting agile with I-can-change-my-requirements anytime in opposite to waterfall where proper specs are required upfront. We have a lot of people in the middle and upper management who actually have no idea what software development and engineering is about. But these people are often the decision makers or "owners", they naturally need more communication and therefore meetings. I really blame mainly the business side for the explosion of meetings in software development. But again, if your process doesn't work, escalate it and try to change it. Otherwise I only recommend to consider looking for a new job. Don't waste your life in stupid meetings and boring companies 🙃

[@codingwithdee]

This is a really solid comment. Well put

[@FranzAllanSee]

I dont blame business for the explosion of meetings. I blame middle management 😂 Tell the person who controls the budget that your team spends 32% of their time on meetings - and you’ll get their full support to cut those numbers down 🥲

[@ChiTheAesthete]

@FranzAllanSee lol this isn't true, considering executives love meetings as well

[@FranzAllanSee]

@@ChiTheAesthete it’s their job to be in meetings. But if ICs are spending more than 15% of their time in meeting, there’s an argument to be made. If it’s 30% or more - even a way stronger argument 😁 it’s like hiring 10 devs but only 7 are working 😂

[@rumble1925]

Management doesn't know anything about software because they don't talk to software departments. It all goes through PM's. Chinese whispers style.

[@SuperAerodragon]

My org attempted to switch to an Agile framework a couple years ago and much of what you highlighted was true, one major flaw we found was that while our team was working in Scrum many of the other groups were fallowing a traditional waterfall method. We experienced a lot of scope creep. Now we are in what you consider WAgile , We set requirement at the beginning of the feature work. However during the sprint when the users begin UAT and identify problems or possible enhancements that should be included , we are met with "that wasn't in the requirements so it will have to be put in the backlog." The backlog is where things go to die. For me this is the most frustrating part because the purpose of agile is to deliver a product and get feedback and iterate on that feedback to deliver the best product. The scrum master/project manager should be there to remove roadblocks and keep us moving forward.

[@vxl]

Scrum meetings ate timeboxed so that the length of meetings is limited. But many meetings you mention are not in the scrum guide. Also some of those meetings only have value if the teams are actually self organized.

[@virtue.learning]

I remember when I was new on a Team, my first Dev Job. I said after a few months that we could make things better and gave two examples. Instead of just doing that non bureaucratically (or reject it) we scheduled a monthly 'retrospective'. I did not knew what it was and said: Why we do not JUST decide to do it or not, like the Agile Manifesto says? But I thought maybe they know more. On the Retrospective it was awful. When any of us brought on a topic to change, one of the other blocked it. Learning: I wanted to change something, it resulted in a 2+h time waste every month.

[@SixStringUk]

I'm not a software dev, I've just recently started working in a dev-ish role and because of technology migration I'm working in two projects. We all here do "agile". My main team works closely with our PMs, we have 2 status meetings every week, and one sprint planning every two. They usually last less than 15 minutes. In the other project, I have a daily status meeting, usually more than half an hour. It's still way less than people describe, but even that is a bit much for me. Status meetings aren't the devil - some people do need to have frequent checks or they'll start to procrastinate - that includes me. But I find that talking about what I did every day is useless as the tasks take more time and I have other work to do. I very much prefer the rare meetings and being encouraged to actually talk to people if I have any questions. I know that if I have a meeting next day, my questions will just wait for that and it slows my work down.

[@ThinkingBetter]

I think a big part of this problem is also that before the pandemic people collaborated in office buildings where we went to talk to the individual on a subject to solve it effectively. Nowadays we work more from home and intercommunication becomes much more reliant on scheduled meetings where the majority at any moment is not productive. One solution could be to drop all those meetings and request the team members to be available during work hours for ad hoc calls when needed.

[@user-vr2rq5hl6l]

Well done video! As a seasoned programmer, with & without agile, I say you did a fantastic job describing the problems of agile. My biggest complaint is that agile has become part of company infrastructure without evaluation of its effectiveness

[@TheScottShepard]

Scrum works when retrospectives address real issues and management listens to the development team. Scrum Masters need to support the team by removing impediments like ineffective meetings and unfocused managers. Sprints, if you use them, need to have realistic and well-defined goals. Agile isn’t Scrum, but Scrum is a good place to learn iterative development behavior.

[@BenFiesta]

Scrum masters needs to be embedded within the team. That is absolutely critical. Best if is the SM functions are handled by the team themselves.

[@user-fe7sn9ed3u]

I'm an old man with 20plus years of waterfall experience. New to agile as well. Other than the hype, listening to your video, I'm thinking the problem not in the process (maybe) but rather in dividing the scrum target which are prob too ambitious and too all over the place (not focused)? Because, knowing your team capacity and productivity rates are core skills of project managers. If the team is in perpetual condition of burning out, what does that say about the pm skill in managing the workload and team productivity?

[@charlesd4572]

Waterfall? Really. You did the entire project without any review of the product during development - no feedback at all (not even alpha, beta and release). Waterfall is a strawman made up by the same folks that came up with Agile.

[@mecanuktutorials6476]

@@charlesd4572 waterfall is a linear development process. It is clear because it is divided into stages. You move to the next stage when you’re done with the current stage. You don’t start implementing until you’ve clarified what the client wants. You don’t start writing user manuals until you’re done implementing. This is much better project management because it’s to the point. Agile I feel should only be used in issue tracking/feature requests. Things that are not the core infrastructure but rather amendments. When you’ve ready acknowledged there’s a large codebase to work off of and a lot of competing directions to steer it in. As others have stated, can’t be dogmatic about it. Sprints and meetings are too disruptive and the end-target is too I’ll-defined in Agile. The various manager roles such as product manager, program manager, and project manager decouple software devs from the planning process and relegate us to code monkeys. I understand “Agile” in startups where you do Extreme Programming for prototyping but Agile in big co is something very different and a reflection on the company being unfocused, top-heavy, chasing too many projects, bring a simp for customers who don’t know what they want and isolating devs from the planning portion of software development. I’m not impressed with Agile at all.

[@charlesd4572]

@@mecanuktutorials6476 in that sense then yes. I think the problem with agile is that it assumes users know exactly what they want. They don't, they have a broad idea of functionality and until they get the product (and by that I mean at least an alpha stage one) they won't care enough to think hard about any specific part of it. Of course once they get something they'll pretend to have known exactly what the wanted all along.

[@frydac]

@@charlesd4572 "I think the problem with agile is that it assumes users know exactly what they want" Agile is about the opposite of that.. the idea is to work in small increments, so the customers/stakeholders/users understanding and requirements has many opportunities to grow and change while the product is being developed.

[@BenFiesta]

@@charlesd4572 Absolutely not true. The waterfall monicker was coined by Winston Royce in the early 70s to describe the flawed process of trying to apply industrial economics, as descibed by Thomas to software development. It was never meant to actually be used. Agile is a set of values and principles described by a team of leading developers in 2001. Royce was not one of them. The stuff being discussed here as nothing or very little to do with the values and principles that were put forward then. The stuff discussed here is not an agile culture but an appropriated terminology.

[@PatrickSteil]

My certification teacher, when pressed on what the goal of Agile is software quality. Not speed of delivery. Not cost optimization. Not developer productivity. I think we are complaining about a system that is doing what it is designed to do. The problem is the hat management may have competing goals.

[@BenjaminVestergaard]

My main issue with agile is in how many startups and small companies use the small iterations to replace the need for a plan or documentation of one. Many simply don't have a specification of requirements for version 1.0, or 2.0 for that matter. Without that specification it becomes virtually impossible to also set up a test plan for QA to go through before signing the release papers. Developers don't necessarily like to document too much, but if you're supposed to work in parallel it helps to "waste some time" at the beginning by specifying the overall goal, also to prevent scope drift. I was educated in the old IBM-style waterfall method, which is also tedious and feels slow, it's not perfect, but it allows for a complex component taking longer than many of the smaller ones, you don't aim for having a fully compilable version every week. You just make unit tests according to specs, and then all the pieces are supposed to work when they're ready to be put together.

[@SixBillion]

Agile when used to micro-manage things leads to too many meetings. Leadership loves it coz they get to see what's happening on a daily basis. Developers hate coz of the daily interference. In my opinion, the best solution to not get burnt out is to increase the sprint cycle from 2 to 3 or 4 weeks.

[@ArturdeSousaRocha]

Leadership *think* they get to see what's happening on a daily basis.

[@danhugo]

I (30 years engineering) was agreeing with you until the end… ultimately, we build things for the customer(s), that is the whole point of the whole thing, including the Agile process and what it hopes to deliver (in small chunks, frequently). Agile 2.0, then, might be starting with the OG Agile Manifesto, NOT treating it like a library that can be wrapped with the latest misguided bureaucracy and worse, and adapting it to the team, situation, and deliverables at hand. Agile 2.0 is maybe a formally-defined Composable Agile…

[@charlesd4572]

Can you remember a time when we built large software projects in one big cycle - I can't and I've been in this game quite a while too.

[@danhugo]

@@charlesd4572 Read the Feynman Appendix to the Challenger Report… be honest with team and management and develop a system that works so that delivery to the customer doesn´t kill them.

[@alexpavlides2047]

I agree with this totally. I just finished working at a startup. We decided we had no time for all these meetings and we all enjoyed our jobs more and got more done.

[@vasylvoina6663]

It's also worth mentioning that goal setting in Agile is such a tricky thing. Team can always set some super simple goal that doesn't even take half of the sprint to finish and then just simulate intence work during the spring having the goal achieved on the very beginning.

[@aleksdeveloper698]

Not only it doesn't work, but the main reason it doesn't it is because the tasks given, are not based on the seniority level and ability of the employee to do the tasks given. Imagine a new developer comes in a company. They give him a task to fix an error they got from another senior engineer who had been working with the company for 5 years. How is the new engineer supposed to fix an error that your company's senior made? It is by far more important what tasks you give, than scheduling the tasks given in sprints.

[@FranzAllanSee]

I understand your point but I disagree on the details. You’re not supposed to give tasks to the best person for the job. As much as possible, you give it to the person who will grow the most from it. Basically, you dont delegate tasks. You delegate opportunities. Having said that, you still dont assign something way too complicated/difficult for a person. It needs to be done gradual. Also if that senior is worth his/her salt, then a junior should be able to fix his/her bug (or at least most of it).

[@gregoriodia]

​@@FranzAllanSeeI have to disagree. Best agile implementation I have seen was where we had a stand up, but we had an opt-out, yet almost everyone attended because we were going round, most said "no update", but then every few standups someone would say "I'm stuck with", and fun would begin when we all jumped to brainstorm. Then we had a set of tasks that we were picking up at will. The only thing Team Leader was doing in terms of having tasks picked up, was reminding us that task been waiting x days and how many days we have left to deliver given functionality.

[@virtue.learning]

Exactly. Then the Junior needs to ask to Senior X something, X is getting angry cuz his tasks are left. In consulting it is even worse, you get a number of hours on a ticket you can book on. The Senior X then gets no gain for helping the Junior do something ineffective which he could have done in 30 minutes...

[@FranzAllanSee]

@@gregoriodia sure. That can get the job done. But there’s no systematic way of growing people. Come performance evaluation (or when you apply for job outside), you might get surprised that you just did work but didnt do impressive work To be fair, this is outside of agile and comes into the territory of talent management. This is also one of the main difference of a Project Manager and an Engineering Manager. PM is primarily focused on the project. While for an EM is managing the project, the operations and growing the team (talent management is critical at any level of engineering leadership. But as you climb up the ranks, focus starts to switch from projects to operations to strategy). Also, when you delegate opportunities, we’re no longer just talking about tasks or tickets here. If you’re a jr, it could be a task. If you’re a sr, it could be an EPIC (i.e. you’re the one creating tickets for you and others). There’s still freedom to choose whatever you want. But more or less, the strategy to grow you should have already been discussed and aligned with during 1on1s. That way, you just dont randomly work on tickets for the whole year. You work on things that will gradually build you up for something greater and more challenging.

[@gaiustacitus4242]

@@FranzAllanSee That is nonsense. You've obviously never owned or managed a business. Every decision you make is about maximizing quality of the product at the lowest possible cost. Whoever you work for should fire you.

[@ralfhergert6296]

I cannot complain: We are a small team of 4 devs, 1PO and 1SM and doing Kanban. Our iteration turns last one week. Review + Planing is done in roughly 45min. The trick: we do not estimate anything, and issues are done, when they are done. Our PO trusts our jugdement: When we think a refactoring might be necessary we are allowed to do it. No questions asked. The result is a healthy codebase with almost no Sonar issues and +83% code coverage.

[@110leo110]

Thanks for creating this video. As someone who has worked most of his career as a software engineer/developer and now as a Scrum Master, I totally understand your point. In my opinion, there's not one solution for all the problems. Scrum (or all the Agile frameworks) gives you ideas and structures to build your process. They are like different architectural patterns in which based on your needs and your availability, you will make your own program. Thus, you should build up your own process with the knowledge of most frameworks. The work of art of the Scrum master is, to understand the unique dynamics of each team and continuously enhance the sprint process. Their goal is not only to ensure efficient software delivery but also to create an environment that aligns with the needs and well-being of software developers. Thanks again for pointing out an important issue of blindly following Scrum!

[@ribbles1699]

I'm a project manager. At my last job, we were implementing agile the best we could, and pods helped. Our standups were 5 minutes max, and the retros were more of a party than anything. The problem was in the C-suite. They disregard the sprints entirely, adding new pet projects several times a week. But heaven help us if we failed to release the original sprint contents on time. The result was very long hours and crazy high stress. Not for the executives, of course. Their day ended after 8 hours of bullying.

[@robkom]

Right on. Agile is a philosophy, not a methodology. The problem is not about being agile, but doing Agile™ (i.e. Scrum). Scrum sells to large late-adapter organizations; they have managers who want to keep their jobs, and budget to burn on scrum consultants to adopt it.

[@LordHog]

Agile => micro management

[@BenFiesta]

Which is the exact opposite of what the manifesto states.

[@krakulandia]

Agile is the complete opposite to micromanagement. It works really well. But people who call Scrum agile are deluded: Scrum is the completely opposite to agile.

[@LordHog]

Ever since Agile was adopted in all my companies it has been a tool for micro management. At the end of the sprint and if you don’t delivery a “feature” it is always why don’t you deliver the feature on time. Two to three times a week would had hour long or longer scrum to discuss the current deliverables for the sprint. This is from industries like aerospace, industrial controls, to storage. All the same

[@JeanPierreWhite]

No Agile is NOT micro management. Micro managers have hijacked agile.

[@jasonhighlander]

Agile/Scrum is a micromanagers dream framework

[@slavar6868]

I’m a product designer, and a couple years ago design sprints were popularized. I tried it a couple times, results were impressive, but it felt so exhausting. I wouldn’t even think twice, no way I’m doing it again ever. You need to do all the meetings and also research, drafts prototypes, user testing and interviews, 9 circles of approvals by PMs, devs, other designers, and come up with a final result ready to pass it to developers with not a single mistake whatsoever. Also, when working with developers or in general I never push sprints. Good work takes time. I visited all kinds of regular meetings - it’s a waste most of the time. But from a pm’s point of view I get it. That’s probably the only stable thing to have in pm’s job. I did promote regulars as a pm, but after 2-4 times I was running low on them always and abandoned the ship 😂 ok, adhd is a thing too, I confess Daily meetings are special kind of bs. I get it, it’s a substitute for a water cooler chat, but it’s not natural in any way.

[@shiouming]

I vividly remember what an agile couch once told me more than a decade ago, the most common mistake in agile adaptation is half-baked agile adaptation. In such environment, any problems arise from non-agile practice, often be counted as agile's problem. Perhaps the common complain of anti-agile practice - everyday wasting 30-60 mins of productivity in standup meeting. That being said, not all types of projects I came across are suitable to use agile.

[@dariobotkuljak9673]

Agile people (PMs, Scrum masters, POs, whoever) are non-technical people trying to get a job and a position in a technical teams without learning technicalities, nor honoring its complexity. They are there for themselves only, posing a middleman's between engineers and the clients, but only having a whip as their position justification. Not technical knowledge, not domain knowledge, nothing. Once I get bored, I will switch to job in which I'll be making money by asking every day 'how is your task progressing?', 'what is your estimation?', and dragging boxes in Jira. brainless, but priceless

[@dimebagdonny]

They're Aristocrats, Bureaucrats, and Charlatans attempting to micromanage, commodity, 'trendify', and cash in on a Cargo Cult. The Agile Industrial Complex.

[@lateefojulari486]

Astute

[@abelabate2635]

1st commenter.. respect😊

[@user-sd8su9cj5d]

You summarized the issue very well. I also feel burned since I work in a scrum environment. It's just soul crushing and I even considered switching to a totally different career...

[@ericbudd2747]

I find myself both agreeing with, and frustrated by the conclusion of this video. I fully agree that Agile and Scrum implementation are failing due to a myopic focus on company profits and customer demands, but none of us developers would be around to complain about it without them. What can we do to convince upper management that shifting the focus to developers and the development process will lead to greater customer satisfaction and company profits?

[@WebDevCody]

The issue is scrum, and it isn’t that bad. 3-4 hours of meetings a week in a 40 hour week isn’t that bad. Agile is fine, kanban is a form of agile and I feel it’s closer to the core of agile. Scrum as put into place because many software teams didn’t know how to communicate anything to each other or business leaders, so forcing daily meetings was to help mitigate these communication issues for the team and also improve communication with the clients. What is worst, an hour a week talking to a client and demoing your progress, or working for a month to find out you’ve build the wrong thing the client doesn’t care about.

[@ChiTheAesthete]

Bingo

[@alea5465]

I understand the problem of not reporting things on time but having a daily meeting makes me feel I am being micro managed. The question “is there something I can do for you?” is also uncomfortable. Just let me work, I need time to think and solve things. Biweekly meetings would be enough and if there is someone that is not meeting the goals, just talk to that person.

[@FetidFart]

Actually it is terrible. 3-4hours * the number of people involved + the time wasted from context shifting. If you do the math it’s actually a very expensive way to add very little value.

[@Saviliana]

Well, Agile develop method is just another name to the famous development trap that call "Feature Creep", that is what it is.

[@mikfhan]

Pretty much, if scope is vague my estimate will exceed the sprint duration. "Story points are not hours!" Then why is sprint velocity or burndown a thing? xD

[@mysteriouse5891]

No matter what, the people whose business success thrives on meetings will have meetings.

[@Apenschi]

This is soo true! Thanks! The main problem is Scrum and the industry behind it. If there's so much money to make with consulting and stupid meaningless fake certificates, Scrum is pressed into every project they can find, no matter if it fits. One essential point of agile development is, that the team decides. If the team decides that Scrum is a good process for the project, then they should use Scrum, if they decide that Scrum is not (or not longer) the right choice, then there is no Scrum. And Scrum is not agile! You can be agile without Scrum. While it is still possible to be agile with it, using Scrum makes it harder to be agile.

[@abdulrenishr]

In reality, we do waterfall in each module or sprint😊 Agile basically comes into picture when the initial phase of the priject is delivered. In an ongoing process after post production, agile is the way. Scrum doesn't actually needed as jargon, but an intial meeting alternate standup, review are enough and will be a part. Only draw back is show casing individuals suppressing the team is worse.😂 The lowering or low branding of team members in the standup even by a gesture word, email all affects the productivity. The actual team is mostly rejected in tech meetings, or no access to management even once in 2 months, are lose points. The opinions or technical aspects are avoided and neglected for the sake of office politics is another issue.

[@dimebagdonny]

Agile is an infinite series of 2-week waterfalls.

[@kwyaza]

The problem is not Agile or SCRUM. Developers need to report progress to the business, this is part of your commitment to the company. The meetings are not always useful to developers, but for the other team members they are, it helps keep everyone in sync. If there are too many meetings, it should be communicated to the PM in a constructive way. Ultimately if you doing your job, and communicating effectively, then you should have no problem with Agile. I do agree some companies butcher Agile, in those cases it's important to have an open dialog with management, if they don't listen, then it's time to leave.

[@l0adofarse]

Great content. Subscribed. I'm a DevOps engineer, but much of this is also relevant.

[@BolsaMB]

In my company main problem is in sprint i am given too much work and during sprint my tasks are modified by manager . He is adding another more priority tasks and i can’t manage my sprint board . Plus we have tons of meetings. They fired few engineers due to cost reductions and now there is more work. Hate this job

[@AndreCarneiro666]

In my opinion, the problem is PMI applying agile. Those people insist in mix waterfall model with agile. ANd that it's not working.

[@pascalmartin1891]

My experience after doing some scrum: - sprints are tools to monitor progress, but once they have made it in the schedule they have become goals visible to upper management. Now the project manager wants/needs to monitor the progress of the sprint daily. - The daily stand-up morphed from a team exchange to a report obligation. I have witnessed a scrum master insist on getting status for each sprint task. My interpretation of the manifesto is that the agile method was meant as a way for an experienced team to self organize. Scrum has become for mid-manageement a tool that they use to micro control. I suspect that scrum was sold to executives as a micro management tool (take control of your teams, and they will love it). My only surprise is that people expected something different. Software projects are incredibly risky, even when not rocket science. The overwhelming majority of executives have no computer science background. There is such a huge gap between the two worlds that the elusive search for the miracle is never going to stop..

[@Bosgek0]

I started working in manufacturing R&D when Agile was seen as the IT spin off from Lean (from our side). It looks like Agile strayed off course from it's Lean principles. Eliminate Muda (waste) is core: time in meetings is clearly not productive. However neither is building something that isn't adding value to the end product. So as long as a meeting is shorter than the time (or risk) the developer is spending on doing the wrong thing it's still productive, but not anything beyond that.

[@donald-parker]

A big problem I saw in 2 different companies is that testing on "completed work" did not begin until the "completed work" was delivered at the end of the sprint. And so there were many bug reports. That got shelved because the developers were focused on the next sprint (and because testing takes time a lot of the bugs were not discovered until partway through the next sprint or even later). Net effect was a huge backlog of bugs. And at the end of the planned series of sprints, everything was "done" and nothing worked. For a long time.

[@AbhishekSrivastava_ab]

Damn all if this feels so relatable and it feels like somebody put words to my less articulated thoughts. I'm gonna think this through now. Im an experienced engineer but im also keen on improving development processes and I am a huge advocate of planning things properly and then managing them well. Thanks for this validation. 🙂

[@navicore]

Great post. Perfectly accurate take on the state of things IMO. Thanks for this. I never believe anyone that says "I'm doing agile" is actually agile without providing me more info because it is almost always as you say in the video - something else that doesn't at all value the points in the manifesto. How would your "new agile" or "agile 2.0" challenge be different from just embracing the manifesto?

[@FastRC_tv]

We so scrum, I think pretty well. We jeep the meetings at a bare minimum and are careful that the correct people are invited to the right meetings and not all meetings. Where it fails for us is the concept itself, agile and iterative, especially the iterative part. Instead of starting with a basic product and iteratively refining with feedback, we do the old school waterfall style of full product planning, just with less detail, because agile, so we use it as an excuse to skip the detailed planning. And the work is broken into Epics and we work in sprints, but the expectation is the delivered feature for the sprint is the final completed product and no time is allotted a next real iteration of that feature. We’re just breaking down the schedule into 2 week blocks and that’s a sprint. Our scrum master is reduced to updating the schedule each week instead of enforcing scrum and working issues and coaching. This is about the only way we can operate because of how our projects are funded.

[@AllanKobelansky]

Best video I’ve watched in a long time. You are 100% spot on. I’ve subscribed. Management should adhere to Agile not just the developers.

[@jwnknoxville1579]

I went from a company that used Safe Agile to a small company that uses nothing. At the company that uses nothing my stress level has gone way down and we get way more done. Not that my current company couldn’t improve. My managers do a good job of hiring so they trust us to do our jobs. It’s crazy. I’m given a project and the software devs just communicate when we need to. We don’t need a scrum master or daily standups. I just walk to my coworkers office and talk to them if I have a question or need to coordinate work.

[@geoffcollins6601]

I started a year ago in a company that has implemented agile, and you are right way too many meetings and micro management is the.result.

[@user-xn4sd3dj9t]

I am afraid to out myself as "agile project manager" by definition, but I completely agree with you and want to thank you for this non-memish approach. I think the problem is that in many companies I worked with there is a sometimes not so subtle need for you to justify your position and this is done most easily by sticking to a formed plan no matter what and then keep your head down as much as possible. I personally try to shield my team from distractions as best as possible and focus on what actually improves our work. In a good team this means mostly let the team do it's stuff, listen to their needs and look out for ideas on how to improve certain aspects. I think most companies and managers are afraid of losing control and thus dont really want to be agile. They just want more control and more output. Funny enough in job interviews I got asked a lot about Sprints and stuff and nothing about values and theory.

[@krisd9506]

When I left the last place I worked at that used Agile, we were having meetings where there was literally 2 "project managers" for every engineer in the meeting. Oh, and they put the IT Manager in charge of software and firmware development. He had never written a line of code in his life...

[@stuartmoncur3569]

I think the closing statement says a lot: We need Agile 2.0. The original agile manifesto was the way to go. The problem is, I think, that bureaucratic organisations prioritise process over people and reporting over good outcomes. That will be difficult to change.

[@gtrbarbarian]

I'm a CSM. And a SE and Architect, 30 years in the biz. Agile is a way for consulting companies to make $$$. Most companies do not even do full Scrum, they use daily standups as a way to micro-manage. Full scrum has roles that (barely) make it work as a methodology. Remove those roles (program manager for instance) and failure is inevitable. I did just fine for twenty years prior to scrum, using waterfall and then rational unified process based on use cases. Use cases worked, and identified wtf you were building. The fallacy is that scrum produces working software. It may produce some software, but it rarely produces what the end user actually needs. It also makes engineers have to basically apologize (in toxic environments) for research spikes, requirements gathering, architecture or any other fundamentals of software engineering for which there used to be formal process. Software engineering practices are on the decline. See 737 MAX, and be very afraid.

[@eboyd53]

The thing about paradigm shifts is that they always require another paradigm shift. I'm happy that I was at the end of my career when SCRUM came into being; I saw it as nothing more than meeting, meeting and then more meeting. As a software developer I always had the end user in mind thinking about ways to make the UX better as if I would be the one doing the task.

[@pommieMJ]

We have adopted agile where I work for the past 3 years. I work in a back of office support function trying to use this framework / methodology and it just doesn’t work. It creates more meetings (as you say) and the use of the tools (JIRA & Confluence) serves absolutely no purpose for me and my team whatsoever; just an administrative overhead that takes hours a week trying to keep “capabilities” lined up to “epics” that contain the right “cards”. Oh and one meeting you forgot to mention was the “Group Sync”

[@hansrosenberg3115]

Worked agile for the last 8 years. My biggest problem is the twoweek sprints,that is way too short to accomplish anything if you're working on a complicated project. 4weeks is much better,also halves the meeting pressure with mandatory meetings per sprint.

[@nikolaimakarov3034]

i hope this video reaches all the tech companies and people who can make a change

[@jcugnoni]

We found a relativelly good balance by having 1 weekly team meeting of 1h max that is structured like a scrum. Then people self organize their week and meet when necessary to clarify something or solve a complex issue. Overall, each team member is spending about 3 to 4 h of meeting a week max. No need for micro management, or 'quantification', as the team is quite small, it is all based on trust and motivation within the team. We do development in steps but do not follow a sprint approach except in rare occasion when projects become very time constrained. Agile 2.0 is actually an agile Agile method (Agile squared?).

[@nicky5185]

I work for a big company that uses Agile / Jira / Kanban. It is funny how they are always pressuring for time estimates when most of the time the tickets I'm assigned to don't have even have the main goals that have to be achieved, left alone a single description. Looks like the title says it all. Even funnier, with all this effort in managing, the QA team is starting to test things I implememented (I kid you not) five months ago

[@alphalunamare]

I stated work as programmer in 1978 and waterfall and quality standards was what is was all about. It was quite relaxing. A couple of years later I relaised that those higher in the chain that wrote the general specifications didn't have a clue as to how to do the basics of the functionality expected. The waterfall allowed the senior designer to draw a box saying 'do this', it was left to the lower engineer to figure out how a 909 radar worked. I asked for more detail and was quickly escorted out. Not nice. The Waterfall hid incompetence. Anyway years later I came across agile and its Moonies and I simply coudn't believe it. What a total load of bollux I thought. I would be bettr off selling perfume for AMWAY. Still, management believe in this stuff because they know so little themselves. When I am developing I am discerning and learning, I need no ones leash upon me.

[@JoeCole_social]

started out as a system Admin, became a developer and then a scrum master, I got so frustrated with the implementation of agile I quit it all and went back to system admin that just so happens to do software development to automate my job. I’ll never be a software developer by title. It’s just a skill set I use to make life a little bit easier, and I couldn’t be happier. For the very reasons mentioned in this video, I was stressed out the most as a scrum master. according to the manifesto, this title is supposed to speak on behalf of the software developers, but has so much pressure from the higher-ups. I’m practice you just become a taskmaster. it’s horrible because the scrum master doesn’t have credibility as a season software developer therefore, the higher-ups don’t appreciate their authority when they represent the development staff and want to give pushback for a fair deal.

[@rallen7425]

I think part of the problem is how people use the term Agile, when they mean Scrum. I think a lot of the issues are with scrum (and SaFE etc) and how rigid they are as frameworks. People have forgotten the Agile principles while using frameworks like scrum to enforce process and track increasingly more detailed data. It makes developers feel like factory workers, not creative problem solving trying to deliver value.

[@vishnunallani]

I still don’t understand what a scrum master does and why they are needed