A humorous response to the AgileManifesto, written by ScottAmbler and submitted to the August edition of SoftwareDevelopmentMagazine.  Sadly in many cases it is more truth than fiction.

http://www.drdobbs.com/architecture-and-design/the-fragile-manifesto/184414888

----
Scott concludes : ''As you may have gathered, this has all been an April Fools' joke.'' No joke. I've been involved in several projects for which my management expected me to adopt exactly the strategy exposed with exactly the same rationale. That's not fiction, that's history. Or sociology.
----

''Another instance, reposted without permission from elsewhere in cyberspace:''

'''The Fr''''''Agile Manifesto (Version 2.2)'''

We are uncovering more profitable ways of developing software by doing it fast and making lots of money.

Through this work we have come to value:

*     Profits and deadlines over individuals, interactions, processes and tools.
*     Mostly working software over elegant software
*     Customers whose checks clear over customer collaboration directly with development
*     Responding to changing directives based on market research over following a technical plan

That is, while there is value in the secondary items, we value the primary items more.

We follow these principles:

Our highest priority is to satisfy the customer through rapid and on
time delivery of software that mostly works, and to provide affordable
(but profitable) customer service in those cases where it doesn't work
out.

We code to the requirements, because the development cycle is too short
to implement any changes (unless those changes are absolutely
necessary). If there are no requirements, we do the best we can.

We deliver working software frequently, every few months. Not during
actual development, because customers or other departments might ask for
changes that would make meeting deadlines harder if they knew what we
were really developing. Developers must never communicate directly with
customers. Under no circumstances should developers ever communicate
directly with sales or marketing unless fighting over a parking space.

Business people and developers must work together every now and again
throughout the project. But not too often, because programmers don't
like meetings and it wastes time that could be spent hacking in code for
the latest marketing checkbox.

Development must not provide code or executables to test until the
official test cycle begins. To do so earlier might result in feedback,
and we all know what that sounds like. Feedback slows development
because we might develop the wrong thing, and if we had feedback we
might have to start over. It's much easier to say, "It's too late in
this cycle to change that."

Build projects around individuals who like to get paid. They'll do what
you ask without much pushback. Give them a computer and supervise them
continuously until the job gets done.

The most efficient and effective method of conveying information to and
within a development team is to ask for surprise demonstrations with
only a few minutes notice.

Kind of working software is the primary measure of progress. Integration
should be delayed until late in the process so that nobody gets
distracted by other people's work. This recognizes that all developers
think that all other developer's work is crap. Avoiding technical
arguments is key to the Fr''''''Agile process.

Fr''''''Agile processes promote not putting too much effort into development
and even less into design. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely. Except when they must
work overtime during integration, and then we recognize them publicly
for their extra effort in keeping management looking good.

Every developer is responsible for their own work, and is not strongly
encouraged to share code with one another; communication takes time, and
makes meeting deadlines harder. It's cheaper to rewrite code over and
over than to have valuable programming time spent talking about esoteric
subjects like "architecture". Every programmer should use only the tools
and class libraries that they are already familiar with, because
learning stuff takes time away from meeting deadlines.

Simplicity is important, but maximizing the amount of work done is
essential. Doing your own design and implementation independently of
other programmers helps to ensure that your code can't get more complex
than you can understand by yourself.

The best architectures, requirements, and designs emerge from
self-organizing teams. But we recognize that you don't need any of these
to make buckets of money. This is especially the case if individual
programs don't get too large and unwieldy. The program as "object" keeps
programs from getting out of hand.

Meetings of any kind involving developers are to be avoided if at all
possible. Meetings take time away from producing code. Communication
between programmers can only lead to coding standards and architecture,
which only distract programmers from the immediate task at hand;
building programs that reach the market first so they can be sold
quickly and profitably. There is no shame in being second, but there is
no profit either. The first vendor to lock in the customer base wins.

Keep projects small. No project should require more than two man years
of development. If projects accidentally get large due to their
popularity, release maintenance releases with gradual evolutionary
improvements or break it up into separate individually maintainable
products.

Under no circumstances ever throw away old code. We recognize the value
of code that's kind of worked for many years. It's been tested by
hundreds of users and it's been sort of fixed over the years. That gives
it value. New code will have new bugs. Never, under any circumstances
refactor code unless absolutely necessary.

Change and retraining are expensive. New development technologies should
be adopted only when the old development technologies are no longer
viable. Only those technologies that are widely accepted by the entire
software development industry should be entertained. Choosing a new
development technology is primarily a business function, not a technical
one.

Avoid the implementation of standard file formats and data interchange
methodologies insofar as is possible. If you create a migration path for
your customers to escape, many will undoubtedly do so over time. Obscure
binary file formats are our friends.

Always pick projects that are neither too vertical (such as internal
enterprise applications), nor too horizontal. Find a niche market where
the customers are non-technical. This is important to avoid competition
from those pesky open source communists in Europe.

Branching code in your revision control system is a great way to stay
out of the other programmer's way. Time wasting multi file refactoring
is thus discouraged, because it would make merging branches later too
difficult.

We value swamp guides over architects. Building a four lane highway
across the swamp tomorrow is less important than keeping the alligators
from chewing body parts off today.

Always remember that while the programmers down the street working for
the struggling startup are writing elegant code, our paychecks are
actually signed.

--KellyAnderson