Monthly Archives: January 2009

The IT Albatross

Steve Gordon posited the following in response to the original poster thinking about

Original Post:

I explained in a simple words as possible the competitive advantage they could get if they give agile a chance, so I hope they will agree on a pilot project. Otherwise, how can they tell if they like chocolate cake without tasting it?

Steve replies:

With no measurable problems, what would be the success criteria of a pilot project anyway? Do you really expect them to adopt agile just because they liked a taste of it, even though it did not measurably improve anything?

IMHO, lack of “measurement” is the albatross around IT’s neck…

heck, i can’t even prove why my design is better than the next guy’s with anything other than a damn sure guarantee that his design will be worse. I base this solely on experience. Yeah, I suppose I could throw out a few metrics… but tying those to “success” or cost is hard to do. One of the problems is that BOTH solutions will work. I know he could get his solution to work, but I am also pretty sure it would be overkill, a nightmare to maintain, and difficult to extend.

I am tempted to put up the two competing examples and get folks to comment… one of these days.

This is generally not so difficult to do in a “hard” engineering discipline. One can usually compute costs of two solutions, roll forward estimates of how each design will cover future scenarios, determine the value proposition going forward, and choose which solution is best for business.

Until we get to this point in Software Engineering, it will forever be a fool’s challenge to “prove” one solution/process is the right way to go. (Not to mention the excessive variability to software that is inherent in its very nature.)

Management By Magazine

Agile Project Management forum got this post:

While on a business trip overseas last week I had an in-promptu meeting with a potential customer during which I explained to them the benefits of Agile. As result the excutives[sic] asked me to send them more info and a proposal. Upon my return to the USA I did so and got a reply from them this morning indicating that they are currently using the “Fast Track” approach to software development. That term is entirely new to me in the context of sw dev.

Before I reply to them with the big question mark, and potentially sounding stupid, I wanted to check if any of you know about it and if so I will highly appreciate a pointer to more information.


Hi,

I think it is some project management software…

So… might be a bad sign.

You: “We specialize in agile development and find it really helps meet business needs… What type of s/w development processes do you use?”

Potential Client: “Oh, we use The Microsoft Project SDLC Process.”

You: “Oh, I feel my phone buzzing, I gotta take this call. It might be my ‘Management By Magazine’ book editor.”

An Agile Parable

This is a great parable about agile development.

Rocks into Gold

Share it with your “management” or clients that might need a boost to their understanding of what agile could become… if people embrace the concepts.

Track Hours?

From Alan (a thread on agile project management forum):

Now as to the why-bother:

1. Government reports require (a) a summary and explanation of R&D activities, and (b) an auditable tally of hours spent doing this.

2. To develop some basis for estimation, I need to know how much effort goes into development. My time is very irregular, and I honestly have no idea how many hours are put into programming on any task. I don’t know if it varies from week to week. I don’t know how long it will take to finish a project AT ALL.


I am suggesting that tracking hours is but one small wee part of estimation… and it must be combined with other, larger pieces of the puzzle to impact estimates. Unless of course, your work is repetitive and non-thinking. Like stamping out license plates.

Though you can certainly have everyone track hours & tasks to the minutest detail… what is the other unit of measure? Lines of code? Features? Story Points? That is, will you strive to be able to predict Lines of Code per hour? Hours per feature? Days per Story Point?

See rest of post here:

Tracking Hours for Every Task