≡ Menu
Pawel Brodzinski on Software Project Management

Agile Methods Applied

In his last blogpost Bob McIlree shares his thoughts after a couple of agile classes he made recently. The whole post is worth reading but my attention was drawn to one general observation – among experienced project managers distance to agile methods is significant and confidence in their effectiveness lays two feet below the ground level.

I was never an agile junkie, I rather prefer agile methods described by Steve Yegge. By the way I guess that’s something which can earn me an excommunication from some Agile Conservatives. What more, I haven’t treated any software development methodology as a religion. Yes, you’ll hear about evangelists, bibles etc, but that doesn’t work like a religion (you just believe and it works). You can easily find environments where agile methods would suit well, but there are some where even implementing a cycle model would end up like a tsunami in a seaside village. That’s one thing which lies behind fear of agile methods. Another is of course lack of will to move from safe and well-known environment. I’m not surprised looking at skeptics among PMs. And to be honest I really don’t think that Bob’s classes will help to overcome distance to anything other what they know.

There’s only one way here – change your environment. Afraid of water? Want to learn swim? Training classes in a classroom won’t help you much. I’d rather try to change environment into more waterish one, like pool or something. I moved to my current firm after several years of working with MSF. My naive point of view was that I’d implement methods I knew and it would work perfectly like during the good old days. I couldn’t be more wrong. Different projects, different people, different teams, different customers, different organization, everything so damn different. Why the heck the process should be the same?

The same rule applies to agile methods. Take from them what you believe can work in that particular environment and leave what you think is useless. There’s none universal and perfect methodology and, excuse my bold statement, agile methods aren’t any different here. In other case we all would use them and I’d be unemployed. My answer for quite often heard “I’m a big fan of agile methods” is “And I’m a big fan of common sense.

in: project management, software development

2 comments… add one

  • Robert McIlree July 8, 2007, 3:11 pm

    Pawel,

    Thank you for your comments. Like you, I resist dogmatic and evangelical approaches to PM and IT architecture – preferring to use what works in a given situation and casting aside what doesn’t.

    The goal of a course like the one I described is to present the facts and methods and leave it up to the student what will or won’t work for them. That’s a primary reason I get the questions that I do in a class like this, and try to give the best answers I can.

    I also point out what can happen when certain things are left out of any particular method approach as I detailed in the post. What I say to the students is: by all means, leave [XXX] out of your approach if you feel the need, just be aware of what can happen if you do, and be prepared for the outcome of that decision, positive or negative.

    I will take issue with your comment that Agile methods are no different from a take-it-or-leave-it standpoint as opposed to traditional process-oriented methods. If iterations are very short, say a couple of weeks, there’s not a lot one can leave out without compromising the iteration and perhaps the project because the delivery tempo is very high when compared to other methods. Also, if people start out with a method roadmap and follow it completely once or twice, they then learn how it fits in their work and organizations as opposed to second-guessing the whole thing right from the start – which lengthens the leaning curve and can lead to sub-optimal results.

    Regards,
    Bob McIlree

  • Pawel Brodzinski July 10, 2007, 1:46 am

    Robert,

    Thanks for a comment. I don’t say your classes aren’t worthy. I just point that having skeptic PMs as an audience makes classes probably useless for them as they’re to scared to use the knowledge. When you ask a skeptic what will and what won’t work in his case, he’ll come with a lot of reasons why it don’t even have chance to work in his case (yet he’ll probably admit the method is good for others).

    Having said that, I like your approach to try to avoid any bias. Although you won’t bring many Agile Believers that way, it’s fair.

    And when talking about “take-it-or-leave-it” standpoint you can use it against any methodology. As far as you are conscious what you resign from and which consequences you agree to face it’s OK. Of course you have to know the whole methodology very well and most likely has experience in using it as a whole. Process-oriented methods are no different here – I guess there are their mutations which do exactly the same thing – cut off a couple of things which didn’t work in specific (author’s) environment.

Leave a Comment

Next post:

Previous post: