02:33 the 3rd step "adapt" always fails, because project managers think "adapt" means "don't refactor, keep stacking prototypes until the whole thing breaks and suddenly we are 3 years over deadline"
this is why you should stay few unpaid hours every week here and there without telling anyone in order to refactor the code . works like a charm . think ahead , expect that software will always grow
@@fallonsky_ I thank you for your comment. Where do I start. It would be sad if I based my self-worth on obfuscated code I maintain for the company I don’t like working for. Perhaps I would like to believe that I have the ambition to co-author communication libraries for, I don’t know, unmanned aerial vehicles, things that could potentially fall on people’s heads. Maybe at some point I can finish my work after just 2 hours because I thought about doors where I was told to build a wall and then tear it down. And I write these things despite the fact that once I lost my job because I delivered not a proof of concept but a working prototype. I know the pain when they take away your child :( I’ve seen what hell looks like, I’ve seen code written in such a hellish and desperate way, MVC framework impl without ‘M’ or ‘C’, random amounts of empty newlines in one file sometimes 5 sometimes 30, ‘pure evils’ like there was no tomorrow. And yes, I’ve also seen how good reputation went nowhere, but more importantly I’ve also seen how bad spreads throughout the entire business domain. I also believe in afterlife and that G.O.D himelf will ask me to help write him an Angel CMS . Blessings!!
Most companies say they're agile while practicing hardcore Watergile, the worst-of-both "let's be flexible but scope creative work items down to the exact number of hours required and use those 'estimates' as deadlines"
This describes my working environment perfectly. I put down 1-2 weeks to get a minimum functionality feature with high uncertainty, and then my PM drills me on why we don't have it completed by that milestone.
@@shimokitazawa1217 I've met very few project managers in my few years in enterprise dev... they're nearly all budget managers merely using different words to do budget management. I have had the pleasure of working with true project managers too, it was amazing. To them the timeline was one of many things to attend to; they fostered a great environment, helped clarify misunderstandings, made sure the tech leads had autonomy and basically worked to maximize the amount of dev time we could do per day - which is kind of the only way to maximize velocity if you think about it. Yeah the rest just measure and project time because it's literally only a proxy for cost to them.
@@shimokitazawa1217During story refinement, you give a reasonable estimate and they make you reduce it, and then when there is carryover, you get blamed for the low points estimate you didn't want in the first place. Constant sprints mean never being able to plan in a day or two off without falling behind. Sprinting is supposed to have tests in between, but it is being run like an endurance race. It burns people out.
When I first read the agile manifesto, I was like, "okay cool. Reasonable." Then I got assigned my first SAFE story and took an "agile" training at work and I was like "what in the flying fuck is this trash? This isn't what that manifesto was about at all!"
Manifestos and reality have rarely been effective when combined. Cases in point - the Communist Manifesto, the Anarchist Manifesto, the Unabomber's Manifesto, Mein Kampf - The Agile Manifesto is just the latest in a long line of high ideals meeting the brute disdain of reality. Basically, reality has an anti-manifesto bias.
There's a lot of assumptions here. But one of the big ones to point out is that not every organisation has great engineers. We have to assume the average. That's not just coding skill, that's problem solving, communicating, working as a team, the full shebang! The type of engineers that can just be given a business problem, find a solution, go away and build a prototype, in an iteration and then communicate with stakeholders in a meaningful way to elicit feedback for the next iteration is vanishingly rare I'd argue.
Proper Scrum pushes decisions to the particular participants that are in the best possible position to make decisions. Engineers shouldn’t be working out business goals, they should be deciding on how to technically implement tightly defined goals, guiding management away from difficult nice to haves in favor of practical must haves.
I worked in waterfall for like 8 years. Clear requirements are great if *and only if* they're correct and don't get changed halfway through. Problem is, the moment we got to a working prototype, every stakeholder suddenly has a bunch of new opinions about their requirements, and what you've got written down suddenly stops mattering. The joy of agile, at least for me, was *getting everyone to that point faster* so we're not scrambling to change everything at the last minute.
@@JP-hr3xqonly for small enterprise. If you have twenty teams working toward a common goal, it works very well! It's almost like, it solves specific problems and if you don't have those problems, then you don't need to use this tool(SAFe)...
Agile Manifesto: "don't believe in Methodolgy(TM)", aka "Management, get out of my face!" Management: "our lengthy evaluation of the Agile Methodology revealed its insurmountable weaknesses."
And meeting time went up 420.69% while meaningful conversations between colleagues that would've finished the milestones faster and better decreased by 38.6%.
And then it probably doesn't matter if you do agile, waterfall or cave carvings. Maybe people underestimate how hard really well done requirements engineering is.
@@alxk3995On the contrary it really matters a lot. compare a waterfall project where you create the wrong specifications and thus the wrong software with a an agile project where you iterate until you get it right.
Yes, that is either over-designed requirement where business for some reason describes exact button locations and back-end architecture, but still can't spell out what is actual problem they are trying to resolve, or highest possible lever of requirements 'idk, add billing or something' with "yes" answers to "A or B?" questions from engineers.
@@smmasongt Business, Logical, Physical. And all the facets ^^ So, yes, 99% of people can't write proper requirements. Who can even conduct a business interview or even know it is a thing 😂
Ya know, I wonder if a lot of this isn’t a consequence from so many guys in the past just going out and “writing something” and then bringing it back to their boss. A lot of tools and programs I’ve used throughout the years were the result of 1 or 2 guys just….solving the problem on their own. But…you’re not allowed to do that anymore 😂❤
We were doing something similar in school, get the spec/features, discuss the UI or batch processing, the output and results, basically ask what's needed. Then create the software, check it with the customer, adjust as needed, and release. Repeat and rinse the last part for bug fixes and new features, I think that's what you refer to as Agile, but you have defined a ridged way people interact. This was over 40 years ago. How you create something, release it, then go back and improve it periodically hasn't really changed, except now management want many layers of controls and ridged, inflexible processes which damage the natural human creativity and interactions. It's extreme micro-management.
11:06 waterfall mentioned! If you Google "waterfall paper" and go beyond page 2, you'll discover, that the paper discusses, that you need a prototype phase and feedback loops, that could trigger changes in spec or implementation :D
Funny thing is Prime roughly laid in his proposal out in his way how Scrum is SUPPOSED to work . Daily meeting are only meant to be 10 to 20 minutes a day. If you have something important you talk 1:1 with the team manager after this . The big retrospective is every 2-4 weeks where you adapt and set the next sprint.
Agile is impossible to disprove because it's not a fully fleshed out methodology. Every time you implement Agile and fail you can be told "you've fleshed it out wrong".
Watching Prime's videos continually brings home how diverse the software industry is in terms of the types of developers/engineers, organisations, sub-industries, and work environments. Hearing Prime talk about how he likes requirements gathering is *very* different to how I've had to do it over the last 2 and a half decades. Not to say either of us is right or wrong - it's just a reflection that we work in different worlds and we can't really generalise about software development/engineering as a whole.
The reason why Agile became some popular wasn't productivity, or efficiency. It's because it optimizes a managers ability to feel busy while minimizing the amount of mental labor that goes into their job. Good management exists out of 3 things; honest, clear and consistent communication, foresight and restraint. With Scrum they can just ignore those, overload the communication factor, abandon foresight to be "agile" and abandon restraint because hey, scope creep isn't a bug, its a feature in the average Scrum interpretation.
I guess really it's partly a question of what "failure" is defined as: - Failure to meet a deadline - Putting out buggy software that's just not usable to the task it's designed for - Continuing increase in time it takes to add new features, as the code gets less and less maintainable.
PM wants you to add 4 more features this sprint so that he can look good in front of the CEO. You can refactor and write these tests later in your free time.
To me failed project is one that ends up either not delivering the feature (probably happens way more than people think it does) or one where the feature ends up having to be reworked after a significant engineering effort has been put into it.
Or is failure putting out software that works but doesn't help the organisation achieve anything it really cares about. If it does the task it's designed for but it turns out that that isn't actually a useful task that's also a failure.
If you don't define the success and fail state and don't compare the result to other methodologies, the "65% of agile projects are not done in time" is just some sentence that sounds astute but bears almost no meaning. We can guess what they count as a failure all we want. Doesn't increase the value of this "study". 🤷♂️
Not promoting Agile, but still, it will be a counter-rant: The problem with agile methods is that 99.99% of the time, companies need to be thinking in terms of a culture change. Agile is sold to management as a product. Use SCRUM, and everything will be great... Zero senior management commitment behind it, zero further investment behind it after the first 1 year (when they celebrate a successful agile transformation). If something needs to be fixed, it has not been improved. In essence, agile transformations are introduced in a waterfall. No proper foundation is laid (at the level of development processes and tools) to build on (e.g., XP). In many places, even the transformation itself consists of introducing Jira and then poking a stick and saying "come on do something". Like buying the Figma license but not hiring a UI/UX designer because the tool itself will do it. If anyone is serious about this they should understand at senior management level how existing processes work and where and how they could be improved. Once that is in place, then a Lean / Agile mindset can be fitted to it and continually improve them...
"If companies just were to change everything they do, Agile would work!" Honestly, I've heard that SO often, and I've NEVER seen "Agile" work. Wherever I go, I just remove it (I'm in the position), and suddenly everything becomes much quicker and better. And no, removing Agile does not mean you do waterfall. You just get rid of all the meetings, estimates and bullshit bingo.
@@3borsresistance551 so you're removing bad practices and processes around agile and it became viable? If so, that's exactly what I was trying to suggest. Or at least emphasize that it is the company's misconception that is causing bloated insufficient processes and workflows.
@@3borsresistance551 What I find is that agile works fine but SAFE, scrumm, etc. don't. I also find that sprints don't make any actual sense. I do believe in CI/CD, unit testing, mob coding, working meetings where you actually code with the people that need to be involved.
I am certain that this is the micromanaging style of Agile, as I had worked on a team that competed many epics with very few hot fixes. But I have had the same micromanaged style at most companies before and since, and those end up having many hot fixes - many were critical, as the testing environments are not very reliable as being a representation of real data. The problem isn’t Agile, it’s how management takes it over and turns it into a monster that I would believe does reduce productivity. When requirements are collected at the beginning, it is clearly just a waterfall process and adding stand-ups isn’t necessary as it won’t improve performance and in fact is an anchor. Agile should be you start with a high level view of the epic, then you have the developers turn that into features and then, when the demo is given, you find out some of the smaller details and create stories to add those. This will get the developers into a process of doing what they do best, CODING! Anything that reduces developers doing administrative tasks is key to success.
This might be covered later in the video, but whenever I see a headline like this in a study, I start to worry, because there is a built in assumption here that all projects are equal. By definition, clearly defined and documented projects are more likely to proceed because they are normally backed by stable companies or governments because those are the people who make tight specifications. Meanwhile agile is favoured by start ups and enterprises which are much less clearly defined and more open ended, more subject to the whims of investors, and as everyone knows, these companies are faaaaar more likely to fail. Any study which doesn’t control for these factors is already on shaky ground
This is actually the fundamental problem with all the “agile” methodologies. They fail to realise programmers are people too and invariably you have a bunch of lazy, unproductive people in any given team.
My first job out of university the programmers were the adults. They brought in a coke snorting consultant to teach us "teams" and we ran the team ourself. We reported directly to 2 VPs. The project was successful. We did have a subject matter expert in the team as well. I would 100% always do that if it was up to me.
I found that the daily as a format is not very useful for that. Very inexperienced people need, in my experience, closer and more intense guidance. More like a 1h+ one-to-one every other day.
@@carstenbohme8813what do you do if you’re a junior/bentry level (2 years in this role incl internship) and I’m very independent and often doing a lot of talking during meetings etc and I feel like I’m not getting the core coding skills development that I need as a entry level
Do you have junior devs that actually know how to code? I'm in a strange predicament where my junior devs (which comprise half the team) literally do not know how to code. What the hell do I even do? I've already told them to utilize the resources available to them in the form of beginner courses on Udemy for example. What works best for them is 1 on 1 sessions where there's pressure to perform. In a daily standup, there's lots of people so not all the eyes are going to be on them. 1 on 1's are more personal, and there's pressure since it's real-time being watched of coding. (of which I wish actually fucking took place. I'm not kidding they genuinely don't know how to write even a single line of valid code, nor pseudocode.)
Projects with clear requirements succeed more often because they have a defined scope. Scope creep kills more projects (of any kind) than anything else. Without a clearly defined scope the project goal posts are constantly moving, and that makes it easy to get into a state of endless cycling. It's like playing Civilization, except instead of "just one more turn" it's "just one more sprint". And at some point the project grows out of control, becomes tedious and boring, becomes a constant effort of refactoring and redesigning to facilitate the new position of the goal posts, people burn out, budgets explode, and then you have a failed project. The ONE JOB of a project manager should be to control scope creep, because engineers fucking LOVE to expand the scope. Good PMs spend most of their time saying "No, we don't need that."
@@BittermanAndy Can't explain without doxxing, but the code was able to be made off of a parallel set of reqs, and we're cleaning up the baselines right now.
About 3:05 on daily stand-ups. I agree with your point that one day is typically not much to get a lot done. However, in a team of any reasonable size, it's pretty likely someone (else) has run into something that they're struggling with. Sometimes signalling that struggle is enough, sometimes it means this person might need some help. A daily stand-up is an ideal moment to share this. Yes, this person can ask for help sooner instead of waiting for the stand-up (and this certainly is a valid thing to do), but: - it's (another) interruption of the other person's activities/focus - asking for help too soon instead of trying to solve the issue (or digging deeper into it) is counter-productive Even if the issue was resolved between 2 stand-ups, its still reasonable to mention it during the stand-up. After all, too many of these struggles might indicate deeper underlying issues and could have an impact on projected deliveries. TL;DR: your point on daily stand-ups is only valid from a self-centred point of view
All the ceremony is to give visible value to middle managers that don’t directly have an impact on delivering value to the customers. They can’t climb the ladder and justify raises without showing impact. Introduce change for change sake. Look at all our process.
Regarding overburdened processes-I did implement a similar thing across my teams as I do have quite a bit of autonomy, but the upper management still wants sprint reports, burndown charts and similar nonsense so I have a small guestimator that kind of repackages what's happening in the team back into more palatable format for those who clearly have no business running a tech company, yet they kept failing upwards until they landed their cushy C level positions in my org...
If only we had an agile system instead of a glorified cyclic waterfall, aka a spiral model to work under. I have yet to see the principle of iteration actually taking place more than once is a very long while.
Agile isn’t the problem: its bastardisation is the problem. Management doesn’t understand that velocity is supposed to be constant, and the idea is that this, along with velocity increase where possible, brings about better predictability and quality.
We've collectively been doing it for 20+ years. If people still don't understand it, maybe it's too hard to understand. If people are still doing it wrong, maybe it's too hard to do right. If it's not helping, it's not useful.
No, the problem is that software engineering is much closer to research than to working on a factory line, but managers can't stop trying to make it the latter.
In our org we started with daily standups that lasted 15 mins to half an hour at max. Slowly and steadily the duration started increasing and now it can easily go up to an hour and a half to two hours long
In all seriousness, I think agile methods is amazing for highly dysfunctional teams. When the stakeholders are out of their minds, the devs hate the business people and/or don’t care about the business needs. Then it has a better chance to work. If your team has good communication usually it’s useless to be so formal
I think it's really important to point out that failure can be a GOOD thing. Take for example the case where the business spends a few hours trying to determine whether it's worth spending up to or more than 40 hours of dev time (and that's just for one dev) on some project or feature. If the business knows they won't get a return on investment on that time, then the project is not worth doing and therefore the project has failed successfully xdd
Agree. It's actually part of the Agile manifesto "maximizing the amount of work *not* done is crucial". One of the less quoted parts of the manifesto and one of the most ignored
Imagine you do a thing that works well, then someone else does something different that doesn't work and calls it the same thing as yours before ranting about how bad your thing is. Wouldn't that be annoying?
@@Reashu Probably just means that - hear me out, this is crazy - Agile doesn't work... for everything. (Because it never claimed to and was never intended to. But people are still using it for everything anyway, and honestly at some point that comes down to the Agile industry pretending it can).
@@BittermanAndy I do think "it" (as in putting the team before the process, the software before the documentation, feedback before assumptions, etc.) can work "for everything", obviously with accommodations for regulatory compliance. But what the agile industry sells is something completely different.
@@Reashu sure, if you look at what you're trying to achieve, and who you're trying to achieve it with, and the resources, budget, time etc. you've got, and you have the experience to know how to do it, and then you just do it, then yes, that will work for everything. It's nearly tautological. But then that thing you're doing is, by definition, different to what anyone else in the world is doing, so no need to get upset when they rant about how bad Agile is because they're not ranting about "your thing". No-one else in the world is doing your thing. Also: by definition, your thing is useless for anyone else to learn from. It's not a process. It's you, figuring out your thing, which is unique to you and your situation at this time. Nobody else can gain a thing from it, except to look at what you've got and hope you're experienced enough to know what to do to get to where you need to be. Which will also work, if they are, but will be different to what you did.
Agile is fine. But you can all go implement waterfall and let me know how it all went in 6 months. Also 9:55 the problem with prototypes is that bosses refuse to throw them away and end up being the foundation of your project.
The popular methodologies will have a high chance of producing redundant prototypes that miss the project deadline by many months. Tell me one successful methodology other than "Talk clear, quickly, and frequently" that made the project succeed most frequently...
@@ErazerPT Except that people turned agile into JIRA and confusing, pointless meetings that make management think they've contributed something when they can just collaborate like normal people solving everyday problems.
@@SimGunther Management types appropriated Agile. But they only got away because we let them. And us lambasting Agile because of something that is NOT Agile helps no one. What we need to do is to simply say "This is NOT Agile, this is trash" every time they try and pass some crap like SCRUM as Agile. And yes, management hates real Agile because they can't plop it down in some chart, but that just means we (devs) need to keep pushing them out of our "space". Their usefulness is in keeping track of things and their progress and facilitating any roadblocks et all. NOT in telling us how to do our work. Because... how would they know?
The easiest way to build a project in my point of view is to write the skeleton result first. See what exactly your application will be. Then start coding and find the solutions that fill this skeleton for you. For example, I want my app to be a console calculator. skeleton result in human words: read a string from a user, process this string and come up with an answer, and show the result to the user. skeleton result in code: string expression = readline() result = calculate(expression) print(result) This way you can speed up your coding time and not wasting lots of time in planing and documentation.
I've been writing software for living for 20+ years and I feel that hardest part is to get decision makers to clearly defined what's "good enough" for release. It seems to change randomly at least weekly.
Daily standups works fine in my team. But we focus on discussing incidents, bring up blockers, confirm what is prio to work on next etc. Max 15 minutes and we work on many parallell projects, not one long...
Waterfall, before Agile even began, was seen to have a 70% failure rate. So, are we saying that Agile is 70x2.68% failing? Like 187.6% of Agile projects fail now? Seriously? How do you even do that? Do all Agile projects fail but not only that: the failure spreads to other non-agile projects in a kind of Domino Theory scenario, like rot spreading through the entire office? This is ridiculous.
Re: Survey statistics, you do not necessarily NEED a large sample size- the key is if the effect measured is large enough, it can be statistically valid. I worked on a project with a relatively small user base (about 6k DAU), we made a small change (adding a button), that increased the usage of a feature by literally 1,000% overnight. Was that change statistically invalid because there weren't 10 million users in the sample? Definitely not, because the effect was large relative to the usual usage pattern where day to to day variation might be 5-10%. Even smaller studies with significant effects can be seen in medical studies where n < 20 is not unheard of, especially for clinical stage oncology drugs. If a drug causes a 100% remission compared to the control then that is a very statistically significant event. A n=600 sample size of engineers as long as it is distributed decently and the change from the baseline is large enough then it CAN indeed be statistically valid.
If your system for management defines failure criteria in more definite terms than success criteria, it will produce more measurable failures. Agil is all about measuring failure
As a Scrum Master / Delivery Manager of nearly 10 years. I both agree and disagree. I agree that a lot of Agile is done poorly, with ridiculous amounts of waste. But what I take problems with is, what's their definition of "Succeeded". It got finished on time and on budget? Sure. That could be the metric. But did it then actually provide any value and solve the problem that they set out to solve? That's been my biggest gripe with being in that role for so long, is it's not about how much value the team is delivering and it's always about "Are they delivering enough, fast enough". Could be delivering lots that ultimately does nothing, but that doesn't matter to upper management -.-
People get so locked in to getting stuff done on time that they don't ask this. I've never been able to find it again, but I remember seeing one study (I think Microsoft) that found two-thirds of features deployed in a period had either no benefit or were detrimental to the user experience. How much development time was that that got flushed down the drain doing things that didn't need to be done?
Study proves what we've all known to be true for years. Feels good to finally have a study to quote from now when asking why we are still in the meeting.
As a developer of 20 years who has worked in agile environments for almost as long, I can guarantee this is true. Agile is a way of not addressing true organisational issues and delaying true organisational development. It lets everyone stay stupid and focus on their little corner without everything blowing up. No wider intelligence is needed, which grand corporate hierarchies love.
I had this playing while I was cooking breakfast and I looked back at the screen at 15:00 and realized why he was using a bunch of weird specific names…
Agile is like building the go kart as you are rolling down the hill. Then when you reach the bottom, you realize there is another hill in front of you.
5:33 I’m less concerned about the number of participants than I am about the insanely short 5 day duration in an industry notorious for almost every organisation and developer doing things their own way. As you say, it reeks of just being a subjective poll of opinions. I’d also love to know how they controlled for different: - business sizes - industries - tech platforms - quality controls - user bases - platform architectures
I’m in this project management class now, we are going over scrum. I was excited after learning the basics of agile. ‘People over process’ etc. Then we got to the scrum and it went down hill from there. I was just reading through the agile stuff and it just didn’t feel right. I think I’m gonna be failing this part.
4:30 I think the more interesting question would have been "for the projects that had clear requirements documented before the development started, how many actually matched the final end user needs?" - I would guess many waterfall projects did actually implement things as designed but I don't believe majority of those projects actually matched the user needs.
I wasn't able to watch all this video to the end, but my take away was that this guy conflated "agile" with a process such as "scrum" when agile is not a process .. it's just a set of values. Agile does not stipulate a process. SAFE is rightly described as "shity agile for enterprises" .. in many cases Srum is the same .. a load of BS that some folks made up to sell training etc and people bought in the expectation that it would make them "agile" and allthis agile stuff would be more palatable to upper management. Agile is not a process!!! Beware of anyone selling you agile in a box .. it's a con !!
"agile" imbeds layers of "management" into the development process (like a cancer), destroying any productivity while consuming 60-80% work time with meetings.
it's crazy thinking 3 weeks is a better feedback frequency. engineers misread requirements all the time. they could've done a lot of unnecessary work by the end of 3 weeks, and you'd be wondering if any of it could've been avoided by discussing the project more frequently. daily standup sucks, but they also make problems smaller. I'd say a better cadence is biweekly, but that also depends on the complexity of the projects.
Aaah he said biweekly. 🤪 Is it twice a week or every two weeks?! But I agree, doing 3 weeks of work into a complete wrong direction is only possible if the company has a bunch of funds to burn.
A problem is when you're matrixed across several projects all doing Agile/Scrum/Kanban and having to hit all the meetings while trying to get anything done.
Imagine if you wanted to build a giant building appartment and the architect says "Lets go with the flow.". There MUST be structure, otherwise you end up in agile hell. I agree with the whole sprint concept. I have been working with a lot of companies and they really want that "Architecture Emerges".
I was about to go on a rant about how we do agile at the company i work for and it works good and then decided to watch until the end and what we are actually doing is what PrimeTime drew in GIMP. So good for us i guess
I worked two places where it worked beautifully. All other places, there almost was no point. One place turned Agile into the Art of the Deal. "Can you do (half of the estimate)?" In Art of the Deal place, we spent all morning Monday doing project planning, only to throw out the planning later. They liked planning but hated execution There's also points vs time. The problem is that points have a direct correlation to time, except the Agile guys say it's not, but computer science majors are pretty much math majors. If there's no true separation, we'll notice it. Place B: we just used the tech lead's estimate, but the tech lead was always wrong... yeah... The best times for stand-up was before we were coding, or right before lunch.
Its waterfall scrum that can be difficult. These hybrid methods. Use Agile when it makes sense and use waterfall when it makes sense. If you know what you are doing you understand the difference. You can use both on the same project for different things you need to build.
I like daily meetings. I use them to transfer the responsibility of the results out of my hands. It's like a safety net: in case things go wrong, it's someone else's problem not mine... Those have even saved me from litigation, and customers like it... Plus, they help keeping procrastination under control... Waiting months to show results is a legal catastrophe waiting to happen...
"Most people struggle when having juniors" - every parent. It truly is, but developing new engineers is important for the company's long-term health and engineering. With the asstit methodology, you could lob juniors in there and let them learn through osmosis, but the management requirement for Juniors, or even newer seniors, to dive in and fill tickets is a huge issue. Those personal commit KPIs can really get in the way.
We have dedicated QA team, they utilize some GUI automation testing, I caution devs to really test their own stuff instead of relying only on QA. Own your stuff devs.
Researcher here: Quantitative sampling can be as small as 100 for statistical significance and as small as 5 for qualitative… So, no… 50,000,000 is not only absurd and resource-intensive, but also completely unnecessary. If you already have engaged users at that level and want to conduct some A/B testing with strong data collection systems in place… I guess you can… But there’s no need to do it at that scale.
While it is true that real agile has never been tried, this kind of study about nebulous terms that don’t have consistent meaning among the people using them means absolutely nothing and using it as evidence of anything is almost pure confirmation bias.
6 independent data points are enough for a statistic, change my mind. Also: look at Mr. Fancy Pant's team over there, working on a single problem at a time as a team instead of each team member working on several problems at the same time, lol.
Agile 'du jour' is like Social[ism], promises Nirvana and delivers Infernum. Reason is simple, Ideolog[ism] + Cargo-Cult[ism], the complete deviation, derailment and transformation from the initial Agile Manifesto aim to just an euphemism for short, crunchy, blood spilling waterfalls.
02:33 the 3rd step "adapt" always fails, because project managers think "adapt" means "don't refactor, keep stacking prototypes until the whole thing breaks and suddenly we are 3 years over deadline"
management shouldn't even exist at that level of granularity 🫤
@@grencez Project managers typically aren't management.
this is why you should stay few unpaid hours every week here and there without telling anyone in order to refactor the code . works like a charm .
think ahead , expect that software will always grow
@@lifeisgameplayit why do unpaid work when the spaghetti makes your job secure?
@@fallonsky_ I thank you for your comment. Where do I start.
It would be sad if I based my self-worth on obfuscated code I maintain for the company I don’t like working for.
Perhaps I would like to believe that I have the ambition to co-author communication libraries for, I don’t know, unmanned aerial vehicles, things that could potentially fall on people’s heads.
Maybe at some point I can finish my work after just 2 hours because I thought about doors where I was told to build a wall and then tear it down.
And I write these things despite the fact that once I lost my job because I delivered not a proof of concept but a working prototype. I know the pain when they take away your child :(
I’ve seen what hell looks like, I’ve seen code written in such a hellish and desperate way, MVC framework impl without ‘M’ or ‘C’, random amounts of empty newlines in one file sometimes 5 sometimes 30, ‘pure evils’ like there was no tomorrow.
And yes, I’ve also seen how good reputation went nowhere, but more importantly I’ve also seen how bad spreads throughout the entire business domain.
I also believe in afterlife and that G.O.D himelf will ask me to help write him an Angel CMS .
Blessings!!
Most companies say they're agile while practicing hardcore Watergile, the worst-of-both "let's be flexible but scope creative work items down to the exact number of hours required and use those 'estimates' as deadlines"
This describes my working environment perfectly. I put down 1-2 weeks to get a minimum functionality feature with high uncertainty, and then my PM drills me on why we don't have it completed by that milestone.
@@shimokitazawa1217 I've met very few project managers in my few years in enterprise dev... they're nearly all budget managers merely using different words to do budget management. I have had the pleasure of working with true project managers too, it was amazing. To them the timeline was one of many things to attend to; they fostered a great environment, helped clarify misunderstandings, made sure the tech leads had autonomy and basically worked to maximize the amount of dev time we could do per day - which is kind of the only way to maximize velocity if you think about it. Yeah the rest just measure and project time because it's literally only a proxy for cost to them.
Watergile is exactly it 😅
This has ruined software development.
@@shimokitazawa1217During story refinement, you give a reasonable estimate and they make you reduce it, and then when there is carryover, you get blamed for the low points estimate you didn't want in the first place. Constant sprints mean never being able to plan in a day or two off without falling behind. Sprinting is supposed to have tests in between, but it is being run like an endurance race. It burns people out.
When I first read the agile manifesto, I was like, "okay cool. Reasonable."
Then I got assigned my first SAFE story and took an "agile" training at work and I was like "what in the flying fuck is this trash? This isn't what that manifesto was about at all!"
Those bastards, they lied to me
SAFe and the Agile have about as much in common as any of the 3 Armstrongs you have heard about.
Manifestos and reality have rarely been effective when combined. Cases in point - the Communist Manifesto, the Anarchist Manifesto, the Unabomber's Manifesto, Mein Kampf - The Agile Manifesto is just the latest in a long line of high ideals meeting the brute disdain of reality.
Basically, reality has an anti-manifesto bias.
no dude agile manifrsto is not reasonable
This is why high performing teams under up undermining safe in order to make the actual system more agile.
Agile = Waterfall broken down into sprints, minus 30% time for bullshit ceremonies catered for non-engineers who don't do any of the actual work.
Scrumfall - Waterfall disguised as Scrum. There has been unfortunately no vetting process for people who are working in this manner.
Agile is literally not waterfal broken into sprints. Anyone who does this did not read the manifesto and are not agile.
@@DanielHeeris You are right. With waterfall, you get documentation and repeatable processes. With agile, you get neither.
There's a lot of assumptions here. But one of the big ones to point out is that not every organisation has great engineers. We have to assume the average. That's not just coding skill, that's problem solving, communicating, working as a team, the full shebang!
The type of engineers that can just be given a business problem, find a solution, go away and build a prototype, in an iteration and then communicate with stakeholders in a meaningful way to elicit feedback for the next iteration is vanishingly rare I'd argue.
Even articulating the business problem well is vanishingly rare. Requirements by spreadsheet was not so bad.
was about to comment something similar to this
100% accurate
People get into software because they're not good at communicating and working as a team. But they're manic about "problem solving".
Proper Scrum pushes decisions to the particular participants that are in the best possible position to make decisions. Engineers shouldn’t be working out business goals, they should be deciding on how to technically implement tightly defined goals, guiding management away from difficult nice to haves in favor of practical must haves.
I worked in waterfall for like 8 years. Clear requirements are great if *and only if* they're correct and don't get changed halfway through. Problem is, the moment we got to a working prototype, every stakeholder suddenly has a bunch of new opinions about their requirements, and what you've got written down suddenly stops mattering. The joy of agile, at least for me, was *getting everyone to that point faster* so we're not scrambling to change everything at the last minute.
SAFe stands for Shitty Agile For enterprises
I gave you an upvote to make it 69 upvotes because you deserve it for this comment
@@JP-hr3xqonly for small enterprise. If you have twenty teams working toward a common goal, it works very well! It's almost like, it solves specific problems and if you don't have those problems, then you don't need to use this tool(SAFe)...
Agile Manifesto: "don't believe in Methodolgy(TM)", aka "Management, get out of my face!"
Management: "our lengthy evaluation of the Agile Methodology revealed its insurmountable weaknesses."
And meeting time went up 420.69% while meaningful conversations between colleagues that would've finished the milestones faster and better decreased by 38.6%.
Projects with clear requirements require organizations that know how to create clear requirements...Haven't found one of those yet...
And then it probably doesn't matter if you do agile, waterfall or cave carvings.
Maybe people underestimate how hard really well done requirements engineering is.
@@alxk3995On the contrary it really matters a lot. compare a waterfall project where you create the wrong specifications and thus the wrong software with a an agile project where you iterate until you get it right.
Yes, that is either over-designed requirement where business for some reason describes exact button locations and back-end architecture, but still can't spell out what is actual problem they are trying to resolve, or highest possible lever of requirements 'idk, add billing or something' with "yes" answers to "A or B?" questions from engineers.
@@smmasongt Business, Logical, Physical.
And all the facets ^^
So, yes, 99% of people can't write proper requirements.
Who can even conduct a business interview or even know it is a thing 😂
Ya know, I wonder if a lot of this isn’t a consequence from so many guys in the past just going out and “writing something” and then bringing it back to their boss.
A lot of tools and programs I’ve used throughout the years were the result of 1 or 2 guys just….solving the problem on their own.
But…you’re not allowed to do that anymore 😂❤
We were doing something similar in school, get the spec/features, discuss the UI or batch processing, the output and results, basically ask what's needed. Then create the software, check it with the customer, adjust as needed, and release. Repeat and rinse the last part for bug fixes and new features, I think that's what you refer to as Agile, but you have defined a ridged way people interact. This was over 40 years ago. How you create something, release it, then go back and improve it periodically hasn't really changed, except now management want many layers of controls and ridged, inflexible processes which damage the natural human creativity and interactions. It's extreme micro-management.
11:06 waterfall mentioned! If you Google "waterfall paper" and go beyond page 2, you'll discover, that the paper discusses, that you need a prototype phase and feedback loops, that could trigger changes in spec or implementation :D
Funny thing is Prime roughly laid in his proposal out in his way how Scrum is SUPPOSED to work . Daily meeting are only meant to be 10 to 20 minutes a day. If you have something important you talk 1:1 with the team manager after this . The big retrospective is every 2-4 weeks where you adapt and set the next sprint.
True. The biggest difference probably is that you just don't start to code. The rest seems not far off.
Agile is impossible to disprove because it's not a fully fleshed out methodology. Every time you implement Agile and fail you can be told "you've fleshed it out wrong".
Sounds like socialism
The lesson that I take from all of this is that just because it has "agile" in the name does not mean it is agile
Socialism mentioned
you can ruin any strategy with the right management
@@mrrolandlawrence Amen and thank you.
Watching Prime's videos continually brings home how diverse the software industry is in terms of the types of developers/engineers, organisations, sub-industries, and work environments.
Hearing Prime talk about how he likes requirements gathering is *very* different to how I've had to do it over the last 2 and a half decades.
Not to say either of us is right or wrong - it's just a reflection that we work in different worlds and we can't really generalise about software development/engineering as a whole.
The reason why Agile became some popular wasn't productivity, or efficiency. It's because it optimizes a managers ability to feel busy while minimizing the amount of mental labor that goes into their job.
Good management exists out of 3 things; honest, clear and consistent communication, foresight and restraint. With Scrum they can just ignore those, overload the communication factor, abandon foresight to be "agile" and abandon restraint because hey, scope creep isn't a bug, its a feature in the average Scrum interpretation.
I guess really it's partly a question of what "failure" is defined as:
- Failure to meet a deadline
- Putting out buggy software that's just not usable to the task it's designed for
- Continuing increase in time it takes to add new features, as the code gets less and less maintainable.
PM wants you to add 4 more features this sprint so that he can look good in front of the CEO.
You can refactor and write these tests later in your free time.
To me failed project is one that ends up either not delivering the feature (probably happens way more than people think it does) or one where the feature ends up having to be reworked after a significant engineering effort has been put into it.
Or is failure putting out software that works but doesn't help the organisation achieve anything it really cares about. If it does the task it's designed for but it turns out that that isn't actually a useful task that's also a failure.
@UCxGY_3xMpJg888KcmARkyJw Yeah, but that's not really something a SWE methodology would fix.
If you don't define the success and fail state and don't compare the result to other methodologies, the "65% of agile projects are not done in time" is just some sentence that sounds astute but bears almost no meaning.
We can guess what they count as a failure all we want. Doesn't increase the value of this "study". 🤷♂️
Not promoting Agile, but still, it will be a counter-rant: The problem with agile methods is that 99.99% of the time, companies need to be thinking in terms of a culture change. Agile is sold to management as a product. Use SCRUM, and everything will be great... Zero senior management commitment behind it, zero further investment behind it after the first 1 year (when they celebrate a successful agile transformation). If something needs to be fixed, it has not been improved. In essence, agile transformations are introduced in a waterfall. No proper foundation is laid (at the level of development processes and tools) to build on (e.g., XP). In many places, even the transformation itself consists of introducing Jira and then poking a stick and saying "come on do something". Like buying the Figma license but not hiring a UI/UX designer because the tool itself will do it.
If anyone is serious about this they should understand at senior management level how existing processes work and where and how they could be improved. Once that is in place, then a Lean / Agile mindset can be fitted to it and continually improve them...
Yeah, it's not that they are doing Agile wrong so much as they.. Aren't even doing it wrong.
"If companies just were to change everything they do, Agile would work!" Honestly, I've heard that SO often, and I've NEVER seen "Agile" work. Wherever I go, I just remove it (I'm in the position), and suddenly everything becomes much quicker and better. And no, removing Agile does not mean you do waterfall. You just get rid of all the meetings, estimates and bullshit bingo.
@@3borsresistance551So you’re getting rid of SCRUM and not agile development? SCRUM is a bad implementation of agile to sell courses to enterprises.
@@3borsresistance551 so you're removing bad practices and processes around agile and it became viable? If so, that's exactly what I was trying to suggest. Or at least emphasize that it is the company's misconception that is causing bloated insufficient processes and workflows.
@@3borsresistance551 What I find is that agile works fine but SAFE, scrumm, etc. don't. I also find that sprints don't make any actual sense. I do believe in CI/CD, unit testing, mob coding, working meetings where you actually code with the people that need to be involved.
I am certain that this is the micromanaging style of Agile, as I had worked on a team that competed many epics with very few hot fixes. But I have had the same micromanaged style at most companies before and since, and those end up having many hot fixes - many were critical, as the testing environments are not very reliable as being a representation of real data.
The problem isn’t Agile, it’s how management takes it over and turns it into a monster that I would believe does reduce productivity. When requirements are collected at the beginning, it is clearly just a waterfall process and adding stand-ups isn’t necessary as it won’t improve performance and in fact is an anchor.
Agile should be you start with a high level view of the epic, then you have the developers turn that into features and then, when the demo is given, you find out some of the smaller details and create stories to add those. This will get the developers into a process of doing what they do best, CODING! Anything that reduces developers doing administrative tasks is key to success.
This might be covered later in the video, but whenever I see a headline like this in a study, I start to worry, because there is a built in assumption here that all projects are equal. By definition, clearly defined and documented projects are more likely to proceed because they are normally backed by stable companies or governments because those are the people who make tight specifications. Meanwhile agile is favoured by start ups and enterprises which are much less clearly defined and more open ended, more subject to the whims of investors, and as everyone knows, these companies are faaaaar more likely to fail. Any study which doesn’t control for these factors is already on shaky ground
"i laughed so loud at the "programmers are going to be adults" @12:15, it made everyone in the office look up...
This is actually the fundamental problem with all the “agile” methodologies. They fail to realise programmers are people too and invariably you have a bunch of lazy, unproductive people in any given team.
My first job out of university the programmers were the adults. They brought in a coke snorting consultant to teach us "teams" and we ran the team ourself. We reported directly to 2 VPs. The project was successful. We did have a subject matter expert in the team as well.
I would 100% always do that if it was up to me.
@@dirkbester9050 What was the role of a coke snorting consultant in your suceess?
I find daily standups are required specifically for junior/lesser skilled developers, who need tabs keeping on their progress and regular help.
A daily email or comment on issues will achieve the same goal while saving time.
And daily standups should be about problems and blockers, not "I did, I am gonna do"
I found that the daily as a format is not very useful for that. Very inexperienced people need, in my experience, closer and more intense guidance. More like a 1h+ one-to-one every other day.
@@carstenbohme8813what do you do if you’re a junior/bentry level (2 years in this role incl internship) and I’m very independent and often doing a lot of talking during meetings etc and I feel like I’m not getting the core coding skills development that I need as a entry level
Do you have junior devs that actually know how to code? I'm in a strange predicament where my junior devs (which comprise half the team) literally do not know how to code. What the hell do I even do? I've already told them to utilize the resources available to them in the form of beginner courses on Udemy for example.
What works best for them is 1 on 1 sessions where there's pressure to perform. In a daily standup, there's lots of people so not all the eyes are going to be on them. 1 on 1's are more personal, and there's pressure since it's real-time being watched of coding. (of which I wish actually fucking took place. I'm not kidding they genuinely don't know how to write even a single line of valid code, nor pseudocode.)
Projects with clear requirements succeed more often because they have a defined scope. Scope creep kills more projects (of any kind) than anything else. Without a clearly defined scope the project goal posts are constantly moving, and that makes it easy to get into a state of endless cycling. It's like playing Civilization, except instead of "just one more turn" it's "just one more sprint". And at some point the project grows out of control, becomes tedious and boring, becomes a constant effort of refactoring and redesigning to facilitate the new position of the goal posts, people burn out, budgets explode, and then you have a failed project. The ONE JOB of a project manager should be to control scope creep, because engineers fucking LOVE to expand the scope. Good PMs spend most of their time saying "No, we don't need that."
Currently writing requirements for code that already shipped. Yes, we are running SAFe.
i'm in the same boat (no SAFe though). Stay strong brother
Wait what.
@@lifelover69 Our best senior dev left the project today. I'm freshening up my resume too.
@@BittermanAndy Can't explain without doxxing, but the code was able to be made off of a parallel set of reqs, and we're cleaning up the baselines right now.
About 3:05 on daily stand-ups. I agree with your point that one day is typically not much to get a lot done.
However, in a team of any reasonable size, it's pretty likely someone (else) has run into something that they're struggling with. Sometimes signalling that struggle is enough, sometimes it means this person might need some help. A daily stand-up is an ideal moment to share this.
Yes, this person can ask for help sooner instead of waiting for the stand-up (and this certainly is a valid thing to do), but:
- it's (another) interruption of the other person's activities/focus
- asking for help too soon instead of trying to solve the issue (or digging deeper into it) is counter-productive
Even if the issue was resolved between 2 stand-ups, its still reasonable to mention it during the stand-up. After all, too many of these struggles might indicate deeper underlying issues and could have an impact on projected deliveries.
TL;DR: your point on daily stand-ups is only valid from a self-centred point of view
All the ceremony is to give visible value to middle managers that don’t directly have an impact on delivering value to the customers. They can’t climb the ladder and justify raises without showing impact. Introduce change for change sake. Look at all our process.
Regarding overburdened processes-I did implement a similar thing across my teams as I do have quite a bit of autonomy, but the upper management still wants sprint reports, burndown charts and similar nonsense so I have a small guestimator that kind of repackages what's happening in the team back into more palatable format for those who clearly have no business running a tech company, yet they kept failing upwards until they landed their cushy C level positions in my org...
Oh boy, I'm probably gonna send this to the scrum master =D. Let's see!
keep us updated
My mind always reads it as Scum master.
"But real Agile™️ has never been tried"
If only we had an agile system instead of a glorified cyclic waterfall, aka a spiral model to work under.
I have yet to see the principle of iteration actually taking place more than once is a very long while.
and some companies have massive company wide quarterly planning sessions or even half year planning... not very agile.
really like that you called out the flaws with the study sample
Nothing can beat the Extreme Go Horse.
You don't need 1 000 project management concept and tricks.
You need defined requirement, time and a competent team.
You don't get any of that with a diversity hire as a PM though...
Pick 1
Well said. 100% agree.
and the trust to them do their thing
Some people are lucky enough to regularly more or less hit all of those. Somehow I feel lucky now.
Agile isn’t the problem: its bastardisation is the problem. Management doesn’t understand that velocity is supposed to be constant, and the idea is that this, along with velocity increase where possible, brings about better predictability and quality.
We've collectively been doing it for 20+ years. If people still don't understand it, maybe it's too hard to understand. If people are still doing it wrong, maybe it's too hard to do right. If it's not helping, it's not useful.
No, the problem is that software engineering is much closer to research than to working on a factory line, but managers can't stop trying to make it the latter.
@@THEMithrandir09 truth.
velocity isnt even in scrum guide anymore, what are you even talking about?!
"Truly random does not mean proper distribution", that.... thank you, sir. I can start to heal now.
In our org we started with daily standups that lasted 15 mins to half an hour at max. Slowly and steadily the duration started increasing and now it can easily go up to an hour and a half to two hours long
yes. SAFe is known as the vuvuzela of Agile...
In all seriousness, I think agile methods is amazing for highly dysfunctional teams. When the stakeholders are out of their minds, the devs hate the business people and/or don’t care about the business needs. Then it has a better chance to work. If your team has good communication usually it’s useless to be so formal
Your development process is 100% spot on. Been doing it that way for 40 years.
I think it's really important to point out that failure can be a GOOD thing. Take for example the case where the business spends a few hours trying to determine whether it's worth spending up to or more than 40 hours of dev time (and that's just for one dev) on some project or feature. If the business knows they won't get a return on investment on that time, then the project is not worth doing and therefore the project has failed successfully xdd
Agree. It's actually part of the Agile manifesto "maximizing the amount of work *not* done is crucial". One of the less quoted parts of the manifesto and one of the most ignored
"They didn't do agile correctly"
Every agile developer ever
Imagine you do a thing that works well, then someone else does something different that doesn't work and calls it the same thing as yours before ranting about how bad your thing is. Wouldn't that be annoying?
@@Reashu Probably just means that - hear me out, this is crazy - Agile doesn't work... for everything. (Because it never claimed to and was never intended to. But people are still using it for everything anyway, and honestly at some point that comes down to the Agile industry pretending it can).
@@BittermanAndy I do think "it" (as in putting the team before the process, the software before the documentation, feedback before assumptions, etc.) can work "for everything", obviously with accommodations for regulatory compliance. But what the agile industry sells is something completely different.
@@Reashu sure, if you look at what you're trying to achieve, and who you're trying to achieve it with, and the resources, budget, time etc. you've got, and you have the experience to know how to do it, and then you just do it, then yes, that will work for everything. It's nearly tautological.
But then that thing you're doing is, by definition, different to what anyone else in the world is doing, so no need to get upset when they rant about how bad Agile is because they're not ranting about "your thing". No-one else in the world is doing your thing.
Also: by definition, your thing is useless for anyone else to learn from. It's not a process. It's you, figuring out your thing, which is unique to you and your situation at this time. Nobody else can gain a thing from it, except to look at what you've got and hope you're experienced enough to know what to do to get to where you need to be. Which will also work, if they are, but will be different to what you did.
Agile is fine. But you can all go implement waterfall and let me know how it all went in 6 months.
Also 9:55 the problem with prototypes is that bosses refuse to throw them away and end up being the foundation of your project.
The popular methodologies will have a high chance of producing redundant prototypes that miss the project deadline by many months. Tell me one successful methodology other than "Talk clear, quickly, and frequently" that made the project succeed most frequently...
@@SimGunther REAL Agile? "Individuals and interactions over processes and tools". THAT is literally what you just described.
@@ErazerPT Except that people turned agile into JIRA and confusing, pointless meetings that make management think they've contributed something when they can just collaborate like normal people solving everyday problems.
@@SimGunther Management types appropriated Agile. But they only got away because we let them. And us lambasting Agile because of something that is NOT Agile helps no one. What we need to do is to simply say "This is NOT Agile, this is trash" every time they try and pass some crap like SCRUM as Agile.
And yes, management hates real Agile because they can't plop it down in some chart, but that just means we (devs) need to keep pushing them out of our "space".
Their usefulness is in keeping track of things and their progress and facilitating any roadblocks et all. NOT in telling us how to do our work. Because... how would they know?
Ah, the classic "the only two possibilities in existence are Agile and waterfall" comment. OK dude. 👍
Many use the word "Agile" to mask a project run using chaos
The easiest way to build a project in my point of view is to write the skeleton result first. See what exactly your application will be. Then start coding and find the solutions that fill this skeleton for you. For example, I want my app to be a console calculator.
skeleton result in human words:
read a string from a user, process this string and come up with an answer, and show the result to the user.
skeleton result in code:
string expression = readline()
result = calculate(expression)
print(result)
This way you can speed up your coding time and not wasting lots of time in planing and documentation.
That study seems really sketchy. My guess is they asked random people on a dev con somewhere.
The company which did the study are publishing a book on their own software pipeline methodology. Clear what's going on here.
The two worst things that happened to agile. 1) Scrum. 2) jira
And SAFe
I've been writing software for living for 20+ years and I feel that hardest part is to get decision makers to clearly defined what's "good enough" for release. It seems to change randomly at least weekly.
Daily standups works fine in my team. But we focus on discussing incidents, bring up blockers, confirm what is prio to work on next etc. Max 15 minutes and we work on many parallell projects, not one long...
Waterfall, before Agile even began, was seen to have a 70% failure rate. So, are we saying that Agile is 70x2.68% failing? Like 187.6% of Agile projects fail now? Seriously? How do you even do that? Do all Agile projects fail but not only that: the failure spreads to other non-agile projects in a kind of Domino Theory scenario, like rot spreading through the entire office?
This is ridiculous.
Re: Survey statistics, you do not necessarily NEED a large sample size- the key is if the effect measured is large enough, it can be statistically valid. I worked on a project with a relatively small user base (about 6k DAU), we made a small change (adding a button), that increased the usage of a feature by literally 1,000% overnight. Was that change statistically invalid because there weren't 10 million users in the sample? Definitely not, because the effect was large relative to the usual usage pattern where day to to day variation might be 5-10%. Even smaller studies with significant effects can be seen in medical studies where n < 20 is not unheard of, especially for clinical stage oncology drugs. If a drug causes a 100% remission compared to the control then that is a very statistically significant event. A n=600 sample size of engineers as long as it is distributed decently and the change from the baseline is large enough then it CAN indeed be statistically valid.
If your system for management defines failure criteria in more definite terms than success criteria, it will produce more measurable failures. Agil is all about measuring failure
Agile is all about failure, FTFY
As a Scrum Master / Delivery Manager of nearly 10 years. I both agree and disagree.
I agree that a lot of Agile is done poorly, with ridiculous amounts of waste.
But what I take problems with is, what's their definition of "Succeeded". It got finished on time and on budget? Sure. That could be the metric. But did it then actually provide any value and solve the problem that they set out to solve?
That's been my biggest gripe with being in that role for so long, is it's not about how much value the team is delivering and it's always about "Are they delivering enough, fast enough". Could be delivering lots that ultimately does nothing, but that doesn't matter to upper management -.-
People get so locked in to getting stuff done on time that they don't ask this. I've never been able to find it again, but I remember seeing one study (I think Microsoft) that found two-thirds of features deployed in a period had either no benefit or were detrimental to the user experience. How much development time was that that got flushed down the drain doing things that didn't need to be done?
@@sasukesarutobi3862 everyone's so focused on what and when, they don't stop to ask why
Study proves what we've all known to be true for years. Feels good to finally have a study to quote from now when asking why we are still in the meeting.
As a developer of 20 years who has worked in agile environments for almost as long, I can guarantee this is true. Agile is a way of not addressing true organisational issues and delaying true organisational development. It lets everyone stay stupid and focus on their little corner without everything blowing up. No wider intelligence is needed, which grand corporate hierarchies love.
I had this playing while I was cooking breakfast and I looked back at the screen at 15:00 and realized why he was using a bunch of weird specific names…
Agile is like building the go kart as you are rolling down the hill. Then when you reach the bottom, you realize there is another hill in front of you.
I wish I have this kind of presentation always!! this vid made my day!! thank you!!
For the love of god, you don't need a "framework" for this kind of thing. Just let people do their jobs and listen when they say something is broken
5:33 I’m less concerned about the number of participants than I am about the insanely short 5 day duration in an industry notorious for almost every organisation and developer doing things their own way.
As you say, it reeks of just being a subjective poll of opinions.
I’d also love to know how they controlled for different:
- business sizes
- industries
- tech platforms
- quality controls
- user bases
- platform architectures
I’m in this project management class now, we are going over scrum. I was excited after learning the basics of agile. ‘People over process’ etc. Then we got to the scrum and it went down hill from there.
I was just reading through the agile stuff and it just didn’t feel right. I think I’m gonna be failing this part.
Watch senior manager heart rates sky-rocket as developers glow in your new agile world 🤣
4:30 I think the more interesting question would have been "for the projects that had clear requirements documented before the development started, how many actually matched the final end user needs?" - I would guess many waterfall projects did actually implement things as designed but I don't believe majority of those projects actually matched the user needs.
I wasn't able to watch all this video to the end, but my take away was that this guy conflated "agile" with a process such as "scrum" when agile is not a process .. it's just a set of values. Agile does not stipulate a process. SAFE is rightly described as "shity agile for enterprises" .. in many cases Srum is the same .. a load of BS that some folks made up to sell training etc and people bought in the expectation that it would make them "agile" and allthis agile stuff would be more palatable to upper management.
Agile is not a process!!! Beware of anyone selling you agile in a box .. it's a con !!
I am already happy when the customer/product owner has a robust idea of what the product is supposed to do or achieve.
Agile is linear, creation is not. You can't schedule invention but you can provide an environment where it may flourish.
Isn't the motto "fail early, fail often" - mission accomplished.
"agile" imbeds layers of "management" into the development process (like a cancer), destroying any productivity while consuming 60-80% work time with meetings.
it's crazy thinking 3 weeks is a better feedback frequency.
engineers misread requirements all the time. they could've done a lot of unnecessary work by the end of 3 weeks, and you'd be wondering if any of it could've been avoided by discussing the project more frequently.
daily standup sucks, but they also make problems smaller. I'd say a better cadence is biweekly, but that also depends on the complexity of the projects.
Aaah he said biweekly. 🤪 Is it twice a week or every two weeks?!
But I agree, doing 3 weeks of work into a complete wrong direction is only possible if the company has a bunch of funds to burn.
@@alxk3995 every two weeks is fortnightly not biweekly
The guy selling his book found bla
I don't like agile/scrum/foo, but this "study" is dogwater tier
"you didn't do it right" -An Agile Expert...
A problem is when you're matrixed across several projects all doing Agile/Scrum/Kanban and having to hit all the meetings while trying to get anything done.
Imagine if you wanted to build a giant building appartment and the architect says "Lets go with the flow.". There MUST be structure, otherwise you end up in agile hell. I agree with the whole sprint concept. I have been working with a lot of companies and they really want that "Architecture Emerges".
some of the best software was written AFTER the handbook for it was compiled.
just as food for thought.
I was about to go on a rant about how we do agile at the company i work for and it works good and then decided to watch until the end and what we are actually doing is what PrimeTime drew in GIMP. So good for us i guess
Fully agree with Prime, Agile is a struggle with less experienced engineers or those not motivated to learn or exert themselves.
I worked two places where it worked beautifully. All other places, there almost was no point. One place turned Agile into the Art of the Deal. "Can you do (half of the estimate)?" In Art of the Deal place, we spent all morning Monday doing project planning, only to throw out the planning later. They liked planning but hated execution
There's also points vs time. The problem is that points have a direct correlation to time, except the Agile guys say it's not, but computer science majors are pretty much math majors. If there's no true separation, we'll notice it.
Place B: we just used the tech lead's estimate, but the tech lead was always wrong... yeah...
The best times for stand-up was before we were coding, or right before lunch.
Its waterfall scrum that can be difficult. These hybrid methods. Use Agile when it makes sense and use waterfall when it makes sense. If you know what you are doing you understand the difference. You can use both on the same project for different things you need to build.
I like daily meetings. I use them to transfer the responsibility of the results out of my hands. It's like a safety net: in case things go wrong, it's someone else's problem not mine... Those have even saved me from litigation, and customers like it... Plus, they help keeping procrastination under control... Waiting months to show results is a legal catastrophe waiting to happen...
why Agile doesn't work? ...well you gotta remember that 1/3 of humanity is pretty dumb, and then you gotta remember that 1/3 are dumber than that
Sat down for a conversation on project management, got T & A. I wish that's how the job worked. 😏
I feel like randos off the street could tell you that Agile was a bad idea on every level...
I don't really mind daily scrums, but I find most of the time that I'm just repeating what I've already said previously in chat during my turn.
Daily standup should just be asking if we need a standup at most
Got told a month ago our job's #1 priority is to look good, not to make the best product. Overestimate them useless points or you're in trouble.
For many situations, you do (or should) know what you are trying to achieve (AKA requirements) early on.
"Corporate Agile" is when you read the list of Agile values from right to left.
"Most people struggle when having juniors" - every parent.
It truly is, but developing new engineers is important for the company's long-term health and engineering. With the asstit methodology, you could lob juniors in there and let them learn through osmosis, but the management requirement for Juniors, or even newer seniors, to dive in and fill tickets is a huge issue. Those personal commit KPIs can really get in the way.
We have dedicated QA team, they utilize some GUI automation testing, I caution devs to really test their own stuff instead of relying only on QA. Own your stuff devs.
The Manifesto never suggests scrum, nor does it prohibit up front design. The consultants, as always, ruined the world.
Researcher here: Quantitative sampling can be as small as 100 for statistical significance and as small as 5 for qualitative… So, no… 50,000,000 is not only absurd and resource-intensive, but also completely unnecessary. If you already have engaged users at that level and want to conduct some A/B testing with strong data collection systems in place… I guess you can… But there’s no need to do it at that scale.
Time to write the "prime development manifesto" AKA PDM
Impact Engineering sounds like some new BS. Apparently, the new thing is focusing on the end user impact. Oh yeah, I’ve never thought of that.
8:22 Next up will be torque engineering, turning the "good" paradigms to the max.
While it is true that real agile has never been tried, this kind of study about nebulous terms that don’t have consistent meaning among the people using them means absolutely nothing and using it as evidence of anything is almost pure confirmation bias.
my preferred project management framework is "chaos engineering"
6 independent data points are enough for a statistic, change my mind. Also: look at Mr. Fancy Pant's team over there, working on a single problem at a time as a team instead of each team member working on several problems at the same time, lol.
Yes! "Predict, ignore, fail, repeat"
From a statistical point, 600 is a good sample with the right selection. It all depends on the questions asked a set frame.
Agile 'du jour' is like Social[ism], promises Nirvana and delivers Infernum. Reason is simple, Ideolog[ism] + Cargo-Cult[ism], the complete deviation, derailment and transformation from the initial Agile Manifesto aim to just an euphemism for short, crunchy, blood spilling waterfalls.