Agile Has Destroyed Programming - Here's How To Fix It

[@perfectionbox]

Developer: What do you want me to build? Stakeholder: Oh, a business app... like a CRM. Dev: Okay, anything in particular? Stakeholder: Just mock up some UIs and I'll review them. Dev: Uhhh okay. (a week later) Here you go. Stakeholder: Hmmmm it's too complex, and there should be a note taking box here. Dev: Okay, anything else? Stakeholder: Just code something and I'll review it. Dev: Uhhhhhhhh okay. (two weeks later) Here's a prototype. Stakeholder: Nah the note taking box is still wrong. And there's no comparison report feature. Dev: You could've mentioned that earlier. Stakeholder: Don't get snippy with me, kid. Dev: So how does the report feature work? Stakeholder: Just Google it. Code something and I'll review it. Dev: Uhhhhhhhhhhhh right. Manager: The stakeholder wants more velocity. Dev: That's a shame, because I'm going to start coding the actual project. Manager: But the prototype is functional, just use that. Dev: Uhhhh seriously? But it's not scalable. Manager: I don't think you understand the bigger picture. You're a team player, right?

[@secretchefcollective444]

I know you're joking but I actually think this is a good example of exactly how UI/customer focussed software *should* be built. Tight feedback loop with the stakeholder, with the developer given free reign to both design and code the application as they go. Good tools will help with this (e.g. Oracle Apex).

[@TheAkiller101]

One tip I learned is to not start coding until the stakeholder signs off on the design, until that I would keep updating the UI prototype according to comments, changing something in figma takes me couple of minutes, changing something in code takes me hours to even days. I politely convince and educate them on anything I dont agree, and I always document everything and show it the stakeholder like meeting notes after a meeting, updated requirements and when they were updated and suggested by whom, this naturally makes the stakeholders be more mindfull and less prone to making the relationship more hostile

[@secretchefcollective444]

@@TheAkiller101 While I agree with you that this is the sane, 'cover your ass' thing that you kind of need to do in most businesses, I do believe it is backwards to how good software is actually made. Dogfooding is a thing which is why developer tools are always lightyears ahead of what end users get. Prototypes are not sufficient for that tight feedback loop.

[@PhilipJReed-db3zc]

@@secretchefcollective444 I agree with you that, despite the hyperbole here, there's a lot here that really should be emulated. Relatedly, if your customer is going to do what @perfectionbox 's is doing here, you're not going to succeed by waterfalling or iterating less. You might press them to *try* to tell you 6 months of what they want instead of 2 weeks. Good luck with that. Instead of "no comparison report feature" they'll be complaining about huge subsystems that didn't turn out like they thought. "Don't get snippy with me, kid" becomes "Don't bother bidding on the recompete."

[@charlesd4572]

Exactly, users are the worst people to ask for requirements.

[@kristianlavigne8270]

Agile = Micro management

[@CodyEngelCodes]

Get offa KZbin and get back to those story points!!!

[@callmeishmaelk767]

It's just a way for dopey liberal arts University of Phoenix graduates to make the big bucks in IT being a worse than useless middleman. So now naturally introverted programmers have to interact in a no skill, extroverted, liberal arts environment

[@tonyennis1787]

Agile = no built-in mechanism for hitting a deadline with a given feature set. This invites what you call micro-management upon the dev teams because they aren't providing what the business leaders need.

[@peterg76yt]

I had an experience with what was incorrectly called Agile but was in reality a kind of super-waterfall, with all the disadvantages plus continuous bureaucracy. It was very late in the project before we realized that half the team thought we there alpha testing a project under development and half thought we were beta testing a supposedly finished product. I think the basic weakness of Agile, which people avoid saying out loud, is that it doesn't scale to very large teams.

[@mellusk9194]

It also doesn't hold up well when you're working on multiple projects. It feels like there are some days where all of my time is spent on scrums.

[@artephank]

Story pointing is not part of scrum. However if used, it is not „for business people”. In good managed scrum project no one outside the Development Team is supposed to even know if team is using story points and what they mean. The problem with agile is that in most cases it is just sugar coating traditional PMbok processes and not really implementing agile framework. Most of things you said are not scrum related at all tbh

[@CodyEngelCodes]

www.scrum.org/resources/blog/why-do-we-use-story-points-estimating

[@artephank]

@@CodyEngelCodes literally the first line: "The scrum guide tells us that estimates should be provided by people that will be doing the work but it doesn’t tell us how we should provide estimates. It leaves that decision to us."

[@Skibbi198]

Truth is, most of these anti-agile videos are just describing problems with waterfall.

[@ChrisAthanas]

Waterfall is still the default and people get very uncomfortable when you bring this up in polite company. Its an ugly secret of the software industry is that Agile is now just re-named Waterfall due to business pressures and cargo cult practices.

[@CodyEngelCodes]

Yes! Most companies that employ "Agile" are actually using Waterfall by another name.

[@geelee1977]

It is certainly the default, when quality matters. Like life support systems on a space shuttle, or the software for an iron lung. It is also the chosen method, or literally every other engineering discipline outside of software...for a reason.

[@artephank]

@@geelee1977 it is not about quality but requirements. The "Waterfall" (I urge you guys to find out the origin of this name, quite funny:) method, or rather Plan->Design->Build->Handover method works when requirements are clear and known from the very beginning. If requirements didn't change and stakeholders knew what the want to build, Agile would not be necessary at all. But they usually don't. And those changes in requirements create huge risks. Scrum has been invented to manage those kind of risks. It has nothing to do with quality. However, I would guess that on 99% of the "Scrum" projects, no one actually read (with understanding) the Scrum Guide.

[@geelee1977]

@@artephank "It has nothing to do with quality" --> That's the truth, 100% of all studies done thus far show no advantage in the quality department. It would be a massive strawman, to try and claim my argument, is about quality, and especially, quality alone. There's so much more to the lack of advantage of Scrum. **Though, I see why one might make that mistake from my one off comment.** On another post, my FULL claim is clear: "there isn't any empirical evidence to support the claims of scrum proponents(quality, speed, estimation, etc), what has been done, shows no advantage, negligible advantage, or, less advantage."

[@geelee1977]

@@artephank "origin of this name" --> Yes, it is funny, the origin of the name, waterfall, is a strawman fallacy version of something that never existed from a paper a long time ago, that the original author acknowledged was intended to be that strawman.

[@bobtoad8601]

The main problem of Agile is it focus on speed. They start writing without any basic previous planning. They don' t take time to test and compare which framework or programing language will best suit for the project. They use for example Django or Python instead of C because development is faster and easier, until they hit a wall as the project grows: performance is terrible, debugging is a nightmare and maintenance is impossible. And there is no plan B. Developers leave half baked implementations to click the task is finished to shut down messages "you have unfinished task this sprint". They don't take time to test and compare different frameworks to decide which best suite. They just start making deliverings without any previous basic design with a wide scope. There is no let's divide the problems into modules, create test benchs to test components individually, there is no documentation to understand the code...

[@notmyfirstnamenotmysecondn2219]

I completely forgot that stand ups are for unblocking because everywhere I worked they were just status updates. At the last company I worked at I actually dredded them because everytime you took more time than estimated you had to explain yourself. But there was no time to explain what is causing the hold up or what I would need to move along. I literally remember managers saying this is just supposed to be a 5 minute status update for everyone. Hence we didn't even get any way to book this time as working hours. I am so happy that I left them.

[@galaxyblur]

The project managers hijacked the standup. I think, originally, they weren’t even supposed to be invited! Most “Agile” meetings now are for “scrum masters” grazing for info to report up the ladder.

[@JeremyAndersonBoise]

Useless managers use it as a shame and blame meeting. It makes me furious.

[@_observer_-xk7hb]

Daily standups are not needed for unblocking. People are capable of talking directly to other people in an informal manner to address any problems, blocking or otherwise.

[@mats66]

Scrum says that it's DEVELOPERS that should be in standup, not managers, product owners (unless they also participate in the team as developers) and absolutely not stakeholders or business.

[@jayg6434]

@@mats66 we are past agile called post agile. Sometimes it’s doing stuff while in meetings aka “mobbing” lol😂

[@What_do_I_Think]

Here is a basic misunderstanding about Agile at least here im Forum. Agile is NOT scrum. Scrum is not Agile. Scrum was invented to pretend to be Agile, but instead Scrum is a means of control and to improve the "performance" of developers by using peer pressure. Agile does nothing of that sort.

[@toddcamnitz6164]

All super true, yet the business-person’s perspective and pressures give rise to these issues, and those pressures are equally valid and important. Clients typically aren’t willing to hear, essentially, “we don’t know” when they ask how long until ___. This is a perennial problem that applies broadly, imo. So sure, non-devs being responsible for dev project management and client expectations/business considerations leads to lots of problems, but really I think the core problem is one of communication and not process. Management needs to be willing to take the time to really talk to devs and viceversa, in an atmosphere of trust and support as opposed to conflict and buck-passing. Business of all types requires deadline estimation and functionality planning, even if we all understand that doing those things up front is basically meaningless. Devs need to deal with the discomfort of being asked to estimate project completion time while knowing the estimate is going to be wrong. Management needs to realize that up front estimates are going to be wrong. And both parties need to trust each other not to skewer anyone when the initial guess isn’t met.

[@jfftck]

Agile isn't what most companies are doing, they are only calling it Agile while still doing Waterfall.

[@veorEL]

Good video, sadly I could not get over the "in a quicker amount of time" - thankfully it was towards the end at 11:02

[@Grenbestyie]

is it me or is the advert algorithm in KZbin getting worse? I started the video and had 3 of them at the start and then they disrupt the video....too much

[@SzaboB33]

Some people even say, that scrum is not even agile even though most people think of scrum first when agile is mentioned.

[@nawkboy]

Consider looking at LeSS (Large-Scale Scrum). At scale, the first order factors influencing adaptiveness are structural, not mindset, values, or methods. Unless structural issues are dealt with the process focused folks will destroy any hope of achieving technical excellence, or focusing on value delivery and adaptability. For example, in LeSS there is no PMO or equivalent, there are no specialists outside of the teams, and middle managers are optional. Each team is self-managing, cross-functional, long-lived, and co-located. The most important aspects of LeSS are not the flow control elements, but rather the deeper organizational design aspects which help to create an ecosystem capable of supporting great engineering teams.

[@Thetechnoligiesthatshapedm-e6v]

Developer Manager: We need NOT to be accountable for software that Doesn't work Software Development Company: I know, let's find someone in the customer organisation who has never written Software or known anything about testing, reliability, scalability, maintainability, cost of change, or interoperability. Developer Manager: How would we be able to persuade them to take accountability? Software Development Company: Get them to believe that the UI is the main thing and that if the UI is 90% complete they should pay and sign off 90% we only lose 10% and we take no responsibility for testing, reliability, scalability, maintainability, cost of change, or interoperability. Developer Manager: What shall we call this? Software development Company: PRODUCT OWNER that will make them feel important

[@aaron5877]

Funny how in my world, the process is the only thing anyone cares about. At least 17 times a week I’m told by a SM, PM, agile coach or someone who I have no idea what exactly their job is, that I’m doing it wrong.

[@secretchefcollective444]

But I'm guessing you never get a specific answer as to what the right way is?

[@sholinwright2229]

The prob I have seen with retrospectives and I & A is that you feel compelled to find a problem. Then the org feels compelled to fix it. There’s no pushback. Maybe we don’t have to fix every grievance. Maybe we are dealing with it already. Gigantic time suck.

[@BillyBob-gq1es]

lol. Developer - “Business people” are the problem. Let’s throw out deadlines. Devs are struggling artists, they can not possibly tell you how long it takes (except you get paid 400k so not exactly the same) Devs need to step up, own the problem and realise they exist in the real world where time matters.

[@BryonLape]

Scrum is what happened. It got into the Enterprise. It is now just waterfall with extra steps.

[@blancheit4696]

where did u get the "it's fine" dog peluche?

[@444haluk]

Scrum is the scummy way of programming. And your argument is basically agile needs more agile because managers empty it.

[@ilovetech8341]

Companies don't realize Agile means listening to the customer. It also means long term benefits to programmers for writing quality. Instead executives treat agile as an assembly line of programmers. Then they bitch about why fixing one bug cost $1M after they fired all the good programmers. Agile means crap to a programmer unless a company puts a benefit in writing to the programmer for following Agile. Too many clueless executives who treat programmers like plumbers.

[@andresdigi25]

I have been using scrum for the last 10 years. All the people i worked with, even now think that scrum is equals to agile. And is the only agile that is valid... For my own fun i just realized that scrum was created by some people that are not related with the agile manifesto guys...

[@pyhead9916]

Roads can easily be built in a timely fashion when the government gets out of the way!

[@tobias-edwards]

Innaccurate and clickbait video title. You're in fact advocating for Agile and raising how most professional teams are implementing it poorly. You recognise frameworks like scrum and SAFe are not fully compatible with the devleopment of software. "Agile Has Destroyed Programming" - instead consider "Your team isn't Agile". It has the same provocative title and is more accurate to your point.

[@SaudBako]

I was never successful at estimating = I won't estimate again.

[@MightYoungJoe]

Unfortunately, fiance and contract work want things done by a given date.

[@doodidood]

"nobody has ever done proper agile" they say

[@kingjames1308]

I mean, shouldn't the title be 'Bad Agile' and not just 'Agile'? Almost everything you describe in your fix section is something that should be taking place in a healthy Agile organization. You are throwing the baby out with the bath water. Scrum typically gets the bad wrap because its too prescribed but Scrum is meant to be a stepping stone for new orgs getting into Agile. There are much more efficient and loser frameworks like Kanban that I personally have guided my org into. Our planning sessions take 15 minutes, we do not care about velocity or story points (Kanban provides me with lagging and leading indicators I can use to tell when something can be done), our reviews include stakeholders and demos. I see these videos a lot and almost everyone of them is describing Agile that is being utilized poorly.

[@Peter-uk6pt]

Agile philosophy in a nutshell. To prevent developing something that's "out of date", set up roadblocks to developing anything at all. As for "waterfall", it only exists in the minds of Agile cultists.

[@T1Oracle]

You're not complaining about agile, you're complaining about businesses. Everything you're saying is a skill issue in the C-suite. The business people need some skill too. If they don't get agile, then no one gets agile.

[@DataPastor]

5:09 “You can’t estimate how long it’s going to take to build something” - I think the ancient enterpreneurs who were supposed to build the Egyptian pyramids were saying the same excuse just before their execution. Wasn’t agile created because managers just got fed up with the same excuse which lazy software developers kept saying to them when being late with all deadlines?

[@chillandhackwithjoel]

I think about something called "support hated"-development. It means simply to let the user test new features fast and also make it user friendly (with guidance or good docs) so the time to answer on support questions is not so much.

[@tombjornebark]

Maybe, just maybe, developers need to consider the other side of the table and stop feeling sorry for themselves. The usual dialogue between bosses and developers goes something like this: • “We want strict requirements so we know what to build!” Here you go, here is a comprehensive set of requirements detailing exactly how the software should work. • “We can’t work according to Waterfall because software changes too frequently!” Ok, here you go, work Agile! • “We don’t like frameworks and meaningless stand-ups!” Ok, then have no stand-ups. Happy? • “No, we need the customer in the same room telling us exactly what to build. Right now, we’re just pushing software that gets rejected.” Ok, I’ve taken the time and even paid for the customer to sit with you daily. Happy? • “We don’t like being micromanaged. We need a product owner to shield us from this guy. Can you be the filter?” This is how it goes. Replace “developer” with “bricklayer,” and you get a sense of how pampered this group is. But I recognize the argument: if only that pesky manager would go away, we could get some work done; if only accounting stopped bothering us about the budget; if, if, if. To me, these are all excuses for laziness. If you have a problem, offer a solution and fix it. No sane manager would reject something that results in a better product. The problem is that developers usually complain, and their excuse for not solving the problem is, “Oh, I’m not in charge,” as they immediately point to the manager, whom they claim they could do just fine without.

[@alichamas63]

It's waterfall, but every two weeks.

[@errrzarrr]

Waterfall is myth, a Strawman created by Agilists.

[@budrho123]

EXACTLY!!!!!

[@Sdfsoepvmsywocmzyw]

And without proper UAT

[@markedgood]

😂😂😂😂

[@ForgottenKnight1]

Bingo. The only advantage with this is that if you fuck up something, it's less work thrown away, less work to repair, so less risk. The rest of the mechanism is pretty much the same.

[@xaviconde]

I've been scrumming for a year and I have nothing but contempt. I've stopped complaining in retros cause I've been told "that's how we do things here" (the old adage "it's not a bug, it's a feature"). Sprint planning is useless, no prioritization or actual review of backlog, and some user stories are not specified (an absolute white canvas which I have to fill). There's no reasoning on how long something is going to take, anyhow the product owner will come in the middle of a sprint with a deadline. Absolute rubbish.

[@Alan.livingston]

So you have a crap team? Give people like that any methodology and they are going to suck to work with.

[@iamfuckingyourwaifuandther2743]

@@Alan.livingston If the excuse of a "crap team" is something that makes the system fail then it's a bad system and it doesn't work because the majority of businesses are going to be made up of "crap teams". You're saying that everything works if it's done perfectly. Nothing is perfect i.e. it doesn't work in the real world and shouldn't be used.

[@comediehero]

Do we work at the same company? 😂

[@xaviconde]

@@comediehero maybe we did. I don't work there anymore.😆

[@brunoniconeves]

I feel bad for you, bad company to work, move away.

[@kevinmcnamee6006]

I think Agile started out to eliminate the bureaucracy of the software development process and unfortunately became the bureaucracy or the software development process.

[@ryanbarker3978]

You either die a hero or live long enough to see yourself become the villian

[@andrewbennett1176]

I think this is an apt comparison. We have built a new bureaucracy. In the old days, we talked about Agile organizations as being flat, non hierarchical, etc. Now it's just a different hierarchy with a ton of overhead and micromanagement.

[@sailingadventuress5489]

This. See who developed the manifesto. Developers. I know a few of them. They still build software, but every single one of them decries what is happening for developers.

[@SedgeHermit]

I don't see it that way at all, the cultish "manifesto" is basically against distancing yourself from the stakeholders and is a direct recipe for getting harassed at all times. It is very easy to see why the "Manifesto" (which is supposedly some golden ideal that, if only it was followed, would magically fix everything) gives a direct line to getting harassed, micromanaged, and having a surprise deadline dropped by the stakeholder/manager who is the biggest crybaby. You either have long term waterfall with some unfortunate bugs at the end that might be harder to rectify or, in 99% of cases, you have a situation that devolves into a harassment nightmare work environment for devs. They are mutually exclusive.

[@yewknight]

The problem with Agile is it abandoned the manifesto and just turned into another corporate tool that serves executives instead of serving customers and people who build software.

[@tonyennis1787]

@@yewknight who are these customers that like half-baked software? Certainly not customers who are paying for software.

[@Peter-uk6pt]

Agile is like a bad movie that management is afraid to walk out of because they've paid for the tickets.

[@andresdigi25]

100%

[@NinjaRunningWild]

Sunk cost fallacy in other words.

[@michaelboggs438]

Every company says the same thing: who really does pure Agile? Truth is, if you don't give yourself permission to be Agile at every level of your organization, you're really not Agile, you're just waterfall done poorly, and Agile becomes a scapegoat

[@ToddMagnussonWasHere]

Agile in most companies turns out to be “Fragile” or “Watersprints”, in the last five companies I’ve worked with, two companies successfully implemented something that looked and felt like agile. And one of them that implemented it well at the team level still had a company level hang-up with excessive meetings.

[@ryuhaneda]

No stand-ups. My boss Rachel needs to coordinate? Email or direct meeting. Wendy, Ignacio, and Sayeed pushing new code? Email or conference call when that involves my team. No one needs to hear I’m blocked again because DevOps reset my virtual machines. And unless I’m being groomed for team lead or manager, I don’t need to see everyone’s status updates.

[@CodyEngelCodes]

It depends but I tend to agree that no stand-ups is the way to go. They can be helpful when focused on unblocking others on a project but at the same time we have Slack, if you're blocked, just say you're blocked instead of waiting until the next day to bring it up.

[@aeggeska1]

"DevOps" reset your machine? You're using the word DevOps wrong.

[@patrickproctor3462]

​@@aeggeska1 Eh, more likely the organization is using it wrong. Our site reliability team does as much networking management as it does building environments through Terraform and a deployment pipeline, and then also watching for infrastructure hiccups. It wouldn't surprise me some organizations smash all of IT (minus acquisition of work machines) and Dev Ops together.

[@kristianlavigne8270]

Agile = Micro management and Bureaucracy

[@gzoechi]

It's always the same. Incompetent people do random dumb stuff and conclude from that that Agile is bad.

[@axelberle]

People who say that probably have experienced a very bad implementation of Agile. Agile is about less bureaucracy.

[@gzoechi]

@@axelberle I don't get why everyone blames Agile when the problem are always people who call their uncooperative behavior and bullying Agile 🤦‍♂️

[@axelberle]

@@gzoechi I see that a lot, as a Scrum Trainer, I see a pattern here. Scrum and Agile are all about real, deeper collaboration, which requires a lot of trust (inside the team and with the organization). Teams that do Scrum as it should be done usually love it.

[@gzoechi]

@@axelberle I'm sure people who care about software development usually do like Agile, but there are just too many in this business who value other things more and there Agile might get in the way. That's my only explanation.

[@supfreshitsourturnbaby]

Confucious once asked, how can Agile destroy programming if nobody does Agile correctly 🤔🤔

[@CodyEngelCodes]

"Agile" is not "The Manifesto for Agile Software Development" although it's hard to say what "Agile" is even supposed to be these days so your comment is still spot on.

[@Alan.livingston]

Been at this 20 years and my take away is that the quality of the team is first, the process they use is second. A great team will take a process and make the best of it, a garbage team the opposite.

[@CodyEngelCodes]

Absolutely agree, a past manager once said (actually he said it every day, possibly multiple times a day): Together we ship correct quality software. It wasn't intended to be in priority order but it was. The team comes first, then focusing on shipping the things, then worry about getting it correct (because the first release never will be) and then make sure it's of high quality.

[@andresdigi25]

A great team just needs good communication and direction. But will not need scrum. Maybe some of the artifacts reference byscrum would be use(like meeetings to talk about problems how to unblocked) but a team like that knows how to be agile even without rephrasing the agile manifesto,

[@secretchefcollective444]

I agree, a good team will make even a lousy process work but a garbage team *needs* a good process to produce good things. Logically then (given that premise), Agile isn't suitable for garbage teams, and so isn't a good process.

[@juliep1122]

As long as the team is given freedom to actually do what works instead of being micromanaged to death

[@aram5642]

Fully agreed on what you've said. I think organizations like agile, because it is widely-recognized and practitioned, it is appealing when you look at the sprint idea, and it has this original connection to business that ensures an early fail. And this article of manifesto - response to change - which gives everyone grounds to totally mess up the plans, but is the main reason for the ever-declining software quality. Features are often left incomplete, or untested fully (because no one tested it after client accepted the basic implementation), the code base is full of dead code (because someone forgot to remove it when the change happened). I was very fond of Scrum when I received the training, as it proved to create a bubble/shell around the dev team when it comes to prioritizing work, but the longer I worked with it the more overwhelming the PROCESS has become.

[@ericpmoss]

Agile sucks. Like any religion, it begins with a golden rule, and devolves into The Inquisition.

[@MorningNapalm]

Then rewrite the rules until it works. At my workplace we keep things very simple and use something more like Kanban than scrum, and it keeps things streamlined. The other groups have devolved to older processes and suffer the consequences.

[@tonyennis1787]

@@MorningNapalm we are also slowing migrating to kanban. It seems to be more realistic.

[@bijosn]

I refuse to work at any company that implements “agile”

[@randyhale8517]

Honest question.... What do you look for in a company that you would work for?

[@bijosn]

@@randyhale8517 treating sits employees like adults

[@MorningNapalm]

What process do you prefer?

[@estebanperalta59]

@@MorningNapalm Waterfall. Best experiences BY FAR in my career as a software dev. Agile it's just a factory of anxiety and micromanagement where a guy called "Scrum Master" gets paid more than you knowing a crap about IT and not writing a single line of code.

[@MorningNapalm]

@@estebanperalta59 I think that the team is far more important than the process. I am currently doing kanban-esque agile and it works great, as long as we stick to it, which we mostly do. I have bad experiences with waterfall, which lacks the regular feedback so important for keeping things on track. You can of course add this to waterfall, but then you are mixing agile and tradition,

[@victormendoza3295]

Most days I am not a fan of Jira, or THAT process. I just personally use excel and have the same steps for any project. just stick an x next to it when it's done, lol. So fast. I got trello/monday on the side, but even those seem like to much.

[@agdevoq]

My boss: let's choose agile for this project. Me: I'd rather eat rats. Office: applause.

[@seinfan9]

And that man's name? Albert Einstein.

[@NiasSweetSounds]

curious how you feel about all of this in the context of regulated software development (medical device, aerospace, pharma, etc.). Documentation is king in that realm. Requirements, safety, etc. are mandatory. You can't just fly by the seat of your pants and wing it.

[@andresdigi25]

in those context even scrum is no enough. But also in the other context like consumer APIs, etc is even worse...

[@alzeNL]

I an attest that having worked for a very large telco, we had to blueprint and step plan everything. These plans where then checked and verified. It was a hell alot of work, but guess what, critical infrastrcuture was always working and available. The highest risk work always got completed within the change window, it was well rehearesed and coordianated, everyone knew what they had to do. Developers wrote code so well documented outside of the code, it was a pleasure to work with. Everything was done to a high standard and ensure critical services.

[@randall.chamberlain]

But then managers who should know better come back at the team with stuff like "we're worried about the velocity", or "upper management prioritized this today" or "why are you not moving more tasks to done in the board, your performance evaluation and salary raise will be impacted if you don't deliver X amount more like others in the team do"

[@neunistivlija]

Less biz managers involved. Give developers freedom and you will see results.

[@andresdigi25]

I think we need freedom to choose but also we to take in account the market or money restrictions of the company where we work. But we need to be able to take decisions and accept the responsabilities

[@juliep1122]

I’m so sick of lack of documentation. The only thing that was needed to solve waterfall was keep the documentation, but develop in shorter cycles and get feedback from customers along the way. But in the name of Agile, documentation of business logic has been thrown away and gets lost in hundreds of jira stories or buried in emails never to be found again, except by painstakingly reverse engineering the code 🙄

[@GnomeEU]

I think the biggest problem with agile is that technical debt keeps piling up if you keep sprinting and adding new stuff on top of a codebase all the time. After a year or two the software is barely maintainable. You will need one or two devs that only fix technical stuff and refactor.

[@PapaP86]

One of the biggest problems with Agile at least in my experience where I'm at is some organizations want the benefits of Agile, but they're not willing to change/restructure their organization (and maybe can't given certain industry regulations) to actually enable Agile processes to work. In case like this, it often ends up being some bastardization of a waterfall SDLC and Agile that doesn't really have the benefits of either. As a results, requirements are often much looser and less understand than having more solid documentation up front. For larger pieces of software with heavy requirements, having deliverable pieces within 2-4 week Sprints isn't even really feasible. There are some projects and situations an Agile process can and does work great, but I think too many organizations want to implement it because it's trendy and see potential flashy advantages they want, but don't understand how it would fit into their organization and projects and why it may just not be the best fit, especially as a one size fits all for all of their projects.

[@artephank]

Great observation. I think that it gives a lot of "business people" free card to not think about requirements at all and just drop even more work on Development Team.

[@gzoechi]

I think the biggest appeal comes from people thinking that Agile just means joy - only do what you like when you like it. That applies to managers and developers alike. In reality it just means everybody is fully responsible for the parts he/she is working on, including the hard and tedious parts.

[@gjw2wj469]

Agile only works for small projects that needed quicker release and definitely not for huge projects. Also agile wont work for new products or projects and works for small upgrades (small feature enhancements) for an already existing project.

[@8Rider6]

​@@gjw2wj469Agreed for the most part. Unfortunately a lot of companies or organizations don't want to see or admit that and try to force it anyway.

[@artephank]

@@gjw2wj469 it works perfectly well for new products. Actually it is great at it. Especially if you don't know in advance exactly what the project is going to be like. As for big projects - nothing really work for big projects. I strongly recommend Fred Brooks' "The Mythical Man Month" - it was true back then as it is now.

[@MaurizioTuratti]

Scrum adoption is the most frequent problem. Software development is a non linear process where you can scratch your head for days and the solve most problems in few hours, while scrum is a linear process expecting a uniform distribution of work and results, that is not how our mind works. This usually leads to a lot of pressure and, as a consequence, burnouts

[@johnpettiford6547]

"How modern day software development destroyed agile"

[@theprimalpitch190]

every Agile description I see equates SW devel to building a house out of bricks. Software is not bricks and systems aren't houses!

[@alanhegewisch4486]

I find it very interesting that I'm seeing a huge backlash recently against Agile that has coincided with the unending waves of layoffs. It almost seems as a rebuttal: "Engineers do produce a lot of value, the problem is agile". And I have to wonder: Is the problem agile or the stakeholders? Like you said, the core tenets of agile still hold up, but it's now used as an excuse for bureaucracy, bogus metrics and a tool for micromanaging. Could it be that some businesses don't know how to create value, so they blame the methodology? There's nothing really "special" about agile. Is there anything special about the companies that are using it and failing?

[@tonyennis1787]

The problem is that Agile was invented by people who didn't have any respect for hitting deadlines. Thus, there is nothing in Agile that allows this honest-to-god need to be satisfied. The micromanaging or whatever is a reaction by the people responsible for delivering a product to know if the software will be made to spec, on time.

[@eyesopen6110]

"agile" is a f_kn joke. Companies are now (finally) firing so-called "scrum masters" and related garbage. Now we just need to stop listening to junior programmers who know nothing.

[@devstories-iv1mw]

I am actually moving away from development to other fields in IT only because of this Agile bs. It it like a cult or a religion...pure madness

[@JonathanRose24]

Story pointing is a huge waste of time

[@regalternative]

I hate the story points system. Makes the whole thing feel like a stupid game I don't want to play

[@LV-1969]

Story points are only as good as the person who is working it. I wrote a ticket to add a new capability to an application. It would take me about 2-3 days to implement and get it out to production. They gave it to an offshore person and it took 2 weeks because they didn't know anything about the application and they had to learn how things worked.

[@PhilDietz]

pointing poker should be during sprint planning. So if junior guy X gets it and he bids 13, then the scrum master or product owner can throw on the brakes and assign it to someone who'd score it a 3. But they dont do it that way. And that implies "the whole team" works on the story, but thats not the case I've seen. Its 1 story per person waterfallesque.

[@schaughtful]

Agile is the method by which tech builds blindly. Agile leads to bad and inconsistent documentation practices because of arbitrary documentation requirements.

[@henrymaddocks984]

Consultants and certifications have destroyed programming and there is nothing you can do about that.

[@swapode]

I wish you'd say "Scrum" instead of "Agile with a capital A". That's more accurate and doesn't perpetuate the idiotic idea that working agile has anything to do with the problems of supposedly agile Scrum teams. Scrum, as an all domineering process, fundamentally is at odds with being agile. Actually being (adjective) agile kinda is the solution to the Scrum problem and conflating those terms really prevents people getting to that realization.

[@andrewbennett1176]

As an Agile coach, I agree with you wholeheartedly. Agile isn't anymore. It was better 10 years ago, and it is a mess these days, and getting worse all the time. I actually find scrum as it was in the late 2000s was often pretty effective, but it is no longer developer focused.

[@jamesgibson3582]

After 35 years developing systems for organizations I have found that the lack of understanding of the organizatiin about who it is, what it does and WHY it does it, leads to disaster down the software develoment road. The 'use case', 'customer experience' 'needs assessment' stuff does not even come close to really knowing what the software should do, how it should do it, or why. I know help companies get all that figured out before they engage a software company. Seems to work better.

[@remek712]

I’m in a situation at work where I’ve been working as a Java Developer for about 7 years across various corporations. In each company, I’ve worked in the Scrum methodology with sprints. I’ve noticed a recurring pattern, and in my current job, it’s the same: managers use sprints as a tool for excessive control and apply pressure to deliver everything within the sprint. They often talk about deadlines and due dates. The atmosphere is such that I always feel behind and like I’m not doing enough. I struggle with working under pressure in sprints, and because of this, I’m considering changing to a position where I wouldn’t have to work in sprints.

[@werthersoriginal]

Young me: I can't wait to code. Old me: No, we're going to spend most of our time talking about the patterns of code.

[@johnvonachen1672]

I've used agile at a couple of companies. The first one did it almost right. The second not at all. People get this wrong a lot. Agile is not a tool for management to get developers to produce more in less time. It only does two things. It lets you make better predictions about how long something is going to take. Better predictions is always better for business. It's not perfect but if you do it right, it's better. And it gives your customer permission to change their mind every two weeks. The cost of that benefit is they might not get all the features they want. They features they might not get are at the bottom of the sequence so it should be no big deal. Everybody, the customer, the management, the developers, need to know that and be OK with it. If they don't understand or they do but are not OK with that, then don't bother doing it. If management thinks this will produce more in the same amount of time or produce the same things but faster, then don't bother doing it. They don't get it.

[@ldaniel8466]

Interesting what you are saying ! I am an agile coach at a company and I see zombie teams which were not engaged. What I observed: tickets were to do lists from the POs, the space for the solution was occupied by BAs and POs. I am starting to teach the POs now that involving the team is crucial. Devs are there to solve problems from customer and not to write code. But I can tell you, I have a lot's of resistance from PO. But if we don't start to trust the smartest part of the company and using their full potential by providing everything that they know how to solve the problems, we just create a toxic environment where people will leave after some time...

[@tonyennis1787]

11:30 Everything you said about deadlines, is wrong 1) Deadlines are correct - they are specified right there in the contract. And so is the expected functionality. And companies that are paying for software actually care that the software works; they are not interested in half-baked software, and they have no desire to test your code. They paid for working code. 2) Non-bullshit companies will not let you deploy code willy-nilly into their production environments. There's a process (sometimes with legal ramifications) and it is slow. Once deployed there, you probably won't have access to it. And the software will likely not be allowed to call home. Your software will be hard to fix when some bug is discovered and you won't be able to stealth fixes in. What the next Agile Methodology will have to include is a mechanism that embraces deadlines. That implies putting real estimates on tasks and holding the dev staff accountable.

[@JanSnieg]

I’m a dev and each task is different. You can’t really keep ppl accountable for knowledge work as sometimes a good idea saves days of work and sometimes shitting in the morning solves unsolvable problems. That attitude of rush and sprinting only burns out creative people.

[@tonyennis1787]

@@JanSnieg like programming is the only creative endeavor on the planet? Dev teams must be held accountable. However, the dates have to be realistic too. You can't 'deploy as quickly as possible' and also expect no problems. That is, the good/fast/cheap triangle is real.

[@JanSnieg]

​@@tonyennis1787 I used "dev" word to introduce myself and only to give you context of my experience and later on referred to this kind of group of work as "knowledge work" to highlight that it applies to ANY creative work so your rhetorical question "like programming is the only creative endeavor on the planet?" is totally missed. I used to be/am hyper performer due to my adhd hyperfocus on programming and believe me that with your approach you can only have mediocre results, you will burn out outstanding people and the team will become mediocre and passive and they will beat you at your own game of storypoints, deadlines and rush. Hire the right people, give them the autonomy, freedom, trust and purpose and believe me that it will work much better than scaring people with deadlines, estimations, velocity, capacity SPRINTS FASTER FASTER FASTER.

[@LeutnantJoker]

Engineers an equal party.. good joke. I've been doing this 10+ years now. Keep dreaming. To anybody reading this: NEVER go into software development. You'll be miserable for the rest of your life.

[@river1duck]

You make very interesting points and I can't say any of them are wrong/false. But let me make a defense from a Scrum Master perspective. As someone who was pushed into the role when I was a technology project manager, I was told that the industry is changing and that I need to change with it. Hence over 8 years later I am struck in thankless job who no one is willing to hire - simply because everyone has taken the mindset that Agile or Scrum is an useless methodology and anyone who is associated with it cannot do actual work. So my point: "Agile did not destroy programming. It is the business that destroyed programming." You will find some of us who do practice Agile or Scrum were not given a choice in the first place.

[@CodyEngelCodes]

It is 100% business folks that don't understand software who destroyed programming. However Scrum was used quite a bit in Corporate America to help destroy programming. Not to say everyone that does Scrum destroyed programming, I've met plenty of folks that get it and I'm sure you're one of them.

[@errrzarrr]

Yeah. Who destroyed Rome, was it Nero or was it the Fire? One is the author of the destruction and the other one is the TOOL of the destruction. All the same in the end. That you let to be used by others doesn't mean you are less responsible for it

[@devstories-iv1mw]

@@errrzarrrWe meet again in scrum hating comment section :D You are right with this one again. In my opinion it all comes down to non-tech people being directly involved in development process. Just replace SM and PO with Lead dev and a lot of problems will be solved. I worked in one company where our head of department was ex dev and he really knew how to negotiate/collaborate with "customer" so to say and how to organize work. Problems started to arise when he assigned some of his work (mostly planning and customer collaboration) to a non-tech person. People just have to understand that if you want to work in tech, you have to have hands on experience in the field....at least lower and middle management (btw like in every other profession)

[@gzoechi]

​@@errrzarrrFire was the tool to warm the homes and for blacksmiths to make steel moldable. It's not the fires fault Rome burned down.

[@rossbagley9015]

Business has never understood what software developers are doing. We're not creating widgets using an existing factory. We're creating new factories to turn out the widgets you asked for. Fundamentally: if you don't know what kind of widget your customers need, we'll build you the wrong factory. And as a rule: everyone's first guess about what is needed and how to build it is wrong. The first one is wrong. Just expect it. Which means that if we estimate how long it will take to build the first (useless) factory, but you need the useful factory by some deadline, there will be tears and gnashing of teeth.

[@SufianBabri]

About the estimation, the example is not correct. In case of construction work, the teams and companies know how long it would take since they've experience in doing the same things before. On the other hand, in software development we're always facing new and unique requirements. We have to cater for dependency/framework updates, new privacy and usage policies, limitations of tools/technology etc which means that we sometimes don't even know if a certain feature is possible at all (without doing a full fledge development). For this reason the "No Estimates" movement makes so much sense.

[@Tasarran]

Yes, I say this when people compare software to construction. Dev work is more like science.

[@kirishima638]

The vast majority of software products are neither unique nor ground breaking. Create a user account in a server database. Hash the password. Add in licensing and telemetry. Serve up a page. So many ‘apps’ are just the same UI elements with a new coat of paint. Most re use existing frameworks and libraries, retreading the same ground. We know how long this will take. But management needs their ‘story points’ and ‘velocity’ to put into pretty graphs for their shareholders. PMs need their scrum meetings to justify their salaries and micro manage the people who are actually building the thing.

[@SufianBabri]

@@kirishima638 login and registration flows are hardly considered to take more than a fraction of a week, and devs have usually no trouble in estimating the time it'd need, but other features are usually very different than what we've worked previously. Yes, if your company works in a specific niche and uses a base repo (e.g. Restaurant management) you can easily estimate the time it'd take to build the software. Most software projects are unique per team, or have specific gotchas that have to be addressed, thus making estimates impractical and silly.

[@budrho123]

Here's the itinerary for a useless meeting this monday reviewing the following... ----- ART Ceremonies Feature Refinement PMT Architecture Sync System Demo Birds of a Feather ART Sync Agile Journey ----- Team Ceremonies Daily Standup Story Build Iteration Planning Meeting Team Demo Team Retro Code Kata

[@BenjaminVestergaard]

The real problem about agile is that the lower requirements to the documentation often makes leaders/management believe that there's no need for a specification of requirements either. Without a SoR, you end up in a situation where QA cannot verify if a product is ready for production. That also encourages scope drift where the customer or manager tries to get "free" features by coming up with ideas along the way.

[@jamesbond_007]

Great articulation of the problems. With agile at my last company, we had quarterly planning meetings where all the teams would talk about their plans for the next quarter, what features they were going to deliver and what effort those would be (not story pointed, but tee-shirt sized), scrums were pointing any unpointed story the PM came up with, and maybe reordering the backlog, etc. It was agile-ish, but not true agile. I wish I had had your video available to share with them when I was working there!

[@acasualviewer5861]

Your argument sound like this: Agile Manifesto Good "Agile" doesn't follow Agile Manifesto Follow Agile Manifesto Also you say: estimation is impossible. Which is false. Read Steve McConnell's book "Software Estimation: Demystifying the Black Art" There's a lot of experience out there. And finding the right way to use it can make software development work quite predictably. But I agree that some companies don't know what they are doing with scrum.

[@spaceenthusiast5696]

As a new software developer, I feel completely demotivated while working with Agile. Everyone except me loves that methodology, but I feel unproductive.

[@Jedimaster36091]

It depends on how you measure your productivity. If you're measuring the number of code lines, then it's the wrong metric - it doesn't matter how many you write in a day. What matters is how many stories you deploy in production.

[@groovediggr8777]

So often, here included, I see devs talking about the failures of Agile when it's them not actually engaging. For example, OP's comments around 4:36 on story pointing amount to him wanting to avoid the (useful) conversation about complexity, and thus just gaming the story pointing process to avoid that. This is not a failure of Agile; it's a failure in team behavior and faith to the valuable parts of the process.

[@fluffysheap]

I have had positive experience with story points, maybe the only part of agile that's actually been helpful. The idea of story points is that even if you aren't good at knowing how long things take, most programmers can tell whether A is harder or easier than B. So if you do the points and the numbers don't reflect the "easier/harder" estimates then you found a problem. If you get into a situation where people are trying to guess what everyone else will say so you can stop doing story points, then you really have a bad situation.

[@Dr_Kenneth_Noisewater]

In 11 years around software, I have never - not even once - seen a management release target hit. They always slip 100% of the time. It’s a meme at this point. Even now that we’re trying for smaller projects pumped out on 2-week release cycles, we’re STILL not hitting the targets set from on high or even on medium. And I do think everyone sincerely is trying to be reasonable it’s just that effort and time estimations are very uncertain unless someone invests time to do spike research and de-risk them - but even then it’s uncertain; just less so. I like the idea of saying eff the timed cycles because they’re already meaningless and just release when shit is ready, piece by piece. We’re trying that but they’re still pushing the sacrosanct “if it’s not a two-week cadence it can’t be Agile”. It’s all just so stupid.

[@tarhelytarhely5662]

Sorry to bust the party, but developers and stakeholders do not need to and should not speak to eachother. The origin of agile was, that people noticed, developers and stakeholders cannot speak to eachother. So they have decided to try even harder... Everyone should speak to everybody all the time. People before processes my ass. They shove together people with vastly different knowledge on different domains, and wonder why the meeting stays at the the common denominator status report level. This madness takes up half of their worktime, leaving no time to speak about something meaningful or - god forbid- work. Everybody is responsible for everything, so no one is. Instead of documentation you end up with a bunch of meeting record, where somebody said something, the next time the opposite. And the result is exactly that. Something contractionary and messy. No one knows how it works, but the upside is no one knows how it should. If you cannot do the work without scrum, you won't do it with it. You cannot substitute responsibility and knowledge with methodology.

[@errrzarrr]

Why we are at it, can we drop estimations and story points entirely? You can't have clear estimations without clear requirements. It's all shackles for the devs and leeway for management. This is a fool's bargain.

[@r.fortner4661]

Throw out deadlines??? Really? If the effort is more than 6-weeks, its probably too big anyway? Wow. So what processes do you use for large software project that have to be in place by a pretty solid SCHEDULE milestone???

[@cgcg9119]

Story points are not primarily for business people. Firstly, it's for the team itself and protects them from bad managers who want everything done yesterday. Story points help the team to predict in sprint planning, as good as possible, what can be delivered by the end of the sprint. Over time, the team gets better in estimating and this is a constant calibration. Needless to say that this is approximation, this is known and accepted. It's software development we are talking about. Good managers will then be able to translate all of this to managerial decisions. This is fine too because software engineers are a part of a wider group and they need to collaborate within a business. This is what my team is doing for years and I hope everyone interested could see the way we do it, i.e. correctly.

[@ManfredWisniewski]

How do you know that is how it is everywhere? I think you are making a generalization that is too big. Yes, mistakes are being made, but they are not the same mistakes everywhere. Also: from your description it's not Agile that has let us down but business. Trying to get together with business on how things supposed to work is sadly a big part of work today. But great product owners and scrum masters can actually do that. (I have met some, but they are few and far between.)

[@gavinlangley8411]

I missed the "how to fix it"? The issues you describe are those of a lazy teams approach to agile, doing the minimum possible, and yes it's very common. Early & incremental or at the end. Flexible process or prescribed stages. Early & incremental & flexible process win every time. These are undeniably better than waterfall. There is a clash between business budgeting and agile software projects. What business can really have open-ended projects? If the aim is to please all developers. It's not possible with more than 2 people. All teams need a process and every developer believes they know best. Agile is a marketing thing for IT people to promote themselves and their ideas. It needs constant changes because people need change and ways to promote spending more money. Best to take a practical perspective do what makes things work best. That's more agile than waterfall.

[@Jedimaster36091]

You mention an important point: business need for close-ended projects. While it's true that businesses need to know when they can get their piece of software deployed, the challenge is to think small at the same time. Meaning, business has to think what is the first, very small piece of software they can take and start using it as soon as possible. It's is easier for business to think big and throw it all on the software dept., than take some responsibility and design their business vision as small increments.

[@vyli1]

Absolutely nothing that was said in the video justifies the title. None of the mentioned points are anywhere near to Agile having destroyed programming. These are very small annoyances that might occur in some teams, but none of them are important. Sure, there are plenty of companies that do agile terribly. But most companies are doing ok. It's certainly not the best, but it's not like agile in most companies is so horrible that it's downright off putting to work under such conditions. My main grips are about the amount of meetings. Most of them are completely unnecessary and I'd much rather went in for ad-hoc meeting styles whenever necessary. Such as standups, they make zero sense. If you're blocked by something or need to share something with the team, write it in the group chat. No need to hear what everyone has been working the last working day, there are tools like Jira for that. But does this break programming? No, it's just a small annoyance.

[@ruedigerfriebel8454]

5:15 what? a developer cannot say how long it takes to build something? interesting. so you go to someone to build your new dream house. you know how much money you can spend and you meet the people to build it. question how long will it take to build it and when will it be ready. Answer a eveloper cannot say how long it takes to build something. Sorry

[@cmart020]

One cannot build a skyscraper without a solid foundation. You cannot build good software without a solid foundation. The problem is that more often than not Agile skips the foundation part and thinks one can start building the walls...

[@korayem]

Doing Agile is totally different from being Agile Following practices and complaining that it's not working is because management first must understand the values and principles before forcing tech to use it Otherwise a lot of anti patterns emerge and Agile is labeled as a failure so let's go back to the worse methodology of waterfall

[@tldw8354]

Never used agile in the last 13 years or so. My customers don't bother with such terms, me neither. They need results and what I do seems to be called waterfall

[@pyhead9916]

When designing software requirements, the business people should be spending 3x more work than the software developers. Analysis using UML is the most important part of any software design, not development.

[@gavinlew8273]

I wonder how AI Multi Agents will change the world of software development.. Nvidia wants to change how software is developed..

[@davidp.7620]

Story pointing doesn't allow you to talk about complexity in a non-biased way. It just gives the illusion of objectivity