I don't know, but you probably do.

Sometimes, the best answer to a question is "I don't know, but you probably do". Let me explain...

I occasionally have the opportunity to speak at user groups or to groups of employees to introduce them to agile - what it is, why it is important, how to start, etc. The presentations vary depending on the audience but always end in an open question period to answer any and all questions about agile. I can usually provide an answer to most of the questions, but I try to use various strategies to draw answers from the audience instead of answering each one on my own. Many times, their answers are better or more convincing than my own. If I'm not sure of the answer, I *usually* tell them I don't know but point them to some resources that might help. However... sometimes I forget.

At a recent speaking engagement I was asked a question about how to apply agile principles to address specific operations and maintenance issues. I answered the question, but I'm pretty sure my answer was too vague and largely unhelpful - some useful comment about reducing wip I think ;). So, here is my attempt at answering the question again using both the principles and the knowledge of the group to solve the problem. Of course, that group isn't here, but hopefully this will help anyways (I'll be e-mailing this to them).

"Thanks for the excellent question! I don't know the answer, but you probably do. Yes, it is true that reducing wip will likely help improve your situation, but since I don't at the moment understand the specifics of your problem, let me give you a few ideas to try. You probably have or can start tracking some metrics of how long it takes maintenance and operational issues to be solved. Using this as a baseline, try a few experiments and measure their results. To determine what experiments to try, have regular meetings with your team and ask them a) what has worked well in the past, b) what hasn't worked well and c) what would they recommend. Based on those recommendations, pick one or two experiments to try and then measure the results. Over time, I'd bet that your team will be successful in solving this problem together."