Agile Has Destroyed Programming - Here's How To Fix It
Vložit
- čas přidán 13. 07. 2024
- 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 CZcams 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
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?
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).
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
@@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.
@@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."
Exactly, users are the worst people to ask for requirements.
It's waterfall, but every two weeks.
Waterfall is myth, a Strawman created by Agilists.
EXACTLY!!!!!
And without proper UAT
😂😂😂😂
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.
Agile = Micro management
Get offa CZcams and get back to those story points!!!
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
I think Agile started out to eliminate the bureaucracy of the software development process and unfortunately became the bureaucracy or the software development process.
You either die a hero or live long enough to see yourself become the villian
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.
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.
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.
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.
Agile is like a bad movie that management is afraid to walk out of because they've paid for the tickets.
100%
Sunk cost fallacy in other words.
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.
So you have a crap team? Give people like that any methodology and they are going to suck to work with.
@@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.
Do we work at the same company? 😂
@@comediehero maybe we did. I don't work there anymore.😆
I feel bad for you, bad company to work, move away.
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.
Yes! Most companies that employ "Agile" are actually using Waterfall by another name.
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.
@@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.
@@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."
@@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.
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.
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.
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.
"DevOps" reset your machine? You're using the word DevOps wrong.
@@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.
Confucious once asked, how can Agile destroy programming if nobody does Agile correctly 🤔🤔
"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.
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.
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.
Useless managers use it as a shame and blame meeting. It makes me furious.
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.
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.
I refuse to work at any company that implements “agile”
Honest question.... What do you look for in a company that you would work for?
@@randyhale8517 treating sits employees like adults
What process do you prefer?
@@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.
@@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,
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!
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.
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.
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,
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.
As long as the team is given freedom to actually do what works instead of being micromanaged to death
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.
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.
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...
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
www.scrum.org/resources/blog/why-do-we-use-story-points-estimating
@@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."
Truth is, most of these anti-agile videos are just describing problems with waterfall.
My boss: let's choose agile for this project.
Me: I'd rather eat rats.
Office: applause.
And that man's name? Albert Einstein.
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.
Less biz managers involved. Give developers freedom and you will see results.
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
This is brilliant!!! All the right insights!!! Bravo!!! 👍🏻
So how do you build software for new hardware? Like a smart thermostat, a security panel or a car dash?
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 🙄
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.
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.
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.
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.
@@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.
@@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.
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"
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.
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.
@@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.
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.
@@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.
@@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.
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.
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.
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
@@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)
@@errrzarrrFire was the tool to warm the homes and for blacksmiths to make steel moldable.
It's not the fires fault Rome burned down.
I'm Loving the daily uploads. It's a good way to turn my brain on before work.
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.
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.
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?
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.
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.
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.
Yes, I say this when people compare software to construction. Dev work is more like science.
Agile isn't what most companies are doing, they are only calling it Agile while still doing Waterfall.
Agile sucks. Like any religion, it begins with a golden rule, and devolves into The Inquisition.
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.
where did u get the "it's fine" dog peluche?
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.
while there is value in the items on
the right, we value the items on the left more.
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.
Good video, sadly I could not get over the "in a quicker amount of time"
- thankfully it was towards the end at 11:02
As a new software developer, I feel completely demotivated while working with Agile. Everyone except me loves that methodology, but I feel unproductive.
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.
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.
in those context even scrum is no enough. But also in the other context like consumer APIs, etc is even worse...
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.
BLESS YOU for saying what I've contended for a long time: Agile is just creatively repackaged waterfall.
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.
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.
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.
@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.
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.
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.
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
Well said! I can relate to much of what you say 😢
Sadly it has become the norm ☹️
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".
Some people even say, that scrum is not even agile even though most people think of scrum first when agile is mentioned.
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.
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.
Customers don’t want to pay much and they expect you to get it right the first time because you are an expert. It’s the customers that aren‘t agile and being agile within your company doesn‘t solve any problem. The challange you are facing is delivering what was ordered in the most efficient way with as few interactions with the customers as possible. Then when they see what they ordered sell them as many change requests as possible. Agile is not going to help here.
Agile = Micro management and Bureaucracy
It's always the same. Incompetent people do random dumb stuff and conclude from that that Agile is bad.
People who say that probably have experienced a very bad implementation of Agile. Agile is about less bureaucracy.
@@axelberle I don't get why everyone blames Agile when the problem are always people who call their uncooperative behavior and bullying Agile 🤦♂️
@@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.
@@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.
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.
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.
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.
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.
Did ChatGPT write this?
👏🏻
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.
is it me or is the advert algorithm in CZcams getting worse?
I started the video and had 3 of them at the start and then they disrupt the video....too much
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
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
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.
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!
Why is the title not about Scrum or SAFE instead of Agile when the Agile manifesto does not mention those things ?
Story pointing doesn't allow you to talk about complexity in a non-biased way. It just gives the illusion of objectivity
I think Daily is required on Remote jobs, because it is a way for the team to interact and know what each other is doing. If it is kept short and POs don't get pissed if someone could not attend, then its fine.
I find it difficult to understand how a 15 min meeting is such a drag for the team. The issue is that it is being misused as a status update. It was never about the status (which one everybody can check it in Jira for example).
@@Jedimaster36091 tru tru keeping the Jira updated is also a chore though.
@@duramirez so how would the team members coordinate, without a tool like Jira? Say the team has 6 members and the story 30 tasks. It takes literally less than a minute to update the task.
@@Jedimaster36091 I am fully ok with using Jira, I just said it is a chore. Thats all.
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.
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.
So basically, your complaint isn't that agile doesn't work but that nobody really does agile.
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.
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.
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).
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.
every Agile description I see equates SW devel to building a house out of bricks. Software is not bricks and systems aren't houses!
Story points were removed a decade ago.
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.
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.
exactly the same thing here in the company i work
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.
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.
I like the "This is fine" dog.
I hate the story points system. Makes the whole thing feel like a stupid game I don't want to play
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.
I actually got an ad for an agile course in the middle of this video. 😂😂😂
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???
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.
you forgot that teams have Architect and Tech leads, they solve these problems.
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.
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.
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.
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.
Scrum is the scummy way of programming. And your argument is basically agile needs more agile because managers empty it.
Agile is the method by which tech builds blindly. Agile leads to bad and inconsistent documentation practices because of arbitrary documentation requirements.
"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.
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.
But I'm guessing you never get a specific answer as to what the right way is?
I wonder how AI Multi Agents will change the world of software development.. Nvidia wants to change how software is developed..
"nobody has ever done proper agile" they say
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...
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.
Consultants and certifications have destroyed programming and there is nothing you can do about that.
I was never successful at estimating = I won't estimate again.
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.
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.)
Comment: Don't cut the video so aggressively. Silence every now and then is desirable so the viewer can reflect on what you just said.