When is Agile not the right choice?
When I give talks on agile, people often ask the inevitable question: “When is Agile not appropriate?” My response is that I don’t really care what people call what they do. What I am concerned about is the quality and frequency of the feedback that informs the control and decisions regarding project management and technical decisions on my project. I find the idea that you might not want to improve your feedback to be very odd.
But I think I understand what the real question may be now. Feedback comes at a cost. You have to actually release and deploy your system. You have to write and maintain test cases. You have to conduct meetings with the team and the stakeholders.
What cost should you be willing to pay for better information?
I can only speak from my own experience. Currently, we have two-week long iteration. The release, demo, planning and retrospective activities take about one and a half day out of each iteration. So the “feedback cost” is about 15%. I don’t think I would like my project to devote less than 15% of its effort towards implementing a feedback cycle. If you spend days integrating your project every iteration, a one week iteration won’t work for you. I don’t recommend doing fake iterations where the iteration degrades into a planning window, either. So if it takes me several days to do a proper iteration, I would rather have longer iterations.
Here is where I depart from the spirit of the question, though: If it takes you several days to integrate your project, how do you plan to act when you have to fix problems in production? A long feedback cycle is a high risk. If you can’t iterate frequently, this is a sign you need to fix your process, not that you should adopt a waterfall approach.