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

In this video, I'm going to talk about how agile has destroyed programming and how to fix it.
Agile is a great method for managing software development, but it has some severe drawbacks that need to be corrected if programming is to be saved. I'm going to discuss the reasons why agile is bad and how to fix it, using examples from my own experience as a programmer. If you're a scrum master or project manager who is concerned about the future of your profession, this video is for you!
🚶‍♂️ FOLLOW ME 🚶‍♂️
Join Our Discord - / discord
Twitter - / codyengeltweets
TikTok - / codyengeltalks
Medium - / membership
Subscribe To My Newsletter - www.engel.dev/
💡Get 20% Off Of Brilliant - brilliant.sjv.io/RyKBBX
🎥 My KZbin Gear - kit.co/CodyEngel/my-youtube-gear
🖥 My Desk Gear - kit.co/CodyEngel/my-desk-gear
🎵 My Background Audio - www.epidemicsound.com/referra...
*The above links are affiliate links.
📚 RESOURCES 📚
Manifesto for Agile Software Development - agilemanifesto.org/
#programming #projectmanagement #vlog

[@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.

[@alichamas63]

It's waterfall, but every two weeks.

[@errrzarrr]

Waterfall is myth, a Strawman created by Agilists.

[@budrho123]

EXACTLY!!!!!

[@424dsfdsfdsfs]

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.

[@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

[@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.

[@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.

[@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

[@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.

[@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.

[@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?

[@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!

[@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.

[@jp-gy3vh]

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

[@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.

[@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.

[@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.

[@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.

[@jp-gy3vh]

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 🙄

[@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.

[@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...

[@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.

[@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.

[@xlerb2286]

Not a fan of Agile as practiced. But I've also done some of those large requirements docs. I remember doing design docs that were 250+ pages long and were out of date and worthless before they even got to the rough draft stage. Worst project I ever worked on though planned out a full 2 year development effort for the next version of the product down to the very week where a feature would be scheduled. And changes to the schedule were not allowed. We survived the projects by a combination of death marches and lying through our teeth. So at code complete we were more like 75% complete and had a huge pile of bugs we'd filed that we used to add the functionality we didn't have time to finish according to the schedule. And this was in one of the largest tech companies in the US. I was so happy to get out of that place.

[@chrisharshman5838]

What is much much worse is when your teams are doing agile, and then months later someone not on the original team needs to investigate a feature. Since the only documentation is user stories from the old project, the new person needs to spend a bunch of time in research just to figure out how the system is currently working, usually by reverse engineering the code. That one feature may have been touched by multiple stories in multiple iterations, even possibly multiple projects. Good luck sorting through all that. Also, backlogs tend to be the place where good ideas go to die.

[@xlerb2286]

@@chrisharshman5838 Exactly. And that code that has been touched by multiple stories over time will never have been refactored because time is tight right now so we'll do it "later" - when we're swimming in spare time ;) So you get all sort of cruft bolted onto it as time goes along.

[@farrenh]

I only worked on waterfall projects for about 25 years, and with one exception they all delivered value on time and in cost. The one exception was when the client gave us a single point person to spec out requirements with and that person refused to allow us to conduct workshops with stakeholders in various departments of the company, insisting that he knew everything about how the whole business worked (it was obvious to us he didn't and we brought our experience from other projects to bear to suggest requirements to him). But even on that project we delivered 70% of what they actually needed on quoted time and in cost. And when the board realized it was exactly what they signed off on and the missing functionality was because of their point person's hubris on the project, they fired him and happily agreed to a second phase of development at additional cost to get to where they needed to be, where we worked with the actual stakeholders in the company. So I'm completely convinced that in the right context, waterfall works. Context matters though. All of those projects were bespoke software for specific and well defined commercial requirements. Some customers, like small banks, already had the procedures they wanted computerized well-documented. They were'n't off-the-shelf products or online services that required continuous development with rapid changes and additions. I've been working on online financial services for the last 5 or 6 years and adjusting to poorly implemented Agile processes that just feel like managed chaos that produces spaghetti architecture after all those years of waterfall. The only way I cope is by doing a lot of after-hours refactoring, and taking whatever opportunity I can to pad the estimated time for new requirements with additional refactoring time and/or time to build bridging facades to ensure that incremental additions don't further spaghettify the architecture. The accumulated pattern-recognition ability from 25 years doing disciplined and thoughtful design helps a lot, too, because I often "just know" exactly what the best architecture is for requirements that can be met with familiar design patterns without having to think about it much. So I can take a kind of "think globally, act locally" approach to code, implementing current requirements in sufficiently generalized ways that cater to many other imaginable future requirements.

[@xlerb2286]

@@farrenh I divide software projects into two categories "voyages of discovery" and "Caribbean cruises". In the former you don't know the domain, maybe the technologies are unfamiliar, etc. In the later you're working in known situations, with types of project and technologies you're familiar with. Waterfall works GREAT for the 2nd category and can work ok for the first. Though there something more sprint-like where you're taking small steps and have the option to backtrack helps. But agile as practiced isn't good for either of them.

[@jp-gy3vh]

@@chrisharshman5838exactly, this is one of the biggest things I despise about agile, the lack of documentation. As if documentation is an all or nothing thing.

[@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"

[@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.

[@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.

[@frank3722]

So how do you build software for new hardware? Like a smart thermostat, a security panel or a car dash?

[@MicheasHerman]

I had a manager say: "The basic thesis of Agile is that we are so bad at planning for waterfall software development that we should just skip the planning part" There is a large amount of truth in that. 80% of all software projects are rejected by their customers. As awful as Agile is, Waterfall has proven to be an almost unmitigated disaster.

[@CodyEngelCodes]

Waterfall is only useful if you are sending things into space. Agile can still have planning but it should be far less rigorous and much more focused on more immediate deliverables.

[@MicheasHerman]

@Cody Engel although the moon landing was almost textbook agile. The radar was producing too much noise so the computer wouldn't be able to land on the moon. While Apollo was in orbit, Margaret Hamilton invented try catch. Implemented it, and then the program was uploaded to the computer that was flying in orbit, and if the program failed, there would've been dead astronauts on the moon.

[@agdevoq]

They're all buzzwords, guys. It's been half century we tried to cook the perfect solution to handle projects. Truth is: projects are difficult, and there's no "one size fits all". The sooner you understand it, the sooner you'll move from thinking about how to think, to thinking about how to actually deliver.

[@michallasan3695]

But scrum also brings needless complexity - it is only the manager's job to know what everyone is doing. A programmer is focused on his own task and making him listen to what everyone else is doing is just a waste of time. When the manager meets everyone one by one, it is more effective. Also, there is this planning part of scrum - you have planned it, so you have to finish it.

[@artephank]

No, the central thesis of agile (or scrum, whis in most cases is a synonym) is that we don’t know future. So lets decide on things as far in the „future” as we can.”The future me is knowing project matter way better than current me, so let him decide”- this is almost exact citation of scrum guide

[@ZwartCode]

I'm Loving the daily uploads. It's a good way to turn my brain on before work.

[@CodyEngelCodes]

Thanks, happy to hear you've been enjoying the daily videos. Unfortunately there's an ongoing family emergency so the daily uploads aren't going to be daily 😭 although I'm going to keep cranking them out as I have time.

[@rombus]

This is brilliant!!! All the right insights!!! Bravo!!! 👍🏻

[@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

[@ryanrichard2736]

while there is value in the items on the right, we value the items on the left more.

[@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.

[@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.

[@carbondragon]

A LONG time ago, working for a big contractor, we used the RUP (Rational Unified Process) a very high ceremony agile process to create a product for the US Government. Initially they were all for it. Then in the preliminary design review (I know, that made no sense but we had one anyway) they went basically berserk and tried to cancel the project because they didn't really understand the process, didn't want different types of work products, didn't want to look at or review intermediate versions of the system, and thought we were mad. Our managers calmed them down so they didn't actually stroke out and we ended up doing it. We had intense resistance from the customer and our own upper management the whole way. But we delivered the project in the end and it did what it needed to do and the customer liked it so much they extorted the company to give them the code so they could try to maintain it (surprise, they couldn't). It was a great experience, but a frustrating one and it goes to how resistant both the USG and big contractors can be to ANY kind of change.

[@harrykauffman3800]

As a 8 year scrummaster I completely agree with you. The main issue is trying to convince leadership to adhere to the good points of Agile can get you fired for working against the grain.

[@jfftck]

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

[@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.

[@MrJacksspleen]

I've seen "Agile" become a means to reduce the reliance on talented developers and true architects. The result has been poorly designed software full of defects with nonconsumable documentation. But hey, management delivered all the sprints on time!

[@DIYDaveOK]

BLESS YOU for saying what I've contended for a long time: Agile is just creatively repackaged waterfall.

[@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...

[@blancheit4696]

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

[@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.

[@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

[@jfftck]

I was on a team that actually did do Scrum and Agile, we hit are estimates for our epics multiple times in a row. This is video hits the nail on the head.

[@Bizzarq]

Very good and (in my opinion :-) objective analysis! I just do not agree about how it was in the nineties at the beginning of the video. The agile manifesto picked up ideas which were around much longer. I would even claim that many of the ideas are older than the programmable machine.

[@stephenwall9036]

Well said! I can relate to much of what you say 😢

[@CodyEngelCodes]

Sadly it has become the norm ☹️

[@SzaboB33]

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

[@oktomatiko59]

In agile software development, particularly with iterative and incremental processes like Scrum, there's no guarantee that the customer won't discard features or requirements from early iterations, even years down the line. A team might toil in an agile manner for three years only to find out in the third year that the customer has dismissed the features from the first two years as outdated. This problem doesn't have an easy solution, and the risk escalates as the software project progresses. Creating a comprehensive specification, as seen in the waterfall model, at the project's beginning is vital for assessing both its complexity and scope. This assessment plays a significant role in team staffing decisions, quality considerations, role allocation, and prioritizing features. It also aids in budget planning and determining the best approach to software development practices, such as Domain-Driven, UX-Driven, or Data-Driven Design, API First, and various Patterns and Principles etc. The agile approach may lead to hard complications. Expanding the team in an "agile" way might delay the project for years and threaten budget, deadlines and team unity. A situation tied to my initial point. Swiftly changing a team's composition, like transforming 3 junior developers into 10 senior developers, is nearly unfeasible due to hidden complexities and insufficient specifications. Since complexity often multiplies exponentially in a software development cycle, such problems might not surface until later stages. These hidden difficulties in agile processes like Scrum can result in developer burnout, unexpected costs, chaotic code, mass refactoring, loss of motivation and skill, and disgruntled customers. Contrarily, the waterfall model offers an advantage by facilitating the clear identification of the project's complexity, size, staffing needs, budget, and more. For simple projects or scenarios where neither time (deadlines) nor money (budget) is a significant concern, the choice between Agile or Waterfall may seem irrelevant. For instance, in a straightforward "Hello World" application, the methodology is likely of little concern. However, when dealing with real-world constraints, selecting the right methodology becomes a complex issue. While I could enumerate numerous arguments against Agile (Scrum), perhaps that's a discussion for another time. The software industry has just got *#!* up. Agile is brainless planless software development as per definition.

[@BittermanAndy]

Did ChatGPT write this?

[@errrzarrr]

👏🏻

[@vyli1]

I would say that the main counter argument to what you're saying is, that almost always when I have worked with a comprehensive specification created ahead of the time, when it came to actually developing it, always there were parts of the problem that were not specified, because nobody was able to predict that such a situation might need specification. In software, it's not easy to predict things unless you actually start doing them. And then some of these missing points in specification could all lead to problems with planning, budgeting and all those other things you mention can happen in agile environment. Having specification ahead of the time does not solve those problems. Some risk is minimised, but not all of the risk. Also, during development, some variables can even change, that will change your plans drastically. For example the operating system of your platform. It's not possible to plan for a future event that is outside of your control. That's why doing analysis and specification at the start of the project brings in some cost, that can decrease some risk, but it is not easily measurable, that the risks avoided by doing the initial analysis outweigh the cost spent on building the initial specification, which you know in advance will be incomplete and sometimes incorrect (no plan survives encounter with reality unchanged) and therefore needs additional costs for maintaining it. And it is nigh impossible to get any data, that would support the argument, that bearing this cost brings so much benefit, that it's worth it.

[@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.

[@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.

[@reinkarnatsioon]

well the fact is that tons of people are missusing the word agile and executing agile development wrongly period. Loads of companies who say they are doing agile development as its meant to be, are actually doing a weird derivative of the real thing, not like skunk works level agile development

[@disgruntledtoons]

Agile has become an example of magic thinking. Having heard that following agile made everything peachy, managers brough in a bunch of Agile consultants, nodded their heads to everything the consultants said, then did whatever they felt like doing and called what they were doing "Agile".

[@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?

[@spaceenthusiast5696]

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

[@YisraelDovL]

About deadlines. If they are arbitrary, then yes, they are not helpful. If management promised a feature to board of directors, they have no business doing that. But sometimes there are business considerations, that is when you need to be able to fail fast.

[@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.

[@amyheartsyou]

I actually got an ad for an agile course in the middle of this video. 😂😂😂

[@duckyguy1147]

if you go back to agile basics, then the founders themselves will suggest you to do automation adopt CI/CD and DevOps. I used to work in an organisation where they used agile and it sucked. Then I researched online about DevOps and found it to be way more interesting and beautiful. I wish I was a DevOps engineer.

[@secretchefcollective444]

Believe me DevOps is no panacea, and CI/CD is great for some kinds of software but much harder with database work (the bulk of business processes where data is warehoused and business rules are implemented in the database).

[@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

[@josephcox3091]

I disagree with the comment about story pointing. Story pointing is to protect the dev team from business stake holders flood the team with work and constantly changing the goal post. I am currently on a team where story pointing isn't happening and it's a sh*t show. We are constantly switching priorities and what ends up happening is we only ever get little things done, because we have no way of showing the stake holders what our velocity is and what the impacts of changing directions causes.

[@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.

[@Marck1122]

Why is the title not about Scrum or SAFE instead of Agile when the Agile manifesto does not mention those things ?

[@ClaudioBrogliato]

As a developer I fail to see how someone could sell agile to anyone. I do get estimation fails all the time, I'm Italian we have lots of roads going to nowhere cause money ended before we got to finish them. Yet without them how could a client compare offerings from different business? Whom the risk of failure is weighting on? How can we compensate that risk? With waterfall it was mainly on software shops, you could fail not delivering in time or not delivering what the clients expected to receive regardless of the documentation agreed upon. You got tons of litigations (which in Italy last forever... so the risk is entirely on the software shop side again)... etc. etc. With agile I can see either the client getting with "valuable" product that meets their expectation but costed maybe too much and was delivered way later then expected or client not receiving a complete product cause they finished the budget. But what I see most of the time is toxic Scrum turned into iterative micro waterfalls where features agreement are converted into sprints.

[@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.

[@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.

[@declanmcardle]

I like the "This is fine" dog.

[@rossbagley9015]

I have yet to see a big company other than Google that wasn't agile. And I understand that Google has mostly lost its agile mojo. Google's secret sauce was: fuck deadlines. To solve the Features/Quality/Schedule trilemma, Google always chose to sacrifice the schedule. And it was a beautiful thing. But with the arrival of cloud and the expectations of enterprise customers, Google's culture was being pulled to "deadlines are real and we need the whole thing done and we need the quality to be high" and (predictably) quality got brutalized.

[@davidp.7620]

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

[@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.

[@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...

[@purdysanchez]

Agile: x= -y + storyPoints Business people: "Now that's a good graph. I think. I don't even know how any of this works, but the PM tells me that's a good graph"

[@CodyEngelCodes]

"Look at that graph going up and to the right! I love when that happens! Nevermind that the graph is documenting company expenses over time."

[@tobiasnickel3750]

if you split a task into two smaller task, you get twice the time.

[@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.

[@sontodosnarcos]

As a PO, I feel my position is completely useless. The team knows way better than I what is to be done, and there is nothing I can do that can't be done between PM and PDEF. I am only there to create stories after the PM and the PDEF tell me what to put in there, and to speak in sprint reviews and system demos on behalf of the team. The position doesn't create any value whatsoever.

[@424dsfdsfdsfs]

Lol thats why Agile fails. Incompetent people being owners. Ah the old days then product managers were responsible not for some abstract features or CX, but the money P&L generated by their product. They always had to generate ideas what features to add for some 120% profit growth (mandated by their budget), and how to make IT deliver that on time. These days “owners” are just monkeys.

[@seanohara5754]

Sounds like you're the PO in name only? The PM is actually filling that role right? Also what is PDEF? And PM for that matter (product manager, program manager, project manager, etc etc etc)?

[@SaudBako]

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

[@pdavis2207]

As a scrum master and developer, I get the feeling the presenter and many of the commenters have been abused by their companies processes in the past. The problem isn't with Agile, it is with the company and how they failed to train and support their emploees in implementing Agile properly.

[@perrinromney4555]

Your comment about construction may be misguided.. construction is one of the most tightly scheduled industries on the planet. I've worked with superintendents who could write a list of phases on the back of a napkin and tell you to the week when a project was going to be done 3 years down the road (and they were right). Quite impressive actually. My transition from construction management to software has been eye opening having to get used to not knowing when we are going to be done with things.

[@CodyEngelCodes]

I'm not saying every construction project goes over their timeline but quite a few end up taking longer than expected. I think it also depends on the industry as well, for new home construction where they build the same home over and over again that's going to be easier to estimate than a new roadway that could run into who knows how many unforeseen issues once they break ground. Similar to your construction anecdote, there are also software engineers that can estimate when something will be done fairly precisely, but it's not a given.

[@ryanbarker3978]

Construction is tightly scheduled but still variable to change. All sorts of things can cause dates to change, especially in large enterprise or government work.

[@kaidzz]

Agile is good if you experience both of them only sweaty bois thinks it's not. the only thing sucks in agile is relationship meeting like retro

[@schaughtful]

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

[@AnnatarTheMaia]

Processes and documentation are the most important thing. The "Agile" movement assumed that programmers are good or will get good, but good programmers didn't materialize, the software of today is a disaster hacked together by "developers", not by good programmers: very few understand how the underlying hardware works! The third calamity which befell the industry is object-oriented programming: it makes the program unnecessarily complex, extremely error prone, and a nightmare to debug and understand, as well as generating slow, large, wasteful machine code.

[@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.

[@regalternative]

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

[@JustLikeBuildingThings]

Agile hasn't destroyed it, all the management buy in and fluff has. You have folks doing a few-hour scrum master course and suddenly managing teams, having never worked with software in their life. Same deal with Product Owners, exceptionally easy to get a certificate without any grounding in software or actually building products.

[@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???

[@JasonTaylor-po5xc]

I'm going to disagree with you here. I agree that Agile done poorly is a step backwards, but when Agile is done correctly (which requires a lot of discipline), it is a thing of beauty. Additionally, I think folks don't realize that Agile is a toolbox of best practices - not a rigid system. Companies and teams should adopt aspects of Agile that make the most sense for them and disregard the rest. I have worked in places where pair programming wasn't a good fit - for personality or logistics (remote teams) reasons. Also, Documentation isn't optional - it's just a value/priority judgement - focus on working code first, document (within reason) afterwards. Since I focus on writing very readable code, I don't document much of my code unless I have to do something fancy (like RegEx). End-user documentation still need to happen regardless and/or public API endpoints - stuff like that. I'm generally ok with Scrum (I prefer Kanban when possible), but I'm not a fan of SAFe at all - just feels like an ITIL person decided to make Agile appealing to large enterprises and could charge them a crap ton for certification/coaching programs. When I was at Disney, before the world ended, we would start every team doing Agile with sticky notes before any tools were introduced - we even had a few teams decide to stay with sticky notes even when JIRA or similar tools were allowed to be used.

[@CodyEngelCodes]

I think we're on the same page, Agile when done well is extraordinary, it's just something that is almost never done well these days.

[@JasonTaylor-po5xc]

@@CodyEngelCodes I do agree with that. At Disney, it took us a solid 3 years to really do Agile well and even so, we had to stay vigil not to slide back to old habits - at least on my teams.

[@ChrisAthanas]

There are little-a agile principles that can help guide certain projects that are looking for product market fit. But big-A Agile™ practices are just modern wrappers on the tired and business-oriented proven-to-be-wrong-for-any-software-project and need to be taken behind the barn and put out of its misery. You cannot make 9 women pregnant and have a baby in a month. Its simply not possible.

[@JasonTaylor-po5xc]

@@ChrisAthanas Yeah, I'm going to disagree. Just sounds like cowboy devs trying to justify jumping in coding without a plan and not following a process and not letting others know what is going on - which, like it or not, is a career limiting move. Agile isn't about getting there faster, it's about showing value sooner and being adaptable. Yes, there are "wrappers" that try to make Agile "enterprise friendly" like SAFe - which I also strongly disagree with.

[@ChrisAthanas]

@@JasonTaylor-po5xc in business there is risk. Software is one of the riskiest businesses. Looking for guarantees about time in a inherent risky business is a way to lose out to someone who is willing to take the risks and go for big wins

[@tradingisthinking]

you forgot that teams have Architect and Tech leads, they solve these problems.

[@OneAndOnlyMe]

Unrealistic to throw out deadlines. In the business world deadlines are necessary because as programmers we are still part of the business process, and responsible for helping the business to manage and set expectations to investors.

[@CodyEngelCodes]

Deadlines themselves have become an unrealistic tool 🤷‍♂️

[@OneAndOnlyMe]

@@CodyEngelCodes That as may be but deadlines are still needed in business. In my org we negotiate with the business on what features we will deliver and keep to the deadlines, and that sometimes means working longer hours (no extra pay, but a larger year end bonus).

[@stannovacki2406]

manager: "we let you do this agile thing so you could get the job done faster. period." I've yet to see any management team defer to engineering, and I've been in the indsutry 40+ years.

[@CodyEngelCodes]

Management knows best 😉

[@444haluk]

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

[@ScrotoTBaggins]

The whole idea of "stakeholders" is bull. Our livelihoods are at stake, yet we must respond to a cohort trying to drive an infinite growth model that can't survive without us.

[@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.

[@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

[@devcybiko]

I am a HUGE proponent of Agile. Having grown up using waterfall or ad-hock, Agile (and Scrum) was a revolution. The problem that Anti-Agile pundits have is they are looking at their problems with tunnel vision. If you're a product owner or a manager or in the C-Suite you need to know where to spend your money. And that takes planning - either quarterly, yearly, or even more. Agile is not "project management." It was not designed for planning. It was designed to prevent the problems with waterfall - where a product owner had to create all the requirements before a line of code could be written - and then could not change them mid-project - and then got something at the end of a (often) multi-year project that was overcome by events. So, these problems that you claim Agile (Scrum) has "destroyed programming" is click bait. Agile was never designed for planning. It was designed to constantly deliver value and nimbly respond to change. The biggest revolution in software development was to embed the product owner in regular review of their product on a weekly / bi-weekly basis. This one thing changed software development forever. So, if Agile is so terrible, what is the alternative.

[@Skibbi198]

Screwdrivers DESTROYED DIY work. I keep smacking the nails with the handle but the nails don't screw in.

[@devcybiko]

@@Skibbi198 I see what you did there.

[@akseiya]

Agile is awesome, just very rare. As opposed to companies claiming to be agile, which are very common.

[@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.

[@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.

[@islandman9619]

Well, I guess the title is there to attract attention. Agile isn't broken; the organizations using it aren't following the principles properly. Also, Scrum and Safe are just marketing terms (as you elude to), but when used by disciplined orgs, they do work (but it's hard). In order to truly be agile, in addition to understanding and following the process from a business perspective, developers need to write adaptive/agile code and this means understanding principles like open/closed to allow the code to be adapted to changing requirements (extended) as opposed to changing it or throwing it away (though this is often a good idea). You mention writing documentation that might help for debugging - this statement concerns me. Generally speaking, you use unit tests to ensure that your code works and to prevent breaking it later; the use of a debugger is a smell and should not be encouraged. In most cases, developers that have to resort to debuggers either don't know or don't want to write unit tests or are simply writing code poorly (use static code analysis and reduce cyclomatic complexity). There are edge cases, like thread locking and memory issues that might require it, but it should be extremely rare. In general, imperative languages like C#/Java/Python will require more unit tests than functional languages with strong type systems, like F#/OCaml. If you write documentation to help debugging, you're adding to the problem as your documentation will eventually deteriorate to half truths and lies that will hamper further development and debugging. There's a lot more to be said about this, but agile certainly isn't broken; just the people using it. Cheers!

[@MarianneExJohnson]

Meh, all those people with their waterfall/agile dichotomy, as if you must either do the one or the other. How about just figuring out a process that works for *your* team? No process is perfect for every situation. (But of course Agile is never the right answer. If you're having more than one scheduled meeting per week, you're doing it wrong and wasting everyone's time.)

[@oracleoftroy]

In my experience, blaming agile, and especially scrum or other methodologies is often a misdirection. Both the best team and the worst team I've ever been on followed "scrum", the difference was the best team took scrum wholesale and then used the process to change their practices (and ended up changing quite a bit of them), and the worst team looked at scrum's practices, immediately decided that some wouldn't work and never even tried them in the first place. Scrum's practices try to get a certain values, and by at least trying them, the team was able to see what it was going for any why it was good, and find a better way to achieve the same value that worked for their context. The teams that cherry-picked what they liked without knowing what they were passing on were just hellbent on doing what they've always done and calling it 'agile' to please whoever was pushing agile. Agile values changeability, and their entire mindset was fixed in stone. I find it astonishing the number of teams that 'do scrum' yet never actually tried all the recommended practices, but rather just tacked on one or two to what they were already doing and called it 'scrum'. That's the main thing I've seen when hearing about bad experiences with agile, they've predecided not to try a suggested practice and so never learned what value that practice was getting at. They are often right that the practice as described wouldn't work in their context, but by not even trying, they didn't gain insight into a gap in their process and weren't able to adapt something better. When things didn't improve, they blamed 'agile' instead of themselves for being unwilling to even try all the practices. If anything, 'agile' just became a buzzword to apply to what people were already doing rather than entail actual different practices. I think you are right to point to the manifesto and show that most people claiming 'agile' aren't even trying to achieve those values.

[@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.)