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.