Hi, guys! Thanks to everyone who reads our blog and shares own views with our team! We will try to answer all questions and raise topics you have mentioned in this or many further articles. One of the most frequent issue is related to the project management bureaucracy. Should we accept or deal with it? How to avoid a loss of productivity and the resistance of developers while meeting all the requirements of a methodology used? Let's attempt to find the best solution together.

An ideal project management methodology should not show itself during the process of use. It must be as transparent and unconstrained as it can possibly be. To achieve this, you need to remember that a person is very lazy by nature. Anybody without exception. And our brain is arranged in such a way that we always adhere to the strategy which allows us to achieve the desired with minimal efforts. Of course, it is important what is meant by "desired" in a specific situation, but now we are talking about developers, so let's focus only on their goals. And their common purpose, by definition, is realization of a particular task. And you should not doubt that it will be done in the simplest way which they will be able to imagine. Project managers are continuously trying to cope with this human trait with enviable regularity and varying success.

So, the problem statement. Here's what we have: a developer needs to implement a task assigned to him with minimal effort (for the developer). The manager's goal: to introduce a system of tasks estimation and tracking for competent project planning.

It's about time to remember about Agile. Let's make the developer to spend time estimating time required and describing the solution before he starts working on the task itself. Let him also first defend his position at the meeting with colleagues and managers. Then every day the developer will write a report on the work done in a free form and commit the progress of the task. Obviously, during the workflow a lot of problems and questions appear, which the developer wants to get answers for. And he, of course, looks for the easiest way to solve the issues. And this is the most interesting thing: what exactly does he do? He is initiating a personal conversation (if it's possible) or contacts other team members via audio-video means of communication if he prefers to communicate. Otherwise, he writes to a chat, if our guinea-pig is an introvert.

After receiving all the answers, it would seem that, finally, it's time to start solving the problem. But no such luck! The developer now needs to update an information about the task in the tracking system used, add a report on all conversations and their results, change a status of the ticket and so on. Of course, everything that the developer must do when the solution is already known, is perceived by him as unnecessary actions and the whole nature of the person goes against doing it. A thousand of reasons can be found why you just need to postpone the ticket editing for later, and why it is also catastrophically important not to change a current state of the task right now. The developer implements the task properly, correctly organizing everything in the code, but for the rest of work the forces and enthusiasm do not remain.

A possible solution: to hire a special person and give him a whip with the power to constantly check the relevance of the bureaucratic machine. For a misconduct the developer will receive ten lashes. The goal is achieved: developers are completely unwilling to experience the full strength of the whip on themselves. A lack of such a solution: our developer drastically changes priorities. Now the main thing is to fill everything correctly in Jira, while the task realization, in fact, takes a back seat. As a result, an interest in the project and work on it is rapidly declining, managers are trying to compensate for this with cash bonuses, that does not help anymore. Smart developers, who write good and correct code, leave the company. There remain those who want more money and agree to fill tickets. That's why morning briefings become so boring and tightened.

Let's think together about a better solution of this problem within the majority of existing companies and organizations. The decision should be completely feasible, it should not require to shoot the entire team and recruit a new one. It won't also be very effective just to use electric shockers or something similar instead of whips. To find the best way, it would be reasonable to use the experience of many companies, review the applied practices in various software development areas. So, if you have an idea to share, feel free to write us about it. How do you deal with the problem in your team? Or, maybe, you don't have such a trouble at all? Describe how the project management process should be organized, in your opinion. We will try to take into account all views on the problem and come to an optimal decision.

Riter development team