Integrating Problems Into a WorkFlow: an Alternative Approach to Business Processes

We are introducing a new category on our blog: personal notes of our colleagues from AdTech Holding who share their fresh ideas on business approaches and development processes.

Today, we are publishing notes of Alexey Pilov, the Team Lead of the AdTech Product Team. Their value is that they unveil an alternative view on problems that product, management, and support teams regularly face.

Sometimes, team leaders, project managers, and other team members struggle to solve various persistent issues. However, they keep failing to find efficient and straightforward solutions. Alexey suggests another approach: what if the issue does not require to be solved and can be implemented into the business process smoothly instead?

This is what is behind Alexey’s provocative statement, ‘Not every problem is a problem’. To show what this approach is about, he shared three real-life examples from his team’s experience.

---

Alexey Pilov: Not Every Problem Is a Problem

Case 1: You Don’t Need to Plan Everything

Teams often spend plenty of time on task grooming or planning. However, in the end, they still don’t have enough time to finish everything planned within a sprint. An opposite problem arises when all the tasks are completed, and most of the team idles until a sprint ends.

The first thought coming to mind is that you need to learn some planning techniques. However, it’s not always the optimal solution.

In some cases, you do need to plan a sprint very scrupulously. For example, it is essential when there is a  very harsh deadline set for business reasons. 

Still, the experience shows that accurate planning is often premised on a cargo cult. In other words, people do it because everyone does — but rarely consider the real motivation for this planning. 

The best way to determine the workflow correctly is to consider a situation when your sprint plans were not accomplished on time and imagine the possible consequences. You might have two possible answers:

• It’s essential to complete everything planned for the next sprint. Otherwise, the tasks won’t be actual anymore. The most obvious case here is when a task is related to some event, for example, if we need to develop discount models for Black Friday.

Sometimes, failing to meet the deadline might result in more severe consequences. When a task is related to changes required by a new law, or when, for instance, we need to switch to the new API version before the previous API is disabled.

• If we don’t have time to, for example, change a pagination page size, the overall process will not be ruined. We can painlessly reschedule it for the next sprint if the team doesn’t have time for it this week.

There also might be a situation where you can schedule a relatively large number of tasks, keeping in mind that some of them will definitely be completed while some might be postponed for a later sprint. 

Today, the world is too changeable to be sure that even your next week’s plans will be realized.

---

Case 2: A Detailed Test Task is Not Required

Briefly, the problem lies in the communication between a team and the customer. And it doesn’t relate to only developers or service teams. For example, such an issue often arises when a customer support department forces a client to fill in an extensive detailed contact form.

So, the root of the problem is that a customer needs a team to perform a task but doesn’t specify many details. However, my experience shows that only a tiny percentage of clients come with a fully-structured and clear task, with all nuances and specifications described in professional language. 

In most cases, a task looks approximately like this:

— Hello, I need to add Paypal payments to my app. Please, do your best.

Such a task requires much time to analyze and groom it. 

What we need to admit is that it is not an issue but a norm. All a customer needs is the solution to his problem — and the precise wording of his problem is enough.

However, many teams tend to complicate interaction with a client, for example:

• Implement various formalities for a client.

It can be, for example, making them choose a topic of their request. Such a measure is supposed to simplify contact routing between the teams but usually results in an inconvenience for a customer.

• Add many necessary fields in the task creation form. 

The tricky part is that such an approach does not make the team’s life much easier, too. If a client does not know the required details or has no desire to spend much time filling out a form, the team will still receive a shambolic task description created with the only aim: to finally start or continue the process.

The reason is that it is you who needs a task, not your client. Thus, creating a precise task with all the necessary details and specifications is your duty. 

Instead of considering new requirements for a client, it is often easier and more efficient to spend it on communication throughout the whole working process. It might seem to be more complicated, but in fact, you will only benefit from it:

• You will start understanding a customer’s business better
• Together with the customer, you will find more straightforward and qualified solutions
• You will keep in touch with a customer and always be sure your solutions meet their needs

---

Case 3: You Can Benefit From Mistiming 

This one became actual for us after AdTech Holding began to expand and open new offices in different parts of the world. Before, we had no issues with synchronization: everyone started and finished working, had lunch, and left for a weekend at the same time.

So, our team became highly geographically dispersed, and it made a significant impact on synchronizing. Different time zones and local holidays changed the usual workflow, with very tight cooperation between all team members, where the consistent schedule helped a lot.

We did not want to refuse our standard synchronization habits at first and started considering various ideas. For example, we tried to move working hours or reschedule holidays and spent hours considering how to synchronize all the team members again.

In the end, we concluded that it was much easier to admit that every team member lives according to their local time and there is no necessity to change it. 

Such a fresh approach proved to have its advantages soon. Now, our overall working hours cover a much larger time span, which allows reacting to incidents and customers’ requests quicker than before.

---

Summary

In all three cases, we tried to solve a problem that was not easily manageable — or was not a problem at all after a look at another angle. What we got from it is new opportunities — and no more fighting against windmills.