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.