Agile Principles, part 1

I'm going to discuss the 12 principles of Agile, why they work, and how they are natural and comfortable to a thoughtful development team.

Principle 1 - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Of course, everyone can agree that in any business venture, the customer comes first.  When I worked at Novell in the early 90's, Ray Noorda often stated his priorities - "Customers first, employees second, shareholders third."  If you take care of the first two, the shareholders pretty much take care of themselves.

If you've studied any economics, you know about the time value of money - a dollar in the hand today is worth more than a dollar you'll get tomorrow.  The same principle applies to software in a fast-changing technology ecosystem.  The software you put in a customer's hands now adds more value to the customer's business than software delivered next week, next month, or next year.  Rather than spending a year building the "perfect" system, give them something that works right now.  Then get feedback, incorporate it, and deliver several iterations over the next year.  At the end of 12 months, you're likely to have a much better product and a much more satisfied, loyal customer than if you'd waited a year to deliver.

Principle 2 - Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
This one's quite obvious.  Anyone can meet requirements that never change.  But who has any of that kind of requirements?  As in the previous example, if you can deliver multiple iterations, in rapid sequence, adapting to requirement changes at each iteration, you'll do far more to enhance the customer's competitive advantage than if you "save up" for a single, monolithic deliverable.

Principle 3 - Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Now we're getting specific.  Days and weeks, not months and years, between deliveries.  Is it easy?  No.  But in a web-oriented, SAAS-heavy world, it's possible, and even expected.  You have to be on top of your game - continuous integration, automated testing, rapid prototyping and deployment, and above all, flawless communication are required.

My Roots

My introduction to agile development came sort of by accident.  I was managing a small team of developers whose job was to work with customer support and create code fixes for bugs that were affecting customers.  We were supporting a complex, system-level software product.  We would meet with customer support periodically and they would tell us what their highest priority issues were.  Then we would start working on them, in priority order.  The problem we ran into was that frequently, once we started making progress on an issue, support would see that we were getting close to a solution, begin to feel comfortable about that issue,  and suddenly change their priorities and start pushing us on a different issue.  It became very difficult to ever finish anything, and almost impossible to track where we were.

About this time I began reading some magazine articles about Scrum.  We knew almost nothing about it, but we decided as a team to try it.  We implemented the idea of 2 week, time-boxed sprints and sprint reviews.  We promised customer support that we would allow them to change their priorities any way they wanted to  between sprints, if they would agree to leave the priority list alone during the sprint.  We started to have some success, which increased our trust in agile and customer support's trust in us.

Buoyed by our early success, I got Ken Schwaber's book and started reading it.  We continue to evolve our process.  In spite of our almost complete inexperience and naivete, our success started to grow.  Later, when our entire division moved to Scrum, we were part of the pilot project.

My point is NOT that agile  training and consulting are unnecessary.  In fact, I'm a big proponent of getting the best training and consulting you can afford.  My point is that agile is a very natural progression for a hard-working, thoughtful engineering team that is running up against the limitations and problems of the waterfall model.  It is very natural and comfortable to adopt a methodology based on iteration and learning as you go, rather than perpetuating the obvious fiction that we can understand every requirement and predict every issue before starting a complex project.

In the next few posts I'm planning to review the twelve agile principles and discuss how they can naturally evolve in a thoughtful, self-aware team.