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.
The excerpts of the study published in the article do not inspire confidence either:
1. Agile ("Agile Requirements Engineering") is defined as: Development starts before clear requirements, no complete specification, significant changes late in development.
I think even those who are opposed to Agile would agree that's a severely lacking if not completely incorrect characterisation of Agile development practices. It sounds more like a list of things that would cause an Agile project to fail.
2. Impact Engineering is defined as: Use of all engineering practices studied which increase success rates.
Why doesn't the author dare to give any properties of Impact Engineering up front? This sounds like he's just baiting for people to buy the book so they could learn what magical engineering practices are studied therein. It smells scammy.
Then of course you'll get a buggy second system that is back at square 0 which the business doesn't understand/hates and the developers hate because they're constantly fighting fires.
I say this because no matter what methodology is used there will be spaghetti code regardless, mid tier devs like to over engineer solutions, junior devs don't know better and do whatever is first on stackoverflow.
Business execs also don't ever know what they want so change a system half way through when they see prototypes so then you still end up with Franken-systems.
To that end, you might as well start with a half spec'd system as it saves time.
It didn't.
> Just build it and figure it out as you go.
That sounds like hundreds of waterfall projects that I was pulled into after they hit the 1/2 way mark and we're running behind because of unexpected scenarios.
Having been on the “customer” side in such companies, I’d say the improvement is the result of more frequent interaction which improves mutual understanding.
The internal customers are forced to think through requirements in detail (albeit in pieces). The developers are forced to explain what they are doing.
Too many projects I’ve seen suffered from a lack of communication. Customers would hand things off (“just build x”, lots of customization requests that aren’t thought through). Developers would start guessing and working in the wrong direction, often going on complicated tangents as a result of the customizations).
Consulting Agile as you call it really helps both sides to understand what’s actually needed and how to get there.
"Agile in doctrine" is the kind all of the anti-Agile crowd rail against because they've been burnt by working for some company or manager who drank the Koolaid without actually understanding what Agile is. Blindly following some consultant's Agile playbook is not Agile.
"Agile in spirit" is a bit like The Zen of Python: X is usually better than Y but there are times where it makes complete sense to do Y. In order for Agile to work, you need to have leaders and CIs who understand that. Agile emphasizes communication and flexibility. Agile is advisory, not prescriptive.
Agile — scrums, scrum masters, epics, stories
agile — http://agilemanifesto.org/principles.html
Agile is a bunch of rules and processes to follow.
agile is an ideal to strive towards, and never perfectly reach.
—-
Edit — this bit from the article is probably the important line
> However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves.
Agile is not the same as agile.
At least in this humble dev’s mostly irrelevant opinion.
At that point, if you are doing those things, there is a certain amount of validity to the criticism that if it didn't work, you really weren't doing it right. Either something external jammed you up so you weren't able to adapt and truly follow agile, your team was personally unable to execute on the adaptation for some reason (structure, personality issues, experience levels, being simply too large to be able to be this flexible because large teams simply need more structure), or the task was simply too hard in the first place for some reason (such as "it doesn't matter how agile and smart the team is, you're not getting 4 people to produce a standards-compliant browser that is also an office suite in six months").
Evolving the methodology to suit the team, product, and company in an additive way seems the best outcome I’ve seen.
Rarely will I have daily meetings, we can slack. Maybe twice a week hop on a call.
For story points I’ve seen models of using Fibonacci sequence, having 4 categories rated which then convert to points, or even (less desirable) 1:1 mapping to days of work. Personally I like the 4 categories approach, it feels less subjective as a whole despite each category being subjective to a degree
And in the end, if process gets in the way of productivity, I say go for it, we’ll either go back and document what happened or refine the process later (though rarely if ever have we skipped QA for good reason)
This to me is the core of agile: the people doing the work have the flexibility to adjust to match their goals and needs. So much of the consultant-industrial complex comes down to finding ways to helping business people who aren’t willing to give flexibility or clear requirements ways to not do that which don’t sound like saying no.
If you applied the same reasoning to any other iterative self-adjusting process, you’ll find they all tend to fail before the iterative aspect has been applied. Because that’s their nature, they’re iterative processes as a mechanism to respond to failure.
I almost laughed out loud. Isn't that agile? :P
These days its been devolved into micromanagement musical chairs of pain. The kind that promotes what it professes to prevent and provide.
> People over processes
and
> Responding to change over plans
And capital-A-agile is literally a textbook process.
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.
Most so called agile coaches are scrum prescriptivists in my experience.
But pushing useless stuff that doesn't work and then leaving, yea that's not agile :P
I worked on one team that had this and it was amazing. It implicitly helped with burnout too. It was an "Agile" team, but we followed more of a scrumifall model that worked well for that project.
I've been on a bunch of Agile teams (some more than others) since then, but the requirements processes are all garbage. Then the leaders wonder why things take so long, there's so many bugs, burnout is high, etc. It's really not surprising.
Once a process was created the business would have to sell any process changes to the product owner by either showing it was a regulatory/legal issue, or using a cost study to show it would save money. So not back and forth or superfluous changes.
...Frankly I think all the standups & the pressure from constantly asking me if I am contributing (every single day?!) instead of trusting that I am... burns me out.
I don't mind 2-3 standups per week, 15 mins max.
But 5x 30 minute standups... Is exhausting. It feels like a lack of trust from product managers.
Oh yeah... and unqualified, zero engineering experience, diversity-hire product managers. That's super annoying-- being managed by people who did not obtain their role via the route expected of an engineer (having demonstrable engineering skills)
I haven't really seen this, but a poorly performing product manager or product owner completely breaks the scrum or agile model (to the extent it works at all). They are assumed to basically know the domain and know what needs to be built at a high level, and the software requirements originate from them in the scrum model. If they don't know what the requirements should be or how to communicate them or how to collaborate with the engineers on the requirements, it is completely garbage-in-garbage-out. On the other hand, working with a product owner who is a domain expert and happy to help define software to solve their needs can be a joy.
And it’s not a test of your contribution. It’s part of being a team.
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.
And the fundamental problem is that agile is completely incompatible with the way most enterprises are built. A truly agile team talks to the users of the product, and they have complete control and responsibility over the development process. That just doesn't happen because managers want to manage, and as much as developers would like freedom, they'd often rather not have the responsibility.
Can you really say it is misunderstood if 90+% of people are "doing it wrong"?
Is it a useful thinking framework if there is a 90+% chance of "getting it wrong"?
I would NEVER buy a tool which advertised only a 10% success chance, so why are we falling for scrum?
A lot of us were doing some form of agile before someone came up with the word agile.
I'll give you an example:
Imagine the process of creating a retro video game. First, you might write a function that clears the screen. Next, you'll get something simple drawn. Maybe just a simple block. Then you write a function that allows you to move the block with a controller. Then you swap the block with some sort of character animation. Next, you'll write a routine to draw girders. Then you'll implement gravity. Etc., etc. You'll just keep iterating until you have a well-balanced and engaging game.
That's agile. You may have had a lot of the game designed beforehand, or none. In fact, you could even create the game design documents with the same method. Make a quick first draft, get feedback, make adjustments, and repeat. And then keep going back to it whenever you notice something doesn't work or some better idea comes along during the course of development.
Originally, agile had nothing to do with rigid meeting schedules. Or "adapting to changes," or whichever buzzwords people like to throw around.
They want the name (scrum, agile ...) without paying for it through the reorganization the would be necessary.
I started programming long before "scrum" or "agile" or even "XP". One consistent observation I've made around every methodology that comes along is that management manages exactly the same way they used to manage after they roll out the methodology as they did before the methodology.
*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.
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.
What constitutes agile is basically a matter of opinion.
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.
- 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")
- If you read reviews for the book it's totally AI generated nonsense
I've been reading that 50+% of software projects "fail" ever since I started programming in 1992 (long before the term "agile" crept into our lexicon). They consistently fail because they consistently have deadlines but no actual definitions. That was true before Agile, was true during Agile, and will be true after Agile.
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.
How did they even measure "success" if the requirements weren't given up front? What did they expect at the end?
Everytime I hear an engineer complain about this, I ask them if you wish the PM would just write a PRD full of guesswork tasks and you execute on them unquestioningly.
The main innovation of agile is showing failures early and thus being able to quickly react and correct course, meanwhile in the waterfall the project spent most the time in a quantum superposition without possibility for correction.
Why not?
> 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
That is an incorrect characterization of Agile. Maybe some "agile" companies use it as an excuse to avoid requirements, but that is definitely not part of the process.
If you fulfill the role of a supplier of a component in a bigger product (especially in an industrial setting), you cannot "try to build something".
People are not happy if you tell them that you want to iterate on their control system and deliver incremental value, or tell them that it's not possible in the contractually agreed way.
> That is an incorrect characterization of Agile. These are also the cases where you just have to work out overarching requirements upfront.
Fundamental to agile is to have clear requirements, the time is not fixed.
With reference to the quality (scope), time, and cost triangle, each of the major methods picks one point to emphasise, another to fix (not allow to change), and another it manages the change of.
Agile wants speed so time is its emphasis, it does that by fixing cost (over a release period) and allowing changing scope, and it does that by limiting the features that go into a release. That doesn't mean that the features required should be unclear. I will deliver these 5 features out of 30 in the next 2 weeks at X dollars. If one of the features isn't ready, we'll drop it. No, I'm not doing features 6,7,8 till later. Yes, you can change you mind about what you want for later releases.
Lean emphasises quality and fixes cost while allowing time to change. You can get your burger for X dollars but you're 5th in the queue, you'll have to wait.
Traditional is about predictable cost, it (tries to) fixes time and allows change in quality to remain on budget. If everything goes to plan you should come in on time and on budget but maybe with less features or worse features than you wanted.
Of course, we know that traditional done badly produces over-budget, over-time projects that don't do what they were supposed to. It seems that agile methods are being used as cover for bad management because, as this entire thread is evidence of, there is widespread misunderstanding of the basics of project management. If you're going into an "agile" project and the requirements that you have are unclear then you need to kick up a fuss and hold the PM and the product owner to account. They should certainly be clear by the beginning of each sprint.
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.
If you are talking about customer expectations, yes, you can manage customer expectations. As long as you are honest and upfront, customers tend to be forgiving.
On the other hand, if you are talking about a core API or building block that downstream APIs will depend on, then no. You can't deliver a API that writes to the database/storage layer that only works 90% of the time.
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.
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.
"Let's have a huddle on the question of whether we have too many meetings?"
(She tended to use a rising terminal in a very passive-aggressive, velvet-glove-on-iron-fist sort of way.)
That’s always a bad sign people justify with the work load generated by these same busy bodies
* 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
> if you have a project that is Very Important To Succeed, a team might be more likely to adopt waterfall
You'd just recognize that they are better for that task.
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.
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.
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.
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.
> 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.
It'd be interested in seeing that argument in the wild. Mostly I see complaints like yours when people point out that an hour-long daily that the manager uses to harangue the developers isn't actually agile, and that is perfectly true. Or that a blame-assigning retro or measuring dev productivity using story points is not actually agile, which is at least true insofar that it clearly is forbidden in Scrum, and stupid in any case.
Though I find it interesting that you end with kanban -- an agile methodology. It seems you do like to use agile after all, just not scrum.
Sounds pretty agile to me.
While the "defenders" of agile might be employing No True Scotsman fallacies, it's detractors (which I personally seem quite a bit more numerous on HN) are often doing the same in reverse: refusing to define what "agile" actually means, and just throwing together a bunch of anecdotes and feelings about excessive meetings and estimates being misused to measure productivity.
I mean - this seems necessary when the agile manifesto is extremely vague and practitioners can't seem to agree on the One True Way to do agile - and in the absence of formal studies and analysis, what else is there but anecdotes?
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.
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.
But in the name of agile, business tends to get away with a lot of bad decisions, at least in the places I’ve worked.
Is it all as bad as it sounds? No, but the times I’ve heard we’re not thinking about design upfront under the name of agile is staggering.
Also what I dislike about the agile way of working is that whenever somebody presents any argument against it, people always say “that’s not agile”. Great. But if it is how people DO agile, that argument is moot.
It’s like REST. Rest is great. But nobody (almost nobody) actually does Rest like described in the original whitepaper. We can’t just ignore the issues resulting from this discrepancy.
> 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 :)
I think Shape Up is one of the most reasonable modern interpretations of the agile manifesto.
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.
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.
Agile is, in my opinion, terrible when you want to ensure the thing never fails.
"Let's slow down development and make sure we've written enough tests" is a phrase I haven't heard too often in Agile.
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.
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.
Sometimes a quick failure is the best outcome.
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.
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.
https://www.engprax.com/post/268-higher-failure-rates-for-ag...
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.
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.
268% higher failure rates over waterfall is a feature not a bug.
- 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")
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).
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
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!"
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.
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.
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
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.
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.
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.
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
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.
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.
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-ag...
The waterfall things we already tried, does not work too great
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.
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-ag...
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.
Aaaaaand close tab
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.
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.