An inconvenient truth, in work management

I bet anyone in my position (Agile Coach) has faced this before: you present a work method to a team or a person (be it scrum, XP, DSDM, FDD, etc.) and they go "yeah, I see what you mean, but that would never work here".

If I only had a dime for every time I heard that I could be rich!

Today it happen again. Here I am presenting the Personal Scrum work method. People are following, they are asking some good questions and at some point it hits: "Yeah, I see what you mean and it makes sense, but that would never work for us. We have too much work we cannot predict because we want to have a very fast turnaround for our customers (1 business day) and that's why we cannot really plan our weeks that way. On top of it we are too busy to spend that much time (1-2 hours/week) planning what to do."

Now, for most of you (if not all) the problems in this phrase/quote are quite transparent, but for the person saying it, it was not. They did not understand some of the basic principles of work/time management and productivity:

1. If you cannot allocate your whole week because some portion of it will be "unpredictable" (have you heard of maintenance in production software?) then you don't allocate the full week to planned work! That's not a reason not to plan... Just estimate how much time you need for "unexpected" items (and that tends to be pretty regular from week to week), and plan the rest of the time!
   
2. If you are too busy, then how do you know your are doing the most important things for your stakeholders/customers? Are you setting aside the time to think through the priorities of your work from your customer/stakeholder's perspective? If not then I'm sure they'll be mad at you or at least disappointed -- even if you are busy!
3. If you are too busy (yes, again), that means you are "thrashing". This means: you have started many threads of work but are getting none of it done! Remember that only work that is "done" counts. Starting something you don't finish does not count (unless your manager/supervisor is clueless, in which case it is time to search for a new job anyway). Search for the ZEN of getting things to "done".
   
4. Work is work. Stating that a method (whatever that method is, take GTD for example) does not apply to manage your work can only be a result of not understanding the basic essence of any piece of work: 1) you get an order with some information and possibly inputs; 2) then you process it, alone or with a team; 3) finally you finish the work (as in "done"). This is true for every piece of work that needs to get done, whether it is planting potatoes or designing a piece of software, and certainly writing a business proposal or answering an RFP. If you don't understand that basic attribute of work there's a deeper problem we need to address. Managing the work is the least of my worries when I face this type of situation.

Now, all of these observations could have been done by anyone with experience in trying to manage work. But (and this is the sad fact) there's not too many people out there that understand the concept of "managing one's (or one's team) work". Sigh...
This brings back memories of a conversation I had with a senior and well known Scrum trainer/guru when he was training at our company:
In the CSM training, after the "promise" game exercise he was looking down and gloomy. I walked up to him and asked what was the matter. He turned and said: "see, this (the problems uncovered by the "promise" game) is what I see in all companies I visit, and that just makes me feel sad about the state of our industry. See, what I'm trying to do is just make our industry better, more professional".

Indeed, better and more professional. That's the right goal!