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.

Project Failure

Nobody talks about the project failure in an agile environment. Some people even celebrate failed sprints. Soon, I will post an article reflecting my opinion about the failed sprints. Now, let me talk about the source of the problems, which ruin projects.

I am sure that in most of cases overestimating the power of agile methodology breaks the project. The project and the related work are never better than the Scrum team and the team's will and knowledge. Agile projects contain the same tasks as the waterfall projects do. The only difference is in organization of the related work and the motivation techniques. Agile is not a miracle; it is just a methodology. What is really count are the people, the agile team behind the methodology.

Lack of the knowledge on the agile methodology is on the second place on the list named agile project failure. Scrum prescribes only few rules; Kanban has only three rules. It is not very difficult to keep these rules, is not it?

I heard many time that the scrum rules must be altered. However, I rarely heard the explanation why scrum rules must be altered. Some says that the goal of the retrospective meetings is the altering the scrum rules. I do not agree. I believe that the agile rules should be untouched. In the retrospective meeting, the working principles must be altered in order to increase the production of the team.

Some weeks ago, I worked as an advisor. I was involved in other company’s project and my job was to analyze the project progress and the possibility of success.

For the first sight, the dark fate of the project was obvious. The team went against the basic Scrum rules. The sprint length was set to 30 days. They reserved 5 days for planning at the beginning of each project and the last 5 days of sprints were testing period.

Wow! Five-day sprint planning sounds a bit much. After some analyze, I realized why they had reserved five days for planning. They just did not know the real requirements. The Product backlog contains standalone stories and the relevant business processes could not be covered by stories.

They said that they had not had enough time analyze the requirements. They wanted to do it during the Sprints. I still wonder how they wanted to set priorities to stories if some of the stories were unknown. The other dangerous point was that the customer did not know much about stories, scrum and software implementation at all. They were sure that their existing business processes would be supported by the new IT system. The customer had no idea that the IT guys did not oversee the business requirements. The language of stories was mostly technical and therefore the business people did not understand them very well.

The testing period at the end of the sprint also could be very dangerous. Tests must be executed during the sprint, on the fly. Otherwise, there would be no time to correct the error and then you will have a non-working product at the end of the sprint. I know that it is true. I know it well. We made the same mistake some months ago.

I started my analyze work in the middle of the second sprint. I rang the bells, but nobody believed me. Nobody wanted to believe me.

The situation changed at the end of the second sprint. The IT guys celebrated the end of the failed sprint. The business guys did not understand the reason of the celebration. They understood only that after two months there was nothing to see.

Then they decided to listen to me and revision their working principles. Why do I tell this all to you? I just would like to draw your attention that it is not a good idea to change to basic Scrum rules. Of course, you can do it. However, before acting so, take a deep breath and think if it is worth.