Gangnam Style

I participated in a PMI conference. I do believe that PMBok contains useful good practices and I do believe that the PMI approach is extremely practical.

There, I learnt a new term the technical project manager. So far, I had supposed that technical project manager was some kind of IT project manager or similar. In accordance with the PMI terminology, the technical project manager is a guy, who knows project management tool and methodology very well and who ignores the project members need, except the stakeholders, of course.

Because, the main subject of the conference was that a project manager had to have technical, leader and manager abilities. The difference between the leadership and the management is that objects are managed and people are leaded.

This approach is not very far from agile, is not it? If you are familiar with them meaning of the PMI expression ‘progressive elaboration’ than you must agree that PMI good practices and agile methodology are very close to each other.

Then why do many people count PMI and agile as opposite approaches? For the first sight, I would say because of the lack of knowledge. However, after the conference, my conviction has changed. Dozens of other reasons could stand behind the curtain. The first and maybe the most important reason could be economical. Both, the Scrum Alliance and PMI organizes exam on agile methodology. Certificate of which organizations has to be better? Which of the organizations can take the money of the agile candidates? These questions are uncomfortable, are not these?

Courses of Scrum Alliance are connected to software development. PMI counts that agile methodologies have to be extended on other industries, as well. And this approach is right; just think about lean methodology.

However, I did not like one of the presenters’ approaches of agile management in the conference. He announced that Scrum does not work; therefore it has to be modified. I do believe that modifying Scrum can cause more problems than benefits. Some people just modify Scrum rules because they do not understand the Scrum basis or they just do not want to struggle to keep them. In these cases, changing the rules can be very dangerous.

The presenter showed us some examples of modified Scrum rules saying that these examples were taken from real life.

The idea of the first example was developing first in iterations and testing when the code is ready. Testing had to be embedded in the entire process. Otherwise, the implementation-testing-correction-testing process could be a never ending story. Believe me, testing on the last day of a sprint guarantees the unsuccessful sprint. There is no time to correct errors and retest them until the end of the sprint.

The second example puzzled me. The idea was based on two separate iterations. The project itself was divided into two phases, the planning and the implementation phases. The deliverable of the planning phase was the system plan. The system plan was written through some iteration. The input of the implementation phase was the finished system plan. The implementation phase worked out through iterations. It is an interesting approach, is not it. If the system plan was ready, complete, and validated, then it had to be implemented. Why are iterations necessary in the implementation phase? It is the mystery.

So, be careful if you decided to change Scrum rules.