Study Finds 268% Higher Failure Rates For Agile Software Projects (theregister.com) 265
Richard Speed reports via The Register: A study has found that software projects adopting Agile practices are 268 percent more likely to fail than those that do not. Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it's cracked up to be. The study's fieldwork was conducted between May 3 and May 7 with 600 software engineers (250 in the UK and 350 in the US) participating. 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."
According to the study, putting a specification in place before development begins can result in a 50 percent increase in success, and making sure the requirements are accurate to the real-world problem can lead to a 57 percent increase. Dr Junade Ali, author of Impact Engineering, said: "With 65 percent of projects adopting Agile practices failing to be delivered on time, it's time to question Agile's cult following. "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." [...] Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed. Worryingly, workers in the UK were 13 percent less likely to feel they could discuss problems than those in the US, according to the study.
According to the study, putting a specification in place before development begins can result in a 50 percent increase in success, and making sure the requirements are accurate to the real-world problem can lead to a 57 percent increase. Dr Junade Ali, author of Impact Engineering, said: "With 65 percent of projects adopting Agile practices failing to be delivered on time, it's time to question Agile's cult following. "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." [...] Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed. Worryingly, workers in the UK were 13 percent less likely to feel they could discuss problems than those in the US, according to the study.
Classic (Score:5, Insightful)
Middle management rectangle-heads always run the same plays from the same playbook. Let's argue about Agile instead of addressing the problem we're trying to solve.
Re:Classic (Score:5, Insightful)
Coding to the request/order instead of coding for the request and recognizing potential problems you should head off with subsequent check code is why shit works and stays working.
Agile sucks, because its money driven.
Re: Classic (Score:5, Insightful)
Shocked, just shocked, to find gambling . . . (Score:5, Informative)
IOW, yet another cult-trendy buzzword turns out to be a less effective way of doing things than just doing them.
It can join ISO-9000, TQM, and so many more. Ooh, how can I forget six sigma while I'm at this?
Re: Shocked, just shocked, to find gambling . . . (Score:3)
Re: (Score:3)
Tell us more about your experiences working for Microsoft. I'm especially interested how Agile kept you from being able to put your pet feature into the OS.
Re: (Score:3)
Every mgmt method is fraught and will fail sometimes - even with the best and brightest running it. The latter of which is rare
Good mgmt systems aren't 'must be x' and that's usually the problem.
The biggest mistake I'
Re: Classic (Score:5, Funny)
Re: Classic (Score:5, Insightful)
Waterfall IS ideal, depending on your problem. Saying otherwise is merely buying into the hype that justifies Agile in the first place.
What matters is what the values and priorities of the project are. Saying that waterfall, a bullshit term in itself, is not "ideal" is merely stating that you're defining the project to be biased against traditional project management techniques.
"There is more than one tool in the agile toolset and if you arenâ(TM)t adapting agile to your project and team, then youâ(TM)ll surely fail."
There is less than one tool in the Agile toolset, and if you're adapting Agile you're doing it wrong.
Re: (Score:3)
An alternative to Agile is Waterfall.
But these aren't the only games in town.
Re: (Score:3, Informative)
Re: Classic (Score:3)
I have experienced both and agile as it was done was worthy of a circle in hell. Not as bad as telemarketers, but worse than a bad HOA.
You can tell MBA types dreamt it up (Score:5, Insightful)
No consideration of how most developers actually work when doing green field - ie spend a long time thinking about HOW its done then DO it. With agile they want you start the do part from the beginning.
Also the pathetic teenage style buzzwords: epic, sprint, standup, burndown, scrum etc , and people putting feckin post-it notes all over a whiteboard then moving them all around during the scrum.
Unless they're using Jira then its an even bigger clusterfuck.
Re:You can tell MBA types dreamt it up (Score:4, Insightful)
https://agilemanifesto.org/aut... [agilemanifesto.org] is stacked with developer credentials. But the manifesto does not mention endless meetings and ticket management. That came from the MBAs,
Re:You can tell MBA types dreamt it up (Score:5, Insightful)
Agile has constantly changing deliverables, thus no project conclusion. Unless there are concrete deliverables and a measurable end, meetings are endless if there are meetings at all.
Agile is not agile.
"And on top of that: every agile method uses time boxes for EVERYTHING."
Yes, an infinite number of time boxes resolved only by project failure.
"If you do 'endless meetings"then you are doing it so wrong, "
True.
"...it is so far from agile, it is beyond believe."
No, it is exactly Agile.
Re:You can tell MBA types dreamt it up (Score:5, Insightful)
One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.
What a surprise - if you don't count the hard part (getting clear requirements) as part of the project, then your project is less likely to fail. But how many projects with BFUD did not even make it to the "clear requirements documented" phase?
Re: (Score:3)
Agile is not the opposite of "clear requirements." Agile simply derives those requirements incrementally, rather than all at once. Lacking clear requirements is a recipe for failure, whether you use agile, or whaterfall.
Re:Classic (Score:5, Informative)
The lead of this study proposes a different software project methodology, which they claim has a project failure rate of 10% (versus 65% for Agile). So on the surface, they are "trying to solve" the problem of software development taking more time or money than expected.
On the other hand, it's all in service of selling a book by an author whose previous book was "How to Protect Yourself from Killer Computers", so there may be some exaggeration or hyperbole involved in the promotional pitch.
Wizard in a cave VERSUS 1000 monkeys (Score:4, Insightful)
Agile and XP suck rocks and make coders miserable and angry? Well, yeah! That's the whole point. Massive oversight by management and some social review group (or a horribly distracting and counterproductive "pair programmer") to keep them knowing their place and limit any one person's productivity or creativity. It's a giant conformity-fest.
Re:Wizard in a cave VERSUS 1000 monkeys (Score:4, Insightful)
This is really at the core of Agile, although it could be said in a number of ways. At its core, Agile refuses to acknowledge the mythical man-month.
Agile demeans the individual worker, claiming he is entirely interchangeable and replaceable with anyone else. It promotes the manager and process and disrespects the learned experience and skill of technical people. It places no value on what managers cannot do and places all value on what they can. It prioritizes interfacing with the customer over proper design and specification. It refuses to even acknowledge the wizard, claiming all the doers are merely monkeys.
"Well, yeah! That's the whole point. "
Exactly, how else can you justify giving management the big paychecks and shitting on the workers?
"It's a giant conformity-fest."
And also a convenient way to attach scores to individual contributors using meaningless metrics while not having to do the real work of being a good manager.
As someone... (Score:5, Insightful)
...who has gone almost into a burnout and has had three colleagues actually go into burnout because we had a dick manager who had a boner for agile, all I can say is AH-HA!!!!
I don't even care about how scientific this study is, for one I'm just gonna bathe in the holy light of righteous "I fucking told you so!"
Disclaimer: We were a service provider and had nothing to do with software development. We spent like a third of our day documenting and scheduling work instead of actually getting work done at the end.
Re:As someone... (Score:4, Funny)
...who has gone almost into a burnout and has had three colleagues actually go into burnout because we had a dick manager who had a boner for agile, all I can say is AH-HA!!!!
Well then you should buy the book [engprax.com] that solves all the Agile problems!
Re: (Score:2)
Can you get me some stones to drain anxiety energy? I'm sure you sell those too.
Re:As someone... (Score:5, Interesting)
Despite Agile's dominance in software development, 81% of UK and 89% of US business leaders are concerned about the timely delivery of projects. The success rates for transformation initiatives are alarming, with 96% of Agile transformations and 70% of digital transformations failing. Just 10% of companies that enter restructuring survive the process.
Personal transformation success is also exceedingly rare, with only 7.5% of smokers successfully quitting despite 55% attempting to quit each year and just 1.8% of obese individuals maintaining a modest 5% weight loss over five years.
Enter “Impact Engineering,” a groundbreaking methodology that reduces Agile project failure rates by an astounding 6.5x and offers psychologically proven strategies for successful personal and business transformations. Presented in the engaging format of a business novel, this book uses extensive case studies and rigorous research to revolutionise the approach to failing projects and catalyse meaningful change.
So, Impact Engineering is better than Agile to quit smoking or to lose weight?
All those groundbreaking, revolutionising and catalysing Methodologies only exist to make managers and other middlemen sound important.
Re:As someone... (Score:5, Interesting)
I'm just gonna bathe in the holy light of righteous "I fucking told you so!"
Yeah, I've been screaming about it for 20+ years. Not that this will make any difference. "If it didn't work, then they weren't really doing agile. Read the manifesto."
It's all just so stupid...
Re: (Score:3)
Sounds a lot like the argument young communists make :D.
Re:As someone... (Score:5, Interesting)
True Agile has never actually been tried.
Agile cannot fail, it can only be failed by imperfect teams.
Hell sprints with hour-long stand-ups full of finger pointing is not really Agile, it's only a temporary phase of the revolution before true equality and the dictatorship of the codetariat as described by Marx's, I mean Beck's, book.
Hmm... I'm really liking this metaphor.
Re: (Score:2, Interesting)
Re: (Score:3)
But sure it's questionable that we're even doing capitalism in the first place.
Bro, do you even capitalism?
Re: As someone... (Score:2)
Re: As someone... (Score:4, Insightful)
My absolute favourite abuse of Agile is when managers use it to get engineers to make âoecommitmentsâ for what theyâ(TM)re going to get done a particular sprint, instead of understanding that the exact point of it is that itâ(TM)s flexible when it turns out a problem is bigger than you thought.
Re: As someone... (Score:4, Interesting)
This, plus having people holding the role of Scrum Master who have no development experience, no training, and very little idea as to what Software Development is all about.
I have first-hand experience with this. My PMO has been saddled with a "Scrum Master" whose previous position was as a bookkeeper. We also brought in a "Project Management Specialist" who was a manager who couldn't handle his management job but couldn't be fired for....reasons.
Under circumstances such as these, no framework or philosophy can be successfully implemented and projects will flounder and fail.
Re: (Score:3)
... having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout."...
But that's literally what Agile was designed to support. Empowering the Developer and User to determine their time requirements and prioritize what their limited time is spent on. And by DOING THIS, you end up with timely delivery on things that matter. That is "Agile" conceptualized in a nutshell.
And NO ONE DOES THIS!!! Everyone focuses on the benefits so much that they throw out everything that can lead to them. Going back to a chaotic development process, just with new tools and lingo. Every time
Re:As someone... (Score:5, Insightful)
Re: As someone... (Score:2)
How can Agile/Scrum even work at all? (Score:3)
I want to know how Agile/Scrum even work at all? In places that did Scrum, every day was a 4-6 hour standup meeting which meant at most half a day to code if you didn't want to go overtime. Plus, because the meeting was the project manager (who was part of marketing) excorcorating every dev and sysadmin for stuff not done, threatening them with being outsourced or mocking their reasons, it was an extremely stressful half of the day, so by the time one decompressed, you might have an hour or two before end
No shit (Score:3)
But “impact engineering” is likely just as stupid as agile. I don't know anything about what impact engineering is, but given that it's a methodology that means it likely sucks. Don't get me wrong Agile is terrible, but peddling some BS impact engineering crap is like saying cobras are terrible, here get bitten by a Viper instead.
All these methodologies seek to take power away from the engineer and hand it to an idiot who can't code for shit.
Re: (Score:2)
What's impact engineering? Throw the shit against the wall and hope the impact will make it stick?
Re: (Score:2)
Works 300% of the time with "AI".
Re: No shit (Score:3)
"All these methodologies seek to take power away from the engineer and hand it to an idiot who can't code for shit."
Nah. This shit is mostly seeking to find a way for lower management to communicate with middle management. If your team estimates 2 weeks and it's not done in 3 weeks, these methods seek to provide a (possibly) data-driven narrative about what happened, where the project is, and how the delay is being addressed.
Agile is Fragile (Score:5, Insightful)
Agile requires too many ducks to be lined up properly. Bad apples and bad management can derail it too easily. Maybe in a well-managed org it can fly well, but most orgs are semi-dysfunctional, at least in IT.
Re: (Score:2)
How is this a problem of Agile? if people don't tell you what they need, you will fail regardless.
Re:Agile is Fragile (Score:5, Insightful)
If a management methodology can't handle a typical working environment, it probably isn't much of a methodology.
Re: (Score:2, Insightful)
If you've got bad apples and bad management you're probably going to make a mess of things in any case...
Re: (Score:2)
True but some messes are easier to clean than others. Your method should produce the smallest messes not the greatest successes. No one cares about huge success. Hitting near the target is good enough 99% of the time. They care about avoiding huge career ending failures.
Re: (Score:2)
It's possible a given technique works better or worse in chaos than another, but those being compared have a different ranking profile under good management: the right tool for the job, where "job" may be the org structure.
Agile appears to degenerate into a time-wasting ritual under dysfunction.
Re: (Score:2)
Sure, but a method that can tolerate average people being the ones practicing is better than one that requires top 10%.
The median person working is going to be slightly below average at any given job (I would accept slightly above, but I think there are more exceptionally good than exceptionally bad in general).
We have methods to help people be more effective, and at a typical workplace that's going to mean making averageish people more effective.
(I'm not saying agile requires everyone to be top 10%, it was
Re: (Score:3)
That's because of how management sees "agile" (Score:5, Insightful)
To incompetent management it's a thinly veiled excuse for not having to specify what they want because development has to be "agile" and react to their latest whims and pipe dreams.
Re: That's because of how management sees "agile" (Score:5, Insightful)
Re: That's because of how management sees "agile" (Score:5, Insightful)
There is exactly one good idea in Agile and that is to always have a working product. No, that's not unique to Agile, but it is the only reason that fractal of absurdity doesn't fail 100% of the time. It's what allows oversized teams pounding on bloated monstrosities to ship on something like a regular schedule.
Re: (Score:3)
Re: (Score:3)
The trick is to develop the two versions concurrently, just like you'd do for an LTS release.
Re: That's because of how management sees "agile" (Score:3, Insightful)
It's not on the client/customer/management to understand how to spec something out or be able to imagine the impact of a decision in a complex scenario. That's on the developers.
If you spend a week in meetings hammering out details, then spend 8 weeks developing, then UAT decides it's not right, that can lead to 10 weeks of wasted work. If - instead - you hammer out some broad strokes with stakeholders then spend a week building something, you'll improve the end user's ability to figure out more specificall
Re: (Score:3)
It's easy to justify anything if your examples are not tethered to reality.
But sure, if your use case looks like what Agile theoretically does well, then maybe Agile makes sense. That's an empty set of use cases though. Perhaps if the world only developed web pages, then web designers helping "end user's ability figure out more specifically what they want" might make sense. Imagine designed a real-time system critical for supporting life that way.
Same problem (Score:2)
Re:Same problem (Score:5, Insightful)
The baby analogy is a good metaphor of why agile fails in all but the best planned software projects.
See, if your project is 100% comprised of small work efforts with 100% defined input and expected output and all you have to do is put it into code, then agile is super!
Only real life never works that way. Real life projects have dependencies toward entities you have little to no control over. And then you start pushing task cards around your weeks.
In a software project where all interfaces are known quantities, you can code each function whenever you damn well please and at the end they'll fit together nicely like a puzzle. But even the best devs will miss an important point or caveat, will misremember how a command works and so forth... so code will change and interfaces will change because things don't work how you expected them.
The moment you step outside software development, things get even worse when you have to wait for hardware that's late or the specs turn out to be different as the sales rep has promised you and so forth. Single points of contact get sick at the most inopportune of times and your daily business still produces tickets from irate customers that expect you to solve the issue NOW and not in the 50% of the week your scrum master reserved for "Other" tasks.
Re: (Score:2)
Probably should have clarified the baby analogy: It's the managers belief that 9 women can together deliver a baby in a month.
Re: (Score:2)
Of course they can: 9 women get pregnant at the same time. Each month each woman produces 1/9th of a full baby.
Therefore they are producing 9 * 1/9th = 1 full baby unit per month but it would take 1 woman working alone a full 9 months!
Ta da!
Re: Same problem (Score:3)
Re: (Score:2)
Ugh. I was managing a small team of devs at this one place, each working on a separate product for different customers.
Micromanaging inexperienced CEO adamantly insisted on using agile and showed at the daily scums which he dragged for 2 hours and religiously followed the jira tickets.
How odd that only 1 of the projects was both correct and reasonably on time.
But at least we had agile! It was misery for the entire team. CEO made promises to customers based on 8 hour days and even gave them jira access "t
Coders are like tradesmen (Score:4, Insightful)
In the trades, there is a plan, often for planning and zoning, but mostly to ensure customer expectations and trade expectations are the same.
Before going into that, this article compares Agile and Impact Engineering. It says a lot that relates to tradesmen (below):
https://www.developer-tech.com... [developer-tech.com]
Tradesmen (carpenters, plumbers, electricians, wallboard, texture, painting, etc.) have developed their systems for ages.
These methods, developed over hundreds of years, typically include an initial plan, and then if there are moves/adds/changes (MACs) to be made, some allow them to be made inline (for a fee) and some after the initial job is done, inspected, passed (for a smaller fee or often at cost+).
Agile has some good ideas, like working with the customer. However, their desire to provide frequent updates, allow MACs in the middle of the process, require all communication to be face-to-face, and PUT OUT SOFTWARE and WE'LL FIX THE DOCUMENTATION IN POST are all reasons for failure. The Register makes this clear without analoging to existing systems.
Even something as simple as taking your car to the mechanic "to fix a rattle" and halfway through THAT job saying "Oh and my lights flicker when it's cold" add cost, complexity, and in modern computer schedule drive shops - an entirely new work order to be processed only once that "rattle" is fixed. To be fair, if you ALREADY KNOW the rattle is coming from the alternator, and it seems worse when it's cold, ALL those details should have gone in the original work order. Replace one alt or reg and you're done.
Does Agile suck? If a project follows their manifesto to the letter the results will not be as good as traditional methods.
At the end of the day if you want to please the customer
- Make sure you and the customer are in 100% lockstep as to what the deliverable is or is supposed to do
- Set timeline everyone is comfortable with.
- Deliver the product; evaluate customer comments; fix ; repeat
I left that face to face thing for last because COVID-19 and WFH vs RTO is a hot topic. However, in a team of N
participants, requiring them all to give up N hours per meeting where they only get to participate an average of
1/N of the time is a loss of (N-1) man-days.
There's a reason email and the various chat/collaboration forums exist - it means you don't have to have everyone
leave their work, stop eveything, and go chat with (N-1) other people whom may not have anything to contribute
to this particular phase of this particular project (assuming you can keep the meeting on task.)
Re: Coders are like tradesmen (Score:2)
"[Agile's] desire to provide frequent updates, allow MACs in the middle of the process, require all communication to be face-to-face, and PUT OUT SOFTWARE and WE'LL FIX THE DOCUMENTATION IN POST are all reasons for failure"
Someone hasn't read the Agile manifesto. Your idea of what agile is seems to be based on some former team's SDLC, not agile. You really think one of the most popular methodologies of the past 20 years can't accommodate a remote team (pre-Zoom era) because communication isn't face-to-face?
When you can't be bothered to read the principles (Score:2)
Check out the "face-to-face" part of https://agilemanifesto.org/pri... [agilemanifesto.org]
Have a great day.
Re: Coders are like tradesmen (Score:5, Insightful)
Re: Coders are like tradesmen (Score:3)
Hi. Agile enthusiast here. Iâ(TM)m a working coder and a manager and a consultant and a trainer all in one.
I firmly believe that Agile methods such as Scrum or Kanban are NOT for any type of work. Misery comes from mis-matching tools to jobs. Pounding a wood screw in with a hammer is possible, but really sucks, and doesnâ(TM)t result in high-quality work. Applying Scrum to non-complex (in the Cynefin sense), non-product development, non-software work is a guarantee of misery. Applying the values a
Re: (Score:3)
And the proper response to a request for change is to say, "We can prioritize that. What existing work to be done are you proposing we postpone in order to accommodate your change?"
If a team, including "management" or "product owner", is unable or unwilling to realize that then it is doomed to failure. It doesn't matter if the team uses Agile, Waterfall, or any other methodology.
Crap Post/Article (Score:3, Insightful)
This "guru" is selling its concept of "Impact Engineering" over Agile.
Let me be more clear: it's about a person with a bias to its own way of software project management that he is pushing as an alternative to Agile.
He even "conducted" a "research" to demonstrate how faulty others are doing and then he came as the savior with his book and his "Impact Engineering" methodology.
Re:Crap Post/Article (Score:5, Insightful)
It's okay. We can acknowledge that Agile is terrible while also ignoring his stupid wannabe alternative.
You don't need a buzzword framework to manage a project. If you think you do, you probably shouldn't be managing projects.
Different methods for different people (Score:5, Insightful)
OTOH, I've worked on a 3 year project that had a quarter page of very vague specs. It grew from something simple into a monster where we kept adding warts over warts. It worked but nobody can understand its structure anymore.
Re: (Score:2)
All specs beforehand is great when all specs are known and clear. That is sometimes the case, it definitely isn't always the case. In many software situations building a minimum viable product and developing it on the go is the only actual workable solution. Remember agile is "new" and back in the day "Product delivered when its finished" was the norm, but evidently far from a guarantee for success.
That said I've seen plenty of boneheadded things done "agile" as well. Like building a industrial processing p
Different methods with similar needs (Score:3)
I have worked on projects where we had clear requirements and ones where we were exploring the future. The latter are hard, and you really need a "product owner" in the room if you want to succeed.
If you deny specs to a waterfall project or a product owner to an agile one, they'll fail.
If you invent a new kind of project, it will need the equivalent. QED (:-))
agile (Score:4, Insightful)
agile is a liturgy based on the success story by a highly skilled and motivated team working on innovative stuff with high uncertainty in a very special environment, compiled by the one guy in the team who's primary skill was being good at selling bullshit.
ofc greedy and incompetent upper management would buy the cool aid and put a bunch of greedy and incompetent middle managers in charge of every trivial project to supercharge their engineer teams, fail miserably and deflect responsibility. what else?
on the bright side ... few things have made me laugh so hard at work!
No true Scotsman... (Score:3)
GIGO (Score:2)
Agile Manifesto is fine (Score:5, Informative)
The Agile Manifesto [agilemanifesto.org] is fine. For anyone who actually hasn't read it, please do so.
What isn't fine, are the people who take "agile" to mean "let's have no plan", "let's not bother with requirements analysis" or "let's change the requirements continuously".
Also at fault are the clueless managers who think that something like Scrum is magic. In my experience, it doesn't matter whether you use Scrum, V-Model, or whatever. What matters is the quality of your team. Good developers, with good leadership, will produce a quality product. Scrum may actually be counterproductive, because it leads to the problems mentioned above (we're agile, we don't need a plan).
Re:Agile Manifesto is fine (Score:4, Insightful)
I am not a software developer.
I read the Agile Manifesto for the first time just now; it says nothing. The whole thing boils down to "make things that work and satisfies the customer."
Well no shit.
Maybe the reason people take Agile to mean "let's have no plan" is because Agile itself doesn't actually have a plan? "Do the thing good" is not a plan, it's basic common sense.
=Smidge=
Re: (Score:2)
I read the Agile Manifesto for the first time just now; it says nothing.
The Agile Manifesto was/is a reaction to big company and big government tendencies to produce endless documents, and never get around to the product. I worked on the government side of a software contract, where it literally took a forklift to life the palette of printed documents. In that particular case, the software also got done, but...don't ask about the total cost.
The whole thing boils down to "make things that work and satisfies the customer."
Yes, that's the point. Actually making things instead of just talking about it. And making things that the customer wants, because you actu
Possibly true, but can't be taken seriously (Score:2)
All pro-Agile and anti-Agile discussions aside, it would be easier to take this seriously if the upshot of it wasn't:
A study commissioned by company A, which invented methodology B, finds that methodology B is better than methodology C.
Not a magic bullet (Score:2)
Like all other methods, techniques and ideas, Agile works well when it's executed by capable people in a productive environment. And it's a trainwreck when executed by incapable people in a toxic environment.
Not method turns a crappy project manager into a good one. At best it can prevent the worst parts of a really shitty one, or guide a capable but inexperienced one.
The best idea in Agile is actually to get rid of the project manager. Of course, that idea didn't survive two seconds once project managers p
Cargo cult programming (Score:4, Insightful)
The reality is that if you go in with a clear idea of what you are trying to do, and can break it down into achievable steps then that's 95% of the process right there. Conversely if you go in with a vague idea what the end product is, or allow the customer to vacillate or change their mind (some processes encourage them to) then it should not be surprising when things go to crap. Doesn't matter if the thing was designed up front or iteratively, either way there is plenty of opportunity to mess up.
Beyond that, all development methodologies are just cargo cult - do the incantations and somehow by magic you get a product. Lead a pious life according to the burndown chart, say your velocity prayers and offer up points to the estimate gods. And when reality disagrees with all this BS, it's obviously because people weren't praying hard enough.
Re: (Score:2)
> if you go in with a vague idea what the end product is, or allow the customer to vacillate or change their mind (some processes encourage them to) then it should not be surprising when things go to crap.
I am disappointed but not surprised that people ever thought 'Agile' was a good idea in the first place.
"We'll just keep changing as we go as a rule rather than an exception"... and people thought this would work despite literal decades of software project management experience available to show it is a
Requirements (Score:2)
I responded in our daily standup with a story from Neil Postman:
A village in Estonia in the 1800's had a problem: a disease was running through the villages that caused you to either get flu-like symptoms and die, or get flu-like symptoms, APPEAR to die, and suddenly recover 3 days later. The villagers decided they needed to fix this problem, so they broke up into two groups to brainstorm.
At
But ... but ... (Score:2)
Well damn. (Score:2)
File a Jira story for it and we'll get it on the kanban board.
View from the Trenches (Score:5, Insightful)
I'm a working software engineer with 40+ years of experience. I've worked on more projects than I can recall - some big, some small, some government, some private. And I worked on projects long before Agile even had a manifesto. Here are my top-line thoughts:
- Today's 'agile' is actually scrum, because the methodology is prescribed, rather than invented locally, as per the manifesto
- Today's methodologies are no better than yesterday's assortment of methodologies - my teams' success rates have always been high and Agile was never a noticable contributor to that success. Rather, team make-up was the critical factor.
- A thoughtfully staffed engineering team has little need for a one-size-fits-all methodology
- Larger teams (50+) need at least some over-arching structure
And here's the cynical side of my opinion:
- Scrum has done little more than involve unqualified managers in what is essentially an engineering effort
- Burndown charts are a waste of time. We sometimes look, but seldom care
If we'd ham we'd've ham and cheese if we'd cheese (Score:2)
"...projects with clear requirements documented before development were 97 percent more likely to succeed."
No shizz. Nobody's knocking clear requirements. The problem is, they are never clear beforehand. So it's better to stop pretending they are.
AI impact (Score:3)
IMO Agile will eventually win though, because it's not a code development process it's a specification development process.
Coding will eventually become free, the new process will be to write a requirements document in stages refining as you go and use AI to generate the code and tests and to run the demos.
The process will stop when the customer gets what he can live with even if it is not quite what he originally envisioned.
Re: (Score:2)
Luckily "Impact Engineering" is here to save us. It also cures smoking and obesity! [engprax.com]
Re: (Score:2)
Oh, look, another stupid fad. Just what we needed.
Re: (Score:2)
Oh, look, another stupid fad. Just what we needed.
It's just some schmuck shilling a self-help book, not a real fad.
Re: I have to laugh... (Score:5, Insightful)
Re: I have to laugh... (Score:4, Insightful)
I bet your world view is skewed in all sorts of interesting ways due to your misunderstanding of statistics and reporting.
Re: I have to laugh... (Score:2)
Re: I have to laugh... (Score:4, Funny)
Re: (Score:3)
Step right up folks! See the Dunning-Kreuger effect in action!
Re: (Score:2)
You might not like it, but the math is correct.
Re: (Score:3)
Did you use Agile to come up with your post? It clearly didn't meet the MVP.
Re: (Score:3)
The projects fails as the OP fails at maths.
Quote: " 268 percent more likely to fail "
Eh... Nope. A "100%" is EVERY project. So saying "268% more" is like saying that EVEN thinking about projects fails.
They should have said "they fail 2.68 times more times" or "their ratio of failure is 2.68 times higher".
Whether they have a 268% higher failure rate or a 2.68 higher failure rate is saying the same thing. What I find myself asking is: Higher failure rate reltative to what? The average for all other project management methods? Some other project management method in particular? A bunch of chimps randomly typing away at Windows workstations while being managed by a pack of angry hyenas? As far as I can tell the main gist of their results is this:
Re: (Score:2)
You should have checked the AC box.
We have the AC box so people won't embarrass themselves when they say knowingly dumb shit.