268% Higher Failure Rates For Agile

[@pieterrossouw8596]

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"

[@shimokitazawa1217]

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.

[@pieterrossouw8596]

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

[@Oglokoog]

Watergile is exactly it 😅

[@MereAYT]

This has ruined software development.

[@MereAYT]

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

[@rrraewr]

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"

[@grencez]

management shouldn't even exist at that level of granularity 🫤

[@Aberusugi]

​@@grencez Project managers typically aren't management.

[@lifeisgameplayit]

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_]

@@lifeisgameplayit why do unpaid work when the spaghetti makes your job secure?

[@lifeisgameplayit]

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

[@kaseywahl]

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!"

[@araarathisyomama787]

Those bastards, they lied to me

[@THEMithrandir09]

SAFe and the Agile have about as much in common as any of the 3 Armstrongs you have heard about.

[@calmhorizons]

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.

[@redhotbits]

no dude agile manifrsto is not reasonable

[@Immudzen]

This is why high performing teams under up undermining safe in order to make the actual system more agile.

[@alichamas63]

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.

[@motorcitysmitty]

Scrumfall - Waterfall disguised as Scrum. There has been unfortunately no vetting process for people who are working in this manner.

[@DanielHeeris]

Agile is literally not waterfal broken into sprints. Anyone who does this did not read the manifesto and are not agile.

[@unclesmrgol]

@@DanielHeeris You are right. With waterfall, you get documentation and repeatable processes. With agile, you get neither.

[@Softcushion]

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.

[@JoepKockelkorn]

Even articulating the business problem well is vanishingly rare. Requirements by spreadsheet was not so bad.

[@TheBeastDispenser]

was about to comment something similar to this

[@mats66]

100% accurate

[@januslast2003]

People get into software because they're not good at communicating and working as a team. But they're manic about "problem solving".

[@omegabit]

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.

[@ArturCzajka]

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

[@chrvberg]

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."

[@borisvulikh4355]

SAFe stands for Shitty Agile For enterprises

[@JP-hr3xq]

I gave you an upvote to make it 69 upvotes because you deserve it for this comment

[@AlgoristHQ]

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

[@warspaniel]

Projects with clear requirements require organizations that know how to create clear requirements...Haven't found one of those yet...

[@alxk3995]

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.

[@matswessling6600]

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

[@L1vv4n]

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.

[@programaths]

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

[@Macheako]

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 😂❤

[@birdrun4246]

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.

[@farkinarkin5099]

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

[@JonathanSwiftUK]

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.

[@SimGunther]

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%.

[@BryantSuiskens]

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.

[@Grumpicles]

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.

[@HaveANceDay]

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

[@airkami]

Socialism mentioned

[@mrrolandlawrence]

you can ruin any strategy with the right management

[@motorcitysmitty]

@@mrrolandlawrence Amen and thank you.

[@justin423]

"i laughed so loud at the "programmers are going to be adults" @12:15, it made everyone in the office look up...

[@ratsock]

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.

[@dirkbester9050]

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.

[@ivanklimovich6656]

@@dirkbester9050 What was the role of a coke snorting consultant in your suceess?

[@taragnor]

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.

[@zyriab5797]

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.

[@JanVerny]

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.

[@barneylaurance1865]

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.

[@JanVerny]

@UCxGY_3xMpJg888KcmARkyJw Yeah, but that's not really something a SWE methodology would fix.

[@alxk3995]

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". 🤷‍♂️

[@maciejtrybilo]

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".

[@cokobware]

Sounds like socialism

[@this-is-bioman]

​@@cokobware next time it'll work - lol

[@jfftck]

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.

[@Fiercesoulking]

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.

[@alxk3995]

True. The biggest difference probably is that you just don't start to code. The rest seems not far off.

[@aenguswright7336]

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

[@nosignal4hollow]

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

[@rapzid3536]

Yeah, it's not that they are doing Agile wrong so much as they.. Aren't even doing it wrong.

[@3borsresistance551]

"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.

[@LordApophis100]

@@3borsresistance551So you’re getting rid of SCRUM and not agile development? SCRUM is a bad implementation of agile to sell courses to enterprises.

[@nosignal4hollow]

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

[@Immudzen]

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

[@datanuke]

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

[@heidebaer41]

Currently writing requirements for code that already shipped. Yes, we are running SAFe.

[@lifelover69]

i'm in the same boat (no SAFe though). Stay strong brother

[@BittermanAndy]

Wait what.

[@heidebaer41]

@@lifelover69 Our best senior dev left the project today. I'm freshening up my resume too.

[@heidebaer41]

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

[@adds-kz3oc]

I find daily standups are required specifically for junior/lesser skilled developers, who need tabs keeping on their progress and regular help.

[@abpdev]

A daily email or comment on issues will achieve the same goal while saving time.

[@Salantor]

And daily standups should be about problems and blockers, not "I did, I am gonna do"

[@carstenbohme8813]

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.

[@RequiosWoW]

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

[@Septem_150]

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

[@Cyanide300]

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."

[@zwerko]

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

[@albertoarmando6711]

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.

[@SimGunther]

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]

@@SimGunther REAL Agile? "Individuals and interactions over processes and tools". THAT is literally what you just described.

[@SimGunther]

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

[@ErazerPT]

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

[@BittermanAndy]

Ah, the classic "the only two possibilities in existence are Agile and waterfall" comment. OK dude. 👍

[@nikarmotte]

Oh boy, I'm probably gonna send this to the scrum master =D. Let's see!

[@dejangegic]

keep us updated

[@creativemaster007]

My mind always reads it as Scum master.

[@zyriab5797]

"But real Agile™️ has never been tried"

[@keyboard_g]

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.

[@extrabladeworks_]

really like that you called out the flaws with the study sample

[@andrearaimondi882]

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.

[@BittermanAndy]

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.

[@THEMithrandir09]

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.

[@BittermanAndy]

@@THEMithrandir09 truth.

[@redhotbits]

velocity isnt even in scrum guide anymore, what are you even talking about?!

[@craigyoung8008]

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

[@MikkoRantalainen]

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.

[@Hersatz]

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.

[@stoffni]

and some companies have massive company wide quarterly planning sessions or even half year planning... not very agile.

[@adbm210]

Nothing can beat the Extreme Go Horse.

[@dough-pizza]

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

[@choilive]

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.

[@platibyte]

"Truly random does not mean proper distribution", that.... thank you, sir. I can start to heal now.

[@JulienTant]

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

[@Luzgar]

You don't need 1 000 project management concept and tricks. You need defined requirement, time and a competent team.

[@zakhoskins6404]

You don't get any of that with a diversity hire as a PM though...

[@TheYahmez]

Pick 1

[@moviesfan5513]

Well said. 100% agree.

[@jasondads9509]

and the trust to them do their thing

[@sorcdk2880]

Some people are lucky enough to regularly more or less hit all of those. Somehow I feel lucky now.

[@maf_aka]

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.

[@alxk3995]

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.

[@MagicGonads]

@@alxk3995 every two weeks is fortnightly not biweekly

[@AllanKobelansky]

Your development process is 100% spot on. Been doing it that way for 40 years.

[@King88Martyn]

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

[@sasukesarutobi3862]

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?

[@King88Martyn]

@@sasukesarutobi3862 everyone's so focused on what and when, they don't stop to ask why

[@whirled_peas]

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.

[@MikkoRantalainen]

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.

[@christians4483]

That study seems really sketchy. My guess is they asked random people on a dev con somewhere.

[@SilySlashLeon]

The company which did the study are publishing a book on their own software pipeline methodology. Clear what's going on here.

[@E8A590]

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.

[@Lorofol]

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

[@philw3039]

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

[@ttrev007]

was the study a "double blind"? if not there might be selection bias.

[@EricLS]

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…

[@katanasteel]

8:22 Next up will be torque engineering, turning the "good" paradigms to the max.

[@jamesgardner6499]

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.

[@philjerkins1593]

How would you hire for this model? How would you evaluate your devs to see who’s working-out, and who’s not?

[@JeepinItReal5x5]

How many story points do you think the study started out with?

[@timedebtor]

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

[@georgezimmer5622]

Agile is all about failure, FTFY

[@mats66]

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

[@smanqele]

Watch senior manager heart rates sky-rocket as developers glow in your new agile world 🤣

[@andyp123456]

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.

[@u9vata]

11:38 actually looks pretty close to what I was naming "RADICS" development methodology that I was using for R&D teams. Its a no-bullshit thing basically + prototyping early on. Maybe I'll blog it down...

[@goraxe01]

The two worst things that happened to agile. 1) Scrum. 2) jira

[@motorcitysmitty]

And SAFe

[@s3rit661]

"They didn't do agile correctly" Every agile developer ever

[@Reashu]

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?

[@BittermanAndy]

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

[@Reashu]

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

[@BittermanAndy]

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

[@Skiamakhos]

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.

[@MikkoRantalainen]

14:15 I think the most important thing to understand that *every* team must invent their own methodology if they want to be effective. You cannot just copy some magical "one-size-fits-all" method that would actually work for real. Some say that developers are like werewolves: always afraid of magic bullets.

[@redcurrantrecords]

Many use the word "Agile" to mask a project run using chaos

[@ChuckAsum]

10:04 usually finding that this approach is best when the people you work with are pretty competent and fluent in software engineering, and flexible with working ambiguity. Though not for those who struggle to translate ideas to code in the context it matters... Sadly I see more and more people fall into the latter category..

[@meetarthur9427]

I wish I have this kind of presentation always!! this vid made my day!! thank you!!

[@iliumboy]

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.

[@eyesopen6110]

"agile" imbeds layers of "management" into the development process (like a cancer), destroying any productivity while consuming 60-80% work time with meetings.

[@bradkuntzelman5343]

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.

[@sailingadventuress5489]

yes. SAFe is known as the vuvuzela of Agile...

[@mike200017]

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.

[@bonly4889]

Real talk, are they adopting 'agile manifesto practices' for real or is it like all but one agile job I ever worked where it's scrum and some strict program manager driven process that doesn't work well for anyone but them?

[@JoeStuffzAlt]

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.

[@tornoutlaw]

I am already happy when the customer/product owner has a robust idea of what the product is supposed to do or achieve.

[@renatoivancic9395]

Do you offer coupon code on BSR methodology certification?

[@GoLDnTRiXX]

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?

[@RN1441]

Did they implement Agile or did they implement 'Extreme Go Horse' the better Brazilian brother from the same cracked out mother?

[@rando5673]

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

[@DavidConnerCodeaholic]

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

[@dave4148]

okay now with your idea how do you come up with an agreed upon deadline and contract cost for custom dev work for a client?

[@lilmisslena1386]

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

[@madlep]

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.

[@BittermanAndy]

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.

[@iliqnikushev3820]

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".

[@sorcdk2880]

You do not need millions of datapoints to say something meaningful. The amount you need depends on what you are studying, and for a lot of cases having around 1000 data points is quite sufficient if you are studying something with a reasonably sized signal to noise ratio and without tons of hidden problems. There are 4 main things you need to consider about the reliability of a such a piece of measurement: 1) The ability of what you measure to measure what you want (this kind of retroactive study generally measure correlation and not causation). 2) The ability to measure something enough to be statistically significant to the degree you want. 3) The biases and other things like that that may move what you measure away from the truth or what you think it is you are measuring. 4) The generalisibility of what piece of evidence gathering and analysis you did, and how to deal with the problems of overfitting and how easy it was to find something like that with how you looked at the data. This study obviously has huge potential issues with part 1 and 3, as you are generally only at some kind of correlation based on "what kind of teams have finished stuff" and "what teams used some kind of agile", which seems nice until you realise that agile teams often aren't constructed with the purpose of finishing something, but rather building and maintaining something in perpetuity. There are also a bunch of different biases to consider, such as "are the team composition in terms of experience different" (hint: a commando group of experts needs a lot less oversight to get things done than a more varied mothly, or a junior heavy group, and as such you would see more management heavy solutions for the latter). 2 and 4 are quite related, but 4 is a fairly advanced math topic that is a lot less well know. For 2, we generally try to have as a requirement that you need 5 sigma significance for a proper scientific result, where sigma refers to the standard deviation, which is the mean expected distance of what you measure from the true value. Generally speaking you can use multiple data both to estimate this value and to generate a better aggregated guess on the true value. For a rule of thumb, you generally get that you can divide the single experiment standard deviation with square root of the number of experiments you do. This means that with 100 experiments you can get a scientific result if the distance between the 2 classes in value is at least half of the standard deviation inside each of them, as that would get the factor 2 of standard deviation be suppressed by a factor 10 down to 1/5th, which is enough for those 5 standard deviations. Note that this is very rough back on the envolope calculations, and the correct way involves a lot more math. In comparison, if you need millions of data, that tells me that the difference of that UI change has an effect compariable to 1/200th of the standard deviation of your users experience with the site in general. There is also the posibiity that it comes more from part 4 instead. Part 4 really comes into play when you try to do something more advanced than say whether 2 things are the same or whether they have a certain simple factor of difference, as what you could possibly say about data expands you need to account for this, and it imposes extra problems similar to 2, which generally means you need more data to have a similar level of certainty of your result. This often comes up for machine learning applications, and Neural Networks are notorious for having gigantic requirements for such data even when they are very simple, but at the same time often also delivering much better results than the uncertainty in the results that the math leaves to it. Deeper Neural Networks rely a lot on that magical better result to actually get things done, because they amount of data they would need to not have math uncertainty problems are just so stupidly high that we generally are on unsafe grounds with them.

[@k2c2]

what if agile is used in teams that are generally weaker (need more guidance), and thus they would fail with any other methodology?

[@jonreznick5531]

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.

[@alexpetrov3289]

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

[@steffenbendel6031]

Isn't the motto "fail early, fail often" - mission accomplished.

[@paulreilly5987]

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.

[@Pruemedia]

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.

[@jacmkno5019]

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

[@velorama-x]

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.

[@kevinkkirimii]

Fully agree with Prime, Agile is a struggle with less experienced engineers or those not motivated to learn or exert themselves.

[@methanbreather]

some of the best software was written AFTER the handbook for it was compiled. just as food for thought.

[@EricTomlinson]

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.

[@MikeC1]

Sat down for a conversation on project management, got T & A. I wish that's how the job worked. 😏

[@michaeljmeyer3]

"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.

[@bitwarper]

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.

[@vincent_sz]

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.