Recommendations for developers to improve the process

We recently met with software development managers from several companies. The meeting was informal, however, it was not without discussion of working issues. During a conversation with a colleague, we touched on a “pain point” – setting tasks. A typical situation is when a task sounds like “Add a Notifications section”, “Make a filter on the page”, or “Do it well”. In the previous article about the criteria for canceling a task in the comments, the developers raised problems caused by incorrect task setting. If the task is set correctly, then the work will be completed quickly.The problem is common, and illiterate staging leads to oddities, but more often to an increase in deadlines due to the expansion of the scope of work.

The difficulty is that product managers often do not report to the development manager, and they have different goals. The consequences of a poorly formulated task are often not obvious to the product manager, nor is the fact that the tasks are not clear to the team.

An example from practice: I conducted a detailed analysis of the process of working on tasks, it turned out that it all starts with the developers taking on a task and then immediately calling the manager for clarification. It turns out that the question is not to call if something is not clear, but that you always have to call. Upon deeper analysis, it became obvious that clarifications are required not only at the initial stage of working on a task, but also throughout the entire process of its implementation. For the manager, this meant the loss of several tens of minutes, but in reality the consequences were much more significant. A manager, having spent 30 minutes carefully thinking about how to formulate tasks, would have saved a lot more. On average, developers lost 3 hours to prepare for the launch.

I tried to convey this problem to the manager and that the reason was that the tasks were too vague. The response was something along the lines of: “Why quibble? We always work this way, and everyone understands perfectly well what is required of them. We are Agile, we value communication above documentation.”

As a result, even if there is something important in the task description, it is not readable. The manager is surprised when something is missed: “How is it possible, since everything is written?” I’ll reveal an unpleasant truth for managers: if you issue tasks that require clarification, don’t expect people to read the description. Of all the text, only the title of the task will be used to refer to it.

Here's another funny moment. The manager created a bug that seemed critical to him, and assigned it to a specific developer, with a description in the spirit of “well, you know where the bug is.” As I already mentioned, our departments operate independently, and our team lead does not coordinate vacation schedules with the product team. With us, any developer can take on fixing any bug, since we value flexibility in planning vacations, and this is also beneficial for business, since it does not create dependence on one employee. This is a win-win situation. It is enough to make good descriptions. In this particular situation there were no consequences, because this happened at the time of introducing close review of descriptions immediately after creation on a daily basis.

This is where we smoothly move from examples where managers poorly pose tasks to a problem, but why is this accepted by development teams? There was a lot of outrage in the comments on the previous post that these leads lacked the resolve to deal with this problem.

A problem is rarely solved by the efforts of one person. You may not know it, but it may be that someone is already working on it. At the same time, tasks continue to arrive, and their formulation leaves much to be desired. Often developers prefer to accept the challenge and work things out as they go.

It is important to realize that if a team takes on an unclearly defined task, the problem becomes theirs. It's as if you took a defective workpiece on an assembly line and tried to do your part of the job, ending up with a low-quality product. Or as if you took a part that did not pass the previous processing, and now you have to put in extra effort to bring it to perfection. This will likely take longer than expected and may require multiple corrections.

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

You're still wasting time on the process, so it's better to spend that effort defining the problem from the beginning. 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 keep in mind: when you take on a job, you take on this problem 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 it well,” we can highlight the first step – add the inscription “It’s good here.”

Let's say you've mastered an approach to organizing work in which you spend time deeply analyzing a task before you begin. This stage is fundamental and contributes to subsequent progress.

In order to receive tasks that are already clearly formulated at the start, it is important to achieve 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.

To analyze, 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 completing the work and the waiting time. You don’t need to be that lead, you can do it yourself. First, you need to break your work process into stages. Here is an example set:

1. Taking a task and clarifying the requirements until ready for development. Here you estimate how much time it takes to understand the task and clarify all the details necessary to get started. For example, if you have taken on a 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 for this stage will be 3 hours 15 minutes, of which 3 hours are wait time, and 15 minutes – direct work.

2. Development. This stage includes direct programming, code review and bringing the problem to a state corresponding to the original statement. Development efficiency is not discussed in this article, but the time estimation approach is also applicable to it.

3. Clarification of “what else is needed” and revision after clarification. This step often arises informally when, during the work process, it becomes clear that additional functionality or changes are required that were not initially agreed upon. We measure the time directly for clarification and revision, 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 could have identified at earlier stages.

5. Time to fix problems and improvements that were not known at the time the problem was set. This is the time spent solving unexpected problems that arose due to insufficient detail of the task. We measure the time for clarification and waiting.

Carry out this analysis for several tasks, preferably with the whole team, to get high-quality average data. If you find that steps 1, 3, and 5 are taking a significant amount of time, especially the wait time, this indicates problems with goal setting. Discuss this with the manager at the retrospective.

If you agree that there is a problem, it is critical that the product manager also acknowledges it. The main indicator of his agreement will be his willingness to invest his time and effort into real change. A simple formal “yes, I agree, come up with something, and I'll 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 to let the team find solutions on their own. In this case, there is no need to waste time moving to the next stage. You will need to work extra to analyze the problem so that it becomes relevant to both 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 verifiably.

As part of a 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 come to a common understanding that the inclusion of a task in the backlog or, especially, in the sprint does not mean that it is ready for implementation. Developers must be able to confirm the readiness of a task based on clearly defined criteria that everyone can understand.

It is also important to agree on a procedure to follow if the task is not ready for work. It is necessary to establish mechanisms that allow you to determine that a task is not ready in advance, and not at the moment when the developer should already start working on it. This may include preliminary discussions of the task with the team, reviews of requirements before their approval, as well as regular synchronization of the status of tasks in the backlog.

Thus, a clear and specific statement of tasks will minimize the time spent on clarifications and corrections, 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 from their work, since they will be able to see the real contribution of their work to the success of the project and the development of the company.

Hello! My name is Leonid Netrebsky. I have been leading development and projects since 2013. I have experience managing development teams of up to several dozen people. I have experience managing development in companies with complete anarchy, permeated by cutting budgets, to adherents 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 out.

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