13 ms·

Study finds 268% higher failure rates for Agile software projects

• affinepplan 2y ago
  this smells very much like selection bias, in that it seems pretty plausible that * if you have a project that is Very Important To Succeed, a team might be more likely to adopt waterfall * if you have a project you just want to trial and don't care if it fails, maybe agile practices are more likely
  • betenoire 2y ago
    I don't think that's what a selection bias is. If I have two cars, and electric for getting around locally, and a guzzler for road trips, you wouldn't call it selection bias if I always chose the guzzler for the road trips. You'd just recognize that they are better for that task.
    • svnt 2y ago
      There is choosing the right tool for the job, and then there is evaluating the tools against each other on the properties specific to the job. If after making your tool selection you went on to author a study about how gas cars result in more frequent bathroom breaks while driving, without controlling for the length of the trip, you’d be doing what these folks did, and that’s selection bias.
  • dustedcodes 2y ago
    > if you have a project that is Very Important To Succeed, a team might be more likely to adopt waterfall Yes, but that is directly in contrast with what Agile promises to do, namely helping teams to succeed.
    • Attrecomet 2y ago
      Not if the project succeeds because it was important enough for more resources and time to be allotted.
  • dstroot 2y ago
    I like to think about it like this. If you are building a skyscraper in Manhattan you need a plan. It has to be engineered. The materials must be specified and ordered long before construction starts. There are engineering practices and building codes that create a measure of safety. There is an order to the construction process. The project plan would likely be called “waterfall”. If you attempted an agile approach of dropping off a team and saying for our first sprint let’s just dig for two weeks, then we’ll plan what’s next is not going to cut it. Agile on the other hand is great for smaller, less complex efforts where the desired outcome is “fluid”. Different methodologies work best for different things.
    • gedy 2y ago
      All I can say is the big waterfall projects I was on pre-agile had excellent planning for the wrong things, and took up most of the time allocated for the project. So we were out of time, the quality and people suffered. Another project was cancelled because we took so long planning, the company lost interest.
  • HelloNurse 2y ago
    There are more direct selection biases in the study: "projects which had clear requirements before starting development were 97% more likely to succeed" because hitting a moving target is more difficult, with all methodologies.
  • TheCoelacanth 2y ago
    Also, how is success vs failure defined? Whether you implemented what you intended to on time and on budget? That's a reasonable definition, but it doesn't capture whether the project actually achieved the business goals it set out to achieve. For many projects, it's better to fail quickly than to succeed and then discover afterwards that it wasn't worth doing the project.
• 000ooo000 2y ago
  >Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, Aaaaaand close tab
• paulsutter 2y ago
  Clear requirements are needed regardless of methodology. The simpler (briefer) the requirements, the more likely to be understood and followed. Iterative development processes can leverage more concise (and thus clearer) requirements > One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. Also, if a project doesnt have requirements, how can it either fail or succeed? EDIT: agile is one type of iterative, and iterative exists in contrast to waterfall. go ahead flame away :)
  • AlotOfReading 2y ago
    I can count on one hand the number of "agile" projects I've seen that were actually iterative, regardless of what the manifesto says. It would be a mistake to confuse what this article is talking about (projects that profess to be agile) with anything based on small, self-organizing teams.
  • boxed 2y ago
    Clear requirements without an artifact to test against is impossible. That is my main focus when thinking of agile. I think Shape Up is one of the most reasonable modern interpretations of the agile manifesto.
• karaterobot 2y ago
  > However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. Is the author an Agile coach? This is the classic response when people observe that Agile has failed to transform their team: you're doing it wrong, the problem is you. When systems seem good in theory but tend to fail in practice, you should just try to learn what you can from them and move on to the next thing.
  • hk1337 2y ago
    Honestly, 99% of the time people are doing it wrong. People are either too strict with it or too "loosey goosey" with it. *EDIT* It doesn't have to be correct, it just has to work for the people on the team. If it works, then use it, if it doesn't then change it. That's agile.
    • fook-dang 2y ago
      [flagged]
    • crowcroft 2y ago
      If people can only ever get into the goldilocks 'not too strict, not too loose zone' 1% of the time, then it the process is by default not fit for purpose in almost any circumstance. Likely the 1% of the time it works is the rare case that you have a small and exceptional team working together, in which case the project management methodology is unlikely the reason they are working well.
      • hk1337 2y ago
        You don't have to, just find what works for your team and use it. It may not be perfect or exactly how it is supposed to be but if it works then use it.
        • deleted 2y ago
          [deleted]
    • 2y ago
• giancarlostoro 2y ago
  Most times I've been in a doomed to fail agile project, it was almost always a manager or higher who overpromised with deadlines, not accounting for real world blockers. One of said projects has insanely awful app store ratings for their mobile apps.
• VikingCoder 2y ago
  Agile is great when you want to see if you can make something work. Agile is, in my opinion, terrible when you want to ensure the thing never fails.
  • lioeters 2y ago
    "Ensuring the thing never fails" is a question of having plenty of tests, which can be practiced as part of an Agile methodology. In fact, it sounds more agile to write tests while (or before) you develop a feature.
    • VikingCoder 2y ago
      Sure, if the Product Owners get that. "Let's slow down development and make sure we've written enough tests" is a phrase I haven't heard too often in Agile.
      • lioeters 2y ago
        That's very true. Same with refactoring, there's never any time set aside to clean up and reorganize the code after it's written.
• kevin_nisbet 2y ago
  I'm not really sure what to make of this article, it says itself it's a study commissioned by promoters of another methodology. If they're consultants trying to pitch their consulting services, they need these types of things to sell. But my fundamental reaction is, what does failure mean. Because in my world view failure should be expected and accepted and learned from. It's entirely possible to spend a bunch of time avoiding every possible failure mode, and really not delivery much value at all... but we've successfully avoided the work being considered a failure.
  • pavel_lishin 2y ago
    The article also doesn't go into what kind of software was being produced, etc. If you're building control systems for the ISS, or an interplanetary probe, of course you need requirements hammered out pretty well before you start development; you can't just continually push updates out incrementally. But if you're building Yet Another CRUD App at your startup's third pivot, then getting every requirement written down beforehand is virtually impossible.
  • fisf 2y ago
    > But my fundamental reaction is, what does failure mean. Because in my world view failure should be expected and accepted and learned from. That's fine in some domains. It's not acceptable in others (i.e. you cannot just try things and see if they stick). But regardless of that, you still want to minimize failure. So if one methodology (Agile) pushes to spend less time on fixed and clear requirements upfront, and this leads to higher failure rates, this is still an issue.
    • trickstra 2y ago
      Agile is about reacting to changing requirements. If the requirements never change, then agile doesn't promise to be better than other methodologies. It came from a rapidly changing crashing markets in the .com bubble. How would the other methodologies fare if requirements changed two or three times in the middle of the project? That's when you need to be agile. How did they even measure "success" if the requirements weren't given up front? What did they expect at the end?
• simonw 2y ago
  This very obvious PR stunt appears to be based entirely on redefining "working software over comprehensive documentation" to mean "don't gather requirements and don't write a spec". Here's the report itself which makes it very clear that the survey was commissioned deliberately to help promote a book about an alternative development process: https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds https://www.engprax.com/post/268-higher-failure-rates-for-ag...
• wild_egg 2y ago
  Article source seems to be mainly an ad for some agile alternative which makes the whole thing suspect. Most of the "results" can boil down to: scope creep kills projects. That's entirely independent of whatever methodology your team follows and they don't make it clear how their "Impact Engineering" concept would address it
• kristopolous 2y ago
  This is such a strange phrasing. The problem with "agile" is when it becomes manager-heavy and meeting-heavy. The last firm I was at was ridiculous. One project had about 30 hours of meetings a week. There's no time to get any work done. It's just lopsided manager bullshit. That's the actual criticism, not some strange dichotomy of things being successful if only it was meeting, manager and also authoritarian focused with some specs decreed by some deputized opinion makers with holier than thou thoughts they wrote down two years ago.
• peeters 2y ago
  I can't find any link to the actual study or even a description of its methodology. The research appears to have been done for the book Impact Engineering, which introduces the new methodology, and yet the research also claims to have measured projects following that methodology. From the marketing summary here [1], it seems like what they actually did was to isolate which individual virtues of various methodologies had an impact on project success (which also goes without a definition of course). Then they choose which of those individual virtues would be promoted by their new methodology, and use projects adhering to those virtues as a proxy for scoring their new methodology. And then claim the result as statistically significant. It would be interesting to see if this was the actual methodology, because if so, that's clearly nonsensical. Also, it would be highly relevant to know the definition of success here. Evaluating an Agile project's success as "completition of the project's initial requirements on time" would be completely asinine, given the entire point of Agile is to adapt to changing requirements. [1]: https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds https://www.engprax.com/post/268-higher-failure-rates-for-ag...
• riffic 2y ago
  maybe it's for the best? fail fast and move on with what you've learned. 268% higher failure rates over waterfall is a feature not a bug.
  • boxed 2y ago
    Yea, failing fast and cheaply can be enormously valuable. In fact, of the projects that "didn't fail" one can wonder how many of them are still in a death march.
• moi2388 2y ago
  I’m sure that agile done right is great. I’m also fairly sure most organisations don’t do Agile right. At least within my organisation, we do not design anything up front. We’re agile. We don’t think about proper api modelling. We’re agile. We also do barely any testing. We’re agile. We do rewrite the UI a dozen times based on user feedback. After all, we’re agile.
  • trickstra 2y ago
    Can you point to any of the 12 principles which says that we should do "barely any testing"? I can point to some that say "deliver working software" and "it's the only valid measure of progress". If testing helps you deliver working software, then do testing, that's agile.
    • Attrecomet 2y ago
      I think you missed the invisible /s tags to those sentences.
      • brazzy 2y ago
        Sarcasm does always, without exception, sabotage a factual discussion into confusion about what people are actually saying (because that remains unclear even when you fully recognize the sarcasm).
      • trickstra 2y ago
        True. Unfortunately I've seen similar arguments discussed unironically before, so I just didn't catch it here.
  • thaanpaa 2y ago
    > At least within my organisation, we do not design anything up front. We’re agile Agile doesn't mean forgo design completely. > We don’t think about proper api modelling. We’re agile. See previous point. > We also do barely any testing. We’re agile. It's difficult, if not impossible, to be agile without testing. If you want to move fast, you want to be confident that your latest change didn't break anything. > We do rewrite the UI a dozen times based on user feedback. After all, we’re agile. Sounds like you built a complete UI before any users could give you feedback. That's the opposite of agile.
• dangerwill 2y ago
  It's funny, the root of the idea is that Agile allows teams to change how they are doing things midstream so we can constantly improve. But I have never met a scrum master or PM who has both the authority and the desire to advocate for changing how work is done. So all it ends up being in practice is a series of rituals that people sleepwalk through.
  • AnimalMuppet 2y ago
    If you're not hacking the process, you're not agile. "We are agile according to this rigidly defined process" is an oxymoron.
  • commandlinefan 2y ago
    Dilbert captured it best: "Our boss can't judge the quality of our work, but he knows when it's late". For everybody doing programming work, there are ten people tasked with making sure it's done by the "due date", whether there's any value in that due date or not.
• boxed 2y ago
  > "Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout." I almost laughed out loud. Isn't that agile? :P
  • Aurornis 2y ago
    Every agile coach always tells me that agile is whatever works for the team. Conveniently, if something isn’t working they dismiss it as not true agile. Of course, all of the processes and meetings they push on to the team don’t actually work out, but they’re long gone by then.
    • boxed 2y ago
      I mean.. "science" is what works too. If something turns out to be false, we throw it out and say it's not science. This is good. I don't see a problem with this at all. But pushing useless stuff that doesn't work and then leaving, yea that's not agile :P
      • giantg2 2y ago
        Science has proven methodologies to it and those are explicitly taught, followed, and reviewed. Agile coaches offer no real guidance if the bulk of the advice is "do what works". No shit...
        • boxed 2y ago
          The methodologies were discovered after the fact though. The only real scientific method is "if you are a winner you are with us". In fact, plenty of scientific methodologies are NOT tested and probably super bad, like the modern peer review system, or grant writing/proposal/reviews.
          • giantg2 2y ago
• CSMastermind 2y ago
  Obviously, it's a biased study that shouldn't be taken seriously, but while we're on the topic of Agile: Consulting Agile, grew out of web development consulting firms as a defensive methodology for managing shitty stakeholders. They incorporated some genuine industry best practices, but they also have a lot there that's simply meant to blunt the worst impacts of having to deliver software in an environment where the person paying you doesn't understand the basics of software development (or project management really). It actually works pretty well in those environments - you don't get hyper-productive engineering teams, but you do get somewhat consistent delivery and a stable enough working environment that the worst outcomes (not delivering anything at all) are avoided. No large tech company that I'm aware of implements this type of Agile but plenty of big non-tech companies do. If you have a CIO in your company and the business refers to software engineers as 'IT' there's a good chance you do this. This is inefficient but it's probably good enough for those companies, especially if it's established, the switching costs alone would be a nightmare. If you're using it as a startup then something has gone terribly wrong and you should seriously reevaluate what you think the future of the company will be.
  • giantg2 2y ago
    Yep, and the big companies basically use Agile as an excuse for not thoroughly planning and vetting ideas. Just build it and figure it out as you go. Then rebuild everything in 2 years since you're left with outdated and unmanageable spaghetti code and you burnt out all your SMEs so they took the knowledge with them.
    • Pet_Ant 2y ago
      Do they ever rebuild things? Or just add features ontop of features till the whole thing creaks.
      • mrbombastic 2y ago
        generally they wait until something explodes or they cannot add any features to the unmaintainable mess and they have no choice :)
• marginalia_nu 2y ago
  The by far strongest correlate of a complete clusterfuck of a project is how often, per meeting, agile is invoked. In fact, I've discovered you can use agile as a sort of meeting hand grenade, if you don't like the direction a meeting is headed, like they're about to decide on something stupid, you can just throw in "wait, is that agile though?" and the rest of the meeting will discuss methodology, never arriving at any sort of conclusion.
  • cjk2 2y ago
    This is my methodology. Set two PMs on each other and go and do some work that generates ROI.
    • yyggvbb 2y ago
      This is a good way to get laid off. A developer has never generated ROI in the history of finance, it was ALWAYS an MBAs idea.
      • notatoad 2y ago
        somebody's got to give the MBAs their ideas.
      • cjk2 2y ago
        I've prevented a lot of losses :)
        • sambazi 2y ago
          what might have been usually doesn't show up in the books though
  • brightball 2y ago
    Yea. I do Fractional CTO consulting and usually have good results with developers because I focus heavily on removing bottlenecks, unhelpful processes and meetings, etc. The challenge is always when you run into sacred cows from other levels of management. - Hard deadlines while acknowledging we don't have enough information to commit to those deadlines - Story points as a measure of time - Absolutely overloaded teams being asked to deliver new features without being given time to improve underlying issues in the system...and then having to constantly stop what they are working on to deal with production issues caused by those underlying problems. It's like clockwork sometimes and the conversations are always hard.
• macNchz 2y ago
  It seems like this is in service of promoting some new competing methodology. I also can’t find any details on the research methods, but it seems like it may be relying on software engineers’ judgment of the success/failure of projects they’ve been involved with, which…I think is pretty questionable. The reality is that there are a lot of software engineers who might describe a project that was hugely profitable as a failure because it has a shitty database schema and lots of dead code because of a last minute change.
  • cbsmith 2y ago
    It looks like, over a span of four days, they had 600 engineers (heavily biased towards UK engineers) answer survey questions. The vast majority of the higher failure rates were for the whether "Development starts before clear requirements, no complete specification, significant changes late in development."... which is placed under "Agile Requirements". Of course, these are things that agile recognizes as factors that create risk, and the methodology is about trying to mitigate said risk as best as possible. So, it's not an indicator of methodology but of the context. Yes, if such risk never presents itself, you are much less likely to fail, regardless of methodology. https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds https://www.engprax.com/post/268-higher-failure-rates-for-ag...
• lushdogg 2y ago
  What about "achieving failure" that is the outcome of many non-agile projects?
• p0nce 2y ago
  Agility is implemented as a way to increase productivity. It does it with more detailed scrutiny of what workers do. Management understood very well that it's taylorism applied to our profession. Taylorism started with measuring every movement of the workers and have their expertise removed from themselves. Daily stand-ups and points kind-of do that, even if there is no magical 4x productivity gain to ever be found, unlike was what won in manufacturing (cf. Braverman). It's a game played against workers, if they self-organized there would be no Agile.
• stilwelldotdev 2y ago
  All I know is that Agile means a lot more meetings and a lot more meetings means I'm a lot less productive.
  • commandlinefan 2y ago
    And it was supposed to mean the exact opposite.
• nsxwolf 2y ago
  Agile vs. what? Who out there isn't claiming to be doing Agile these days?
  • whimsicalism 2y ago
    pretty much all the big tech cos. since i jumped to top tier companies i don't think i've even heard the word agile
• JohnDeHope 2y ago
  I'm sorry I didn't RTFA, but I wonder if there's a correlation / causation issue here. Did the "agile" projects fail because they were agile, or because their project management methodology was prescribed by management than is higher up than appropriate. Maybe they happened to choose agile because it's the flavor de jure at the moment, but it wasn't the "agile" that was the problem exactly, as much as the undue influence of the wrong layers of leadership.
• wg0 2y ago
  Because agile has itself been made so heavy weight that it is no more agile. You have product managers and then you have scrum masters and then there are meetings about whether how pure and religious we were about our agile practices, how pure we were, would gods of agile be pleased with every single second that we spent in past few weeks or our hearts had some impurities deep down somewhere? And no kidding, there are then meetings about those meetings and their outcomes and action items and their evaluation. The obsession with the process itself is a sight to behold. It is now a whole cottage industry, major technology journal and websites have whole sections devoted to just Agile. Consultants, Coachs, Gurus and what not.
• msurekci 2y ago
  "One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed" The issue with a majority of projects are the requirements aren't always clear from the start or even if they are it tends to deviate while the project is in progress. Agile tries to mitigate that by allowing teams to be able to react more easily to changing requirements. That being said not many companies understand or implement agile correctly, unfortunately.
  • kohbo 2y ago
    > Agile tries to mitigate that by allowing teams to be able to react more easily to changing requirements. This often breaks down into a practice where maintaining requirements is not given enough priority and in very short time the actual product has deviated from the documented requirements to the point where they're basically useless and there's no clear goal for any of the features.
• foobarkey 2y ago
  Not a huge fan of scrum ceremonies (besides daily standup) but as long as people dont know what they want before they see it, agile is the best way. The waterfall things we already tried, does not work too great
• mbesto 2y ago
  "Agile" and "failure rates" don't have strict, universally accepted definitions, so any study (even if definitions are described) is essentially meaningless.
• tsunamifury 2y ago
  I’ll never understand the hate for agile on this site. The process is at its core, enumerating tasks to get to a. Goal, prioritizing them, and letting those who do them do them at their own pace and order across a larger team. I’ve run teams that way for decades and never had a complaint.
  • Attrecomet 2y ago
    I think the hate stems from so many people working in environments where either the company has bureaucratized their nominally agile process to the point of absurdity or just having superiors that are in over their head, which makes any kind of methodology a farce; bad leadership can only be mitigated so far by processes, especially of someone has to take responsibility for said processes and that often by default is the mentioned in-over-their-head superior.
• mindcrime 2y ago
  sigh. It's nearly impossible to have a meaningful conversation about anything to do with "agile" these days. And that's because there's approximately zero agreement about what "agile" even is, and all of the various terms are overloaded with 100 different meanings, and every "agile" implementation is different from all of the others. I'll just note that, in my experience, a few things are true: 1. The Agile Manifesto, in and of itself, is great. 2. There is no such thing as "agile development", as a methodology in its own right. 3. There are many "agile" methodologies, including Scrum, SAFe, Disciplined Agile Delivery, Agile Unified Process, Crystal, XP, etc. And then on top of that, every company in the world has implemented their own poorly specified, half-assed, bug-riddled, barely comprehensible implementation of "agile". 4. Approximately everybody misunderstood / misunderstands (perhaps intentionally at times) the Agile Manifesto and bends it to suit their own biases. A classic example is illustrated in this article: One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is "Working Software over Comprehensive Documentation." NOWHERE in the Agile Manifesto will you find any instructions saying "Don't do requirements engineering" OR "Don't identify requirements up front". I promise. If you don't believe me, go read it right now and see if you can find those instructions. What you will find instead, is the quoted admonition to NOT put documentation (possibly including requirements) OVER actually delivering software. But the Manifesto itself clearly says "there is value in the items on the right". Where "The items on the right" include: - processes and tools - comprehensive documentation - contract negotiation - following a plan Unfortunately we, as an industry, collectively managed to myopically focus on items on the left and the "we value the items on the left more" phrasing and threw the baby out with the bathwater. "We are doing Agile" became the excuse to abdicate with regards to the necessity of doing requirements engineering, architecture/design work, documentation, etc. Basically, we swung too far in one direction, and need to move back towards the center. No, I'm not calling for a return to waterfall or anything. I'm saying that we can embrace the principles of the Agile Manifesto and STILL DO requirements engineering, architecture, and all of those other things. A good starting place would be to stop talking about "agile" like it's a discrete methodology (as opposed to a family of loosely related methodologies) and - as organizations - pick an actual methodology to implement and then actually embrace the "empiricism" attribute that Scrum emphasizes (whether or not you're using Scrum per-se)... measure things empirically and actually make adjustments based on THE REAL WORLD not somebody's whack ass theory. Reality trumps everything and I desperately wish we could get everybody to acknowledge this.
• smugglerFlynn 2y ago
  Isn't it the whole point of failing fast? It seems the industry rebooted back into "any project must be a success" mindset, which we all have been walking away from for the past couple of decades. Truth is, there are shitty goals, wrecked scoping, high-risk biz hypotheses, managers cheap skating on resource and talent side, and many, many other things that deserve early failure. All these do fail much faster today, provide valuable early feedback and lead to changes.
• btutt 2y ago
  I don't agree that on time and on budget are the correct measures for determining overall project success or failure. By these standards a multi-year project delivered a single day after the original estimate, or a massively profitable project that went a dollar over the original budget are counted as a failed project. Ideally some actual business outcomes need to be included before determining if a project succeeded or failed. I think this problem persists for a lot of research and discourse about software project success and failure where we conflate whether we estimated accurately with whether or not the project succeeded or met the needs of the business.
  • TheCoelacanth 2y ago
    Also, a project that was cancelled after two weeks because it was determined that it wouldn't be valuable enough is a failure while a project that spent two years building something and then didn't make a single dollar is a success as long as it was budgeted for two years. Sometimes a quick failure is the best outcome.
• ACV001 2y ago
  It's not a study, but a piece of advertisement. That's all you need to know about this.
• ChrisMarshallNY 2y ago
  I've always liked the Agile Manifesto, but it's fairly vague, and leaves a lot of details to be provided at implementation time. I suspect that a lot of Agile is actually "agile™." A branding facade, over an unstructured, ad hoc development system. Not even Waterfall, which is actually a very robust system (just robustly inflexible, which often gives bad results). I like the idea of evolutionary design, and adapting to change, but I have found that it needs to be done carefully, and that having experienced developers; concentrating on results, is a must. As always, I think the proper answer is "It depends." The search for The One True Methodology is one that will never be satisfied. Even different projects, under a single organization, probably need to take different approaches. I just believe that we always need to keep our eye on the end result, and all development needs to be done, with that in mind. I think that (for me), Agile is accepting that we don't actually know what "done" looks like, when we start, but we have to have a heuristic to help us to understand when we're done.
• hugocbp 2y ago
  This looks like more of an "ad" (or a very directed study by a competing methodology), but excess pragmatism can ruin even the most sensible ideas. Agile, testing, design patterns, best practices can all tank and bury a project if applied excessively "by the books" without consideration of the actual problem to solve. I've worked in teams that had about 10 people actual doing dev work that implemented the full suite of Agile "principles" as rules. Daily standups, grooming, retros, pointing as "poker", 1:1s every week. The result was that we had barely time to actual work since the week had 10-20 hours of meetings. Most retros and standups were literally just us saying "same as yesterday, only had a few minutes to work on this" the whole week. Testing is the same. If applied without consideration for the actual problems, reaching that 90%+ code coverage is easy if nobody cares about how hard and time consuming it will be to change code later. Specially when a feature is in very early development. I think all those things are good, but what I see sometimes is that they are applied as absolute rules that cannot be deviated from, which inevitably leads to poor results. I'm now working in a "light Agile" environment with just 2-3 meetings a week, barely 1 hour total, and much less strict PR/testing requirements (we focus on testing the important functionality, not line coverage count) and it is so much better. Some of the same co-workers that were under the more strict rules are now twice or more more productive then before.
• yobbo 2y ago
  The manifesto describes an effect or desirable end state. Not a method. Anything you do that fails to bring you this effect is your responsibility. Coaches are only agile insofar as they are helpful. But this also mean you are free to learn from all possible sources, and you are not bound to any particular method or ritual.
• JohnMakin 2y ago
  In any discussion on this site or others about Agile, you will find a flurry of PM's rigorously defending it with the typical line of reasoning - If you tried agile and it failed, it wasn't actually agile. When you show how it was actually agile, you didn't do it right. When you show you did it right - go back to argument 1. It's a really circular no true scotsman style of argument. Obviously this "study" is not good or even really a study, but I think the general arguments it makes aren't tremendously out of line. I have been an IC on agile teams, an IC on more traditional teams that I guess would be called "waterfall," and I've been tasked with implementing a scrum process both as a team leader and as a PM in my career - I've personally never seen it work on Ops/Infrastructure teams. In fact, I'm convinced it can't. It's far too difficult to determine the scope of work, far too interrupt driven, far too difficult to measure actual velocity, way too easy for engineers and managers to bullshit the system. All the arguments I see in favor of it over the years strike me as pretty dogmatic. The way I like to manage projects these days is a kind of kanban system with a task queue, and 1-2x a week brief cadence meetings to discuss priority/alignment and any blockers. edit: should probably clarify I'm using agile == scrum here, which I know isn't technically correct, but that's how I've seen it implemented in 99% of cases so far in my career.
  • lloydatkinson 2y ago
    I agree with you completely and what you said brings to mind something I wrote on my blog a few days ago: > I posit that if I showed the Agile Manifesto bullet points (without the title) to a group of people with cringe-worthy titles like Scrum Master, Agile Delivery Manager, Agile Coach, or Head of Agile Delivery, and asked them “Is this agile?” almost all of them would say it isn’t. I can only imagine the effect that revealing the title and explaining that, actually, this really is the agile, would have on their Jira-addled brains.
  • whynotminot 2y ago
    > The way I like to manage projects these days is a kind of kanban system with a task queue, and 1-2x a week brief cadence meetings to discuss priority/alignment and any blockers. To me, distilled down to its core, agile is all about faster feedback loops and course corrections. If you’re regularly getting good, actionable feedback on your work, and maintaining alignment, I think you’re living up the spirit of agile. There are plenty of “agile” teams going through the motions, doing the ceremonies, but not actually reaping what the real benefit is supposed to be: frequent, actionable feedback that helps guide and align the next phase of work.
• readthenotes1 2y ago
  "projects with clear requirements documented before development started were 97 percent more likely to succeed." I believe Barry boehm is on record stating that the biggest mistake he made in designing a software creation process was believing people who told him that you could get firm requirements up front. So yes, if you're in that rare case where you can start out with clear and non-contradictory requirements, probably anything you do is going to succeed better than when you don't. There's a good book on risk management that goes into this more, Waltzing With Bears, by Demarco and Lister
• jerf 2y ago
  Don't confuse "the Agile manifesto" with "Agile". I say this neither in attack of, nor in defense of, either one. Make your own decision. But those two things are now diametrically opposed to each other, so this is the sort of word carelessness that will destroy all ability to converse or think about the characteristics of each.
• jmward01 2y ago
  I have only seen three principles work consistently in software engineering: tight iterations, divide and conquer and fixed max sizes. All of these principles work because development is a NP problem and the best we can hope for is a local optimum. In general you see best practice anti-patterns come up that break one or more of these things and math takes over. Take a product backlog for example. In general these backlogs become the one place that everything is put but then you break divide and conquer and fixed max sizes. Since scheduling is an NP problem, if I have an unbounded backlog I have just created an NP problem to solve. the correct way to do things is to admit that you will not find the optimum solution, so the best you can do is break the problem into pieces, assign teams and minimize communication between the teams so that the pieces don't get combined into one again. The teams then need to do the same if the individual pieces are still too big. Massive monolith teams break all the principles and are basically guaranteed to fail. Or they are guaranteed to fail until someone proves that P = NP.
• deleted 2y ago
  [deleted]
• spamizbad 2y ago
  > One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. Having worked with both this approach and agile, I'm not surprised by these results. However, I will also say that writing clear requirements is easier said than done - when those requirements are vague or of even mediocre quality it can very easily send a project off-course immediately. Part of this stems from, in my view, a lack of accountability when it comes to waterfall approaches. If the BAs responsible for drawing up the requirements burn through time and budget that ultimately gets felt by the development team. It requires Engineering Managers to carefully vet those requirements to ensure they're appropriate start work, which results in a tremendous amount of back-and-forth.
  • brightball 2y ago
    Yep. And my favorite is when developers spend far too much time discussing the story point estimate, having long discussions about why something is higher or lower...and then not writing any of it down other than "3" or "5".
• renegade-otter 2y ago
  Agile in itself is not a development methodology - it's a communication one. A small team working on a stealth R&D project, where everyone is same rank and in the same boat, would be suicidal to use Agile. This is what Kanban is for. Agile is an overhead. It doesn't make things faster, or more efficient, quite the opposite. It's there to avoid arbitrary deadlines coming from the management and developers not working on an island, with no visibility. That's a recipe for some nasty surprises. "But we thought you were working on THAT and it would be ready NOW!"
• ChicagoDave 2y ago
  Even with agile, modeling the business and documenting requirements is still important. The difference is that 30 years ago we’d spend 6 months defining requirements in functional and detailed requirements and the larger the problem, the more fragile those documents became. And proper story development is hard. Most “agile” implementations don’t bother to get stories “completed”. It’s an afterthought. Agile works very well if you actually do it well.
  • FeistySkink 2y ago
    Am I misreading this as a No true Scotsman?
    • ChicagoDave 2y ago
      In fifteen years I’ve only seen agile done well twice. I mostly agree it has become a failure. I think the measurements of success become suspect as a project grows in size and complexity. A better way to succeed regardless of pm method is making sure you reduce complexity and scope of any given project.
• brazzy 2y ago
  > One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is "Working Software over Comprehensive Documentation." Someone does not understand (or is intentionally misreading) the meaning of "Comprehensive Documentation". The Agile Manifesto is not discouraging having requirements before you start implementing. It's against having a multi-month planning phase that produces hundreds of pages of detailed specs before you start implementing. Agile development was a reaction to the status quo where that was done - and a staggeringly large percentage of projects failed. It was called the "Software Crisis": https://en.wikipedia.org/wiki/Software_crisis https://en.wikipedia.org/wiki/Software_crisis
• zzzeek 2y ago
  who really does "Agile" or "waterfall" or anything ? I'm in this job for 30 years. I've never seen any formal methods my whole career. it's like here's the thing we need or what the customer needs, gather some vague requirements, write some prototypes, do internal demos, now more requirements are there, more clarity, iterate on the prototypes, etc., repeat. use issue trackers, use "stories", use kanban boards sure, but are we adhering to some rigid notion of "agile"? no way. I can't imagine the "waterfall" method actually working either.
  • oytis 2y ago
    V-Model is a variation of waterfall which is still used in regulated industries (automotive, medical, aerospace etc.) as far as I know.
• EVa5I7bHFq9mnYK 2y ago
  What requirements? Agile is a way for managers to daily and publicly whip devs falling behind their sprint estimates.
• kelseyfrog 2y ago
  Well, yeah. It's impossible to do Agile right. Why would a practice that's impossible to execute correctly have anything other than a higher failure rate? It's Agile's fault and it shows.
• gortok 2y ago
  The study isn't shared, so we can't see the methodology to determine its accuracy. We see the results of the survey; but that's not a study, and the survey itself isn't shared with us. I don't dispute that agile has its issues -- and I'd be surprised if 'agile' failure rates weren't an issue. We can empirically see the result of 25 years of 'agile', and it's not somewhere we should aspire to be. The issues comes down to this: 1. Is adopting an 'agile' methodology sufficient to ensure (insert goal here)? 2. Has the software industry adopted a method of operating that creates a statistical quality control; and adopted practices that investigate and remediate special causes and common causes of variation in quality? To spoil it: for #1 the answer is 'no', and for #2 the answer is a resounding 'no'. There are practices that are ingredients to the world described in #2, but we as an industry have not yet adopted a systematic way of thinking and resolving problems in the software development process. I think we'd be better off adopting Deming's method of management and his System of Profound Knowledge and be far better off than adopting the agile fad of the week; even as I admit I still have open questions on how to apply his work to Software. (See "The New Economics" 3rd Edition, and "Out of the Crisis", both written by Deming).
• prerok 2y ago
  The article does state that the referenced study may be seen as endorsement of this new shiny approach without clear analysis of the problem. What is true, in my experience, is that Agile is poorly implemented across the board. Sprints are just biweekly massive status updates and no developer talks to the customer/stakeholder directly. So, criticism of implementation should not have been underrated in the article. That said, in the referenced study, they are calling some ad hoc development practices without requirements "agile", because they feel like calling it that, and then blaming the authors of Agile Manifesto for not delivering on their promise. Clearly, today, a lot of software management malpractices are called "Agile" and then the fault for the failure is pointed outside of the organization. It's the management's fault, not the Agile methodology.
• OutOfHere 2y ago
  There is no scientific evidence in support of Agile. Its supporters, usually Scrum Masters and the like, will go to any length to save their pointless job.
• karmakaze 2y ago
  Confounding variables. It's possible that riskier projects use agile because they're less well defined to begin with. The stats I'd really like to see is how many people, how many months, how much money. Hypothetically, one successful waterfall project could perhaps fund 3 failed and one successful agile one with comparable output. My takeaway from the article (which has a "people before process" feel to it): > Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed. Also beware capital-A "Agile", it defines a process devoid of project characteristics, making it not.
• lo_zamoyski 2y ago
  You get into problems when you turn these things into fixed recipes. Prudential judgement is something you must learn and keep learning all your life, and the heart of prudence is humility, which is to say, a submissive attitude toward the truth in place of willfulness (something that comes easy, and is celebrated by our morally bankrupt culture). There are general principles, yes, but the application of them in the concrete and particular, as it were, is subject to prudential judgement.
• bsoles 2y ago
  Complex things (life/political systems/software) cannot be built based on a manifesto or commandments. See where Christianity and communism got us. When you reduce complexity into simple but interpretable phrases, we always open doors to priesthoods (Agile coaches, the church, The Communist Party) who claim to know the right way and try to impose a rigid structure on everybody else in their respective communities. I wish a more scientific method to software development could have been possible. And Agile is not it.
• deleted 2y ago
  [deleted]
• signal 2y ago
  - Based on a random survey of software engineers (who somehow had visibility to project inception & outcome) - Doesn't define project - Success was defined by not violating the iron triangle (so nobody knew what they were saying OR they're working on trivial "projects")