Here is a little ironic reflection on the 12 principles of Agile Manifesto. Scroll to the end of the page to read serious content.

Making fun of methodology

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

In most cases, the highest priority is to get as much money from the customer as possible with least work thanks to a big mouth sales manager, submissive project manager, and coders who know how to kick the bucket of refactoring long down the road.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Almost any software engineer moans and yells when requirements change, because the world should be static enough to fit in his mind work, but not static enough to let him go and stop getting paid for his creation.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Sprint a week is nice, do you agree, fellow developer? winks uncontrollably

Business people and developers must work together daily throughout the project.

It is an amusement and great pleasure to get an answer from BA less than 3 days after the request, most time they are very busy with making your life harder. On the other hand, developers don't really want to get alongwith those humanitarian degree peasants that don't embrace the greatness of another Javascript framework and are not hip at all, a business does not give a damn about developers and requires working functionality here and now(they have not yet decided actual body of work for it, but you gotta do something).

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Motivated individuals are great people with hiring ratio for your company close to zero. Most of the people work to get fed and covered, not to bring value to somebody else's business. Unfortunately, the real world breaks the bright visions of the future when methodology for focused self-controlled motivated professionals is applied to procrastinating incontinent discouraged amateurs.

The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.

Outsourcing reality: your manager is the only in/out source of data to the customer which leads to unfortunate data corruption on the way. Your teammates are not willing to do anything but code and drink coffee, so face-to-face conversations turn into interrogations with an enemy spy rather than friendly convos.

Working software is the primary measure of progress.

Translation from your manager: don't give a heck about legacy and technical debt the size of US national debt until the system starts breaking like a heart of 90 years old coffee maniac. When it does - rush to fix it, but not too long, you are not paid for fixing stuff.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

That is the development pace - you break and rot the project until every new feature implementation process feels like Indiana Jones movie tomb walks, then customer sets you up one sprint for refactoring and fixing the tech debt. After a few hours of fixing customer is confused that the project is still not elegantly ideal.

Continuous attention to technical excellence and good design enhances agility.

Code up and break things, production will signal all the bugs, leave "technical excellence" at the university, we are in the real world of development, where there is only blood, iron and bits... What? Our test suite runs for hours and some components are 3000 lines long? Come on, we bring the value, there is no need to worry.

Simplicity--the art of maximizing the amount of work not done--is essential.

The customer knows best what to do, yep, we had a lot of situations where requirements changed mid-sprint or right after it, even though everyone was digging hard to release the feature no one needs as a result. This is simple - you are paid to code, not to argue.

The best architectures, requirements, and designs emerge from self-organizing teams.

And his left hand did not know what the right did, so they were self-organized as a swan, pike and a crab.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

It is hard to reflect when your manager thinks effectivity depends on the number of hours you spend at the office.

On the serious note

Modern computer industry has a steady flow of newcomers, growing each year, Though, part of them are professional, aspired by the domain, have appropriate education(by themselves or in the university) and would stay in the field even if wages were lower and hype was not there, there is a vast majority of individuals that are here to make money and do the job that pays out most. Those people have different intentions but both types are welcome to the workplace because demand does still outreach supply and from the first sight it is hard to separate one from another(not even going into the debate on moving from one state to the other because or burning out, finding pleasure in coding, e.t.c).

Different intentions, focus and working quality of people directly influence the processes and treatment needed for their employer to reach his goals. Agile was created as a movement for better code, better quality and value brought to energize customers business. It implied that people who work in the field are self-manageable motivated professionals that know what they are doing. And some people are like that, so agile works for them. The others, on the other hand... They are not that independent yet or at all, so at some level methodology fails for them. In can be everywhere, on the business level, on the level of management or development. The fact is that some people are unable to work without process close to Ford factory where they are responsible only for their part of the process and are not required to do anything else.

Fast-food pipeline

Let us draw a cooking analogy. One of the major process features of McDonald's (and almost any other fast food restaurant chain) is steadiness and relative simplicity of their recipes. They try to keep their instructions on how to prepare some meal in a form which can be perceived and reproduced by any sapient human with the expectable result. Such cuisine will never be tremendously delicious, but it will be edible and the customer will be able to have some sense of decent meal even though it won't be anything special. They produce semimanufactures, write recipes and shape processes in a way that will allow the pipeline to produce steady result no matter what cooking skills a person at the kitchen has.

Perfect cuisine

On the other side of the specter, you have an elite-class Michelin star restaurant with a team of dedicated professional chefs that know perfectly well how to cook a proper meal from anything they are given except maybe from milk with cucumber. They know how to team up and work alone, they tried every piece of equipment in the kitchen and know when to use it, they learned to improvise and to be consistent with the recipe to the last word. Each one would have opened a restaurant of their own if they did not enjoy working together so much. They are given a free choice of products for their meals and can do everything they want with one little constraint - clients should always be happy with what they eat.

So what?

Most of the companies out there are somewhere between those categories. The problem is - the same methodology does not fit all. You cannot give freedom to a person that wants to be constrained and have proper wording of what is required, do the steps and pass it to the next employee in the chain, the same way you cannot limit and put in the mechanic process a Michelin chef expecting him to work better in such an environment. In the industry sometimes you have highly constrained and detailed processes that use developer only as a code-generating bolt in the sequence as well as do-what-you-have processes that require tact, open mind, motivation and mindfulness from everyone in the chain for the job to be done. Strangely, both process configurations are called agile, even though the only thing they share in common is rituals around the delivery process but none of the values. Maybe we should come with new terminology on how the Manifesto was implemented in the wild?