The debate between Scrum and PMI

In the words of my ex boss, "This is a chicken and an egg situation." Here the issue is not what came first, but what is better. I fear if we toss a coin to decide that, the coin will defy the law of gravity and refuse to come down.

In 2004 I attended my PMP exam preparation course. It was wonderful and I hold the trainer Mr. Gurudev Randhawa in very high esteem. That course was a turning point in my life. Besides knowing what the project management was all about, the PMBOK (Project management body of knowledge) kind of got embedded into my mind. After the course I could see very deep into the PMBOK but I could see nothing beyond it, or rather outside it. I thought PMBOK was the ultimate and you simply could not fail once you knew PMBOK. (Gosh, how many times did I have to type PMBOK?)

In 2005 I did my Six Sigma Green Belt certification and attended a training course on Six Sigma. Does the history really repeat itself? It did! We were told that Six Sigma was the ultimate that was required for success by any organization. In the four day (32 hour) training program, project management was hardly given two hours. That was a bit strange. A bit hard to digest, but that is what they probably thought so called project management deserved within the all important Six Sigma.

In 2006 I did my PMP. Third time I was told the same. "After PMP you will be in demand, because PMP is blah blah blah!!!" Few questions through in my exam, I knew I was doing everything right and expected around 90%. Probably I had started dreaming that HR of a few top companies were waiting for me right outside the door. The moment I step out they will all pounce on me with their offers. All I had to do was to accept the highest offer. I agree that is a bit exaggerated, but just a bit, just to make it spicy. The advocates of PMP had painted such a rosy picture of "post PMP myself", that I was already feeling on top of the world.

In 2007 I attended another training program titled "Managing program professionally." Probably that was my first step towards PgMP. This time I was sure I would have been able to do what I had not been able to, after my PMP. But looks like time is a wheel and same things have to happen again and again, though with some small differences. The fact is that there was an improvement in my capability, but not so extraordinary.

In 2008, after reading lot and hearing a lot, I gave a try to scrum in my organization. Now this scrum, as the advocates claimed, was expected to do wonders. It did. We produced the same "value adding output" that we did earlier in one third the time. Rework was almost eliminated as the product owner was virtually with the development team throughout the project, in every project. We were also able to effectively take the advantage from the ideas that sprung from everywhere. Probably everybody had collected so many ideas but before this they did not find the right opportunity to speak out.

Having said so, I still do not recommend anybody to blindly adopt any methodology, not even scrum. At the moment scrum is quite happening and it is not bad at all, but it is slightly risky. Rather I should say it has its own pit falls, like other methodologies. The biggest assumption that we make in scrum is that the programmers are knowledgeable and skilled. How can we even make this assumption when the statistics show that 75% of fresh IT graduates are not even "Industry ready?"

Basically there are four types of people. 1. Intelligent and hard working.2. Intelligent and not hard working.3. Not intelligent and hard working.4. Not intelligent and not hard working.
Most agile methodologies and particularly scrum is bound to fail if there are just a couple of team members from group 4. It has very high chances of failure even if there are a couple of team members from group 2 or 3. In other words, scrum is very likely to succeed only if all the team members are intelligent and hard working. How many such teams have you seen? Such teams can be developed by differentiation and elimination. However, that will have significant negative effect.

In practical situation, no matter how hard we try, we end up having employees with wide range of knowledge, skill sets, aptitude and motivation level, etc. All cannot be on the same level.
Another big issue is expectation level of the customer (sometimes the attitude of the customer). In a typical B-B customer-vendor scenario we come across two types of people who disagree with us. For the sake of confusion avoidance let us call them type A and type B.

Type A people disagree because they have their own valid and logical point of view. They often have a clear teachable point of view (TPOV). While it might be a little discomforting working with type A for a short while, in the long run it is a great opportunity. With them, often in just one or two rounds of discussions a third approach evolves that takes care of everybody's concern. From such people we get to learn.

Type B people disagree because they have to disagree. Disagreement is in their nature. They can never tell you why they are disagreeing. At the most they will tell you they want things their way because they want it. "I think it should be like this," that is what they will say in the beginning and "I still think it should be like this," is what they will tell you after days of screaming, shouting and head banging. Neither in the beginning nor in the end will they be able to tell you why they think so.

Do I need to explain why scrum will miserably fail with type B people? The only way of saving yourself from a heart attack will be to commit suicide.

So far I mentioned only PMBOK approach and scrum. I did that deliberately because that is what the debate has been about. Further I am not saying that PMBOK is a methodology and neither does PMI prescribe any methodology except the mention of waterfall model and spiral model, if I correctly remember. PMBOK is a collection of all the processes recommended by PMI, out of which the ones relevant to the project can be chosen and adopted for results. On the other hand scrum is very much a methodology.

The overall list of methodologies from the two main families is quite long. I do not think any methodology is bad enough not to deserve a place in the respective list. But for the practical situation I feel one size fits all does not work. The proper choice of methodology can be made based on the nature of project, resources available, capabilities of the organization, customer, other environmental factors and circumstances, etc.

In the end I would say, scrum worked for me because none of my projects related to lives of people. Had I been working on medical equipment hardware or software or a banking project, scrum would have probably been the last choice, system development life cycle (SDLC) the first.

P.S: Many websites refer to PMBOK as a methodology. I do not intend to contest anybody. In my blog I write what I know and believe. In legal language one would say, "To the best of my knowledge and belief."