Introduction to Agile Planning and Project Management webinar

I finally had to listen to the recording instead of the live webinar.  Work sometimes sucks…

One of the assumptions laid out at the beginning of the webinar was that we’d be talking about large project involving single and multiple teams.  This is interesting because most of the Agile case studies I’ve seen are for small projects.

The presentation continued into a review of the Agile manifesto.  I don’t want to be nasty (well maybe I do…) but nothing new here and the manifesto is basically just good common sense applied by most good project managers, Agile or not.

There was some silliness about “reversing” triple constraints.  Again, time boxing is not new and using it in Agile does not make for a new approach.  The presenter then stated that “known” projects are more suited to the predictive (traditional) approach while an empirical (agile) approach works more for discovery type projects.  It flies in the face of the definition of a project doesn’t it?  If you know everything that you are going to face I would contend that you are in an operations setting not a project one.

The presenter went into a couple of notional graphs; one on Emergence or Convergence for which there was a Y axis but no X axis, and one burndown chart.  Both looked good but meant very little; no scales equal no real number hence no metrics.  What is the point?

The presenter then stated the Agile is team based.  Compared to what?  I don’t work in an Agile environment and I sure as hell have teams.  The presenter also contended that in Agile PM brings people together while in traditional projects the PM is a hub through which all must go to communicate to each other.  Really?  Who the hell does that?

A couple of interesting statements

• “You look for the presence of teams…”.  What the hell is that supposed to mean?
• “Linking resources between Agile teams diminishes Agility”.  Doesn’t it invite resource problems regardless of you approach?
• “Agile PMs manage the system not the people”.  Old PMs manage tasks and lead people…

I could go on and on.  Show me how Agile is different from the existing approaches.  Don’t tell me and expect me to drink the Kool-Aid...  All I hear about Agile would be recognized by anyone with some experience as a rehash of existing methods.  I am getting bored about this entire thing, real fast.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

 

Comments

[Hajar Hamid (jadehamid@twitter)]

I agree with you! There's nothing new about Agile in fact. It has been around, but never "defined" publicly as a methodology or technique or whatnots.

To me a PM has to be agile all the time, regardless what methodology or framework the project is using. Otherwise, it's gonna be hard to do the job.

Anyway, as for the techniques introduced, I think we have to again be agile enough to use what can be used with the current environment we're in.

[Shim Marom]

In all fairness, the public advance of agile has brought about a change of attitude in mainstream software development projects, realising and recognising the need to bring faster value with greater focus on time to market.

With that in mind I agree that in today's reality some of the claims made by agile advocates are slightly behind the time and should be taken of the agile justification slides.

Couple of months ago I went to a similar workshop that was supposed to be discussing Agile in DW projects. I then had to sit through a similar set of slides telling me how agile is the solution while waterfall is the problem. I really don't need to hear this sort of propoganda anymore, let's move on and deal with the real issus.

Cheers,

Shim.

[craig]

So I am spending some of my time teaching agile practices these days. There are three kinds of messages I like to share :-)

1 if you are a 'proper project manager very little of what I am about to sy is new. It is a collection of established good practices.

2 the real underlying principles are around building a culture of accountability and learning, and

3 At the end of the day, only a small share of the people tiled project manager know more than the mehanc of pmbok, prince2;, etc. If that is you today, another 'method' is not going to make a difference to you.

Forget training. Forget webinars. They are aimed at beginners.

Instead, as a rel pm, go find an agile sw shop in your town and inspect their operations. See a mature sw business and compare it to most bureacratic orgs and the difference is vast.

[Patrick Richard]

Hajar,

First, thanks for the comments, they are so very true.

[Patrick Richard]

Shim,

We had to take an "Agile-like" turn years ago not because we wanted to but because our customer demanded it. Still, we are not pure Agile and I don't see us becoming it.

What rubs me wrong is many fold:

1. Take each point in the manifesto and make it a negative; does it describe "traditional" project management? I think not.

2. Make believe that clients will commit ($$$) to a long term project based on yet to be documented requirements. I have never seen it work that way.

3. Lack of hard numbers showing a benefit.

4. Renaming everything does not make it new. The Epic/Feature/etc. construct looks a hell like a WBS...

I'm not saying Agile is bad but is is really badly sold.

[Patrick Richard]

Hello Craig,

I don't disagree with you points that much. However, to the neophite, Agile is presented as a revolution which I believe did not happen.

I like your approach that Agile is a set of best practice. Let me however ask a question (not a trap). Who deals with people that are shown not to be accountable in Agile?

[craig]

Patrick, I assume you mean client side accountability dodgers.

Once again, the same principles apply. In the project context I would be looking to male the issue as transparent as possible. Stopping the line may be an option for example, and so would presenting issues to the sponsor. Assuming you can find them...

[Patrick Richard]

Craig,

It could be client side but it also could be service organization side.

The Manifesto (the 12 principles) says "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.". My experience is that people can be trusted but it helps to check. A bad (or sad) analogy is that people respect speed limits because the police enforce them. In “traditional” project management it is often the PM. My question is: Who is playing the policeman in Agile?

[Project Management Professional Certification]

I liked the information that you have shared regarding the Agile Planning.

[Patrick Richard]

Hello and thanks for reading and commenting