Snarky responses to the Principles Behind the Agile Manifesto

The original principles can be found here: http://agilemanifesto.org/principles.html

(if you’re into handwavium and naked emperors)

Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.
Because there’s nothing customers like more than half baked software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Because scope creep allows for us to bill more.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
We couldn’t think of 12 principles, so we cut the first one in half and used it again.
Business people and developers must work together daily throughout the project.
Not like those other methodologies where developers create software in a perfect vacuum. In Space.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
If your project fails, you just weren’t motivated enough.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
If we don’t write anything down, we can’t get sued.
Working software is the primary measure of progress.
Meeting goals, deadlines, and budgets don’t count
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Sustainable, constant development means we never stop billing.
Continuous attention to technical excellence and good design enhances agility.
We maximize our ROI by redeploying developer cycles in a proactive heads-down manner using Web 2.0.
Simplicity–the art of maximizing the amount of work not done–is essential.
This is the sound of one hand coding.
The best architectures, requirements, and designs emerge from self-organizing teams.
Because bullies, loudmouths, and jerks should run every project.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
But don’t call it a performance review.

Posted on Sunday, January 11th, 2009 at 6:56 pm under Development.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

«
»

Comments are closed.