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?
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...
@@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.
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 :)
@@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...
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
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.
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
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.
@@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
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...)
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?
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.
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.
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
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.
@@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.
@@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
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
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.
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).
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).
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 😢
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.
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
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
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
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.
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.
@@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.
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.
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 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
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.
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
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.
@@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.
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
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.
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.
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"
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.
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.
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.
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.
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.
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.
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.
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.
@@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.
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.
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
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.
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.
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
@@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
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.
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.
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.
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.
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"
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.,
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.
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.
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.
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
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.
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.
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.
@@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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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..."
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.
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
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.
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 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.
@@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...
@@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...
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.
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
@@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. 🤷♀️
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.
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.
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.
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.)
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.
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.
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!"
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.
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.
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
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.
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.
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.
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.
After years of "oh you're not even doing agile" and "oh we'll fix this in the next sprint" condescending which all turned into mega corps midfle managers putting "100% agile" in their vocabulary I just feel a lot of happy satisfaction seeing titles like this.
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.
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?
@@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!
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.
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.
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.
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?
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.
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...
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
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.
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.
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.
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".
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...
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.
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
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”
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.
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.
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.
my strat: just pick 3 points (out of 7). most ended up at 3 anyway. Documentation tasks were 1, architecting was 5, nothing was a 7 because if a ticket is a 7 it can probably be broken down into smaller chunks AND it uses management's own logic against them (nobody gets a 5 because there is always room for improvement KMA)
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.
There are so many contradictory hot takes going around for agile that you can be doing things totally backwards and you can always find a hot take to justify yourself.
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.
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.
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
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.
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?
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...
@@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.
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 :)
@@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...
Did my best to act as if I at least was agile, now people seem to think I'm the Jira master or something.
What went wrong? Agile became a product, then snake oil, sold by consultants. Now it's dead.
☝That's it, that is the only thing this video and any other video, article, or any other commentary on this top needs include.
That oversimplifies it a little too much. The problem was that it was a victim of its own success in several ways.
@@falxonPSN agreed
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
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.
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
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.
@@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
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...)
You literally heard that? They know why, but won't volunteer it? Incredible.
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?
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.
Christ, what an arsehole.
My scrum master is a complete moron!!!
Agile originally was about bottom up visibility, but managers got ahold of it and turned it into top down command.
Truth!
Agile is just waterfall where they blame the devs instead of management when it goes off track.
But agile seems to be waterfall by 1000 cuts.
Your victims to project managers that used agile wrong or in name only.
@@stephenhookings1985 waterfall but with more time wasting "rituals"
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.
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
I think project management has been adopting agile not evolving or butchering it. They are just adopting our existing problems.
In 2024 "agile" means "just do it as fast as possible".
And w/o SOW or resource plan... as we make it up as we go along
@@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.
Yep
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
@@xlerb2286 Oh, that's when I would be like, 23 points, which is probably accurate
Agile is shit ton of micromanagement of the delivery team and putting pressure everyday to finish the work by tomorrow.
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
yesterday
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.
@@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.
@@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
Exactly. Agile feels more like trying to turn software development into an automotive assembly line.
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
@@HealthyDevwow
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.
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).
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).
Poor management is driving us mad. Agile gets the blame.
Agreed. I can't but think of Larman's laws of organizational behaviour.
Poor management brings poor projects. With everything that includes.
do you even agile bro?
... no cuz this's a WATERFALL PROJECT with SPRINTS!
Thank god we don't build infrastructure like we do software. I'm not driving over an 'agile' developed bridge.
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 😢
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.
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
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
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
My team treats 1 story point as 8 working hours 🤦♀️
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.
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.
@@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.
@@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
Very large companies just sh*t out APIs that don't work because "we have 300 teams working fast".
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.
And these 'values' profoundly SUCK.
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
@@raptorate2872 "Common sense is not common practice" --Mary Meaney Haynes
@@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
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.
What happened... a bunch of MBA's got involved.
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
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.
@@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.
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
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.
The best thing about SCRUM is the Burnout Chart.
lol
🤣🤣🤣
The true name of the chart
Oof!
oh no lol
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.
Exactly!!!!
Same here…and what we have experienced really is Agile making us less agile.
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"
Bummer! Hey at least you got a taste! That's more than many people I meet, sad to say :(
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.
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.
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.
@@robby3467 You said it!
As soon as I saw SAFe on the screen i threw up in my mouth a little bit.
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.
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.
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.
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.
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.
@@HealthyDev I've noticed a trend to companies actually going back to waterfall. Go figure.
@@Erik_The_Viking for sure. If the company cannot operate without fixed delivery dates, waterfall sucks but less than scrum (in that situation).
@@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.
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!
Yes, that is the way it should be.
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.
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
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.
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.
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
@@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
The goal is spposed to include (finding and) working at the pace that the team can maintain forever...you have experienced incompetent Scrum Masters
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.
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.
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.
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.
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"
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.,
You can either talk about work, or do work. So frustrating.
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.
I wish there was a job board for vetted companies that don't pollute the industry in the ways you describe...
Same
I'm pretty sure you can find an empty website out there somewhere and use that as a stand-in
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.
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.
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
@@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.
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.
Literally gaslighting. How can we not go crazy with them changing the definition of things constantly to suit their comfort level at the moment?
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.
As with many things in life, those who want control will do anything to rewrite history...
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.
@@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.
@@HealthyDev I may reformulate... I as a developer am bad at time estimation :D
@@75yado ha! OK I got you now. Me too.
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.
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.
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.
Great analysis. I started in software in the late 90s so we probably had similar experiences. Thanks for sharing your perspective.
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.
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!
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.
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.
No, keep going
@@crazyboyandyomama That's pretty much the same.
Your audio quality is amazing!!
Thank you, I put a lot of work into the audio actually. Glad to hear it's working!
@@HealthyDev It's pure ear candy, better than much bigger podcasts, even.
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.
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.
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.
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..."
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.
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
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.
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...
Raising bugs is forbidden? Wow I've heard of being in denial for good optics, but that's on another level...
@@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.
@@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...
@@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...
@@FreeStyleKid777 hrmm. Keep that detective hat on. Sounds like you're onto something.
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.
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.
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
@@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. 🤷♀️
@@markw.schumann297more that agile will fail for the same reason waterfall would. The scope wasn't actually fixed.
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.
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.
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.
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.)
The attitude you're describing is exactly what truly agile development is. Great job!
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.
Your guitar scenes are always at the right time to give me space to digest what was said.
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.
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!"
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.
Management is hopelessly tied to Taylorism.
If only Deming was required reading...
As a programmer and musician I enjoy the combo in the videos.
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.
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
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.
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.
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.
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.
After years of "oh you're not even doing agile" and "oh we'll fix this in the next sprint" condescending which all turned into mega corps midfle managers putting "100% agile" in their vocabulary I just feel a lot of happy satisfaction seeing titles like this.
100% agile? I've never heard this used. Is this really a thing now?
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.
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?
@@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!
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.
Excellent breakdown of the issues around modern agile practices
Thanks Chris. Hope you're doing well man!
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.
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.
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?
And to top it, I find myself spending time reading comments online against this practice when really I should get back to work ..
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.
Refactoring-friendly code and deployments should be the new agile.
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...
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
Nice, I have heard that stated in a little different terms. Cool to hear where it came from! Thanks for sharing.
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.
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.
@@HealthyDev Is it true that the managers have nothing to do if not in a meeting?
@@dstgre no, lol.
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.
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".
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.
On point
This guy has been deep in the pits
You can be either agile or big.
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...
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.
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
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.
Boy they really did a number on us with this Static Psudo-Agile.
Sadly, you nailed it.
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”
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.
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.
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.
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.
My favourite hated words in the context: “planning poker”….. 3hrs of very “agile” planning work, makes the most patient of mankind cry
It's really just a way to guilt trip objectors into corroborating the smallest estimate IMHO.
my strat: just pick 3 points (out of 7). most ended up at 3 anyway. Documentation tasks were 1, architecting was 5, nothing was a 7 because if a ticket is a 7 it can probably be broken down into smaller chunks AND it uses management's own logic against them (nobody gets a 5 because there is always room for improvement KMA)
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.
Did I just heard companies' Agile implementation = micro management? here have my upvote
Maybe Goodheart's law is partly applicable here...
"When a measure becomes a target, it ceases to be a good measure."
I heard literally this from a project manager once: "My project is so agile! We have all our sprints planned out for the next two years!"
🤦♂️
🤣
There are so many contradictory hot takes going around for agile that you can be doing things totally backwards and you can always find a hot take to justify yourself.
Truth!
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.
Glad to see making videos again m8
Thank you! I've had two extended hiatus since the inception of the channel. I think the RUclips algorithm never knows what to do with it lol.
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.
also too many people on the project perhaps?
@@xybersurfer Far too many. Everyone appears to be a lead of something.
I'd love to see a healthy guitarist channel 😄 your playing is very emotive
Ha! Nice ;)
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
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.