Recommendations for developers on process improvement

Recommendations for developers on process improvement

Recently met with software development executives from several companies. The meeting was informal, but it was not without discussion of working points. During the conversation with a colleague, they touched on a “pain point” – the setting of tasks. A typical situation is when the task sounds like “Add a Notifications section”, “Do filtering on the page”, or “Do well”. will be completed quickly. The problem is widespread, and illiterate production leads to curiosities, but more often to an increase in deadlines due to the expansion of the scope of work.

The difficulty is that product managers often report to the head of development, and they have different goals. The consequences of a poorly formulated task are often obvious to the product manager, as well as that the task is unclear to the team.

An example from practice: I conducted a detailed analysis of the process of working on tasks, it turned out that everything starts with the fact that developers take tasks to work, and immediately call the manager for clarification. It turns out that the issue is not to call if something is unclear, but to always have to call. Upon deeper analysis, it became clear that clarifications are needed both at the initial stage of work on the task, and throughout the entire process of its implementation. For the manager, it meant the loss of several tens of minutes, but in reality the consequences were much more significant. A manager, spending 30 minutes on thorough consideration of how to formulate the task, would save much more. Developers lost an average of 3:00 to prepare for launch.

We have Agile

I tried to convey this problem to the manager and that the reason is too vague wording of the tasks. The answer was something along the lines of: “Why cling? This is how we always work, and everyone perfectly understands what is required of them. At Agile, we value communication over documentation.”

As a result, even if there is something important in the task description, it is not read. The manager is surprised when something is lost: “How so, because everything is written?” I will reveal an unpleasant truth for managers: if you issue tasks that require clarification, do not expect that the description will be read. Throughout the text, only the name of the task will be used to refer to it.

Here is another funny moment. The manager created a bug that seemed critical to him and assigned it to a certain developer, with a description like “well, you yourself know where the error is.” As I mentioned, our divisions operate independently and our team does not coordinate vacation schedules with the product team. With us, any developer can take on fixing any bug, because we value flexibility in scheduling vacations, and it’s also good for business because there’s no dependency on one employee. It’s a win-win situation. It is enough to make good descriptions. It was this situation that had consequences, because this happened at the moment of implementing the watchful roar of descriptions immediately after creation on a daily basis.

This is where we smoothly move from examples when managers poorly set tasks to problems, and why is this accepted by development teams? In the comments on the previous post, there was a lot of outrage that those leaders lacked the determination to deal with this problem.

A problem is rarely solved by the efforts of one person. You may not know about it, but it may turn out that someone is already working on it. The assignments keep coming, but his performance leaves much to be desired. Often, developers prefer to accept the task and resolve issues as they go.

It is important to realize that even the team takes on a vaguely formulated task, the problem shifts from their side. It is as if you took a defective workpiece on the assembly line and tried to do your part of the job, resulting in a poor quality product. Or as if you took a part that was not pre-processed, and now you have to make an extra effort to bring it to mind. This will likely take longer than expected and may require multiple fixes.

So, when you accept an assignment and don’t fully understand its boundaries and expectations, you are taking on a risk. You can influence the task setting process only indirectly through communication and retrospectives. The manager may even agree that the approach to staging needs to be changed, but his agreement does not guarantee that the tasks will immediately become better. This process is out of your control. Control passes to you when a task enters your backlog.

You’re still spending time looking at the process, so it’s better to spend that effort defining the task from the start. Start preparing before it’s time to move the task to “Active” status. Some may say that the problem is not on their side, but consider: when you take on a job, you take the problem on yourself. Do not start work until it is clear what exactly is required of you. Clarify the details, decompose the task, or at least agree on a specific first step. From the general “do well” you can highlight the first step – add the inscription “It’s good here”.

Let’s say you’ve mastered an approach to work in which you spend time analyzing a task in depth before starting. This stage is fundamental and promotes further progress.

In order to get the tasks clearly formulated at the start, it is important to reach a common understanding and agreement on the problem. If agreement is not reached during the discussion, it is advisable to conduct an analysis and estimate the current costs associated with the existing problem and its formulation.

For analysis, it is necessary to break down the entire process of working on a separate task into several stages and estimate the time spent on each of them. Determine the time spent both directly on work and waiting time. You don’t need to be the leader, you can do it yourself. To begin with, you need to break down your work process into stages. Here is a sample set:

  1. Taking the task and clarifying the requirements for readiness for development. This is where you estimate how much time it takes to understand the task and clarify all the details needed to get started. For example, if you took the task, but the manager will be able to discuss the requirements only after 3 hours, and the conversation itself will take 15 minutes, then the total time of this stage will be 3 hours and 15 minutes, of which 3 hours is waiting time (wait time), and 15 minutes – Direct work.

  2. development. This stage includes direct programming, code review and bringing the task to a state that corresponds to the initial setting. Development efficiency is not discussed in this article, but a time estimation approach is also applied to it.

  3. Clarification of “what else is needed” and revision after clarification. This step often occurs informally, when in the course of work it becomes clear that additional functionality or changes that were not originally stipulated are needed. We measure the time directly for clarification and refinement, as well as the time for waiting.

  4. Time for fixes and problems that could have been prevented. Here you estimate how much time it takes to correct errors that YOU may have discovered in the early stages.

  5. Time to fix problems and finalize, which were not known at the time of setting the task. This is the time spent on solving unexpected problems that arose due to insufficient detail of the task. We measure the time for clarification and waiting.

Perform this analysis across multiple tasks, preferably with the entire team, to get quality averaged data. If you find that steps 1, 3, and 5 are taking a significant amount of time, especially waiting time, this indicates a problem with the assignment. Discuss this with the manager at the retrospective.

If you agree that there is a problem, it is very important that the product manager also acknowledges it. The main indicator of his agreement will be the willingness to invest his time and effort in real change. A simple formal “yes, I agree, come up with something, and I support” may mean that you have not convinced him, or he does not see delays in work as a problem for himself. Perhaps he feels that his involvement and investment are not justified by the potential savings in time and resources, and prefers that the team find solutions on their own. In this case, you should not waste time moving to the next stage. You will need to do additional work on analyzing the problem so that it becomes relevant to the manager, and so that he really wants to solve it.

If the product manager recognizes the problem and is ready to make changes, it’s time to move on to finding solutions. The correct formulation of requirements is the topic of more than one article, and the key point here is that each task should solve one specific problem and be formulated clearly and verifiable.

As part of the retrospective, it is important to pay attention not only to the expected result of the task, but also to the criteria for its readiness. It is necessary to reach a common understanding that a task falling into the backlog or, even more so, into the sprint does not mean that it is ready for execution. Developers must be able to confirm the readiness of a task based on clearly defined and universally understood criteria.

It is also important to agree on a procedure for actions in case the task is not ready for work. It is necessary to establish mechanisms that allow determining the unreadiness of the task in advance, and not at the moment when the developer must start working on it. This can include preliminary discussions of the task with the team, review of requirements before their approval, as well as regular synchronization of the status of tasks in the blog.

Thus, a clear and specific statement of tasks will minimize the time spent on clarification and correction, and focus the team’s efforts on quality development. This, in turn, will increase the efficiency of the team and bring satisfaction to the developers in their work, because they will be able to see the real contribution of their work to the success of the project and the development of the company.


Congratulations! My name is Leonid Netrebskyi. I have been managing development and projects since 2013. I have experience managing development teams of up to several dozen people. There is experience in managing development in companies with complete anarchy, imbued with sawing budgets to adepts of performance metrics. I am the leader who builds the process comprehensively, including CI/CD, test automation, architecture, SRE. If necessary, I can also write code to demonstrate an example or try something.

Once upon a time I wanted to blog to say something. Now I have something to say and am very happy to share my experiences and observations in the field of software development management.

Related posts