And some more thoughts on project management methodologies

Recently, I have often been enrolled in a camp of opponents of project management methodologies (more often referring to agile / scrum / kanban). This is not entirely true. I am not against methodologies, but against their fanatical application to the place and without it, as well as simply mystical confidence in success after the implementation of agile.

It seems to me that many do not understand why a methodology is needed at all.

Methodology is a kind of contract (agreement) between all participants in the process. It is like a sign language, rules of the road, Esperanto, or mathematical formulas. The difference between these examples and aglile / scrum / kanban is that they do not imply different interpretations. In the case of aglile / scrum / kanban, each company, and even each team has its own kanban, which for the most part has nothing to do with it.
')
In fact, you just need to get together all the participants in the process and discuss all the nuances. This is quite simple, for example:

1. Reporting. Once a week in writing, twice a week (Tuesday and Thursday) - via Skype.
2. Response time For regular letters - 4 hours, for those that are marked as "important" - 1 hour (for many companies it is 15 minutes).
3. Duties. Vasya answers for technical questions, Kohl for the server, Petya for tea in the kitchen.
4. Etc.

For example, why write tasks on a blackboard if they are in fat or TFS. If you are sure that there will be no problems with this - feel free to exclude this clause from the “contract”. And notice, this way you can combine best practices from different methodologies, adapting to a specific team and project. By the way, this is also agile, only without the pseudo-elitism.

The task of the manager is not to write a report on the work done or to find performers for the project. Project management involves achieving the goal in the absence of the necessary resources and complete or partial uncertainty. I believe that knowledge of risk management techniques and business fundamentals will help the average team more than the introduction of agile.

Further, any management methodology is intended, first of all, for experienced professionals. Thus, if you have new specialists or new employees in your team (and this was the situation in every first team I worked for), then the introduction of flexible methodologies will adversely affect the performance of some team members. After all, the junior will think: “ok, I don’t have time for this sprint, I will do the following, as the methodology says” (although this is not the case).

Recently asked: "Is it possible to have a fixed price + agile?". Why not. With proper planning. But, again, proper and effective planning does not depend on the methodology, but on the ability to plan correctly (sorry for the tautology).

Another problem is the use of agile / scrum / kanban where it is not necessary to use it. For example, in projects with very limited deadlines or R & D. Or when the performance of your task depends not on you or your boss, but on external factors that you cannot influence. Examples are many.

As conclusions:

1. Does it make sense to introduce methodologies? Definitely.
2. Does agile mean everywhere? Not.
3. Does it make sense in all forums and sites where there is the word “methodology” to write “agile will save everyone, and if not, your hands are growing out of assholes”? Your will, but from the side you look, at least, stupid.
4. Do I need to read books about methodologies and go to agile parties? Definitely, yes. But you should be skeptical about everything you hear and sift all opinions through a strainer.
5. And finally, which methodology is better? There is no better methodology. The best methodology is the one that suits you, your team and customer at a particular moment and in a particular place and project.

Thanks for attention!