Agile 2007 is near

Hopefully you signed up for the Agile 2007 conference that is coming to Washington D.C. from August 13-17. If not, you're out of luck since it sold out. If you are going, be sure to attend the sessions on introducing Agile to a team and various means to ensure its success.

From my experiences with Agile/Scrum, learning the mechanics of the methodology is pretty simple for the Team (and the Product Owner). The planning meeting structure. The Daily Scrums. The review meeting at the end. The sprint lengths of 2 or 4 weeks. And so on.

What is really hard and a bit of an art, is learning how to apply Agile (and in my case, Scrum) to given scenarios that don't necessarily fit into the cookbook. Here's an example of something that happened recently and how we adapted to it.

As we came into the end of a 4 week long sprint, it happened to coincide with some vacation days by team members, as well as some unexpected illnesses and days off. Due to scheduling difficulties with the Product Owner, we struggled to find a post-sprint day where we could meet and do the normal sprint review and next sprint planning meeting. We finally found a day that fit that was a couple of weeks after the original end date. Wow, you say. That one really slipped.

As Scrum Master, I had a choice to make: create a new sprint without the participation of key team members and the PO, or lengthen the sprint by accomodating additional Backlog items. I made the decision to lengthen the sprint in this case and allow the Team to take on additional work (which they did). The Product Owner was happy since work didn't stop due to the scheduling issues. The Team was happy since they could all be together on the planning day.

I viewed this as the lesser of evils. Although Agile/Scrum treats a sprint boundary as inviolate, I've found that in practice, every once in a while something happens that forces an adjustment as distasteful as it is. Especially when working with a small team, it's not always possible to find backups for missing team members nor conduct the meetings without their presence.

Overall, everyone came out of the experience pleased with what happened. They still know and observe that we have the 2 or 4 wk boundaries and we still to them except for unusual circumstances like what happened that time. But for them (and for me) the heart of the notion of Agile development is "adaptation to circumstances". If any Agile practice becomes so rigid that it cannot accomodate unforeseen circumstances within a project, it quickly becomes like those Waterfall methods we so wish to forget. The purists may disagree, but for me, I go with what works.

Posted by Mark M. Baker at 12:11 PM  Permalink