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
Agile = no built-in mechanism for hitting a deadline with a given feature set. This invites what you call micro-management upon the dev teams because they aren't providing what the business leaders need.
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."
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 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.
I think Agile started out to eliminate the bureaucracy of the software development process and unfortunately became the bureaucracy or the software development process.
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 don't see it that way at all, the cultish "manifesto" is basically against distancing yourself from the stakeholders and is a direct recipe for getting harassed at all times. It is very easy to see why the "Manifesto" (which is supposedly some golden ideal that, if only it was followed, would magically fix everything) gives a direct line to getting harassed, micromanaged, and having a surprise deadline dropped by the stakeholder/manager who is the biggest crybaby. You either have long term waterfall with some unfortunate bugs at the end that might be harder to rectify or, in 99% of cases, you have a situation that devolves into a harassment nightmare work environment for devs. They are mutually exclusive.
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.
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.
Every company says the same thing: who really does pure Agile? Truth is, if you don't give yourself permission to be Agile at every level of your organization, you're really not Agile, you're just waterfall done poorly, and Agile becomes a scapegoat
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 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.
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.
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.
"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.
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.
@@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.
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.
@@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.
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.
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 🙄
The main problem of Agile is it focus on speed. They start writing without any basic previous planning. They don' t take time to test and compare which framework or programing language will best suit for the project. They use for example Django or Python instead of C because development is faster and easier, until they hit a wall as the project grows: performance is terrible, debugging is a nightmare and maintenance is impossible. And there is no plan B. Developers leave half baked implementations to click the task is finished to shut down messages "you have unfinished task this sprint". They don't take time to test and compare different frameworks to decide which best suite. They just start making deliverings without any previous basic design with a wide scope. There is no let's divide the problems into modules, create test benchs to test components individually, there is no documentation to understand the code...
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 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."
@@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,
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.
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.
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"
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...
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.
Scrum adoption is the most frequent problem. Software development is a non linear process where you can scratch your head for days and the solve most problems in few hours, while scrum is a linear process expecting a uniform distribution of work and results, that is not how our mind works. This usually leads to a lot of pressure and, as a consequence, burnouts
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
I think the biggest problem with agile is that technical debt keeps piling up if you keep sprinting and adding new stuff on top of a codebase all the time. After a year or two the software is barely maintainable. You will need one or two devs that only fix technical stuff and refactor.
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.
pointing poker should be during sprint planning. So if junior guy X gets it and he bids 13, then the scrum master or product owner can throw on the brakes and assign it to someone who'd score it a 3. But they dont do it that way. And that implies "the whole team" works on the story, but thats not the case I've seen. Its 1 story per person waterfallesque.
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?
The problem is that Agile was invented by people who didn't have any respect for hitting deadlines. Thus, there is nothing in Agile that allows this honest-to-god need to be satisfied. The micromanaging or whatever is a reaction by the people responsible for delivering a product to know if the software will be made to spec, on time.
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.
@@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.
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
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)
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.
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.
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.
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.
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.
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.
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.
Agile is the method by which tech builds blindly. Agile leads to bad and inconsistent documentation practices because of arbitrary documentation requirements.
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!
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.
The vast majority of software products are neither unique nor ground breaking. Create a user account in a server database. Hash the password. Add in licensing and telemetry. Serve up a page. So many ‘apps’ are just the same UI elements with a new coat of paint. Most re use existing frameworks and libraries, retreading the same ground. We know how long this will take. But management needs their ‘story points’ and ‘velocity’ to put into pretty graphs for their shareholders. PMs need their scrum meetings to justify their salaries and micro manage the people who are actually building the thing.
@@kirishima638 login and registration flows are hardly considered to take more than a fraction of a week, and devs have usually no trouble in estimating the time it'd need, but other features are usually very different than what we've worked previously. Yes, if your company works in a specific niche and uses a base repo (e.g. Restaurant management) you can easily estimate the time it'd take to build the software. Most software projects are unique per team, or have specific gotchas that have to be addressed, thus making estimates impractical and silly.
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.
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.
Story points are not primarily for business people. Firstly, it's for the team itself and protects them from bad managers who want everything done yesterday. Story points help the team to predict in sprint planning, as good as possible, what can be delivered by the end of the sprint. Over time, the team gets better in estimating and this is a constant calibration. Needless to say that this is approximation, this is known and accepted. It's software development we are talking about. Good managers will then be able to translate all of this to managerial decisions. This is fine too because software engineers are a part of a wider group and they need to collaborate within a business. This is what my team is doing for years and I hope everyone interested could see the way we do it, i.e. correctly.
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.
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".
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.
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.
So often, here included, I see devs talking about the failures of Agile when it's them not actually engaging. For example, OP's comments around 4:36 on story pointing amount to him wanting to avoid the (useful) conversation about complexity, and thus just gaming the story pointing process to avoid that. This is not a failure of Agile; it's a failure in team behavior and faith to the valuable parts of the process.
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
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.
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.
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!
Developer Manager: We need NOT to be accountable for software that Doesn't work Software Development Company: I know, let's find someone in the customer organisation who has never written Software or known anything about testing, reliability, scalability, maintainability, cost of change, or interoperability. Developer Manager: How would we be able to persuade them to take accountability? Software Development Company: Get them to believe that the UI is the main thing and that if the UI is 90% complete they should pay and sign off 90% we only lose 10% and we take no responsibility for testing, reliability, scalability, maintainability, cost of change, or interoperability. Developer Manager: What shall we call this? Software development Company: PRODUCT OWNER that will make them feel important
This happens, wherever a good thing is turned into religion / bureaucracy. The original text is very good. But if it's applied without thinking, it fails. Like IBM said: THINK! My personal experience is, that good, intense planning helps every project. The architects (very small team) and stakeholders should frame the concepts and requirements as good as possible. When they are feeling good and secure, the development can start. My experience with both, waterfall and agile was bad, the truth lays in the middle.
I have had positive experience with story points, maybe the only part of agile that's actually been helpful. The idea of story points is that even if you aren't good at knowing how long things take, most programmers can tell whether A is harder or easier than B. So if you do the points and the numbers don't reflect the "easier/harder" estimates then you found a problem. If you get into a situation where people are trying to guess what everyone else will say so you can stop doing story points, then you really have a bad situation.
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.
11:30 Everything you said about deadlines, is wrong 1) Deadlines are correct - they are specified right there in the contract. And so is the expected functionality. And companies that are paying for software actually care that the software works; they are not interested in half-baked software, and they have no desire to test your code. They paid for working code. 2) Non-bullshit companies will not let you deploy code willy-nilly into their production environments. There's a process (sometimes with legal ramifications) and it is slow. Once deployed there, you probably won't have access to it. And the software will likely not be allowed to call home. Your software will be hard to fix when some bug is discovered and you won't be able to stealth fixes in. What the next Agile Methodology will have to include is a mechanism that embraces deadlines. That implies putting real estimates on tasks and holding the dev staff accountable.
I’m a dev and each task is different. You can’t really keep ppl accountable for knowledge work as sometimes a good idea saves days of work and sometimes shitting in the morning solves unsolvable problems. That attitude of rush and sprinting only burns out creative people.
@@JanSnieg like programming is the only creative endeavor on the planet? Dev teams must be held accountable. However, the dates have to be realistic too. You can't 'deploy as quickly as possible' and also expect no problems. That is, the good/fast/cheap triangle is real.
@@tonyennis1787 I used "dev" word to introduce myself and only to give you context of my experience and later on referred to this kind of group of work as "knowledge work" to highlight that it applies to ANY creative work so your rhetorical question "like programming is the only creative endeavor on the planet?" is totally missed. I used to be/am hyper performer due to my adhd hyperfocus on programming and believe me that with your approach you can only have mediocre results, you will burn out outstanding people and the team will become mediocre and passive and they will beat you at your own game of storypoints, deadlines and rush. Hire the right people, give them the autonomy, freedom, trust and purpose and believe me that it will work much better than scaring people with deadlines, estimations, velocity, capacity SPRINTS FASTER FASTER FASTER.
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.
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.
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.
In 11 years around software, I have never - not even once - seen a management release target hit. They always slip 100% of the time. It’s a meme at this point. Even now that we’re trying for smaller projects pumped out on 2-week release cycles, we’re STILL not hitting the targets set from on high or even on medium. And I do think everyone sincerely is trying to be reasonable it’s just that effort and time estimations are very uncertain unless someone invests time to do spike research and de-risk them - but even then it’s uncertain; just less so. I like the idea of saying eff the timed cycles because they’re already meaningless and just release when shit is ready, piece by piece. We’re trying that but they’re still pushing the sacrosanct “if it’s not a two-week cadence it can’t be Agile”. It’s all just so stupid.
Never used agile in the last 13 years or so. My customers don't bother with such terms, me neither. They need results and what I do seems to be called waterfall
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.
is it me or is the advert algorithm in RUclips getting worse? I started the video and had 3 of them at the start and then they disrupt the video....too much
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.
One cannot build a skyscraper without a solid foundation. You cannot build good software without a solid foundation. The problem is that more often than not Agile skips the foundation part and thinks one can start building the walls...
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.
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.
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.
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).
@@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.
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.
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.
"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.
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.
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 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.
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
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???
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.
![Baby Kia - GLOVES & DRACS (BLACK AF1s) [Official Music Video]](http://i.ytimg.com/vi/ajm8LeB0qQk/mqdefault.jpg)
Agile = Micro management
Get offa RUclips 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
Agile = no built-in mechanism for hitting a deadline with a given feature set. This invites what you call micro-management upon the dev teams because they aren't providing what the business leaders need.
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.
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.
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 don't see it that way at all, the cultish "manifesto" is basically against distancing yourself from the stakeholders and is a direct recipe for getting harassed at all times. It is very easy to see why the "Manifesto" (which is supposedly some golden ideal that, if only it was followed, would magically fix everything) gives a direct line to getting harassed, micromanaged, and having a surprise deadline dropped by the stakeholder/manager who is the biggest crybaby. You either have long term waterfall with some unfortunate bugs at the end that might be harder to rectify or, in 99% of cases, you have a situation that devolves into a harassment nightmare work environment for devs. They are mutually exclusive.
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.
@@yewknight who are these customers that like half-baked software? Certainly not customers who are paying for software.
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.
Every company says the same thing: who really does pure Agile?
Truth is, if you don't give yourself permission to be Agile at every level of your organization, you're really not Agile, you're just waterfall done poorly, and Agile becomes a scapegoat
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 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.
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.
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.
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.
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.
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.
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
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 🙄
The main problem of Agile is it focus on speed. They start writing without any basic previous planning. They don' t take time to test and compare which framework or programing language will best suit for the project. They use for example Django or Python instead of C because development is faster and easier, until they hit a wall as the project grows: performance is terrible, debugging is a nightmare and maintenance is impossible. And there is no plan B.
Developers leave half baked implementations to click the task is finished to shut down messages "you have unfinished task this sprint".
They don't take time to test and compare different frameworks to decide which best suite. They just start making deliverings without any previous basic design with a wide scope. There is no let's divide the problems into modules, create test benchs to test components individually, there is no documentation to understand the code...
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.
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,
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.
@@mats66 we are past agile called post agile. Sometimes it’s doing stuff while in meetings aka “mobbing” lol😂
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"
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...
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.
Scrum adoption is the most frequent problem. Software development is a non linear process where you can scratch your head for days and the solve most problems in few hours, while scrum is a linear process expecting a uniform distribution of work and results, that is not how our mind works. This usually leads to a lot of pressure and, as a consequence, burnouts
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
I think the biggest problem with agile is that technical debt keeps piling up if you keep sprinting and adding new stuff on top of a codebase all the time. After a year or two the software is barely maintainable. You will need one or two devs that only fix technical stuff and refactor.
My boss: let's choose agile for this project.
Me: I'd rather eat rats.
Office: applause.
And that man's name? Albert Einstein.
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.
pointing poker should be during sprint planning. So if junior guy X gets it and he bids 13, then the scrum master or product owner can throw on the brakes and assign it to someone who'd score it a 3. But they dont do it that way. And that implies "the whole team" works on the story, but thats not the case I've seen. Its 1 story per person waterfallesque.
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?
The problem is that Agile was invented by people who didn't have any respect for hitting deadlines. Thus, there is nothing in Agile that allows this honest-to-god need to be satisfied. The micromanaging or whatever is a reaction by the people responsible for delivering a product to know if the software will be made to spec, on time.
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.
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
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.
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.
@@MorningNapalm we are also slowing migrating to kanban. It seems to be more realistic.
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.
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.
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.
Yes, if your team cannot commit to a deadline then they are useless. That'll get a manager fired.
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.
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.
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.
Agile is the method by which tech builds blindly. Agile leads to bad and inconsistent documentation practices because of arbitrary documentation requirements.
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!
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.
The vast majority of software products are neither unique nor ground breaking.
Create a user account in a server database. Hash the password. Add in licensing and telemetry. Serve up a page.
So many ‘apps’ are just the same UI elements with a new coat of paint. Most re use existing frameworks and libraries, retreading the same ground.
We know how long this will take. But management needs their ‘story points’ and ‘velocity’ to put into pretty graphs for their shareholders. PMs need their scrum meetings to justify their salaries and micro manage the people who are actually building the thing.
@@kirishima638 login and registration flows are hardly considered to take more than a fraction of a week, and devs have usually no trouble in estimating the time it'd need, but other features are usually very different than what we've worked previously. Yes, if your company works in a specific niche and uses a base repo (e.g. Restaurant management) you can easily estimate the time it'd take to build the software. Most software projects are unique per team, or have specific gotchas that have to be addressed, thus making estimates impractical and silly.
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.
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.
Story points are not primarily for business people. Firstly, it's for the team itself and protects them from bad managers who want everything done yesterday. Story points help the team to predict in sprint planning, as good as possible, what can be delivered by the end of the sprint. Over time, the team gets better in estimating and this is a constant calibration. Needless to say that this is approximation, this is known and accepted. It's software development we are talking about. Good managers will then be able to translate all of this to managerial decisions. This is fine too because software engineers are a part of a wider group and they need to collaborate within a business. This is what my team is doing for years and I hope everyone interested could see the way we do it, i.e. correctly.
BLESS YOU for saying what I've contended for a long time: Agile is just creatively repackaged waterfall.
Agile isn't what most companies are doing, they are only calling it Agile while still doing Waterfall.
Consultants and certifications have destroyed programming and there is nothing you can do about that.
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.
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".
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?
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.
So often, here included, I see devs talking about the failures of Agile when it's them not actually engaging. For example, OP's comments around 4:36 on story pointing amount to him wanting to avoid the (useful) conversation about complexity, and thus just gaming the story pointing process to avoid that. This is not a failure of Agile; it's a failure in team behavior and faith to the valuable parts of the process.
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
I hate the story points system. Makes the whole thing feel like a stupid game I don't want to play
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.
every Agile description I see equates SW devel to building a house out of bricks. Software is not bricks and systems aren't houses!
Some people even say, that scrum is not even agile even though most people think of scrum first when agile is mentioned.
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!
while there is value in the items on
the right, we value the items on the left more.
Developer Manager: We need NOT to be accountable for software that Doesn't work
Software Development Company: I know, let's find someone in the customer organisation who has never written Software or known anything about testing, reliability, scalability, maintainability, cost of change, or interoperability.
Developer Manager: How would we be able to persuade them to take accountability?
Software Development Company: Get them to believe that the UI is the main thing and that if the UI is 90% complete they should pay and sign off 90% we only lose 10% and we take no responsibility for testing, reliability, scalability, maintainability, cost of change, or interoperability.
Developer Manager: What shall we call this?
Software development Company: PRODUCT OWNER that will make them feel important
This happens, wherever a good thing is turned into religion / bureaucracy. The original text is very good. But if it's applied without thinking, it fails. Like IBM said: THINK! My personal experience is, that good, intense planning helps every project. The architects (very small team) and stakeholders should frame the concepts and requirements as good as possible. When they are feeling good and secure, the development can start. My experience with both, waterfall and agile was bad, the truth lays in the middle.
I have had positive experience with story points, maybe the only part of agile that's actually been helpful.
The idea of story points is that even if you aren't good at knowing how long things take, most programmers can tell whether A is harder or easier than B. So if you do the points and the numbers don't reflect the "easier/harder" estimates then you found a problem.
If you get into a situation where people are trying to guess what everyone else will say so you can stop doing story points, then you really have a bad situation.
"How modern day software development destroyed agile"
Good video, sadly I could not get over the "in a quicker amount of time"
- thankfully it was towards the end at 11:02
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.
Agile is awesome, just very rare. As opposed to companies claiming to be agile, which are very common.
11:30 Everything you said about deadlines, is wrong
1) Deadlines are correct - they are specified right there in the contract. And so is the expected functionality. And companies that are paying for software actually care that the software works; they are not interested in half-baked software, and they have no desire to test your code. They paid for working code.
2) Non-bullshit companies will not let you deploy code willy-nilly into their production environments. There's a process (sometimes with legal ramifications) and it is slow. Once deployed there, you probably won't have access to it. And the software will likely not be allowed to call home. Your software will be hard to fix when some bug is discovered and you won't be able to stealth fixes in.
What the next Agile Methodology will have to include is a mechanism that embraces deadlines. That implies putting real estimates on tasks and holding the dev staff accountable.
I’m a dev and each task is different. You can’t really keep ppl accountable for knowledge work as sometimes a good idea saves days of work and sometimes shitting in the morning solves unsolvable problems.
That attitude of rush and sprinting only burns out creative people.
@@JanSnieg like programming is the only creative endeavor on the planet? Dev teams must be held accountable. However, the dates have to be realistic too. You can't 'deploy as quickly as possible' and also expect no problems. That is, the good/fast/cheap triangle is real.
@@tonyennis1787 I used "dev" word to introduce myself and only to give you context of my experience and later on referred to this kind of group of work as "knowledge work" to highlight that it applies to ANY creative work so your rhetorical question "like programming is the only creative endeavor on the planet?" is totally missed.
I used to be/am hyper performer due to my adhd hyperfocus on programming and believe me that with your approach you can only have mediocre results, you will burn out outstanding people and the team will become mediocre and passive and they will beat you at your own game of storypoints, deadlines and rush.
Hire the right people, give them the autonomy, freedom, trust and purpose and believe me that it will work much better than scaring people with deadlines, estimations, velocity, capacity SPRINTS FASTER FASTER FASTER.
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.
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.
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.
In 11 years around software, I have never - not even once - seen a management release target hit. They always slip 100% of the time. It’s a meme at this point. Even now that we’re trying for smaller projects pumped out on 2-week release cycles, we’re STILL not hitting the targets set from on high or even on medium. And I do think everyone sincerely is trying to be reasonable it’s just that effort and time estimations are very uncertain unless someone invests time to do spike research and de-risk them - but even then it’s uncertain; just less so. I like the idea of saying eff the timed cycles because they’re already meaningless and just release when shit is ready, piece by piece. We’re trying that but they’re still pushing the sacrosanct “if it’s not a two-week cadence it can’t be Agile”. It’s all just so stupid.
Never used agile in the last 13 years or so. My customers don't bother with such terms, me neither. They need results and what I do seems to be called waterfall
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.
is it me or is the advert algorithm in RUclips getting worse?
I started the video and had 3 of them at the start and then they disrupt the video....too much
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.
Story pointing doesn't allow you to talk about complexity in a non-biased way. It just gives the illusion of objectivity
I am actually moving away from development to other fields in IT only because of this Agile bs. It it like a cult or a religion...pure madness
One cannot build a skyscraper without a solid foundation. You cannot build good software without a solid foundation. The problem is that more often than not Agile skips the foundation part and thinks one can start building the walls...
So how do you build software for new hardware? Like a smart thermostat, a security panel or a car dash?
More often its like building a house without solid foundation.... we will figure it out in the next sprint.
Agile is the reason why all our new software come out buggy and creativity from big companies is dead
Why is the title not about Scrum or SAFE instead of Agile when the Agile manifesto does not mention those things ?
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.
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.
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.
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.
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.
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.
if you split a task into two smaller task, you get twice the time.
This is brilliant!!! All the right insights!!! Bravo!!! 👍🏻
Story pointing is a huge waste of time
"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.
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.
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 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.
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
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???
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.
Management knows best 😉