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!!
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.
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.
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.
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 😂❤
@@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)...
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.
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%.
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
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.
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."
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.
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 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". 🤷♂️
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.
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".
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
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."
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.
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.
@@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.
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.)
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...
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.
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
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.
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 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?
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.
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.
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...
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
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.
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?
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.
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 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
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.
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
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.
"agile" imbeds layers of "management" into the development process (like a cancer), destroying any productivity while consuming 60-80% work time with meetings.
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.
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…
The interesting questions regarding those studies is, how do you define failure or success of a project... When is a project a failure? When it is canceled? When it is not finished until deadline? Is there a clear deadline?
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.
yeh it's because the strengths of agile become weaknesses. IMO, agile was never supposed to mean a complete absence of planning. in my experience, only the higher level managers are doing any kind of planning, but it's somewhat deprived of feedback from subordinates and 1-subordinates. agile is supposed provide various options (daily standup, etc) that couteract a lack of feedback. however, that's not really what happens the capacity of humans to abstract themselves from time and plan months into the future is one thing that separates us from animals. "planning poker" lol yeh i got a real 9-pointer right here
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.
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.
Doesn’t say anything about how much it cost to get those “robust requirements”, or what the relative size of the projects were. My hunch is that 97% of projects started after a multi-million dollar requirements phase went just great. They don’t mention that most of those requirements exercises ended up not even starting a project, because the whole thing was deemed too hard and costly. Where as most projects put together on a back or a napkin, and can succeed or fail in a couple of weeks probably do fail - but it doesn’t matter. It’s like the old story of getting pottery students to make as many pots as they can, vs spending all their time creating a single perfect pot. The ones failing a lot end up doing better overall. Fail fast. Fail cheap. Learn and iterate.
Yes, this. Extremely-well-defined requirements ARE code, just need translating from human language to computer language. But writing requirements that well-defined is slow, expensive, and error-prone.
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.
The problem with studies like these is usually neither sample size nor selection, but rather confounding factors. I would guess that there is a high correlation between companies using Agile and other factors that lead to "failures" (delays, breakages, feature creep, etc.). Places with too many juniors and not enough experienced engineers. Startups that have a high likelihood to fail or meander to begin with. Places where Agile is something managers adopt as a substitute for not really knowing what they're doing. And on the opposite end, you probably have a lot of well-established places, with plenty of senior engineers, working in well-defined industries, who probably don't use Agile, and are more likely to "succeed" at meeting their goals regularly. And in the end, it says nothing about whether the first group would succeed more with less Agile, or if the second group would succeed less with more Agile. People are technically correct to say that 600 would be a representative sample size, but only if there were no confounding factors to account for. When you start eliminating other factors, that sample size will quickly appear insufficient.
I think this is an interesting take, and I’m not sure if it would work across-the-board because I think there are some assumptions being made in the conversation which include that the development team is employed by the company that the program is being created for. In the case of a corporation contracting with another group to perform this work this proposal doesn’t really work in the sense that you can’t then features and time after the fact when you sold a specific contract. I might also be missing some finer details, but that was my first thought here
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.
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.
"Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan" This is agile, a recipe for failure. Those things on the right of "over" are really important. In particular, "comprehensive documentation" includes design plans, test plans, and build plans. That second bullet, far more than any other, is a recipe for failure, because "working software" depends on knowing what the customer needs, and what the customer needs is commonly called out in a contract. Hmm.
The question is not how large the sample size is but what the confidence interval of the result is. 600 is more than adequate for some national political polls, which largely go above 1200.
What I have noticed is that highly functional teams are already pretty agile. However, I see managers try to add agile to non-functional teams and that just fails. I also see many companies use SAFE which is pretty far from agile. It is hard to get anything done with managers twist agile to micromanage. Mostly the way companies use SAFE still looks like waterfall to me.
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.
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 !!
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.
"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.
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 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...
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.
Agile was supposed to be about using a feedback loop to improve estimation by discovering the *actual* throughput of a team. That's it. Everything else was pure McManagement junk food piled on top of that to justify managerial salaries. I've only worked at maybe two or three companies who grasped this, and used it effectively.
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".
Agile works when done without the SCRUM bs etc.. I am working on a project where the details are yet to be discovered. We have a clear understanding where we want to go, but dont really know our requirements. It would be stupid to spend month in planning. Instead we do it "agile". 1. Short iterations, 2. bare minimum features to begin with (even UI design is minimum an clean because time is spen more in completing a WORKING product than a shiny one (sill looks good because all basics like typography, colors are in place), 3. Priority on working and stable product, 4. Business is highly involved and gives feedback + ideas. This is agile, not this whole SCRUM bs.
It would work better if we were writing properly modular code, functionally complete modules. But that seems to have gone out the window. We are moving backwards, not forwards.
Anyone else seeing the "no late reqiorements change" is the core of the argument.... And both agile and waterfall seem aligned on that. For agile, of you have significant changes well in a project's development it probably is a lack of regular communication with your stakeholders. Even their shock 268% statistic comes from the same problem of significant changes late in development.
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!!
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.
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.
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.
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.
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 😂❤
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)...
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.
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%.
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
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.
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."
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.
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 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". 🤷♂️
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.
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.
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
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."
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 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?
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.
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.)
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...
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.
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
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.
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.
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.
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. 👍
really like that you called out the flaws with the study sample
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?!
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.
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...
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"
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
Nothing can beat the Extreme Go Horse.
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.
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
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
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 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
yes. SAFe is known as the vuvuzela of Agile...
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.
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
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.
Your development process is 100% spot on. Been doing it that way for 40 years.
"Truly random does not mean proper distribution", that.... thank you, sir. I can start to heal now.
"agile" imbeds layers of "management" into the development process (like a cancer), destroying any productivity while consuming 60-80% work time with meetings.
The two worst things that happened to agile. 1) Scrum. 2) jira
And SAFe
Agile is linear, creation is not. You can't schedule invention but you can provide an environment where it may flourish.
Many use the word "Agile" to mask a project run using chaos
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.
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…
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 interesting questions regarding those studies is, how do you define failure or success of a project...
When is a project a failure? When it is canceled? When it is not finished until deadline? Is there a clear deadline?
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.
yeh it's because the strengths of agile become weaknesses. IMO, agile was never supposed to mean a complete absence of planning.
in my experience, only the higher level managers are doing any kind of planning, but it's somewhat deprived of feedback from subordinates and 1-subordinates. agile is supposed provide various options (daily standup, etc) that couteract a lack of feedback. however, that's not really what happens
the capacity of humans to abstract themselves from time and plan months into the future is one thing that separates us from animals.
"planning poker" lol yeh i got a real 9-pointer right here
The guy selling his book found bla
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.
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.
Doesn’t say anything about how much it cost to get those “robust requirements”, or what the relative size of the projects were.
My hunch is that 97% of projects started after a multi-million dollar requirements phase went just great. They don’t mention that most of those requirements exercises ended up not even starting a project, because the whole thing was deemed too hard and costly.
Where as most projects put together on a back or a napkin, and can succeed or fail in a couple of weeks probably do fail - but it doesn’t matter.
It’s like the old story of getting pottery students to make as many pots as they can, vs spending all their time creating a single perfect pot. The ones failing a lot end up doing better overall.
Fail fast. Fail cheap. Learn and iterate.
Yes, this. Extremely-well-defined requirements ARE code, just need translating from human language to computer language. But writing requirements that well-defined is slow, expensive, and error-prone.
I wish I have this kind of presentation always!! this vid made my day!! thank you!!
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.
The problem with studies like these is usually neither sample size nor selection, but rather confounding factors. I would guess that there is a high correlation between companies using Agile and other factors that lead to "failures" (delays, breakages, feature creep, etc.). Places with too many juniors and not enough experienced engineers. Startups that have a high likelihood to fail or meander to begin with. Places where Agile is something managers adopt as a substitute for not really knowing what they're doing. And on the opposite end, you probably have a lot of well-established places, with plenty of senior engineers, working in well-defined industries, who probably don't use Agile, and are more likely to "succeed" at meeting their goals regularly. And in the end, it says nothing about whether the first group would succeed more with less Agile, or if the second group would succeed less with more Agile.
People are technically correct to say that 600 would be a representative sample size, but only if there were no confounding factors to account for. When you start eliminating other factors, that sample size will quickly appear insufficient.
8:22 Next up will be torque engineering, turning the "good" paradigms to the max.
I think this is an interesting take, and I’m not sure if it would work across-the-board because I think there are some assumptions being made in the conversation which include that the development team is employed by the company that the program is being created for. In the case of a corporation contracting with another group to perform this work this proposal doesn’t really work in the sense that you can’t then features and time after the fact when you sold a specific contract. I might also be missing some finer details, but that was my first thought here
How would you hire for this model? How would you evaluate your devs to see who’s working-out, and who’s not?
I am already happy when the customer/product owner has a robust idea of what the product is supposed to do or achieve.
"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.
some of the best software was written AFTER the handbook for it was compiled.
just as food for thought.
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.
"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan"
This is agile, a recipe for failure. Those things on the right of "over" are really important. In particular, "comprehensive documentation" includes design plans, test plans, and build plans. That second bullet, far more than any other, is a recipe for failure, because "working software" depends on knowing what the customer needs, and what the customer needs is commonly called out in a contract. Hmm.
The question is not how large the sample size is but what the confidence interval of the result is. 600 is more than adequate for some national political polls, which largely go above 1200.
How many story points do you think the study started out with?
was the study a "double blind"? if not there might be selection bias.
From a statistical point, 600 is a good sample with the right selection. It all depends on the questions asked a set frame.
What I have noticed is that highly functional teams are already pretty agile. However, I see managers try to add agile to non-functional teams and that just fails. I also see many companies use SAFE which is pretty far from agile. It is hard to get anything done with managers twist agile to micromanage. Mostly the way companies use SAFE still looks like waterfall to me.
For many situations, you do (or should) know what you are trying to achieve (AKA requirements) early on.
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.
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 !!
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.
"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.
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.
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.
if the effect is over 200%. n=600 is more than enough. The problem is that it could be that riskier enterprises more often chose the Agile method
Sat down for a conversation on project management, got T & A. I wish that's how the job worked. 😏
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 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...
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.
Fully agree with Prime, Agile is a struggle with less experienced engineers or those not motivated to learn or exert themselves.
Agile was supposed to be about using a feedback loop to improve estimation by discovering the *actual* throughput of a team. That's it. Everything else was pure McManagement junk food piled on top of that to justify managerial salaries. I've only worked at maybe two or three companies who grasped this, and used it effectively.
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".
Agile works when done without the SCRUM bs etc.. I am working on a project where the details are yet to be discovered. We have a clear understanding where we want to go, but dont really know our requirements. It would be stupid to spend month in planning. Instead we do it "agile". 1. Short iterations, 2. bare minimum features to begin with (even UI design is minimum an clean because time is spen more in completing a WORKING product than a shiny one (sill looks good because all basics like typography, colors are in place), 3. Priority on working and stable product, 4. Business is highly involved and gives feedback + ideas. This is agile, not this whole SCRUM bs.
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
It would work better if we were writing properly modular code, functionally complete modules. But that seems to have gone out the window. We are moving backwards, not forwards.
Anyone else seeing the "no late reqiorements change" is the core of the argument.... And both agile and waterfall seem aligned on that. For agile, of you have significant changes well in a project's development it probably is a lack of regular communication with your stakeholders.
Even their shock 268% statistic comes from the same problem of significant changes late in development.