It’s time to move on from Agile Software Development (It's not working)
ฝัง
- เผยแพร่เมื่อ 28 มิ.ย. 2024
- 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? - วิทยาศาสตร์และเทคโนโลยี
It's failing, because agile is being used to micro-manage people
but that is not a fault with agile or scrum.
@@matswessling6600 yes you are right, agile methodologies for self management has been hijacked by managers to micro manage hours
@@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.
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.
@@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
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.
I found agile to be a way for management to micro-manage since anyone could follow us in Jira & Rally.
@@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.
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.
@@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.
@@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.
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. :)
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.
@@SpaceCadet4Jesus Yeap. NO. 😞
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.
@@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.
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.
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.
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. 😞
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.
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...
Oh my. guys been coding here since the 70s and 80s.. hats off
@@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.
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.
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.
@@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...
@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. 🤣
@@SpaceCadet4Jesus Scrum is just a money maker for some hack that came up with the idea. A Scrum Master has to pay $300 or more to take an on-line course. It looks good on paper but it is just padding for a manager's resume. Agile, Kanban, Jira too. In engineering, many middle managers have the position go to their head because they think they are a "super engineer" and that is why they are a manager. No, true engineers want to create not manage. I chose to remain technical and create. I knew one manager that read all sorts of books on management. He tried to implement several philosophies at once.... Ineffective.
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".
Yes. So tell him. Find a way to make it work for you.
Maybe thet are conducted incorrectly
@@phillipsparks9690 They certainly are....
Ironically, advertised as the framework meant to empower devs. _"By devs, for devs."_ Yeah, right, it never was.
@@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.
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.
"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.
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.
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!
@@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.
@@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.
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.
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...
They already are breaking their own rules with that one
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!
true and real brother.
I'm sorry, but that's not agile.
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.
Correct! These frameworks are for people who shouldn't be working on projects
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.
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.
@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?
@@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!
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.
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.
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.
Well tbf that is the oppoaite of agile work. So your company really wasn't following an agile progress
@@TheMathias95 A lot of companies do not follow the real agile, that's the thing.
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.
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!!!!!
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.
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.”
Tell 'em you are doing what they wish. Meanwhile, do what better fits you. Afterall, that's the _Agile Manifesto._
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.
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.
@@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.
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.
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.
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.
@@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.
@@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....
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.
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.
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.
@@FinnGamble well, that's what I meant. Of course you don't ask users to design the product literally.
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.
@@FinnGamble exactly. I've been in this game for nearly 20 years and I couldn't agree more.
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 :)
Managerial-type people will always try to make themselves "relevant".
LOL - what like communism.
😂😂😂
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?'
@@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.
The spy observation was on point. You're not paranoid, just aware
I can conform that this is exactly what is happening to me.
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.
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.
the primeagen has a better solution in his recent video about agile being dog doodoo.
Id rather just GSD than sit in random meetings.
@@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
@@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
@@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
Agile isn't really the problem it's how businesses apply it
agreed, the meetings could've been just an email or some sort
@@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 …
Communism isn't really the problem, it's how societies apply it
Communism isn't really the problem, it's how people misuse it ;)
Well, if anybody does it wrong, it might be sound good on paper but cannot be mass implemented.
I already quit software development because Agile is actual hell. Switched back to cyber and not looking back.
They force agile now in cybersec too unfortunately... Which obviously works as terrible as one may think. Source: I work in cybersec and some projects are run in scrum/agile.
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.
I would get ansy with anyone asking me how many days.
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.
@@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.
Yup, all these "frameworks" are to get metrics on developers so they can be controlled by performance reviews that are heavily documented, make the managers look effective, and help human resources that loves documented performance to justify a layoff. Under these frameworks, the developer is sweating to keep up with the clock and not really focusing on their work. It is a self fulfilling prophecy to damnation at that point.
@@paulromsky9527 Spot On!
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.
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.
@@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.
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.
Ironically Agile was invented to cure the annoying "status meetings" that existed pre-Agile
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.
@@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.
@@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.
@@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.
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.
Agile is the ultimate job security for PO and SM
I'm happy to hear at least someone is doing actual agile..
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)
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!
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.
Spies!!! I never thought about it that way! Your video speaks volumes! Keep up the great work! Subscribed!
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.
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.
I've seen one company that went bankrupt because of bad management. and I think scrum played a big silent role in this.
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,
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.
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).
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.
Agile isnt scrum or safe.
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?
Sounds like you hate your job.
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.
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.
I retired four years ago early at 57. Mainly becuse Covid was starting, but also because of the Scrum/Agile/Kanban/Jira nonsense. I was a contract engineer at the time. I started turning down offers when the following happened:
I went to a company where 8 developers sat in a room with 2 rows of 4 desks that faced each other. No cubicles, not even low wall ones. I called it the Lord's Table. Our work area was also the Scrum meeting room. Every morning we had a Scrum where we were told to stand at our desk for the entire 15 minute or so meeting. The "gods" as they clearly thought they were (office dwellers) came in too, along with the project manager (PM) who was also the Scrum Master. I had to endure standing listening to what other people were doing but I could not collaborate with them during the scurm so it was total waste of time. I asked the PM if I could sit during the Scrum and stand only when I gave my "status" because of my arthritic knee. He said, "No! Everyone must stand at the Scrum". We didn't have phones on our desks, we had to use our personal cell phones. The office dwellers would come into the room throughout the day and have meetings STANDING OVER US AS WE WORKED AS IF WE WERE NOT THERE. They made us feel inferior and it seemed on purpose. They had big offices where 3 guys could have a meeting, but no, they had to "invade our workspace".
I told the other developers, I can see them doing this to a contract guy like me that is just there to get them through a tough time, but you regular employees put up with this? Just then an office dweller came in puffing out his chest telling us to be quiet. One of the developers told him just go back to your office and close your door - we don't have offices. That started a huge argument between everyone the room and a couple more office dwellers. The tension had been building for some time but nobody said anything. At least one developer was burnt out and a zombie. I had to call a colleague in a differnt facility. I was told the guy I was calling was a real jerk and to use the "phone booth" room and close the door. They other 7 guys had a pool as to how long it would take for me to get upset with guy on the phone.. it was 5 minutes and one guy won 50 bucks. This kind of stuff kept their sanity. This was my SECOND day there. I walked out. Management was annoyed. I was told 2 other guys quit right after that. I told my contract agency (that was angry with me for walking out) all of this - focused on the known jerk in the other facility. A month later my contract house called me that the guy they sent to replace me reported the exact same situation - right down to the jerk on the phone. They said I was exonerated and they had another assignment for me... I passed.
@@paulromsky9527 wow - sounds like a nightmare! I could not work like this.
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 🙃
This is a really solid comment. Well put
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 🥲
@FranzAllanSee lol this isn't true, considering executives love meetings as well
@@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 😂
Management doesn't know anything about software because they don't talk to software departments. It all goes through PM's. Chinese whispers style.
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.
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.
YES, Yes, yesssssssss!!!!! Finally, someone is speaking out.
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.
It's not going anywhere. There is too much tied up in consulting.
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.
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.
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.
Wait - Scrum Masters with programming background actually exist?
😂😂😂😂😂😂like for real😅😅😅....
😂😂😂
@@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
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.
ha ha.. .. scrum master.. really .. ha ha..
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?
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.
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…
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.
@@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.
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.
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.
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.
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?
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.
Exactly!
Have you tried XtremProgramming or just Kanban ?
Because they both work better than Scrum :)
No framework is even better imo
This is the “no true Scotsman” fallacy. Scrum sucks. Get over it.
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.
@@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.
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.
Leadership *think* they get to see what's happening on a daily basis.
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
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.
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.
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.
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).
@@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.
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...
@@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.
@@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.
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.
Agree 100% except for the last part. There's no way companies will put developers or the process first. Even though I think that would benefit customers and therefore the company more than putting the customer/company first. I started in waterfall before they called it waterfall. Agile was never done right at least where I worked. At best it was micro waterfall and only meant to micro manage developers (cause we're always goofing off). And retrospectives were simply excuse sessions because there were no lessons learned. If you push back you are told that's the way Agile works even if you have read up on the subject matter.
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?
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.
@@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.
@@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.
@@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.
@@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.
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.
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.
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..
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
They're Aristocrats, Bureaucrats, and Charlatans attempting to micromanage, commodity, 'trendify', and cash in on a Cargo Cult. The Agile Industrial Complex.
Astute
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.
Bingo
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.
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.
Utter luxury, just 13 hours of meetings? At a bank I no longer work (obviously) as a dev I could spend 2x2 hours max outside any meeting. I was part of 2 teams so every morning 30min meeting for each, 2x 45min chapter lead meetings per week,2 hour review, 2 hour retro, 2 hour refinement, 2 hour sprint planning every other week, usually 2 meetings per week to deal with outages usually 2-4 hours. Alignment meetings with multiple teams. Migration meetings etc etc.
Then when you finally got to do some actual work, you spend 15 min every 1-2 hours getting login credentials (4 eyes principle, so request access and find someone to grant it). Writing reports about meetings and progress etc.
Most of the meetings weren't relevant to my work at all but all were mandatory to attend.
It really was meeting paralysis.
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.
Agile => micro management
Which is the exact opposite of what the manifesto states.
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.
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
No Agile is NOT micro management. Micro managers have hijacked agile.
Agile/Scrum is a micromanagers dream framework
1st commenter.. respect😊
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.
I too am think of coming up with my own framework:
My maifesto:
Do not adopt framework fads.
Hire intelligent, innovating, hard working, focused engineers.
Negotiate the Scope/Cost/Schedule of a project with them.
Break the project into smaller goals but not too small as to micromanage.
Set your engineers off to make it happen.
Give them small personal spaces, not open boiler room offices.
Get weekly feedback from everyone via an email.
Hold meetings only when needed to stay on track.
Don't over document task progress.
Don't over communicate.
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!
Well, Agile develop method is just another name to the famous development trap that call "Feature Creep", that is what it is.
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
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.
Agile is an infinite series of 2-week waterfalls.
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.
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.
"Agile, like communism, never fails". Use the quotes and append my last name if needed.
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.
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.
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.
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.
At my last AAA game dev gig we always said, “when the sprint becomes a marathon”. Never again I want to work this way.
I run very lean Scrumban and it works great. Daily standups are usually 5 minutes. We combine retrospectives and planning into a single meeting every 2 weeks and it is usually done within 30-45 minutes. It works fine as long as the person running it is trying to keep these meetings short and efficient, and the developers themselves are the ones breaking down big tasks into smaller ones, providing their own time estimates, etc.
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.
I still don’t understand what a scrum master does and why they are needed
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.
I briefly worked for a company that was all in on Agile / Scrum. When I left I told the boss, "You processes and people are failing you!" Six months later the government reduced their contract by 1/2 due to non performance.
No matter what, the people whose business success thrives on meetings will have meetings.
Starting a job as project manager and developer soon (first time in both roles) and this video is gonna come in handy a lot. Thank you!
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.
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”
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.
It's not time to move on from agile, it's time for managers and scrum masters etc to finally take a look at the actual agile manifesto and realize that it's literally about teams having the power to decide their own process and do what works best for them. I worked in one place where that was actually what we did and it was amazing. No goddamn standup or retro or any of that crap, if anyone was blocked or needed help or code review we just asked in chat. We had literally one fixed meeting weekly that was like 2 hours long where we went through everything that was in progress and what tasks are up for grabs next, then everybody just took one of those when they were out of work. If the actual tasks needed to be discussed, we just asked whoever was competent in that area for a bit of help, instead of wasting the whole team's time with planning poker and such. Deadlines were also not strict promises, more like estimates, but we only released features when they were actually ready, no half baked shit allowed in the code base. It was amazingly simple and effective.
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.
I’m not a dev but an end customer. I completely agree - Agile as implemented currently doesn’t work for the client either. I say get rid of the middlemen whether it’s scrum masters or micromanagers and let the client or end user communicate directly with the developers who are doing the work. A lot of issues and frustrations could be avoided. The reason the system isn’t designed upfront is because the client has no idea what they want, they usually have a vague concept and a wishlist; direct communication with the dev team can actually help a lot in shaping the end result early on.
As a PO i hate scrum.... all those hours reviewing, retrospecting, refining, never end.
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?
I work for a manufacturing company that uses this form of 'mis-applied' agile methodology in the product design & development process.
My group works directly with engineers, and have heard from them that they have so many meetings that they barely have time to get any work done. They seem to go from meeting to meeting to meeting almost all day, everyday...make their job easy, but harder to make progress on their projects.
Thanks for the primer on Agile, and the pitfalls of this project management method.
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...
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. 🙂
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
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...
I worked as a client side PM for about 12 years. Almost without exception, I found development side PMs and account managers and scrum masters to be essentially useless fluff that mostly got in the way of progress. By the time I was in my second year in this role, I insisted on always working directly with the code writers, and completely bypassed all the dross. Generally we had one or two pre-Sprint meetings, and one debrief at the end of iterations. All other communication was handled through the ticketing system. It took a while to work out the kinks, but once we did it was a lot of fun, and we got a lot done.
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.