@tristanmills4948
Having gone through an 'agile transformation' which handicapped an engineering organisation which was pretty agile and effective, this resonates a lot.
@ringorango529
I see most of the people who are forcing agile and scrum are business/management people. Similar to any other management certification. They took it as an opportunity to legitimize their position without knowing software engineering at all. They instinctively understand that their position doesn't produce any value rather than running the corporate hierarchy. So they need something else to be seen as doing something or bringing value. And since they are in the management, they shovel it down the throat of the actual developer who suffers from cleaning up all the gaps pushed down the project hierarchy. And dev who are not good at technical or can't withstand the prolonged stress change career to become agile coach/scrum master/product owner or any non-programming role. And also those roles have a better chance to climb the corporate ladder compared to the programming role. Then we start again the cultic cycle.
@JustLikeBuildingThings
The whole certificate culture is bewildering. Companies hiring folks who've passed an online open book exam over those with real experience delivering software and doing the roles. I actually booked the wrong exam by accident and still passed...
@vanivari359
A car manufacturer in the far south of Germany uses a scrum model, where EACH STORY is a fixed price contract and the only way a provider gets payed. If a story takes longer (or there are any bugs), the provider has to pay for that out of the own pocket and if a story seems overestimated, there are tons of discussions with the POs. This of course results in a lot of "management" on provider side because if stories are your only income for everything including managers, scrum masters, BAs etc. they start to monitor heavily and annoy the team with all kinds of pre-plannings and pre-reviews and "status-checkpoints". Everything in JIRA + Confluence + Excel lists. And every "spill-over" is a giant drama, which requires even more bookkeeping and discussions. And god forbid that you don't deliver the ordered SP over multiple sprints, because then the customer starts all kinds of additional monitoring and tracking because the release might be in danger. And of course all developers have 0-2 years experience and each team has a scrum muster who never developed a single line of code, but has a certificate. SCRUM was never a great experience, but not even a single year in that car company burned me out like crazy - I'm so done with SCRUM and agile in big corporations. And all that for a bunch of backend systems which must be ready in a year (of course as microservices...), so many aspects of scrum don't make sense anyways. But then you get stories like "As system A i want a masterdata batch job so i can transfer data to system B". So personal ranting aside, i see a giant software crisis ahead because every year we throw more unexperienced developers into unexperienced teams, give them an unexperienced "scrum master" and a Cargo-Cult-like process and let them build software, which is not maintainable anymore after 12 months. No specification, no documentation, just unreadable unmaintainable code. I guess I will spent the rest of my career reviewing and firefighting projects and maintaining unmaintainable messes.
@davidburris3500
My experience with Agile/Scrum is that it's implementation constitutes all of the things that the originators said NOT to do. Pile on the concept that in product development involves estimating Jira tasks for yet unknown implementation details for features never done before, standup meetings that on their face are status meetings, more meetings for accountability when schedules predictably slip, and what you have is stressful results bordering on abusive.
@gautumb
Scrum and all those BS like story points, retro, daily draining meetings,etc make our job feel so superficial, unsecure and not enjoyable.
@RacerRookie
I'm a heavy introvert and find overcommunication too much, Scrum is something I also despise. It causes over communication which is leading me to be burned out and loose all motivation, an endlessly growing list of tickets and stress, I don't like talking to people too much and when were talking its making me loose focus on programming
@recmtnbiker4368
If I was a student majoring in computer science, I'd take math classes such as liner algebra and a statistics class with calculus as a prerequisite as well as some electrical engineering classes and look for jobs in real time embedded software and more math intensive products like inertial reference systems. You don't have anything until almost everything is nearly completed, which makes these product lines more scrum proof. Working as a software engineer was better back in the 80's and 90's before agile scrum. I graduated college in 1982 with a degree in electrical engineering and worked as a software engineer since 1987. I started working exclusively as a contractor in 1990. Since I mostly work in real time embedded, safety critical software, I hadn't heard of agile scrum until 2016. I worked at a job that does agile scrum in 2021 to 2022 and it was like being a character in a dystopian sci fi movie, with all their cult like behaviors. Most of my career I worked autonomously and was treated like an adult. With agile scrum and the pointless daily morning meetings, employees are treated like six year olds. I just started working what will probably be my last contract job before I retire for good, with a former employer that makes inertial reference systems in the commercial avionics industry. The reason I went back there, and not some other companies is because they are not doing agile scrum. It is good to be able to work autonomously and be treated like an adult.
@Metalblowing
Our team got a new scrum master recently. He came in with a list of mandatory practices that cannot change. I asked about aligning some of the stuff to our business model to ensure that we deliver value more efficiently - he replied "we can't change this because these rules are fixed in stone". Okey, coooooooool. Really agile.
@_winston_smith_
I think the root problem is one of competence. If you have a small group of highly talented engineers who work well together then almost any process will work. So you have very skilled people defining a light weight iterative process and some basic principles as “agile.” Then you have a mass of management and mediocre software developers trying to apply concepts that, while simple, they don’t fully appreciate. Most software developers think they are great. Not everyone can be the best. The majority are simply code monkeys. The folks who defined agile originally are probably all really smart. Often smart people underestimate their own ability and drastically overestimate the ability of the average software developer.
@stingyhatgames789
As a software engineer, I've yet to see Agile succeed in the workplaces I've been in that tried to implement it. And the failures have been spectacular and would be funny if they weren't so painful to have to live through. I've seen grown adults cry during stand ups, and retrospectives devolve into finger pointing, name calling, and even chair throwing.
@TheMetadude
I can only echo this. I have worked with / for several companies using "Agile and Scrum" and in my experience it's been a tool used to micro manage the development process and give managers (BTW I have managed teams myself) the illusion of regular progress and control. In these companies progress was measured by the completion of artificial tickets and lots of time is wasted with inefficient tools like JIRA. I'm sure Agile and Scrum is properly implemented somewhere but I haven't seen it myself yet. So when a company empathises their "Agile process" I get suspicious. When they start talking about JIRA I get worried because. If they have a scrum master I am genuinely scared !
@lairjuniortv
They are broken because companies got the agile manifesto, throw everything away and kept only the “respond to change”. Who needs working software when we can push to delivery even with cumbersome release management processes? Who needs to talk with clients when we can have a surrogate called Product Owner.
@allieg4011
As a computer programmer since the 1970s, I've seen the same happen to every software development method as is now happening to Agile. I've been through no process, iterative process with 6 week releases, waterfall, spiral development, CMM, and now Agile. I'm currently working using Agile development and it has been much harder to get a handle on it. I feel completely disassociated with the team because we use Jira and tasks are broken down so much that you don't really know the reason for the change. I have to ask the team lead what is meant by its Jira story. You go back to the same piece of code you were working on a few months ago and it has completely changed because the developer working on it decided to refactor the code as part of his/her Jira story. You end up with no expertise in any area and sometimes completely out of the loop. It's very frustrating.
@Ian-eb2io
There are some serious problems with extreme programming. Having people sit close together without any privacy or personal space. Which is then contradicted by wanting people to be focused and free from distractions. Then there is pair programming, the perfect way to induce increased stress, fatigue and ultimately burnout. It is a practice that takes giving people no privacy or personal space to it's extreme. These practices seem to be driven by people who have no need of personal space or a quiet place to work. The problem with scrum is that it becomes a cult focussed on the ceremonies. You may not abandon the ceremonies even when you don't need them. It is also common to blame the implementation when it goes wrong while simultaneously attacking a parody of waterfall.
@daverooneyca
I watched this video at a 1.3x rate... every time Allen & Dave laughed together they sounded like Beavis & Butthead, but in a good way! 😂
@paladinsorcerer67
My first experience with Agile/Scrum outside of college was as far as I know a full-on implementation of the techniques. So I feel that I can speak to Agile/Scrum. My first understanding was that Agile/Scrum is a way to allow developers to sort of manage themselves, with acknowledgement that they can't get away from management completely and therefore tack on the idea of accountability to make it fit in a business context. But instead it has become a way for the business to micromanage developers. Agile/Scrum, I thought, was a way to identify work that is blocked or not working, and to fix it as a group. But In my experience it was not always done with the right attitude. Agile/scrum techniques are meant to quickly identify developer problems. Since everybody is different, all developers have different abilities. And so developer problems can also look like problem developers; problematic or underperforming developers. It can put rockstar developers on a pedestal, since they are responsible for making the burn down charts look good, and incentivizes those developers to look out for themselves. Instead, you have to have the right attitude, so that solving problems as a group means working with the group that you have. If you don't do that, it incentivizes developers to cut corners, in order to make artificial deadlines, and so you end up with bug-driven development instead of high quality code. The same goes for deadlines, where strict adherence to deadlines incentivizes mediocre developers to avoid taking the time to build in quality, and to cut corners instead, since only the top performers can be safely transparent.
@alichamas63
The problem I've seen with Agile (particularly in larger business) is that it's a methodology primarily for management, not for software engineers. Software engineers become disempowered under layers of middle management ceremony, and product owners are often so far removed from the actual production of the software that they equally become disempowered. This leads to a true lack of actual ownership and quality assurance yet it looks good and sensible from a line management point of view (and there are lovely graphs!) so it's the defacto tool of choice for big tech brother. Nobody uses it on smaller more passionate projects which are often far superior in quality, as they actually care about what they're doing.
@jack6539
The engineering went out of software engineering more than a decade ago. Even from the xp days it was an ideology. The result is we now have heaps of crap, insecure software because teams choose the features, tools and methods they want to do at the expense of stuff that needs to be done. Just look at the 2022 cisq report on sw quality and security in the us and tell me how ideology driven development has served anyone other than the 5minute experts (probably from marketing) who attend a weekend scrum master course and then carry on about how they know sw development. /rant
@MoisheLettvin