DRAG

So in fact we are more or less in agreement.



I suppose a proponent of Agile methods would argue that if done properly, it should be making developers lift their heads up from the screen. Meaning they are forced to communicate with the user representative frequently. However I understand what you are saying. You are looking at the big picture and the end point.



I think you are quite correct in this. It’s a bit like the motor is running, we can see the ship is going somewhere but nobody is navigating.



BTW I’m sorry we got off the subject of Drag but SCRUM was an important topic as well.



Cheers,



Dave.

David,



I’m not saying project management is easy, but i am saying the planning process should be.



As for looking at the overall task; take a component based software development project for instance, spending time planning the project in a trational method in unison with creating detailed architecture diagrams means that the ’overall’ conception of the project is discussed at the beginning of the project.

Agile methods mean that planning gets left until the next sprint and this seems only to serve the developer. Upfront planning means thought about overall integration is there in the beginning and avoids the proverbial birds-nest.



If tasks haven’t been done before then it means developers will have to ESTIMATE, i personally feel Agile just excuses developers from lifting their heads up from the screen!

My opinion is that its only place is for changes to existing systems when you have a small team of experienced developers.

Maybe you are right int saying it has its place within a project, possibly as a development managers method of managing work functionally?



Cheers,

I agree with some of what you say.



One of the key issues with most agile methods including SCRUM is that the customer/sponsor is taking most of the risk. At any point along the way the customer may not have realised enough business value for the cost spent to date. How can the customer decide when to pull the plug? Also it means the customer is taking the risk that at the end there will be a better solution than other available options. Yet that is not guaranteed at the start.



With respect, I do not agree with some key points that you say. The way I read your post, you appear to be making a false assumption.



In the majority of software development projects it is next to impossible to define 100% accurately what needs to be produced before you start. I could go into detail about why this is if you like. My point here is that the assumption that it is even feasible to look "...at the overall task..." is where I strongly disagree with you.



Since one is highly unlikely to be able to properly pre-define what will be produced it is therefore not possible to "make a [complete] list of things to do and do them in the right order".



I could also go on about how difficult it is to "...decide what and how to do it" if by that you also mean how long it will take. In software development projects most tasks have never been done before. Nobody really knows how long most tasks will take.



I certainly disagree with you that project managing such projects is simple. I am quite sure that most authorities would agree with me on that score.



I think it’s worth looking at agile methodologies like SCRUM as a way to complete sub-projects within a larger more traditional project plan. Perhaps the advantages of each approach addresses the weaknesses of each?

IMHO,



SCRUM is and excuse to not plan properly.



Its the equivilant of starting construction without any drawings. Getting to the 5th floor with square footings and deciding you wanted a round building all along!



Its championed by developers as it means the end of time-related accountability, there are studies on the internet that find it to be a highly disruptive form of management.



Planning is simple. Make a list of things to do and do them in the right order. SCRUM allows work to begin before thinking about all the details and this doesnt work as the most important part of planning is not the programme that is produced, but the process of looking at the overall task and deciding what and how to do it!

Hi Mike,



Fair enough! There is no law which says you should develop an interest in a totally different field. Personally I work across the intersection between the two - which is a unique situation.



SCRUM is indeed a methodology for doing the work. However a key part of the technique is the process of planning the work. Still what you say is true, since the focus is on what will be attempted in a fixed time rather than how much time to produce a fixed deliverable.



Cheers,



Dave.

Hi Dave



Never having read a book on construction planning I am not going to start developing an interest in software planning.



The process you describe seems to be the actual development work being done step by step - not the planning.



However your penultimate sentence is quite right - if you can’t build it you can’t plan it.



Best regards



Mike Testro

I suggest that if you were to read a book about software project planning you might learn something new.



For example; SCRUM is not bottom up planning.



By the way, SCRUM is not an acronym. In fact there is no real reason why it is written in capitals except that it does help clarify you are not talking about rugby.



SCRUM is a team process which results in making a fairly minimal set of changes to produce a working version of the software. Basically a collaborative small step forward.



In software development projects with goal posts that never stop moving this objective of an incremental step forward is key.



The collaboration of the stakeholders in the team might remind you of bottom up planning but the objectives of the SCRUM technique are not defined by the term "bottom up planning". Frankly, neither is the process.



In fact bottom up planning is usually considered when you have some good sources of knowledge about what is required to do the project. Experience of a similar project with different details for example.



Whereas the whole need for techniques like SCRUM is precisely because too little is known about what is required to do the project.



Dave.

Hi, Mike.



What I actually said was:



"BE-BOP is for the Birds!

(And, of course, Dizzy people.)"



Here’s what I meant:



http://en.wikipedia.org/wiki/Charlie_Parker

http://en.wikipedia.org/wiki/Dizzy_gillespie



I’m all for bottom-up planning -- though I think that too often the requisite step of reconciling the bottom-up plan with the strategic, business, and big picture goals is omitted.



Still better than a top-down "Build that bridge in three notes!" kind of approach, though!



BTW, I was right about Windies having the potential to blow it! They won, but talk about batting like scared rabbits!



Where’s Trevor? He needs to come in here and accept the accolades for Aus beating S. Africa!



Fraternally in PM,



Steve D.

Hi Stephen



When you say BE-BOP is for the Birds!



Do you mean my Acronym or Bottom Up Planning as a method?



Best regards



Mike Testro

Hi Chris O,



Just read the article in Wiki. Very interesting. It is a method we use but don’t call it anything in particular. That can be said for many techniques in all honesty - it gets described and critiqued but none-the-less is what many of us do day to day, in one form or another.



That is NOT to say it is not worth documenting or describing; it is important to illustrate that elements of techniques are transferable and what better way of communicating it.

Hi, Mike.



BE-BOP is for the Birds!



(And, of course, Dizzy people.)



"I have never read a book on planning neither have I had the temerity to attempt to write one."



temerity, n. Foolhardy disregard of danger; recklessness.



Hm.



"If I ever did I would try to avoid acronyms such as DRAG that mean nothing to an old hack like me - until that is the true meaning is explained and then I realise that it is something I have been doing as routine delay management all along."



But, Mike, why should it matter what has meaning to "an old hack like me"? Surely the one person one DOESN’T write a book for is someone who won’t be reading it??



But I’ve been very pleased with the acronym, as engineers in the industries I work in most (aerospace, defense, communications) work with the concept of drag all the time, and understand it well. Indeed, I suspect that the CP meaning will become SOP, even though the all-caps and acronym disappear.



And, of course, many athletes pointed out that Fosbury was doing nothing more than they’d been doing for years -- jumping!



"Anyway - congratulations on the Windies hard won draw."



Thanks, but it’s not quite over yet, and after the many failures of the past 15 years, WI fans don’t take any success for granted. But if it happens, I will be happy to accept your congrats on the return of the Wisden Trophy to the Caribbean after several years in England.



Unfortunately, the person truly deserving of our congrats is Trevor, as Australia seem on the verge of an unexpected series victory in S. Africa.



Fraternally in PM,



Steve D.

Hi Chris



Thanks for the link - I found this bit interesting:



SCRUM BASICS

The first Scrum started with a half day planning session that outlined the feature set we wanted to achieve in a six month period. We then broke it into six pieces which were achievable in 30 day sprints. This was the product backlog. For the first sprint, the product backlog was transformed into development tasks that could be done in less than a day.



Isn’t that Bottom Up Planning to level 3.



Nothing new.



Best regards



Mike Testro

Hi Mike,



SCRUM is for real. I’ve never used it, but I’m told it’s fairly common in software development, it’s got some similarities with RUP (Rational Unified Process) in that it’s iterative, but that’s about the sum total of my knowledge.



I’ve just had a look at an article about it in Wikipedia which seems quite informative, might be worth a quick look.



Chris Oggham

Hi Anoon



I was wondering if someone would take the bait.



It is something I made up yesterday to describe - "Best Example-Bottom Up Planning".



I did it to demonstrate that anybody can create an acronym for a particular planning technique that is generally common knowledge among experienced people.



I think Trevor was doing the same when he set down SCRUM as a potential planning method but has not explained any further.



I will add acronyms to my list of planning abominations and leave it at that.



Best regards



Mike Testro

Hi Mike,



What’s BE-BOP?



regards

Hi Stephen



You will recall my recent quote - "Keep learning and if you don’t know then ask someone who does"



I have never read a book on planning neither have I had the temerity to attempt to write one.



If I ever did I would try to avoid acronyms such as DRAG that mean nothing to an old hack like me - until that is the true meaning is explained and then I realise that it is something I have been doing as routine delay management all along.



By the way I have been expounding the BE-BOP planning system for some months in the PP forum - nobody seems to be taking any notice.



Maybe I should write a book about it.



Anyway - congratulations on the Windies hard won draw.



Best regards and much respect



Mike Testro

Hi, Mike and Trevor.



Mike, to be fair, if you’re not willing to read anything, then it’s not surprising that "that so far no one has told me anything new."



When you asked what DRAG was, I could have referred you to my book, but since a 300+ page publication seems a bit over the top, I just pointed you to two relatively short articles, one of which is written by Bill Duncan, author of the first PMBOK Guide. You felt even that was more than you wanted to do. Now, if the real limit is what someone "has told me in 25 words or less," that’s a pretty stringent constraint, and I suspect that you will, in fact, never hear anything new. (While not a believer myself, I’m certainly not going to attempt to describe SCRUM within those constraints!)



Simple things can have very brief explanations, but sometimes their nuances and implications can be quite complex and extensive. But, having been a teacher for many years, I know it’s impossible for someone to acquire new information if they don’t want to. And that is certainly everyone’s right.



Fraternally in PM,



Steve Devaux

Hi Trevor



Its not that I know everything - its just that so far no one has told me anything new.



Except for Ken Sadler when he explained the SMM7 definition of Defined Provisional Sums - that was very useful.



When there are delays to work in progress it is common sense to direct your attention to the tasks on the critical path to see where the most economical improvements can be made - if any can be made at all.



I do not need to read a book to tell me that.



I accept that there are some who have little concept of the principles of CPM who need to be told.



They may find acronyms like DRAG and SCRUM a useful memory jerker.



By the way what is SCRUM - I have never heard of it before?



Best regards



Mike Testro

Mike, what’s your point?

You don’t read books because you already know everything?

You don’t believe that there is ever going to be anything new, so you decide in advance there will be no more original ideas written in books?

Steve has introduced something which is really quite original and practical, more so than EV, critical chain, scrum etc.



Steve has introduced a way of distinguishing which critical tasks, out of the numerous critical tasks that you can choose from, are worth the most to get off the critical path. That is, not all critical tasks are equal. I am paraphrasing from memory so I might be corrected.



The difficulty is that almost no one understands basic CPM to start with.

Hi Trevor



Thanks for the advice - I have never yet read a book on planning techniques or delay analysis.



The only acronim I use regularly is EOT which is on my personalised number plate - A1 EOT.



I need to ask what things like DRAG really mean because it may possibly be something new - so far nothing new has been revealed but I live in hope.



Best regards



Mike Testro

Buy Steve’s book, Total Project Control. It’s all in there.

Hi Stephen



Thanks for the concise explanation - Dominanat critical delays may need extra resources to save overhead costs.



Simple when you know how.



Sorry to put you to such bother when so much is going on in the Windies.



Best regards



Mike Testro

Gee, guys!



I’ve not only explained it several times on PP, but two days ago, in a response specifically to you, Mike, in the Delay Analysis with Float thread, I gave two URLs to articles about DRAG. That thread post is here:



http://www.planningplanet.com/forum/forum_post.asp?fid=1&Cat=7&Top=56268



I don’t mind explaining it, but I do mind going into great detailed explanation after pointing out URLs that would answer many questions. If someone can’t be bothered to read an article, they are probably not interested.



In a nutshell, just as drag is what slows down an object traveling through a fluid, DRAG is what slows down a project moving toward completion. Big DRAG activities are the work items most delaying completion of the critical path. And DRAG Cost is the amount by which those delays are reducing the "project profit," thus often justifying additional resources to decrease DRAG.



Mike, a big day today in Trinidad -- can WI bat out the day for the loss of five or fewer wickets? If so, they have an excellent chance of drawing the match and regaining the Wisden Trophy!



Fraternally in PM,



Steve D.

Hi Abdul



I have no idea what DRAG means in planning - and I have been asking PP members to explain it for some time.



Let hope that someone can explain.



Best regards



Mike Testro