About Reduced Flexibility in Project Management - Agile Blog - Riter

About Reduced Flexibility in Project Management

Hi, guys! As promised in the previous post, by this publication we continue the theme of project management. We remind you that it will include various views on technical development processes and, first of all, not from the editorial staff, but from your, dear readers, own practice. Send your thoughts and description of your project management solutions to us, because such valuable knowledge should be a common asset. One of the frequent approaches to development process, we have already heard about from our readers, is related to the reducing of flexibility in the project management.

You can wish to simplify the workflow of a programmer to such an extent that there will be nothing required to do at all. But in fact all problems of control and terms determination are based on the principles of flexibility and constant changes in requirements. After all, with a cascade model, we know relatively exactly how many people with what skills are needed to carry out the project, since all processes are approved at the stage of project preparation. In this case, everything, at least in theory, is simple and understandable.

And when the requirements change every day, programmers need to understand the overall architecture of the project, cover it with tests, explain their decisions to colleagues. New frameworks are being introduced all the time, and it's good if they are not burdened with the DevOps. The front-end developers write not only javascript browser code, but also the server layer on the Node.js, make up websites, work with database models and so on. In other words, in the right way such developers should be called "hybrid developers".

One of the difficulties of this approach is to understand what is happening in the neighboring room and, if necessary, to accept the task from there, that is sometimes not an easy duty. It turns out that the less clear project requirements you have at the beginning of the development, the more universal developers you should find and the more managers you need to link all the workflow elements together. As a result, it is clear that reducing of the manager's role, by a developer's version, should be proportionally to the reducing of a project flexibility. The solution is not the best, but from a developer's point of view everything looks that way. We became hostages to the fact that projects are launched, tested and changed without a strategy, only with tactics.

Remember that you are always welcome to share your opinion on such a project management solution and its perspectives in today's teams. Feel free to express your disagreement and alternative approaches to the workflow organization.

Riter development team