To avoid the Agile crowds inevitable "but, again, that's not agile" (even though that's the agile that exists out in the world) - just change the scenario to:
Customer: I want a house at this location...
Development team designs and builds a house.
Every two weeks development checks with customer, customer is happy!
24 Weeks Later
Customer: Hey everybody, here's our new house.
Another Department at the Customer: We need a house we can drive to the lake.
That's the stuff that happens constantly.
You can follow Agile perfectly and yet customer satisfaction is vastly more complicated when you let them design your software. They don't know to tell you that you can't encrypt certain things because it breaks the workflows of tools they didn't even know their company uses? Or that you can't change the formatting of something because it breaks another tool. That you can't augment the data in their system because it now violates GDPR because they don't know wtf GDPR is? Et cetera, ad nausem...
Let's create a fictional company by which we can answer your questions.
CoolSoft has a vision to create a revolutionary product that crushes the 3D content creation pipeline market (think 3DSMAX/MAYA market.) They're going to call this product Cool3D (ugh...) and their primary target are AAA game development teams.
"Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software."
DUMP - Christ almighty, yes, dump this hideously inappropriate idea. Instead, find world class technical directors that have been living/breathing/eating 3D content pipelines for at least 10 years and who want to create something great - in other words pay for DOMAIN EXPERTISE so you can build the bedrock of your product by relying on their expertise augmented by your own and your teams' synergies.
This one? "Minimally Viable Product" is not a fit concept for a product or technology related company? Really?
NOT AGILE - Classic Agile zealot straw man - as if coming to market as soon as you think you will benefit is something new, LULZ. Of course you build to MVP, people have been doing that for 40 years - this is not an 'agile' thing, only the ubiquity of the term MVP is. It's not a question of keep, it's something you always do, whatever your methodology is (never heard of one that said to over develop for your market...)
"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."
DUMP - Late significant changes should require a drastic evaluation of how you came to your, and require a change control process that includes identifying why your highly paid team of domain experts totally messed up. It's possible the reason is legitimate, and if the opportunity cost balances out the loss of market - go ahead and make the changes. PMs shouldn't count on getting bonuses though.
Do you really think your Product Manager is really infallible? That he won't take advantage of knowing the resulting product/technology as it's going on to perfect his own mind and vision? Really?
DUMP - Cool3D only hires PMs who were designers and/or implementors of AAA art content pipelines for 10 years or more. Nobody knows more than they do, that's why you hired them. They can, of course, make mistakes - but it's incredibly unlikely they'll make mistakes that damage your software in the marketplace.
"Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale."
DUMP - Cool3D thinks this is criminally stupid. It's going to take them 12 months minimum to get to better, and that's not counting the suite of tools necessary for multi-platform integration and their SDKs (ios/android/ps4/xbox/pc.)
See MVP. And then, if you can't produce a working piece within two months, rethink very carefully, since you probably don't understand it well enough as to put your time/money on it. If after deep thinking, you really think a given piece of your solution really takes that long, go ahead, on your own peril. These, after all, are just "principles", not Law from God carved in stone.
DUMP - You clearly have only worked with limited types of software and software companies (maybe not even software companies) because you seem to be unable to imagine scenarios that totally invalidate that type of thinking...
"Business people and developers must work
together daily throughout the project."
DUMP - Holy f*** no - this is the single biggest problem with Agile - and it's almost always wanna-be bullshit PMs (who are really poorly trained project managers) who love to use this crap - because they then have ZERO RESPONSIBILITY for the result. They don't need to know shit, just ask the customer. Cool3D would never even dream about building their software this way - that type of stuff happens in beta.
Do you think your great Product Manager should communicate his wonderful vision to the development minions and then disappear for a year? Really?
Product Managers don't do vision, they're the people who are supposed to translate the company's vision into a market strategy - in other words "okay, we understand the vision, but how do we get there?" This means they either work from an MRD or create one (if domain experts) and then generate a PRD - no software company, even "Agile" ones should be without a PRD (or what would technically be the equivalent.) The PM doesn't disappear, they're there every day answering questions, revalidating their PRD, coordinating between teams in order to produce an aggregated result, working with the Dev Manager or Dev Lead (depending upon your team setup) to manage priorities (which means you can work via sprints or Kanban if you wish, but that's internal - depends on the visibility you want to monitoring the process.) Why would a PM go disappear for a year, even in some crazy waterfall black hole?
"Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done."
NOT AGILE - Again, another bullshit Agile zealot straw man. Oh, before Agile, nobody built projects around motivated people. Nobody gave developers an environment of support. Nobody trusted people. Oh, wait, if Agile trusts people to get the job done, why don't the developers manage the backlogs and why are there reviews? LOL.
I have problems even finding a viable alternative to the above one, so go figure!
"The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."
Have you *ever* really find other more efficient method? That even the best written down specs doesn't benefit from a face-to-face with their authors to clarify the most obscure/difficult points? And then, "most efficient" doesn't mean "only one".
DUMP - Another bullshit strawman. Why is having a PRD and a face to face every day mutually f***ing exclusive? The whole point to writing shit down is so that if your PM quits, is fired, gets hit by a bus, takes vacation, or can't keep track of every decision that results in Cool3D having a 3 million LOC codebase - you've got a reference. Oh, and if you ever hire another QA, dev, PM, or marketing person - guess what? They can get up to speed by reading the PRD and know what the f*** is going on without spending 3 days with the PM.
Like any religious movement, some Agile people love to create ridiculous black/white situations that (a) aren't black or white and (b)aren't mutually exclusive.
"Working software is the primary measure of progress."
Talked from the developer's perspective. Can there really be any other measure of progress?
NOT AGILE - again, there's no reason to have software that doesn't work until you're ready to release, it should be testable ASAP. Oh, wait, as an Agile guy you would rather use the market as QA, right...
"Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely."
WTF? This is true, but it's also true of methodologies other than "Agile" - shocker - if you do it correctly, just like Agile needs to be done correctly.
Unless death march is your hobby, of course!
Damn, you haven't done much Agile with a real live customer if you haven't been on an Agile death march, LOL! Every methodology I've ever seen is equally subject to this problem, but usually driven by different reasons. E.g., for a spiral project it tends to be time to market compression, or another market driven factor such as a competitive first mover leading to changes. For Agile, in a project appropriately using Agile, it's a commonly customer who doesn't know what they want (and oh, those are so rare, right?)
"Continuous attention to technical excellence
and good design enhances agility."
Really? who would figured that!
NOT AGILE - Wait, before Agile existed people didn't pay attention to technical excellence continually? LOL.
"Good design enhances agility"? Sorry, Good design has got absolutely f*** all with agility - unless one of your design goals IS agility.
At Cool3D that wouldn't be necessary because you have the absolute best customers in your PMs themselves - which is why you pay them so much.
"Simplicity--the art of maximizing the amount
of work not done--is essential."
NOT AGILE - Common to anything,
Ockham's razor in action. Valid for any complex project, isn't it?
"The best architectures, requirements, and designs
emerge from self-organizing teams."
Humm... one that can be argued... at least! But, now, think of the chances of your great Product Owner to achieve any goal if he doesn't manage to be recognized as an trust-worthy figure to follow. That's also self-organization.
DUMP - Yeah, best architectures and requirements and designs emerge from self organizing teams? Not at Cool3D, they're not going to led some 5 year C++ dev tell the woman who built RockStar San Diego's art pipeline that he thinks his ideas are better than hers, lol. Oh, and the 3 yr Python 'veteran' wants his P2P node based network architecture to be used instead of the Cool3D Chief Architect's scalable/reliable multi-region/multi-provider architecture... Yeah, good idea. Hey, maybe these 'Agile' guys could "trust" the PMs and the architects to do their jobs... I seem to remember you suggesting that.
"At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly."
Continous improvement anyone?
Now, really, you can tell that this is too general to be put in practice as-is but are you really arguing these are not (mutanda mutandi) desireable principles for basically *any* human endevour?
Wait - Agile invented the post-mortem? The dev cycle review? Feedback meetings? Progress reviews? Holy sh**, how did we do all that before Agile came around and told us it had value?
Look, as I mentioned previously, for the right job - Agile is 100% the best approach - but it's a TOOL IN A TOOLBOX. Right tool for the right job. It's agonizing watching large companies, who aren't software companies, misapply Agile and f*** it all up - primary because (here I go again) of "Agile PMs" - In other words Product Managers with zero domain expertise in a job where their primary value is their domain expertise...
...its pervasiveness.
It's a valuable tool IN A TOOLBOX.
If you're NOT an ISV, and you make software solutions for individual customers (which is what the vast majority of software developers find themselves doing) - then Agile is probably the right way for your company to go.
If you ARE an ISV (and Independent Software Vendor makes products, unlike the folks above who work on PROJECTS) then use Agile at your peril.
ISVs that use agile are those that tend to have "Product Managers" who are not actually Product Managers, but are instead "Project Managers" with a penchant for making products up out of virtually thin air ("Oh, a customer wants this, so this must be part of the 'product.')
ISVs that know what they are doing start with Product Managers - because a Product Manager has DOMAIN EXPERTISE that means they actually know what the market wants - not just a single customer. The problem for wanna-be ISVs is that real Product Managers are expensive and difficult to find (but they're out there) due to the Product Management market being swamped with Project Managers calling themselves Product Managers.
If your company has a technology or product related vision - you should not use Agile.
If your company has a market dominance or growth related vision, and you make software tailored to a specific customer's needs - you should probably use Agile.
...and post them all over FaceBook now that they're "free speech"
BTW, it takes a little over 200 million years to completely rotate around the center of our galaxy (i.e. a 'cosmic year')
You seem to be forgetting that the neutrino has been traveling to us for, apparently, 4 billion years. The speed at which galaxies move over 4 billion years is significant - not to mention the rotation of our galaxy relative to the orientation of the speculated galaxy is huge.
How could they possible track where the neutrino came from given their incredibly sporadic observability for measurement, a spinning earth, a spinning solar system, a spinning arm of the milky way - and 4 billion light years distance?
The article says they notified astronomers of a patch of sky that was a candidate for the source - how could this be correct if our galaxy is spinning?
Again, apologies if this is a dumb question, but thank to Einstein I think everything's relative - especially the orientation of bodies
If you're not going to be hybrid (which gives you other opportunities) then you simply DNS load balance between regions AND cloud providers. Easiest way? Containerize.
The complexity comes into play around your databases, but there are a myriad of well known solutions to all of these problems.
There's no other rational way to provide solid service that to spread your risk.
Setup DNS Failover (or load balance if you prefer)
Setup in multiple AWS regions.
Setup in multiple GCE regions.
Optionally setup for Azure
If you're really paranoid, have an on premise instance somewhere local to you (or a metapod in house or something similar.)
Containerization makes all of this vastly simpler than in the past.
As many others have mentioned - don't trust anyone to be up all the time, trust that at least one of them will be up all the time.
Ridiculous. While non Republicans (Dems, Libertarians, whatever) are made up of fallible human beings just like Republicans - this story is interesting BECAUSE it's a Democrat acting like a Republican. The majority of Dems are for Net Neutrality in some shape or form that most people would recognize as 'neutrality', the majority of Republicans are against those forms of Net Neutrality.
It's like saying that because there are (something like 4 or 5) pro-choice Republicans that "Republicans are just as beholden to the pro-choice mafia as Democrats."
(I'm pro-choice myself by the way, and independent.)
Isn't its methodologies - it's the fundamental premise that it's a solution for everyone and every thing.
If you're building custom solutions for anyone (consumer, SMB, Enterprise) - Agile is likely your friend. Go with Agile.
If you're building a consumer facing web application - Agile is possibly your friend, it depends on how clear a vision you have. If you're not sure - go with Agile.
If you're building a PRODUCT (something you expect to use unchanged - excepting, of course, new additions and features) for the Enterprise - Agile is NOT your friend - but it is most certainly the friend of the integration team who will be deploying your PRODUCT into that enterprise.
Agile is hugely beneficial in the right scenarios - usually a scenario where the people who want something don't know what it is they actually want - they just know they need something fixed.
Agile is hugely detrimental in the wrong scenarios - for example when you have a company that hires 'Agile Product Managers' who are NOT domain experts; ergo, they have no idea what is or is not good for the target market verticals.
The other problem with Agile is that they created (somewhat accidentally) a strawman argument to establish themselves - that if it's not agile it's some kind of horrifying version of 'waterfall.' In other words, a black and white situation that's simply bullshit.
I've run teams where Agile was the only reasonable approach - and it worked well for us. I've run teams where Agile would have been a disaster for us and a waterfall/spiral type of approach worked well for us.
Tools in a toolbox people - just like operating systems, languages, patterns, testing methodologies - et cetera. Right tool, in the right place, at the right time.
Know them all (or as many as you can) - know their strengths and (sometimes more importantly) their weaknesses.
The really interesting time is when you build a startup and as the company matures, so does everything inside of it (technology, operations, organizations, processes, et cetera.) You may spend 90 days head down and very NOT agile, and then at seed round embrace Agile because it's right for you. You may be agile for a year or two until you close an enterprise deal - and then perhaps you re-evaluate using Agile - or modify it.
The point is (that I am very poorly making) - You need to know when Agile, and/or some particular aspect of Agile, is or is not appropriate for you and either embrace it or distance it. Don't fall for marketing hype, or the legions of people who cover their incompetencies (primarily in the world of Product Management) by hiding behind it.
...you trained a multi-layer perceptron on gruesome images, then submitted 'impossible' to classify images to it and it matched up against the only other things it's seen before?
Wow, who could have guessed that would be the outcome...?
He has not acquired a fortune; the fortune has acquired him. -- Bion