I think groups going Agile need the one sheet Principles Behind The Agile Manifesto.  Short and clear, it has a good chance of galvanizing change.  In true contrarian manner though, I’d like to point out why blindly following these principles is a bad idea.

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

   Most teams need to focus on delivering must faster with smaller iterations.  However, customers are not always satisfied just by valuable software.  We need to make sure we look at every aspect of what customers want.  Make sure you have an analytic method to listen to customers!  I’m certain you’ll be surprised.

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

   Yup, there’s no point in complaining about late requirements.  They happen, and they are usually important.  However, it is critical to note that the vast majority of the quality, cost and delay problems in software stem directly from late requirements.  Get involved early to help make requirements development, from a business perspective, successful.

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

   Yup, the more often a complete release cycle is done, the better off everyone is.  However, customers can be irritated and confused by software that constantly changes.  If so, find a way to make releases to a select group of “mavens” that appreciate the chance to use software before public release.

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

   Duh.  However, having this ideal and getting it to fly is something all together different.  Talented project management, a good understanding of the cultures and corporate cultures involved, and solid requirements processes are needed to survive this.  Ideas are one thing, knowing what actions to take is another.  If you’re not succeeding here, don’t wait.  Get help.

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

   I would just like to point out however that human beings are complicated.  If we don’t have goals and measures, subjectivity will lead to judgment, and then to emotionalism.  Not good.  We all like to think we’re above this.  We aren’t.  Get a performance methodology in place and use it.  I like HP’s Management By Objective.  In the long run, it will create the fairness to allow trust to happen.

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

   This is a red herring.  Psychologists continue to discover all the ways humans use body language, gestures, micro-facial gestures, etc. to communicate while we are face to face.  That said, I’ve had super effective technical cooperation with people I’ve never seen.  Mind you, I don’t have a bullet proof recipe for virtual teams, but I’ve had them work wonderfully.

7. Working software is the primary measure of progress.

   Yes, yes, we’re programmers after all, right?  Wrong.  When we ship a product, what we really have is a relationship with a customer.  They give us money (hopefully) and we give them what they want.  It may be software, support or back rubs.  Maybe even prestige!  You know about the customer always being right, right?  As programmers we need to make sure we are getting measurable feedback that we are on track to a happy customer.  Think analytics.

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

   In theory this is true.  It will rarely be true.  Reality can be crazy.  I’m not saying that being out of balance is a good thing.  However, if we accept requirements change at the last minute, we need to be ready to work quickly.  Life happens, sometimes fast.

9. Continuous attention to technical excellence
   and good design enhances agility.

   So often when deadlines hit the emphasis on doing the best job possible on the software slides out the window. However, engineers tend to noodle over stuff.  Do not get stuck looking for the “right” design. That’s what smaller iterations are helpful in doing, refactoring towards better designs.

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

    Just realize, doing something complicated is easy.  Simple is hard.  There may be several iterations of complicated before everything gets boiled down to simple.  However, always ship the simplest and most usable interface, no exceptions. If you’ve got tests, you can always clean up what’s behind the curtain.

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

    Yup, as long as the team has direction and no-one is actively trying to kill another team member.  There is nothing toxic about roles and responsibilities handed out by leadership.  The best teams self-organize, others might need direct help and facilitation.  Just be nice about it.

12. At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly.
    
    Continuous improvement is absolutely critical for everyone in the software field.  Fall behind and we are penalizing ourselves and our teams.  It’s easy to calculate the cost of everyone in the same room, and stop doing postmortems.  What is the cost of having poorly trained and performing folks adding to your source code base?

Okay, so I agree with this last principle without reservations.  With Agility, like any fad, there is an underlying truth to the doctrine.  However, blindly following a doctrine, even a good one like Agility, is a lemming’s plan.

Isms in my opinion are not good. A person should not believe in an ism – he should believe in himself. I quote John Lennon: “I don’t believe in Beatles – I just believe in me”. A good point there. Of course, he was the Walrus. I could be the Walrus – I’d still have to bum rides off of people.  — Ferris Bueller

• Principles behind the Agile Manifesto
• Deal With It: Retrospectives Are Postmortems
• Ferris Bueller’s Day Off
• A Firm Agile-ism Debunking from a Google Engineer
  

• Previous Entry: The Alchemist
• Next Entry: How To Save The World?