Software Project Management: Light Weight (agile) Or Heavy Weight (old School)

bas says : I know, I just keep on repeating myself on this subject, but that is just my attempt to make up my mind about it: doing software project management light weight (agile) or heavy weight (old school PMP, Prince 2). As I explained earlier, I am Dutch, we always compromise, so, it depends on the situation…

Very inspirational is the article Empirical or planned. It discusses the development process, but the discussion is also valid for the software projects. Main argument: development is not like building a house, it is not that predictable, so if you try to use processes that assume it can be planned, you are heading for a fall. However, there are alternatives that are also used in other industries.

As I am writing this, I am lying in front of my mailbox, hoping that Amazon drops my just ordered Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm in it. I am hoping to get some great insights from this book. I’ll let you know when I have read it.

In the mean time, I’m guessing that there are two criteria for choosing between one of the two approaches:

I assume that the starting point of the design of a project organization / strategy is the agile side, in this respect, a minimum on procedures, formality and as much delegation of tasks and responsibilities to the people performing the tasks as possible.

My main reason to take this is as the starting point is that in this way you maximize motivation, creativity and speed at the level that does the actual project work (yep, PM is just overhead).

So, why then should you increase the amount of heavy weight methods into the mix?

First, when you have a serious risk that people will neglect the project needs that have a high priority (e.g. at a given point in time, speed can be more important than quality – I know, but YES it can) and you have to put on more control to urge people to take on other priorities than they normally would do themselves, and track this.
Note, this is actually the agency risk discussed in agency theory.

Second, if a serious communication risk might occur. If people are not co-located and teams work on software that is dependent on each other, you can increase formality on this aspect: formal specifications and a formal change procedure on for example interfacing jobs.

The determination of project approach / strategy and the derived organization doesn't start with "this is our method!" but with a proper risk assessment. Which brings me back to starting with stakeholder analysis :)

Just my thoughts at this moment.



Cheers,

And don’t forget the great formula 1 race at Monaco tomorrow!


Bas

bas says : Yeah! Just got the book Balancing Agility and Discipline: A Guide for the Perplexed from amazon... can´t wait to find time to read it...

Darn nice weather ;)

Bas

bas says : So I took myself a nice heineken and started glancing through the book...

Incredible, an entire book dedicated on the subject the balance between flexibilty and discipline in software management / development.

It looks pretty good. Nice overview and comparing of new methods (which is always nice), good introductions to plan-based (old school :) ) and agile methods. I havent reached the point when they start discussing how to find the "sweetspot" as they call it, the right balance between agile and plan-based.

However, it is nice to know that they agree with me :D that it is dependend on the circumstances (so different for each project) and the start to determine this is a risk assesment.... hmmm, will be difficult to proof who got there first... heck, I let them have the credits :D

Keep you posted
Bas

bas says : A nice introduction for the book from Boehm can be found here:

http://www.stsc.hill.af.mil/crosstalk/2003/12/0312turner.html

People Factors in Software Management: Lessons From Comparing Agile and Plan-Driven Methods

This is an article they wrote before publishing the entire book.