While I was on vacation, I got a great question from an alert listener, who asked,

Is it still possible to use Agile development for a team that works remotely and frequently changes focus from one project to the next? I have found the requirements management aspects extremely challenging, but I have not found many discussions online that address this particular challenge.

We are going to make this a focus of a future podcast. But off the top of my head, here are a couple of comments that occur to me.

Agile techniques can be applied any time and place. It is just that the practices differ.

Certainly, Agile makes sense even for small teams. Large or small, you help to avoid a lot of wasted effort, and code when you focus on doing just enough, doing what needs to be done next, and keeping close relationship with the “available customer.”

You want to ensure you are getting as much feedback as possible.

This helps with requirements management because you are only doing what is the next most important to do. To accomplish this, we teach a method of using “stories” (think packets of tasks centered around a desired feature or desirement) to prioritize the features that must be worked on. The Product Owner prioritizes these stories according to his/her needs at the time, putting them on a “front burner, back burner, or fridge.” For the next sprint, the Team only looks at things on the Front Burner to decide which ones they can and should do in this sprint. The rest of the stories stay on the burners to be looked at next time.

When the Sprint begins, it is important to try to finish that work within the agreed-upon iteration and not get diverted. If that is a problem, one solution is simply to use shorter time frames for your Sprint iteration.

You certainly have a greater challenge when your team is distributed, not co-located. I’d be interested in what you think about this. In my experience, it is still possible but it puts a premium on discipline and communication. The team facilitator needs to be extra sensitivity, making sure people are synched up, are participating in the daily meetings, and are aware of what each other is doing. Of course, IM and something like NetMeeting or GoToMeeting or other desktop-sharing solution can work. And I’d recommend using a good agile project management tool like VersionOne to make sure everyone is in synch.

Alan Shalloway has additional points:

• Don't write code until you have a test specified. This helps you avoid the waste of debugging.
• Look at the entire problem not just pieces of it
• Defer commitment by encapsulating your designs. Design Patterns help with this.

If at all possible, I’d recommend taking our Test-Driven Development and our Design Patterns courses, which will really help you here. A good introduction to Scrum would also help.

Recommendations - Training by Net Objectives

• Test Driven Design
• Lean Software Development
• Design Patterns
• Scrum

Recommendations - Reading

• Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott
• Reading recommendations for testing and validation
• Creating a Lean Culture: Tools to Sustain Lean Conversions, by David Mann

Recommendations - Tools

• VersionOne, for Agile Life-cycle Project Management

Music used in this podcast:

• “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
• “On the Cool Side” ©2006 Kevin McLeod: www.incompetech.com

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Technorati Tags: Lean-Agile

tag with del.icio.us