Have you ever been gaslighted by software companies trying to signal their agility? What did they claim, versus how they actually worked? How did you cope with it?
@edbrito-swdevАй бұрын
I can honestly say I've only worked in a single company (out of 5) that was truly agile. One I worked at was waterfall and wasn't as bad as most others. Most said they were agile but were more waterfall than Niagara...! One of them used ALL of the intended Scrum meetings and tools and were so stuck into them and were so rigid that, in a way, were worse than your typical waterfall. The problem I had in the company that was agile wasn't even related to these things. Most problems were mostly due to the total inefficiency of the build system... Between pushing your PR and having it going through the whole CI/CD pipeline, including restarting twice or more times because of flakey tests, it could take you the whole day to have something up for CR even if you had finished it in the morning.... For people with ADHD, having that task lingering was a killer of productivity and a source of stress and anxiety...
@HealthyDevАй бұрын
@@edbrito-swdev sounds about right. When I've been on truly agile teams technology is the thing we struggle to overcome - instead of people. At least that can be done by the developers.
@manishm9478Ай бұрын
Calling this gaslighting is spot on. My current company talks the talk, but it took me months to realise there was no substance behind the words. Once i had that realisation i stopped investing in the rituals or trying to create change, and have just focused on becoming a technically better dev. This has been much better for my sanity :)
@edbrito-swdevАй бұрын
@@HealthyDev it can be done by the developers IF management allows it... In that specific case, the organisation of the project was beyond any repair. There were two initiatives to improve the time for the CI/CD pipeline and none yielded any improvements.... Although they did find one E2E test that was always taking 45 minutes (or more) to finish... I don't even know how such a test was even made AND approved...
@MissPlaced84Ай бұрын
Did my best to act as if I at least was agile, now people seem to think I'm the Jira master or something.
@taikoHHАй бұрын
What went wrong? Agile became a product, then snake oil, sold by consultants. Now it's dead.
@jamessullenriotАй бұрын
☝That's it, that is the only thing this video and any other video, article, or any other commentary on this top needs include.
@falxonPSNАй бұрын
That oversimplifies it a little too much. The problem was that it was a victim of its own success in several ways.
@taikoHHАй бұрын
@@falxonPSN agreed
@llothar68Ай бұрын
eXtreme Programming, Agile was to save a project that was stuck in problems. It wasn't used as the complete and only developent methology for everything. Especially in the beginning you need a different way
@sacredgeometry29 күн бұрын
Engineers stopped owning it. Incompetent middle management, and failed conference hopping/ book authoring developers and consultants used it as a way to sell themselves. The manifesto is really simple, its straightforward and pretty sensible. Yet I doubt the people that advocate for SCRUM have ever even read or understood it as they hyper-focus on the literal opposite.
@adambickford8720Ай бұрын
Agile is just waterfall where they blame the devs instead of management when it goes off track.
@stephenhookings1985Ай бұрын
But agile seems to be waterfall by 1000 cuts.
@watamatafoyu27 күн бұрын
Your victims to project managers that used agile wrong or in name only.
@NicholasMa4219 күн бұрын
@@stephenhookings1985 waterfall but with more time wasting "rituals"
@picleusАй бұрын
It feels like Scrum/Agile is just an excuse for leadership to shift blame for all problems onto the development team. And leadership has no interest in helping the team improve because the team is supposedly self organizing. Most frustrating thing I heard from my Scrum Master: "I know why your team is underperforming, but you need to figure out the issue yourselves and tell us how to fix it." (as if we haven't been suggesting improvements for months in retros...)
@HealthyDevАй бұрын
You literally heard that? They know why, but won't volunteer it? Incredible.
@hb-manАй бұрын
I'm trying to decode what situation you may be in. So you are talking about "my team", still refer to "my scrum master". Assuming that this scrum master is the one responsible for you and your team, like a normal situation with a scrum team would be, doesn't fit the rest of the story. Are you the local scrum master and answering to this scrum master oracle? On the one hand, I understand it might be inappropriate for him to simply tell you what the reason may be, on the other hand: why this cloud of mystery?
@first_m3m3Ай бұрын
Sounds like my previous manager who was using a mixture of Scrum and 6 sigma to turbo bust the project times... That was the weirdest professional experience of my live.
@steve1978ger28 күн бұрын
Christ, what an arsehole.
@teeg303028 күн бұрын
My scrum master is a complete moron!!!
@16randomcharactersАй бұрын
Agile originally was about bottom up visibility, but managers got ahold of it and turned it into top down command.
@HealthyDevАй бұрын
Truth!
@TheRealJacquesStanderАй бұрын
This is without a doubt the most insightful critique of agile. It's taken every ounce of joy out of my profession as a software engineer. I see people all around me cutting corners, being "yes-men," and not putting effort into development. It's no longer about the engineering; it's about making our progress accessible to management in an overly superficial way. This shift has led to a decline in quality and innovation, and it's disheartening to witness the erosion of our craft. Very demotivating
@HealthyDevАй бұрын
I'm sorry, I feel for all of you. I hope this at least gave you a couple insights into why it happened and maybe that helps you see at least a glimpse of promise that the original ideas are needed and have some merit. In the meantime, it sure is frustrating to not be able to see those original ideas come to fruition, to be sure.
@Froggalopalous14 күн бұрын
@@HealthyDev It sucks being an admin/Ops person in companies that never put a focus on really understanding and implementing the philosophies and practices of quality software development. You can espouse the values of R.T.F.M., understanding adjacent abstraction layers, reading the RFCs 'til the cows come home. But, devs are often so incentivized to take a development-task-myopia approach that you know little to nothing of it will find purchase in the brain of the receiver. The world is too obsessed with XaaS
@yasuynnuf1947Ай бұрын
Agile is shit ton of micromanagement of the delivery team and putting pressure everyday to finish the work by tomorrow.
@ChrisAthanasАй бұрын
Make work is necessity in a ZIRP environment where people who got access to the free money have no idea how to make the stuff
@herp_derpingsonАй бұрын
yesterday
@Gnaritas42Ай бұрын
Agile is nothing of the sort. Whatever process you're describing, if it doesn't conform to these values Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan It's not agile. Scrum is not agile. Whatever shit you're criticizing, also isn't agile.
@OldTiredFatАй бұрын
@@Gnaritas42If it walks like a duck, and sounds like a duck, it's a duck. Good programmers develop a list of things not to do. Agile is just another POS method which doesn't define wrong.
@qj0n26 күн бұрын
@@OldTiredFat nah, you can screw everything in infinite number of ways, the important part is what you want to achieve, not what you don't want to achieve. That's mostly defined in agile principles - sustainable development, customer satisfaction, continous improvement etc.. And using the duck method - if you don't improve (or at least reflect), team is not self-managed and development pace isn't sustainable - that's not agile
@KeeperKen30Ай бұрын
Poor management is driving us mad. Agile gets the blame.
@Rob-zp3hn27 күн бұрын
Agreed. I can't but think of Larman's laws of organizational behaviour.
@gkprojectmanagement12 күн бұрын
Poor management brings poor projects. With everything that includes.
@purdysanchezАй бұрын
In 2024 "agile" means "just do it as fast as possible".
@theaccountant666Ай бұрын
And w/o SOW or resource plan... as we make it up as we go along
@xlerb2286Ай бұрын
@@theaccountant666 I've heard "just story point it, we'll work out the details of the story later". Nuh uh, not falling for that ever again.
@markboler8411Ай бұрын
Yep
@SongfugelАй бұрын
I wish! Here it usually means: we know the project is not important and will fail anyway, so here is an excuse you can blame it on when that eventually happens, since no one in the project group has any idea what agile actually means
@kelvinkao7436Ай бұрын
@@xlerb2286 Oh, that's when I would be like, 23 points, which is probably accurate
@rich_in_paradiseАй бұрын
What went wrong is the Project Management Industrial Complex got involved. True agile is an anethma to traditional project management, but those people weren't just going to go away, so they decided to improse their management goals (predictability and long-term planning) on an inherently chaotic process and the result is BS like scrum and scaled agile.
@ChrisAthanasАй бұрын
They want to make the risks in software the same risks they heard about in them fancy management books they read at that big name college
@Benforeva27 күн бұрын
I think project management has been adopting agile not evolving or butchering it. They are just adopting our existing problems.
@JJSmallsАй бұрын
Exactly. Agile feels more like trying to turn software development into an automotive assembly line.
@HealthyDevАй бұрын
Yep. John cutler coined the term "feature factory" years ago and it describes this mindset perfectly IMHO: medium.com/@johnpcutler/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2
@pencilcheckАй бұрын
@@HealthyDevwow
@rodrigoserafim8834Ай бұрын
If I could only tell you how right you are. Endless discussions with my boss trying to explain him that we are not the workers of an auto assembly line, we are the guys the design the assembly line. We never do the same task twice, and if we do, we are probably doing something wrong that forced us to do boilerplate by hand or reinvent the wheel though ignorance. At the end of the day management cares only about KPI's and return on investment (focus on the return), not through malice, but because that is their stress point. But that does not work for SE. We know how to program a bubble sort, but we never ever do, because its already in the standard library. Our work is to find out the advantages to apply it to this situation or not. I spend more time not programming and analyzing a problem than actual keyboard action programming. "Programmer" no longer means the person that punches the cards or inputs the machine code into the cpu. What we do is more akin to vaccine development than to sorting boxes. There is a process, there is a very high probability that a solution exists, there are stages of achievement, but there is no predictability in many of those stages.
@gregsimoes864529 күн бұрын
This is the issue precisely. Basically, management wants a clean metric to identify good vs bad performers, but problem solving can't be neatly defined that way. Just because one person takes an hour to solve a problem and another person takes 3 days to solve a completely different problem doesn't mean the first person is a "good" performer, the second person might have had a significantly more complex issue to deal with. "Agile" has destroyed most development teams because management thinks they can use it to get maximum efficiency with developers that will crank out features on a clearly definable cadence. Even better, that cadence (sprint) is usually pretty short (approx 2 weeks).
@gregsimoes864529 күн бұрын
This is the issue precisely. Basically, management wants a clean metric to identify good vs bad performers, but problem solving can't be neatly defined that way. Just because one person takes an hour to solve a problem and another person takes 3 days to solve a completely different problem doesn't mean the first person is a "good" performer, the second person might have had a significantly more complex issue to deal with. "Agile" has destroyed most development teams because management thinks they can use it to get maximum efficiency with developers that will crank out features on a clearly definable cadence. Even better, that cadence (sprint) is usually pretty short (approx 2 weeks).
@chancepaladinАй бұрын
do you even agile bro? ... no cuz this's a WATERFALL PROJECT with SPRINTS!
@mmmarcdАй бұрын
Thank god we don't build infrastructure like we do software. I'm not driving over an 'agile' developed bridge.
@simonorange4191Ай бұрын
The problem is the higher up executives who know nothing about software developmemt are demanding us to give them "how long will it take?" and "when can the project be completed?". Then the manager thinks he can control the time and prediction. What can we developers do 😢
@user-oj7uc8tw9rАй бұрын
This is the problem. They think that software development is like buying a catalogue house. It isnt. I cant think of how many times these questions are asked and how many times things never go to plan. It aggravates me every time its asked because the answer is never correct.
@xybersurferАй бұрын
i agree. there is basically an optimistic answer where everything goes as planned, and a more pessimistic answer where you are almost certain it's enough time. it's hard to find a balance and they try to get you to go lower. either way, i always try to communicate that it's just an estimate and name the problems i may encounter, also information or other things i expect to be ready when i get started. this is a good time to not only estimate, but to also have a critical look at the project and ask questions. what is expected from you, should be crystal clear. you basically have to cover your ass
@dylanpeterson6449Ай бұрын
What happened... a bunch of MBA's got involved.
@tonipejic2645Ай бұрын
Totally on point, in my previous company we spent over 2 years trying to build an MVP and failed miserably, at some point there were discussions of adapting SAFe as well. Constant meetings all the time, planning, planning and more planning and even with all that planning requirements were never clear, making constant dissonance between QA and developers, we were spending so much time on bullshit just because people have different interpretations on requirements (in my opinion QA is not even needed for an MVP, just slows down the process by at least x2 and most of the MVP will change anyway by the time we launch). Any hope of a change of the process was squashed because "we can't do that, that's not scrum". I'm glad I no longer work there, it was just a complete mess. In my current job I discovered what blessing it is to have a technical manager, someone who actually contributes and understands what we are doing. Also sprints are complete bullshit, it's just there for managers to keep them busy. The amount of damage caused to code bases from trying to cut everything to fit in 1-2 weeks is extreme, it produces so much technical dept. Some things should just take time, an unpredictable amount of time but that's what scares managers and that's why scrum and agile can't ever work
@orange-vlcybpd2Ай бұрын
My biggest "problem with agile" is that people say agile and mean scrum. Those are not interchangeable terms. And what failed is scrum. Agile is just fine. Agile is set of values. And scrum is a process. And if you want to know why your project does not work with scrum, look at the 12 agile principles and you will find every single of them violated in your scrum process. We need to go back to the roots i would say.
@piotrd.4850Ай бұрын
And these 'values' profoundly SUCK.
@raptorate2872Ай бұрын
Nope with agile people mean agile. Developers end management know the difference, you're not some high iq guy who can get away with "actually". Your not that guy mate, not that guy. The whole principles of agile is just generic decent business practices that are more common sense than anything. You just fell for the propaganda. Scrum is literally implementation of agile
@orange-vlcybpd2Ай бұрын
@@raptorate2872 "Common sense is not common practice" --Mary Meaney Haynes
@raptorate2872Ай бұрын
@@orange-vlcybpd2 Instead of addressing the arguement, you gonna write some generic quotes. No wonder you fell for the scrum propaganda, it's also the most generic advice. Sigh, if only people like you could think for themselves. It'll get better mate, hopefully. Ciao
@gbitteraАй бұрын
When you read the scrum guide and understand the manifesto, you will clearly see how easy it is to create alignment between the values and principles of the manifesto and what is being offered in the Scrum Guide.
@purdysanchezАй бұрын
Very large companies just sh*t out APIs that don't work because "we have 300 teams working fast".
@OiTiO82Ай бұрын
The best thing about SCRUM is the Burnout Chart.
@renato_n.nАй бұрын
lol
@HealthyDevАй бұрын
🤣🤣🤣
@ChrisAthanasАй бұрын
The true name of the chart
@jasonhighlanderАй бұрын
Oof!
@PeaceIndustrialComplex21 күн бұрын
oh no lol
@mat4246Ай бұрын
The best I've ever heard about scrum is this dialogue: New team member: What does 1 point mean in task estimations for our team? Manager: it's 3 hours of work
@carterbc618Ай бұрын
My team treats 1 story point as 8 working hours 🤦♀️
@glader88Ай бұрын
I called BS on the entire thing and now we're estimating in man-days, which is what it ultimately gets translated to anyway. At least we're honest about what it is and we don't have to endlessly debate how much a point is worth when we're doing the estimations.
@mmmarcdАй бұрын
The way people estimate is stupidly backwards. You don't look at a task and work out how long it will take, you give yourself fixed 2-3 day boxes to start filling in with tasks you estimate you can get done in those days. If you can't break something down into 2-3 days worth of work, you haven't put enough thought into it.
@mmmarcd28 күн бұрын
@@steve1978ger Aaaand you miss the point. There are many tasks that take less than that to do. The time boxes are not task based, we're talking about estimating here.
@steve1978ger28 күн бұрын
@@mmmarcd - Alright, sorry, fair enough. I've been made to do fake agile for many years now, so I'm pretty cynical about the whole thing
@dinckelmanАй бұрын
I had a job that’d mention agile principles at every damn convenient moment, but then ignore literally all of them, and make people spend so much time in useless meetings, that you’d be away from work for more than HALF of your total work time. They sponsored my certification too lmao. Needless to say, the project failed
@bearwolffishАй бұрын
Excuse for management with nothing else to bill for to have a meeting to get updated on progress and workout who's job they can cut to increase their bonus.
@edbrito-swdevАй бұрын
@@dinckelman very true. One company I was at it got to the point where half of the time was meetings. When confronted by this, one answer was: "you can mute while at the meeting and continue work". What's the point of the meeting then? That meeting should have been an email (or a fistfight), indeed.
@xybersurferАй бұрын
that sounds crazy to me, but i frequently see such a comment. i'm guessing it's some kind of stand-up meeting. some places really need to keep those short and reduce the frequency
@_Mentat24 күн бұрын
LOL, you work for the same company as me. Here 'certified scrum master' admits you to the priesthood and you become one of the elite. I've got the cert. I still think agile is crap. Not the philosophy, but the scrum methodology.
@xlerb2286Ай бұрын
The last company I was at before I retried did agile better than any other company I was at but I'd still call it fake agile. They were trying, and management was actually pretty good most of the time. But a crunch would come along and it would all go out the window with a statement like "we have to do this set of features by March 1 and we can't negotiate the features or the date". Well the old features/speed/quality triangle still holds, and management picked two. So I had enough. I was going to wait until 65 to retire but I called it quits a couple years early. Mainly due to agile.
@robby346719 күн бұрын
I'm around the same age and looking to retire soon, depending on what comes along in terms of projects. The most annoying thing for me is forcing release by date, thereby sacrificing features and reliability. Better a month late than on time and broken, or lacking an important feature. Upper management seems to be all about ticking boxes rather than producing solid reliable products.
@xlerb228618 күн бұрын
@@robby3467 You said it!
@coldfusiontrashcompactor5643Ай бұрын
Before Agile I was used to working on a project directly with the Business end. Business had a basic idea of what was needed and we would start working back and forth to make sure we covered everything that was needed. If issues came up that was not accounted for by Business we would brainstorm and figure out. From my side as a dev It was a fantastic way to LEARN the Business side of what we were making software for and develop a good intuitive sense of process and what people were "Really" asking for when they said they wanted a new feature or item. I loved it and the job was fun. This has been COMPLETLY severed do to Agile. now it's just vague user stories, devs not allowed to ask questions of the business, imposable deadlines, business never happy with outcome, lots of NEW stories for reworks...on and on and on. it is painful.
@teeg303028 күн бұрын
Exactly!!!!
@David-no7zi23 күн бұрын
Same here…and what we have experienced really is Agile making us less agile.
@karlssbergАй бұрын
I once worked on a team that I suppose you could say was truly agile. I was brought in halfway through the project as a contractor and it was clear from the beginning that the devs were in charge of the work/schedule. We didn't even have a board. It was the most satisfying team I have worked in and it seemed to get the most out of people. I later moved to a different team (in every way) and was chatting with a manager who said that she wanted to reign in the first team because they had such unorthodox practicies. Just like they used to say "Nobody got fired for choosing IBM", today it's "Nobody got fired for choosing (faux-agile) Scrum"
@HealthyDevАй бұрын
Bummer! Hey at least you got a taste! That's more than many people I meet, sad to say :(
@THEROOT1111Ай бұрын
I dont consider companies that use agile let alone scrum and scrum masters serious companies, it is what it is, nobody wants to work for people that don't know what the hell their doing, they might aswell outsource all their engineers and close shop.
@henson2k24 күн бұрын
Just few companies need to be really Agile, most of the time speed of development is less important than reliability, compliancy, security and so on. It's a shame we stuck with the same Scrum cult everywhere.
@IdkMaybeShawnАй бұрын
As soon as I saw SAFe on the screen i threw up in my mouth a little bit.
@stephenhookings1985Ай бұрын
How dare you! I have a SAFe qualification... oh wait. You are right. Soz. In one IP the team of diverse subject matter experts stopped communicating. One dude sat and hid a problem for a 3 days. Then consulted with one colleague for another 3 days. At that point they realised they couldn't deliver what they committed to - and the ART came to a halt. People blamed agile. Perhaps.
@witblitsfpv1265Ай бұрын
It is frustrating, almost to a point where waterfall looks appealing. Nowadays in most companies Agile is being used as recipe for success with the added bonus of micro management. Well said on the burn down charts etc. that is exactly what they are being used for - now it makes sense. I find it a bit weird how burn down charts are pushed without addressing the elephant in the room - hard (and fast) work gets rewarded with more work.
@Erik_The_VikingАй бұрын
Scrum and Agile = micromanagement. As you mentioned, many projects were way over budget and generally months behind schedule or cancelled. The *IDEA* of them is good, but it's turned into "get this done quicker" which isn't what it was intended to be. Software is unpredictable by definition. Every company I've seen who's attempted or has implemented "agile" has been a train wreck.
@JohnSmith-op7lsАй бұрын
That’s the issue. Agile was meant to just be a handful of high level rules to manage by. While in theory this left a lot of room to figure out how best to implement those rules in your specific setup, it ended up just leaving the door open to the creation of over complicated dogma which was pushed along by countless grifters looking to sell training, certs, and get cushy jobs. The more complex, the more you need training, certs, and dedicated people to manage the process.
@HealthyDevАй бұрын
It's sad that we adopted agile methods to have less overbudget and late projects than what we had with waterfall - but fake agile projects make them even later and more overbudget! This is why I suggest many people use waterfall these days.
@Erik_The_VikingАй бұрын
@@HealthyDev I've noticed a trend to companies actually going back to waterfall. Go figure.
@HealthyDevАй бұрын
@@Erik_The_Viking for sure. If the company cannot operate without fixed delivery dates, waterfall sucks but less than scrum (in that situation).
@ricmorris975825 күн бұрын
@@HealthyDevI think this fundamentally misunderstands capitalism. Agile doesn't mean avoiding commitment to delivery and quality. If the team is poor and builds up technical debt in the face of change (which agile welcomes) then they will become unfundable. At that point they have reached a stable product proposition or they haven't. Both waterfall and agile fail for the same reasons. The consequences of change. And that doesn't even touch the reputation and brand damage of putting none functional/sub optimal product to market.
@sebastiaanmaure6434Ай бұрын
Agile is like marxism: the advocates always state that it didnt work because it wasnt implemented right. Maybe, after 30 years of failure, it is time to accept the fact that the thought of Agile is nice, but it really has no place in 99.9% of businesses. I have built many successful products, on time, but also many unsuccessful products, not on time. The common denominator is not the work process, but the in depth understanding of the problem that needed solving. And the ability to communicate it properly. Because that gives pure direction, a clear goal, and creates an environment and team where everybody participates into achieving that goal. And just shitting on the management is bad. Agile did morph into micro management, true. But it also morphed developers, where they usually are totally disengaged from the product. But hey, at least they gave the story 8 points and the productowner didnt listen. Sure.
@lesleymorgan01Ай бұрын
You can either talk about work, or do work. So frustrating.
@glader88Ай бұрын
Are you sure? I suggest we schedule a meeting right when you are in the zone or half an hour after your lunch break ended to discuss our way of working. We could have bi-weekly follow-ups to iterate on it.
@jmmoyadevАй бұрын
The problem isn't Agile. The problem is SCRUM, that is a methodology to burn developers every 3 or 4 weeks. Before that, a developer usually had peaks of work eventually, now each iteration is a peak of work, you are always "sprinting". In my opinion software development is more like a marathon (with checkpoints) than a 100 meters sprint. You get really tired and frustrated. You can't run a marathon sprinting all 42 km.
@kelly418727 күн бұрын
I’ve just given a talk about this at my work, having managed now both agile and scrum contract projects. Agile is pretty fluid. You can be as risk averse or risk taking as you like. You can be as fast or slow as your needs demand. Each ‘sprint’ is as big or small, or long or short as your need. It has next to no bureaucracy built in. Scrum however takes all of the good points of agile and throws them out with mandatory bureaucracy. It’s now bloated with life being led by a Jira or ADO board. It has all the worst points of PRINCE2 without any of the benefits of textbook agile. I refuse to use either now. From experience I actually find using a normal waterfall approach tinged with a bit of sprint to set the main objective for the next 2 weeks or so, gives lots of flexibility.
@qj0n26 күн бұрын
Devs should decade pace on development so that it can be sustainable. Nowhere in scrum guide it's saying you should do any overhours or exhaust the devs
@qj0n26 күн бұрын
@@kelly4187 which parts of Scrum beurocracy is useless? We have product backlogs with some ideas to do and sprint backlog where devs can put some tasks... I don't know any method with substantially lower paperwork. Definitely not waterfall, if you are doing it as described in the waterfall whitepaper
@TheUnkaDaveProject7 күн бұрын
The goal is spposed to include (finding and) working at the pace that the team can maintain forever...you have experienced incompetent Scrum Masters
@jose6183Ай бұрын
Management is the worst type of employee. What a curse...I quit my job this month to change career. Been a developer since I was 15 and I will continue to work but not for corporate, nor use "agile" for this crap
@ryuhanedaАй бұрын
My focus these days is heads down. I want to code, to get better at it or find new things to do with it. I burned out. I know I still wanna code, but I'm not at peace with a career that doesn't function like it used to. But work still needs to get done. So I'll be doing the best I can as fast as I can until the day I figure out how to do something else.
@HealthyDevАй бұрын
Hang in there. I felt the same way for many years. At some point I had to go on my own. But until then, I did the best I can given the circumstances. I was able to provide for myself and my family the best I could, despite the dysfunctions. Which is honorable and sometimes necessary for a time.
@ricmorris975825 күн бұрын
Then agile is not for you. The emphasis in agile is on a direct relationship between customer and developer That means spending more time understanding the customer than you spend coding... which is why, after spending years blaming the BA a lot of teams fail at agile by treating the PO as "the great requirements dictation machine"
@ddubb3000Ай бұрын
Agile has been corrupted because those who write the checks call the shots and what they say goes bottom line. Love the video great job!
@brianernzen250921 күн бұрын
Yes, that is the way it should be.
@JimAllen-PersonaАй бұрын
This is why Charles Wang (CA) took people off software projects that were running late and limited hours team members could read email. Counterintuitive? Yes. Did it work? Sometimes.
@whydoubtАй бұрын
This really does help answer some questions I had about Scrum and Agile. I heard someone state recently that story points are supposed to be about complexity, not time. My immediate thought about that was "then why did my employer use them for velocity tracking?" (said employer gave up on Agile recently FWIW) That those things were bolted on to appease people concerned with scheduling makes a lot of sense.
@HealthyDevАй бұрын
As with many things in life, those who want control will do anything to rewrite history...
@75yado28 күн бұрын
of course they are about complexity... developer are notorically bad at time estimation and there is no guarantee that two problem with similar complexity would take the same amount of time.
@HealthyDev27 күн бұрын
@@75yado it's not that developers are bad at estimation. It's that the inherent qualities of software (being knowledge work) are unreliable to predict.
@75yado27 күн бұрын
@@HealthyDev I may reformulate... I as a developer am bad at time estimation :D
@HealthyDev27 күн бұрын
@@75yado ha! OK I got you now. Me too.
@declinox29 күн бұрын
100% agree, as a developer and software architect working professionally since the early 90s. Agile is, at its core, about providing a structure within which a business can change direction in a controlled manner. Secondarily, it's a contract between the business and its developers that defines the responsibilities and obligations of each party, in a way that is at least somewhat fair to the developers. My experience was that there was a boom in the late 2000s, and 2010s, of companies trying to sell agile training, in particular Scrum. Very often, Scrum was sold as "2x the delivery at 1/2 the cost"... and of course lots of companies ate that up. But Scrum isn't (in my experience) the quickest or most efficient way to build software, and lots of other things can impede velocity. Too often, business people see all problems as ones of process or motivation, because that's what they understand... but if your problem is 500k lines of spaghetti code, good luck. As far as the contract aspect goes, any software development management paradigm has to say who's going to own the uncertainty. The fundamental problem is that the variation, complexity, states, paths, etc., whatever you want to call it, are too high in many projects for mere mortals. If a development team can't tell you straight away how much effort something will take, or if they need to spelunk through the code to answer simple questions, or if they avoid touching existing code in favor of adding new code, those are all signs they don't have a good grasp of the codebase. So there IS uncertainty. The business must acknowledge that, and either a) adjust their requirements, b) give the dev team enough time to resolve the unknowns and figure out a solution, or c) give the dev team an arbitrary deadline. In the case of c), expect developers to leave, which will exacerbate the problem. So - in my opinion, good velocity is a side effect of good requirements (that recognizes what is likely to change, and what is not), and good architecture. Good architecture is a side effect of good requirements, valuation of good technical design, and enough slack in the schedule to actually work on it. If you take Mark Twain's quote (paraphrased) "I didn't have time to write you a shorter letter" to heart, that's a decent approximation of good architecture. The more corners you cut early, the more you're going to pay when you need to change the design. As a result, too many companies' software bogs down under its own weight around the 9-10 year mark, and can't be maintained without a lot of work. Is it agile's fault? No. But agile is sold as a solution to the problem, when it is not. By the time you experience the problem, it's too late.
@HealthyDev29 күн бұрын
Great analysis. I started in software in the late 90s so we probably had similar experiences. Thanks for sharing your perspective.
@rickvance896424 күн бұрын
As an "agile coach", I agree with everything said. To me there are only two important things to becoming "agile". #1 use lean principles to organize/plan work. This includes limiting WIP, reduce/eliminate handoffs, develop incrementally, #2 implement continuous delivery practices.,
@manishm9478Ай бұрын
I read a book years ago from a lean manufacturing consultant. He described how hard it was for companies to successfully make the transition from traditional manufacturing to lean. One factor was that the activities that were easiest to implement only gave a short term boost to effectiveness. If they weren't followed up by deeper change, the company would eventually revert back to the same or worse performance. Another was that a company might implement practices mostly right, yet miss a key detail that renders the practice ineffective. I see this applying to Agile too. If you implement tools and processes without deeply understanding what problem they solve and how, you risk having the change become pointless. Eg at my company we have 'user stories' which usually have nothing to do with the user and lack a story of how they use the software. So tickets become heavily dependent on each other, and the whole thing can't be released to prod for months.
@HealthyDevАй бұрын
Great insight. I couldn't agree more. Reverting when the change isn't deep is exactly what I've seen happen too many times. Thanks for bringing that up!
@thomasracer56Ай бұрын
Working for a company that has all 4. Which usually translates to vendors keeping inventory and restocking production lines (usually termed Vendor-Managed Inventory or VMI). 2021 and 2022 were an interesting time. A short list of what that translated to: -suppliers frequently asking us to sign off on deviations(~20 deviations/week at its worst). Even in 2024 we still get some kicked our way. -difficulties with quoting anything new that could be used across multiple projects, and routinely having those efforts fall flat because Minimum Order Quantities are a thing. -of course we were hit by the chip shortage. The software and systems teams loved dealing with that. -Vendors rarely having enough personnel at a time to deal with rapid changes during prototyping. Burned bridges ensue. More so when prototype parts needed are also responsible for holding up the almighty testing schedule. -testing schedule is almighty but no one remembers where old test results are kept. Or trusts them when found and presented. -engineers become punching bags for holding up testing over even small mistakes, no room to ever be wrong. Half the time over things they didn't design or were overridden by management or other engineers on. -engineers being asked by management and other engineers about vendor lead times repeatedly in the hopes that asking more times leads to engineer promising all parts will be there tomorrow. -enticing some vendors to lie about what they can deliver and hope that no one actually needs the parts THAT badly. Getting caught in lies either begets more lies or a vendor that's afraid to commit to anything ever. -engineers frequently tossed between aggressive deadlines on new products (24 month development time to a product that can be sold is what's commonly being pushed) and existing products (Vendors saying we have a week or less to sign off on deviations before engineering is blamed for production shutdown) -attempts at multisourcing parts with equivalent specs falls apart quickly. Frequently pressured to work with sources not covered by multisourcing strategy who may take shortcuts to getting parts delivered or have little potential of supplying parts long-term. Forces engineers to choose between getting chewed out by manufacturing/techs and being berated by service when things come back. -and of course, software being everyone's least favorite team Really does feel like a guy can't win sometimes and has to make a judgement call of who gets to be pissed off any particular week. Except the techs who always hate engineering and anything that constitutes even the slightest slowdown.
@lost-prototypeАй бұрын
I wish there was a job board for vetted companies that don't pollute the industry in the ways you describe...
@pencilcheckАй бұрын
Same
@gullijons9135Ай бұрын
I'm pretty sure you can find an empty website out there somewhere and use that as a stand-in
@Reflekt0rАй бұрын
Your audio quality is amazing!!
@HealthyDevАй бұрын
Thank you, I put a lot of work into the audio actually. Glad to hear it's working!
@Reflekt0rАй бұрын
@@HealthyDev It's pure ear candy, better than much bigger podcasts, even.
@aaronbono4688Ай бұрын
What I find bizarre is that, for nearly 2 decades I have worked in places that say "we do Agile" but it was waterfall and I knew it all that time. Now I am finally in a company where change is the name of the game on a daily basis - it is the first place I can say they at least try to be a little Agile and it is now that things are as non-Agile than ever everywhere else. My world seems to run backwards.
@HealthyDevАй бұрын
Literally gaslighting. How can we not go crazy with them changing the definition of things constantly to suit their comfort level at the moment?
@toddbu-WK7LАй бұрын
You are absolutely right about this. But I think that you need to explicitly say that Agile is a management failure. Here's why I say this... back in the mid-90s, before Agile was being widely adopted, I had a PM who would often prioritize tasks because they could be done easily and quickly. One day I told him, "you don't do things because they can be done quickly, you do things because they are important". This has been my mantra ever since. Yet even within the past few months, my team wanted to strengthen its use of Agile because management was worried that resources would dry up and they wanted to know how they could shuffle around the work. This is exactly the wrong strategy. If the business can't afford to fund every project then isn't it all the more important to get work done that has the greatest net positive impact on the business? If all you can afford it to do is one project done right then that's far better than to half-ass a dozen projects and get very little return on that same investment, often with a bunch of tech debt because you cut corners.
@HealthyDevАй бұрын
I'm not sure what about agile specifically mandates doing quick tasks over important ones. That's more a prioritization mistake of individuals, versus an inherent fault of agile methods in my opinion. I do see your point though. That absolutely is a big problem and very common unfortunately.
@xybersurferАй бұрын
that's a tricky problem. i've seen that it's often the simple stuff brings in a lot of cash, even when half-assed (low hanging fruit). but, it's of course not good to be working on too many projects simultaneously and being rushed, especially in "experimental" projects. unless it's really obvious, i usually try to stay out of deciding the order the tasks need to be done in. i agree that Agile won't solve it
@HealthyDevАй бұрын
@@xybersurfer same here. Unless I'm invited to help with product management as a consultant, I don't get involved in business direction on a project.
@PeaceIndustrialComplex21 күн бұрын
I've been in the software engineering space for about a decade and I have recognized this co-opting pattern of what I can only call "management brain". Where it feels as if leadership read a book or Harvard business review from 10 years ago and decided to implement new policies without bothering to read any case study outcomes from later works. The key points you gave are exactly what I see in my work these days and I couldn't put it into words. The problem is and always will be management. I see it now with "data-driven" decision making. Just management doing massive tracking and data collection on employees but lacking any data science background or nuance to make good decisions from this data. So many people want to work and build things well and these management practices force people to lie, under scope, and deny ignorance.
@HealthyDev4 күн бұрын
Great insights. I agree. This field requires nuance, subtlety, learning, and grace with people. Unfortunately we're training everyone to believe it just requires smarts, grit, and accountability.
@darylphuahАй бұрын
The problem is agile needs communicative, high performing, disciplined members for it it work. If you already have such people on a team, you don't really need agile in the first place because the way they work will automatically fall into the core values of the agile manifesto. So for all the other folks that need to learn such methods, frameworks like scrum were created so that they get to learn through a process. The process however then becomes dogma, and is anti-thesis to agility. We have to also appreciate the problem from the perspective of the business/client. Deadlines do have to be met, software often isn't the only thing in a product/service/project, there may be many other moving pieces as well. Some even had the experience of giving an agile team full autonomy, and they just took forever to get things done (incompetent team), this leads to them thinking that agile sucks and needs to be controlled/managed better.
@OldTiredFatАй бұрын
It also needs tasks done in the order of dependency. What happens instead, is the job's broken down into roles, so all single mothers, former scaffolders, secretaries, and so on have a salary, then the work is handed to the people who actually know software, and it's handed in the wrong order because the secretaries don't understand tech, they see it from a product perspective. So the builders put up a white picket fence, then a front door, then a roof, then bedrooms, then a kitchen. Then they have to retrofit walls, and utilities, all the while listening to some complete amateur say "Why can't you just..."
@7th_CAV_TrooperАй бұрын
Management is hopelessly tied to Taylorism.
@HealthyDevАй бұрын
If only Deming was required reading...
@DanRamosDRАй бұрын
A lot of the times, Agile pretty much turned into micromanagement for mid-managers and PM's, instead of simply a way to manage your own workload so you can get stuff done.
@svenst18 күн бұрын
I couldn’t agree more. I worked as a software system engineer and lead system engineer in the automotive industry for a decade and left it because it’s just frustrating to do these nonsense stuff/work/burn-down-what-so-ever. But, Instead of sticking my head into the sand I decided to actively work on this problem, which is the reason why I started my own company
@HealthyDev4 күн бұрын
Awesome! That's the best thing many of us can do (start their own company as an engineer). Not for everyone, but we need more people taking that risk and getting out of a cycle of despair.
@FreeStyleKid777Ай бұрын
I work at a large company and in the interview I was told how AGILE they are, how they are dynamic and moving fast and swifty...only to be informed on my 1st day that in my department, raising bugs in Jira is forbidden. Literally, forbidden...I am still in shock months later...and yes, it's an impossible situation. But, like so many others...I am stuck in this IT market...
@HealthyDevАй бұрын
Raising bugs is forbidden? Wow I've heard of being in denial for good optics, but that's on another level...
@FreeStyleKid777Ай бұрын
@@HealthyDev Yep...I was told the following: "The way we handle issues here is by talking and raising awareness. Also, we call them issues, not bugs." Of course the app is bugged beyond belief and no one even remembers when those bugs were introduced and where they are anymore.
@HealthyDevАй бұрын
@@FreeStyleKid777 I can see calling them issues, but basically saying "don't track bugs, just talk about them" is frickin' insane. There must be some unspoken history there. Maybe they had a prior release or another project that was riddled with bugs, and this is their "solution"? The mind is boggling over here...
@FreeStyleKid777Ай бұрын
@@HealthyDev Yeah, from my understanding, there seems to be some kind of past "trauma". But I've only been here a couple of months, and I still didn't get a straight answer for this, and not for lack of asking...
@HealthyDevАй бұрын
@@FreeStyleKid777 hrmm. Keep that detective hat on. Sounds like you're onto something.
@yaannoАй бұрын
Never heard about safe - before i joined ta megacorp as an engineer last year. The only thing that saves the engineers from burning out quickly is a friendly team spirit and luck. We are lucky to have a PO who understands how things actually work and he has respect from the business side. It is astonishing to see how agile transformed into this i don't even know what. Thank you for these videos, I often circulate them among the team.
@DebateFilmsАй бұрын
While I completely agree with you, there is a big blind spot in Agile software development which is: How to work with products and companies which do have fixed dates, either events, product launches, marketing campaigns? I've asked it to Farley and he could not give a satisfactory answer. We can't just say "it will be done when it's done" in cases where other departments are aligning on specific dates to accomplish their goals. If you're a exclusively software company that might be fine, but if you're a car company, and there's a new model launching in Q3 2024, you need to some way to align and coordinate software development. And AFAIK Agile does not provide a good answer to this. But I believe it MUST be able to, otherwise frameworks like SAFe will continue to be attractive to businesses that rely on deadlines.
@markw.schumann297Ай бұрын
If you have a fixed delivery date and a fixed scope then you probably shouldn't be using Agile practices and that's totally fine.
@xybersurferАй бұрын
i've run into a similar problem, but with a fixed budget. i think it comes from the way some companies are used to working. from my experience, a lot of times things are not actually fixed though (which is typical in software). it helps if they can get some idea of the progress, regularly. and very often, they are wiling to drop features. ideally everything that is normally fixed should become agile too. agile development, agile dates, agile budget (customer pays for the workhours as they are spent). i think it just take companies a while to adapt, and maybe get wrong the first time, especially the budget
@RolandHesz27 күн бұрын
@@markw.schumann297agile practices: "there is no silver bullet", i.e. don't get stuck on specific processes and tools just because ; don't do unnecessary documentation but do the necessary ones and spend the time saved on the software; talk to the customers and people and don't stop at "well we wrote a contract on day 1"; if changes invalidate the plan, be ready to change, don't hang unto the now worthless plan. Then there are the principles like "quality is important", "working software is the measure of progress", "frequent feedback", etc. all of which are very useful for a fixed deadline project - it's better to know that things are going wrong 1 month into the project than learn about it 1 week before the deadline. Agile doesn't even define how to work. But a mindset can't be monetised, you can't charge £3,000 for a Black Belt in Mindset certification and definitely can't build dashboard and workflow management solutions for it. 🤷♀️
@ricmorris975825 күн бұрын
@@markw.schumann297more that agile will fail for the same reason waterfall would. The scope wasn't actually fixed.
@timop6340Ай бұрын
It is funny that I am doing some volunteering stuff with small self organised groups of people and the smallest denominator is bunch of principles that need to be obeyed at all times. For example well-being of people and creating safer places etc. There is far less messing around than at work. No need to do some bs reporting or jump hoops just because. Zero fear of micro management. And suddenly couple hours is a huge amount of time and a lot can be accomplished during short period.
@jwnknoxville157921 күн бұрын
Worked at company that did SAFE. Was the least agile and most micromanaged I have ever felt. Best decision I have ever made was to quit my job and get a job that doesn’t use “Agile”. I think my non agile development team is actually more Agile and gets more stuff done, better, and quicker.
@XLpacman80525 күн бұрын
Your guitar scenes are always at the right time to give me space to digest what was said.
@user-vr2rq5hl6l29 күн бұрын
Every programming class needs to start with a 10 minute standup. Every assignment needs to start with pointing sessions before the students get an adequate chance to review the assignment. Following each assignment, there needs to be a retrospective meeting. Everyone needs to learn how Agile will destroy all the fun and enjoyment in a career of computer programming.
@mathewbollington9569Ай бұрын
The problem never goes away and maybe the Agile methodology obscures it or even makes it worse. Agile is the antithesis to what a business needs to know about a project - outcome, time, cost and resources. I don't think it ever should have gone outside of a development team. The problem is that businesses want software as fast and as cheaply as possible. As far as I can tell that's more important than making sure you deliver a quality product. IMO by adopting agile the software industry has just enabled bad management in software rather than forcing business to be more honest about how difficult and expensive producing software really is.
@chainq68k23 күн бұрын
I fight against the push for whatever "Agile" devolved into, by preferring interactions between individuals over tools and processes. I prioritize delivering working software, over comprehensive documentation. I talk to customers (or at least to our sales guys) over trying to negotiate what needs to be delivered. I respond to change over following a plan. I try to recognize BS early, and just ignore it. There's nothing else one can do, really. But I realize I'm in a privileged position as one of the most senior engineers, who over the years, has built up the reputation to be able to deliver things when I'm left alone and left to work my own ways. So they just let me. But I think more talented people should just literally flip the table and walk away, and come back with working stuff. It's hard to argue that. You usually have more power than you think. (Caution: In a lot of organizations, politics and following the playbook matters more than working stuff. In this case, consider not being part of that organization, if you're passionate about delivering working software.)
@HealthyDev22 күн бұрын
The attitude you're describing is exactly what truly agile development is. Great job!
@heatvisuals21 күн бұрын
As a programmer and musician I enjoy the combo in the videos.
@axthelm25 күн бұрын
Great Video! What I argue is that Agile is not a methodology but rather a philosophy (same with Lean). Methodologies/frameworks (XP, Scrum, Kanban, FDD, etc.) cannot and never were Agile because they focused on the 'how' (rituals, metrics, whatever) instead of the 'why'. Note, both XP and Scrum were made before Agile, and of the 4 guys who made Scrum, only two were signatories of the Agile Manifesto. Methodologies are like focusing on the tools you need to build a deck rather than the carpentry knowledge (using screws vs. nails, type of lumber, etc.). If you follow Agile as a philosophy you look at how to help the development team and get them what they need. That is the main thing, Agile was MADE to help the development team navigate & survive the corporate world, but has since been co-opted by the corporate world.
@1chopsticks29 күн бұрын
The generous "understanding" and application of Agile by organizations is seriously destroying engineering talent pools and culture across industries. "Failing fast" is seen as some kind of virtue, instead of putting a small amount of forethought into something and getting it done right the first time. "CI/CD" is just repeated over and over as some kind of scapegoat for not having any kind of governance or accountability.
@JasonWelch22 күн бұрын
As a programmer, I really could give a shit less how tasks and sprints are planned.. I take tasks on as needed, often jumping between multiple at a time. If I'm busy, I skip standup. If I need to discuss something and chat communications break down, I jump on a quick call. Where I care about "agile" is how quickly I can make changes to code. I spend my time and brain energy thinking about the architecture, use cases, specs, etc. If I'm "blocked" by someone else's workload, I find workarounds or "shims" to get me by until the deps are ready. I've always felt story points were bullshit because nobody actually gives a shit about "oh it's 5 points" what they want to know is "when will it be done", "what's the status?". Every team I've ever been on that "used story points" everyone secretly converted them to hours / days in their head. All the gimmicky BS just gets in the way. The only reason I like "sprints" is because it helps a little to scope my work out for the next 10 working days, but even then, it's very lose. Priorities change.
@HealthyDev22 күн бұрын
I hear you. Unfortunately if the company's product design and delivery isn't agile, they have business consequences. That means less money. And that means people get laid off, or raises can't be given out. So while you're free to not care about agility beyond how it allows you to change code, it actually is important to your job whether you want to make an impact on it or not. Just something to consider.
@alanjavari4067Ай бұрын
Agile is one piece of the pie in a business, it has to work for management too. The key is being a learning organization, and management need to use that learning to plan better not to punish.
@magnuslindgren9460Ай бұрын
Being a developer, I've never felt that agile was there to benefit me, care for my needs and so on. It has always been about control. One of many things about being a highly sensitive introvert is that we (apparently) are curious and love discovery. I love to sit down to tinker and learn about things that I then can use to create marvelous things, things that make others, end users, eager to go to work in the morning. What many managers don't seam to understand is that you can't take that part away, the uncertainty, from me and still expect me to do great stuff, it doesn't work like that.
@ericpmossАй бұрын
It's a religion, and like most religions, it may have begun as a golden rule from someone with a good intent. It quickly became an ugly institution, complete with magic incantations, holy documents, priests, apologists with "well, that isn't TRUE Agile" excuses, and most of all, inquisitors. Even its founders were heretics within a short time, and abandoned it.
@qj0n26 күн бұрын
There are actually whole conferences of people who do understand the agile development and agile founders are still coming to them. The problem lays in consultant companies, who started to call themselves agile as well and are hard to distinguish for people not knowing agile and give easier solutions
@ddanielsandbergАй бұрын
Same with DevOps (vendor tools/consultancy) - You're a devops engineer, you're also a devops engineer, EVERYBODY is a devops engineer!!1!!1! - "What is DevOps and what is a DevOps engineer?" - "Well, we made shit up and renamed 'whatever-we-were-already-doing' to be 'DevOps' and then re-titled a bunch of other roles to 'DevOps Engineer' so organizations could pretend they are "modern" and made us sound important so we could double our salaries". And don't get me started on the term QA! sigh.
@crazyboyandyomamaАй бұрын
No, keep going
@piotrd.4850Ай бұрын
@@crazyboyandyomama That's pretty much the same.
@ChrisAthanasАй бұрын
Excellent breakdown of the issues around modern agile practices
@HealthyDevАй бұрын
Thanks Chris. Hope you're doing well man!
@phpn9928 күн бұрын
Project Management and Human Resources have become corporate police ; substitution for engagement by management, and this is the root cause of the problem. Lack of engagement by management.
@drrodopszinАй бұрын
I had one company where they set up all the burn down charts of the product to be visible. They bought big TVs and they were constantly shifting to show yet another team's one. The expectation was some kind of a Communist style "worker competition" kicking in, but none of the charts meant anything without context. We tried to figure out for 5 minutes and then everyone went on their own. Therefore one day when I was distracted the 100th already by the moving object on the screen I asked if everyone agrees to turn it off a little bit. They agreed. Soon people forgot to turn on the TV. It's a sad story of treating college educated, smart, passionate people like livestock. "Let's see if showing there cows green pastures will increase milk production!"
@DuRoehre90210Ай бұрын
Yes. Scalability is an illusion. We have had Scrum-of-Scrum, NEXUS, now SAFe, nothing has really worked in the way how I have expected the original idea/concept to be. The SAFe party here still pretends to be successful by sticking the "ART" suffix to the name of every domain team. But in the end, they still don't do much more than getting release schedule planing along the draft from the management, covering this under the cringe activities in all-parties-demos (formerly known as Scrom-of-Scrum Sprint Reviews). At the same time they have to combine "the agile" with the regulations and official processes which we have to obey in my industry. Which ends up in the ticket hell. For every little aspect or topic, everything gets projected and repeated in every system, thus a simple task of implementing a requirement can end up in a dozen of tickets with lots of attributes and traits, and the processing of all those tickets needs to adhere to specific demands and expectations of various stakeholders which you might not even know, or who have their own "special understanding" of the exchanged attributes, like "Fix Version" or "Due Date".
@HealthyDevАй бұрын
Yep. I think they should make that Jez Humble video I mentioned towards the end required viewing for every executive and manager of software projects.
@ChrisAthanasАй бұрын
On point This guy has been deep in the pits
@piotrd.4850Ай бұрын
You can be either agile or big.
@nohandlehere55Ай бұрын
Agile has been a way to just make everything a Priority 1 w/o any accountability nor ability to put resources behind it. No time bounds, no ability to know "where the buck stops" and no strategic planning. Now it is being to applied to inherently non-agile products that are H/W heavy with organizations that are gate-driven that can be better served by staying "water-fall". What should take a couple of months at most to field now keeps "moving to the right" and can take years with no accountability. Team members also use agile points to prevent taking time for discussions as "it isn't in their backlog" and we must go thru Agile planning to "get on the calendar". The teams are just going thru the movements with Agile and the unspoken feeling is Agile suxs. Management has a backlog of 100 priority 1's with some Epics of 2 or 3 years old. If I had to work under an Agile framework w/ daily scrums (which is just a daily "check-in" meeting), I'd look for another project. Oh, and Agile is totally "passive aggressive" when it comes to having members accountability (both in leadership, and between the team), self-managing by "confederation" is a terrible except in the most exceptional of teams (there is a vacuum w/ someone that has authority to hold accountability if needed). I so long for MS Project and hate JIRA with a passion...Agile is not agile as it is implemented in many large organizations. Waterfall might be the superior methodology for large enterprises or complex projects.
@piotrd.4850Ай бұрын
If you adopt crisis management methodology as basic, you need to create and maintaine atmosphere of permament crisis for it to work. Simple as that.
@tomraaff457627 күн бұрын
I found out my current company isn't agile by following the money. When I learned how things are budgeted, I figured out it can't possibly be agile. Money flows like this: Product owner writes a document to explain what we are going to do, why we want to do it and what the scope is. It also includes a ridiculous rough estimation on how long it might take. Management accepts or declines this plan with a fixed budget. A new project is born. Whenever we run out of money, a new document is made and the cycle just starts over again. And when projects are cut off halfway, we're left with having delivered half the value and having received twice the maintenance. Anyway, I think following the money is probably a universally good way to see whether a company is agile or not.
@rogerbartlet5720Ай бұрын
Some things I've noticed about Agile and the way it's implemented: - One Agile fail is when it's assumed product requirements aren't important. It's really all downhill from there. - This precipitates into improvised product development, which leads to endless firefighting in integration. QA is often left out of the loop or can't keep up. - I have never seen Agile guidelines developed into company-specific processes, this leads to everything being about metrics. - I have never seen Agile coaches properly utilized. IMO it's a dead-weight job. - Self-directed teams need to be Agile trained and technically competent. IMO only senior level people should work on these type of teams - Scrum masters are not supposed to be schedule keepers or nagging about story details. This is a red Flag - RTE's are not supposed to babysit Scrum masters and drop into DSU's all the time. Another red flag. - Stories and backlogs need to be owned at the project level. You can end up with so much backlog that no one can make sense of it or correlate anything. If Agile isn't making your project better managed allowing timely responses to requirement updates, then your *real* project is learning how to implement Agile, first.
@JanVernyАй бұрын
I mostly see your points and agree. But why would you try to gatekeep juniors from working in actual agile teams? How are they meant to learn how "good" agile team works, if they're stuck working in dysfunctional teams?
@rogerbartlet5720Ай бұрын
@@JanVerny I would structure the team so juniors weren't in the critical path. Seniors can mentor better when they aren't running defense on newbie's. An Agile team is not a place for on-the-job-training. When I see kids on self-directed teams they are set up to fail and the experience is detrimental to everyone. Hey! you just came up for a possible use for Agile coaches!
@heyjordnАй бұрын
Glad to see making videos again m8
@HealthyDevАй бұрын
Thank you! I've had two extended hiatus since the inception of the channel. I think the KZbin algorithm never knows what to do with it lol.
@ascetahedonista7161Ай бұрын
Don't let them to change the meaning. Agile is about auto-organized teams. So organize your team and make your pm understand them does not have to interfer with the process but on the macro scale of the project.
@eddiec5036Ай бұрын
The problem isn’t necessarily agile. The problem is the way it’s implemented. The people responsible for implementing your agile methodology should not be the same people whose job is reliant on constant meetings, reporting, and status updates (PMP). Proper training and implementation is crucial.
@HealthyDevАй бұрын
I was at a consultancy where they didn't want to adopt agile because they didn't know what the PMO (project management office) would do. You are correct, sir.
@dstgre21 күн бұрын
@@HealthyDev Is it true that the managers have nothing to do if not in a meeting?
@HealthyDev18 күн бұрын
@@dstgre no, lol.
@monterreymxisfun3627Ай бұрын
Refactoring-friendly code and deployments should be the new agile.
@HealthyDevАй бұрын
I can understand that view. It's cool when we're able to be agile with the code. But without the product work itself being agile, it kind of feels like a bandaid on a fatal wound. Maybe it's just me...
@astatinn-ltd5 күн бұрын
In the tech industry, the term "agile" is often misused as a facade rather than a genuine approach to adaptability and improvement. Many companies engage in agile signaling-presenting an agile image without embracing its core principles. This creates a facade where the true benefits of agility, such as easy adaptation to change, are sacrificed for superficial processes. The dissatisfaction expressed by professionals with agile methodologies like Scrum or SAFe often stems from this misalignment. Instead of fostering a culture of continuous improvement, these frameworks sometimes exacerbate pressure and hinder real progress. Agile should be about flexibility and team empowerment, not just metrics and managerial control. As AI and rapid change become increasingly prevalent, embracing the true essence of agile is crucial. We need to focus on practices that genuinely support teams in adapting and evolving, rather than perpetuating a performative version of agility.
@CynicalOldDwarfАй бұрын
Funny timing, this morning I'd seen some LinkedIn cringe from a hiring manager saying he'd rather hire someone coachable than experienced and good at their job. His reasoning for this was an interview where the candidate had done really well on the tests etc, was really knowledgeable, did well talking to the other members of the team, etc. But when he got to asking the team their negative opinions one of them chimed up "He was a bit arrogant about agile"🙄 So good to know that in this industry you can be a top tier candidate, but if you're *_opinionated_* about Agile as a lot of workers and leaders in this industry are... you're kryptonite.
@mbarker_lng23 күн бұрын
I was suspicious of agile the moment I came into contact with it. The people telling me it was a silver bullet that solved all problems were also the ones selling training, materials, certifications, and even a job created from the Aether ("scrum master") which they happen to have people to fill. My take on it was "so its basically endless, low-grade crunch-time". I had worked in the gaming industry so I was very familiar with crunch. In every Agile shop I've seen, the same things appear: No time allotted for R+D, your work performance becomes tied to the number of tasks you can knock out in a sprint (regardless of difficulty), and vast amounts of time spent talking about work vs. doing work. Agile poker, anyone?
@dstgre21 күн бұрын
And to top it, I find myself spending time reading comments online against this practice when really I should get back to work ..
@hmtnl26 күн бұрын
There is something called Goodhart's law, which goes like: "When a measure becomes a target, it ceases to be a good measure", which is a good description of todays state of agile. We are not doing agile to improve our development cycles, we are doing agile for the sake of agile even if it hinders development
@HealthyDev25 күн бұрын
Nice, I have heard that stated in a little different terms. Cool to hear where it came from! Thanks for sharing.
@s81n19 күн бұрын
I’ve been a software developer for a long time, and the only thing I’ve ever seen Agile do is cause enormous amounts of technical debt because the project was rushed by project management and we had to go back to fix the things we told them we didn’t have time to do.
@VV-nw4czАй бұрын
Agile came up from practices smart people borrowed from other smart people, but it got adopted by not so smart, or rather so not smart people, that it changed into antithesis of itself. As it happens with everything.
@jeffreyparker939628 күн бұрын
I worked at a company several years ago that while I was there they decided to make a big push for agile development. They ended up hiring like 3 layers of management, many were "agile experts" and we went from getting a good amount of work done at a good pace to spending a huge amount of time in meetings, for me it was about half of each day, plus additional like 3 full days between each 2 week sprint, so I had a lot less time to get things done. Then we would do the planning meetings and were told to include the testing in estimates and there would be a ticket for a change to a critical part of the software that could impact just about everything and I was told that I was wrong for putting a very high score on it due to every part of the software needing to be tested. That was the only place that I worked at that followed strict agile practices as they are currently defined. Every other company has kinda done their own thing that works out to somewhere between the current agile definition and the original agile definition.
@riccardo-964Ай бұрын
Now AI is sold as the way of speeding up everything and get rid of developers. So sad.
@user-mc7ez6lm4x26 күн бұрын
I was just a traditional Soviet school engineer, migrating from factory to factory starting up systems that were either designed more than 10 years ago by different people with full stack of documentation, and corresponding full stack of implementation errors, in need of correction. Now I joined a marketplace startup and I find myself one on one with daily meetings and a calendar-like table and several different types of Jira tasks without knowing anything about where all of this came from... suddenly I got a notice from my Scrum Manager that among other developers I have several tasks with errors, one of the errors being a mysterious "backlog", or to be precise " task in progress in a backlog" and the whole situation makes me feel like a noob. And this video helped me to get back my selfawareness to some degree by explaining who those certified Scrum Masters really are and understand how I instinctively pursue agile ideas by sticking my nose into all the other teams tasks, getting different front and back programmers explain me how their things work on the level where my subsystem will be implemented...
@timp2315Ай бұрын
It's a tool to take power away form developers and into the hand for business managers. In a high inefficient way but they dont care as long as they have control. Agile makes it easy to micromanage and squeeze all the value out of each developer. You are a product in an excel sheet now :)
@HealthyDevАй бұрын
Didn't start that way (as explained) but yes, that is how it's used in many cases today unfortunately.
@timp2315Ай бұрын
@@HealthyDev Yeah sorry if sounding like a lesson i realized later you said exactly what i was thinking. I feel like developers need to unionize against these things. Also do you know much about developer Unions? I think developers could quickly benefit from not getting "gamed" by Agile Managers. Though i see many dev just put their heads down and follows the commands, happy to have their 6figure job.
@HealthyDevАй бұрын
@@timp2315 I've seen some attempts to unionize. I don't know how successful any of them have been long term, but I'm not opposed to the idea. The hard part is knowing whether the negotiation can actually result in terms that make the job more palatable or not.
@pepsico815Ай бұрын
Speaking of Agile, I couldn't stand working at Mutual Mobile where layoffs happened almost quarterly and eventually the Austin team was so barebones that 90% of our work involved speaking to teams in India with the most inconvenient schedule. I was basically on call 24/7
@HealthyDevАй бұрын
Sorry to hear. I worked on a project for them as an outside consultant briefly. It went south but there were a few good people I met on that one.
@RobinBare19 күн бұрын
I am an agile coach that is fighting to stop agile in the ways you are talking about! Lets see how long I keep my job :D thanks for the video! (also I never hire anyone who has their certifications at the top of their resume or if they even talk about them)
@HealthyDev4 күн бұрын
Hang in there. Choose those battles wisely! I know how tough it is when you understand agile but have to work with people who don't...
@jos1515Ай бұрын
What framework do you recommend we follow? Being in a startup environment for over 10 years I never followed Scrum exactly, if we did the company would missed deadlines every single time. Daily standups are a waste but I still need updates from time to time. Management doesn't care about velocity or burndown charts, they just want 'estimated' timelines which really mean hard deadlines. Sometimes they want a Gantt chart or sometimes they want a workback schedule, or it could be even be waterfall again. To me, I can use all these "tools" to meet what management really cares about which is how long a task / project would take and the costs. I would then come back with an 'estimate' based on how much a dev thinks it takes, what the bandwidth is to handle this task/project among other existing ones, what are the priorities at the moment and the technical debt we need to tackle. Having senior developer experience helps me determine that estimate as well, as I know what the devs are talking about and but also important, are the capabilities of each dev. I have to have some intuition on how they perform on each project. Always helps to pad estimates since there are so many variables to consider. I feel like scrum and SAFe are just frameworks to meet checkmarks of being done, as long as something is produced at a set timeframe middle management can pat themselves on the back.
@kelly418727 күн бұрын
I’m coining it Kelly’s law “Any good and effective management system will inevitably be destroyed by ego, greed, and pointless training and certifications”
@MorvaynАй бұрын
The main problem is power shifting across time. A team might have the freedom to do agile and yeld a good result (as management is open to try out stuff). As time goes by management will shift people arround and try reproducing the same output while restricting their freedom to continue performing agile. This happens because management over time will seed management stuff into the team daily life untill everyone is sick of it or it breaks If you have decent management the stuff seeded into the teams activity won't have an impact(management gets the numbers and everything else and the teams continues doing its thing as they deem needed and work gets done). If you have bad managament you disrupt the flow and daily life of the team (management gets the numbers but instead of letting the team do whatever they deem necessary and time goes by). My 2c
@capability-snobАй бұрын
AI was more of a distraction than a disruption, but I guess the effect on roadmaps is the same
@keepitreal2902Ай бұрын
I'm redeveloping a system I helped to build 18 years ago. Back then we had informal processes and a delivery team of 15 people and budget of $20M. We got the job done. Now we use AGILE SAFE and we have a budget of $90M and team of 75, and it is failing. Agile SAFE is just a recipe for disaster. We have a team for every little thing, and they all do their own thing.
@xybersurferАй бұрын
also too many people on the project perhaps?
@keepitreal2902Ай бұрын
@@xybersurfer Far too many. Everyone appears to be a lead of something.
@Rob-zp3hn27 күн бұрын
This video is a breath of fresh air. I guess a lot of movements get redefined by successful bad actors. This vid made me go lookup Larman's laws of organizational behavior.
@TheUnkaDaveProject7 күн бұрын
Nice video; good, accurate analysis. You asked us to share what we are struggling with; my top one: folks leading the organizations bring in "Consultant" organizations that are tasked with figuring out how to restructure to save $ (and shed people); the "Consultants" have no competence in Scrum, and retain dysfunctional Agile mindsets; they get listened to rather than the folks 'in-the-trenches' (like me), and these 'leaders' kill their orgs by reverting back to the illusion of project management 'control' ... It feels a constant struggle..... Like the 'Borg' in Star-Trek..... "you will be assimilated"..... hmmmmm
@HealthyDev4 күн бұрын
There are definitely good and bad consulting companies. If your company doesn't know how to vet them well, they will probably continue to get burned like this. Maybe you can offer some suggestions (privately) on how to vet the consulting companies better? That is if your company even sees a problem. If not, that would probably be a better strategy first - helping raise awareness (again privately, not in front of the consultants lol). If that sounds like too much work, I hope you're able to hang on until you can find something that's a better fit.
@danielf9917Ай бұрын
SAFe and PI planning is evil incarnate. Detailed planning with the whole company what you must achieve the next three months and how everything and everybody interacts with each other is just pure nonsense and is invalid already the next day due to unforeseen circumstances. Sorry I was in a bad project last year...
@maci6990Ай бұрын
Very true. Lots of wasted time there
@DustinDustin0025 күн бұрын
I always work one sprint ahead. I always "get done" what I said I'd do. No over or under estimates to fuss over. If it looks like I'm short, I know exactly why it took longer than it is expected; so I sound like I have deep insight into future problems.
@TaleOfTwoIdiots25 күн бұрын
My experience with Agile was: Commit to a small unit of work to be completed in two weeks, have management subsequently schedule about 30 hours of pointless meetings for those same two weeks, then have that same management asking why we were so far behind as those two weeks started to come to a close. I hated every aspect of it.
@whatshendrix23 күн бұрын
The problem is people who enter the work force as managers with no prior experience doing any work of any kind. Most people are lazy parasites who just want to sit by idly as others do all the work. These people are useless politicians and I have no idea why companies hire them. Their only means of surviving is to make themselves look important and to make hard-working people look irrelevant. Managers should be the most experienced and skilled workers, who understand the work processes. Once you gain enough experience and skill, the most productive use of your time is in training and organizing less experienced hires. A person with exclusively manager experience simply can't do that, so they're utterly useless.