When not to use Agile

When building products with teams of people over the course of months, I think the Agile project management approach works best.  I have my own customized Agile approach I like to use that I'll likely describe in a future post.  But first, this posting describes when not to use Agile.

I've been noticing an increase in the number of extremely short, tactical coding exercises to deliver urgently needed functionality within hours or days.  More and more, I see people doing things like: throwing together a web site, building a prototype, creating a custom ETL solution, creating a new kind of widget, fending off a hacker attack, or creating a new report.  Sometimes the code may only be used once, or it might be used for years.  Often times these coding exercises must be delivered as quickly as possible, and with no advance notice.

I've found the best way to deal with these situations is to immediately create a team composed of the people that need to work together to deliver this.  Have them meet and figure out who's going to do what and when, and then they go off and do it.  No sprint meetings, no burn down charts, no stand up meetings - the team just gets the job done.

The challenge here is that the set of people that are working on these types of urgent tasks may largely overlap with the set of  people working as part of an Agile team, and they will most likely be in the middle of developing work that they've committed to delivering by the end of the sprint.

I think there are a few solutions to this problem, each with pros and cons.

First, you can reserve a certain total percentage of your Agile team's velocity for urgent tasks - say 20%.  This basically comes off the top of the total team velocity that you start with at the beginning of a sprint planning session.  At the same time, you identify a few stretch tasks in the sprint - bonus features that are either in the next sprint or that would be really nice to have.  If you don't use up your 20% reserve, you can tackle some of these bonus features.  The down side of this approach is the extra cost for context-switching mid-sprint; it takes extra time to switch between a person's sprint tasks and their 20% urgent task.

Second, you can just make sure that these two sets of people don't overlap - reserve different people for the short, tactical projects and manage that pool of people differently (but also probably not Agile).  You can periodically swap people between these two sets for cross training purposes.  The down side is that this probably requires more total people, so it's much more expensive.