Agile Development

There are a number of methods that software development teams can use to help manage themselves. Years ago, teams would create detailed specifications over a period of months and then spend years coding only to discover they had built the wrong product. In 2001 a bunch of successful software developers met at a ski resort in Utah and created the Agile Manifesto. This then spurred a new process where developers would work on small pieces of the product with short release cycles so they could get constant feedback on what they were building. Then product users could provide instant feedback to ensure the development team is on the right track.

My current software development team uses Agile development and so the company hired an instructor to come in and teach a 2-day refresher course. It was interesting to spend a couple of days going through the training material. There were other teams new to the process taking part in the course and it was fun to see their reaction. Some were eager to embrace the method while others were less than eager to change their current development practices.

I have to say that there is one problem with Agile for me. I have a specific skill that requires me to work with a number of different teams. So while there is  about 4 hours a week of meeting overhead for the rest of the team members, I end up with about 12 hours a week of meetings. Considering there are only 40 hours of work during the work week, that means I only have 28 to get useful stuff done. So when someone gets all energetic about Agile, I have to bite my tongue to keep from grumbling too loudly.

I am hoping that the guys that created the Agile Manifesto will show up at Snowbird again, where they originally drafted the short statement, and come up with a way to keep me from going to so many meetings. I'd even provide a couple of lift tickets.