The principles of Agile

I’ve never been much impressed with any of the “best practices” concepts, from Six Sigma to Agile. They strike me primarily as a way for midwitted bureaucrats and technical workers of modest talent to cover their asses and claim failure can’t be their fault because they are Doing Everything The Right Way:

The Twelve Principles of Agile Software

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5.  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6.  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7.  Working software is the primary measure of progress.
  8.  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

My thoughts on each point:

  1.  Sounds good in principle. In reality, the customer seldom knows what he really wants. The good designer has to anticipate his user and provide him what he doesn’t know he wants yet. “Early and continuous delivery” sounds like more ass-covering stuff. “It’s not our fault, he approved the deliverable” is what this sounds like to me.
  2. Bullshit. That’s fine in the early stages. In the middle to late stages, this is what is known as “mission creep”.
  3. Good for testing, but against, strikes me as more CYA, especially if it is going out to the customer.
  4. No. Hell no. While the biggest failure of which I’ve been a part was the fault of the chip engineer failing to listen to the marketing guy, I did talk to him on a bi-weekly basis. Talking to him daily wouldn’t have helped. The key is that the technical people must LISTEN to the business people, not see their faces on a regular basis.
  5. Yes.
  6. No. I run into this problem frequently. Most companies would rather have an inferior employee they can talk to face-to-face than a better one who is external. This makes no sense, especially if they then leave the position vacant because they can’t find anyone local who is good enough.
  7. Yes.
  8. Dubious. Sounds like snake oil to me.
  9. True, but obvious to the point of being tautological. “Program good code that works properly!” Okay….
  10. True. But I prefer “don’t reinvent the wheel”.
  11. No. A certain amount of flexibility is desirable, but there must be someone who is accountable for the vision and someone to make the hard decisions. Which is to say a designer and a producer. The best designs most certainly do NOT emerge from self-appointed committees.
  12. Yes, this is reasonable.

Overall, the entire concept stinks of being little more than client-marketing to me. “Hey, we’re AGILE-CERTIFIED, obviously we are much better than those guys over there who don’t have CREDENTIALS. All they have is a proven track record of delivering successful products, and we all know how little that means.