An interesting and well written article. I can understand your points and some of them are excellent such as limit task switching and separate urgent from important. I am not so sure about a couple of the others. Based on my experience in the software industry and now as a time management coach I am not convinced about "don't add a buffer to time estimates" and "defer decisions". I have found my clients (and my previously staff) are very bad at estimating how long task will take and they always under estimate, so a buffer was important in managing expectations. Also, deferring decision falls in to the area of procrastination and can lead to people avoiding making decisions. I'd be interested in other thoughts on this.

Thanks for that important information, it really helpful..Interesting article

It's true that it's very hard to "correctly" estimate stories/tasks. In my opinion, a better way to solve that problem is by estimating in abstract units of time and using "yesterday's weather" to decide how much can be done in an iteration. Or, if you really need real units of time, use a load factor.

Seems like another important component would be tracking your time. The reason is that tracking your time effectively provides you with invaluable data on how long it takes you to accomplish certain tasks. As you continue along in your cycle you will start to see similar tasks repeating themselves and will be better able to slot them into your workday knowing how long they will take. We've been doing this for years and have found ourselves transitioning much easier into agile development as a result. Thanks for the list!

Hi, I think this article is very interesting however I have been trying to look if there are specific standards when it come to the allotment of "time" when it comes to project management. I mean how many hours should we be investing in actual project management for a particular deliverable? Is there a rule like 10% of actual project effort?

Thanks...

Great work on this article... I will definitely share it with my staff at work... Thanx and keep up the good work

I think you should change the this principle to "Based decision on Complete Facts" , what you are accomplishing by delaying the decision making is to get enough knowledge and understanding of the situation to make a sound decision. the problem is identifying when is that the case. your point is the longer you wait the more knowlege you have about the particular situation. So the solutions is to create a systematic approach for facts finding. the solution is to create a test driven approach, start by creating test cases before you do any depelopment, this will force you to think about every "What If.." situation expediting your fact finding period,

BTW. "Deferring decisions" in my opinion clearly derives from XP "simplicity" value i.e. implement what you need today and nothing more. If you need something else tomorrow you will re-factor what you implemented today (or implement it from scratch).

I like the valuable information you provide in your articles. I will bookmark your blog and check again here regularly. I'm quite certain I'll learn many new stuff right here!!oilseed expeller

I am very enjoyed for this side. Its a nice topic. It help me very much to solve some problems. Its opportunity are so fantastic and working style so speedy. I think it may be help all of you. Thanks
Roll Forming Machinery

I think Agile methodology is fine when experienced PMs use it as a tool for organizing work. The times I've seen Agile fail have been when people with zero project management experience are made PMs because they have Agile certification. which some companies equate with PM training. In inexperienced hands Agile lends itself to treating a project like a collection of little fragments that can be designed and written in isolation. as if clicking the pieces together will somehow create the underlying structure that makes the difference between a solid application and a mess. numéro rio