Monday, April 28, 2008
Do you know any project managers who live, breathe and bathe in the waterfall?
The PMP indoctrinated model for software development is broken down into sequential steps: Analysis, Design, Coding and Testing. There are a variety of reasons why enterprises still aren't agile. It could be ignorance, fear, pride or even fraud. Fraud is an interesting dimension not previously discussed by others in that many become project managers in large enterprises without having ever actually developed software themselves. They pretend to understand but in all reality have no clue. Ignoring this truth for a moment, waterfall is an acceptable way of failing.
The first signal that an enterprise is practicing waterfall even if they believe they are agile is when folks say they are too busy. I wonder if others have detected a loose correlation between a project's health and the availability of project members to help others? For the record, I am not suggest that your project team be interrupted by a stream of questions that will ruin any remaining productivity, especially when the person asking the question could have simply read the fine manual.
If a project member can't reply to others within two hours, this is a prediction that something is wrong. This may be a hint that they are using process as a substitute for competence and the facade of actually knowing is starting to crumble. It could be that assigning a person five tasks where they are supposed to spend 50% of their time on each is simply stupid, or it could be that they are simply focusing on something more important than their own project.
In the past I have talked about big design upfront but skipped over an even bigger problem known as drive by analysis. Remember, the more you pump a customer up with a formal analysis phase, then immediately linearly followed by months of invisible tinkering, the more elated they will be to see their dream implemented after the final hooray of big bang testing.
Every project, no matter how big or small, begins with analyzing someone's nebulous idea of what the customer wants and then giving The Customer what they will accept. There are no exceptions to this rule. One must negotiate this realm of the possible even if you are your own customer.Therefore, on any project everybody is a customer" for someone else's product. So, in your enterprise, do you still have it twisted as to who the customer is?
