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.

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?

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.

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 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, 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 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 Mike,

What’s BE-BOP?

regards

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

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.

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

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.