Due date as a component of responsibility in the development process
The issue of efficiency is always a highly relevant one in the sphere of product development. How does one put together an optimal workflow in terms of business objectives, employee growth, and many other factors, while ensuring that it’s modifiable and transparent? Where is the “silver bullet”, which will solve all the problems at once and spare you a number of managerial headaches?
Various fashionable (and not so fashionable) development methodologies — Scrum, Kanban, XP, RAD, FDD, etc — alternately vie for the title of such a “silver bullet”. New ways and approaches, frameworks and tools emerge all the time. Business consultants meet with companies and impart their wisdom for a handsome fee, preaching the right way of doing things. And hopefully, a more economical way, while at it.
And it’s great if people can formulate the needs that they want to satisfy through this or that process. But oftentimes, a fashionable approach is implemented without much thought, which eventually proves inefficient or dissatisfying to various participants. And in this day and age, with its high velocity and the proliferation of start–ups in a highly competitive environment, such imprudence can prove disastrous for the business.
Let’s consider what’s required of the process, what problems need to be solved, and what approaches are adopted to accomplish this. And I’ll tell you about how we do this at Badoo. I’m Ilya Ageev, the QA Manager at Badoo.
Participants in the process
In speaking about the process, we primarily talk about its participants. Other aspects include conditions, results, resources, objective, etc. But the process of organizing teamwork in such a way that it’s both comfortable and effective in most cases implies a feature development process.
Various company employees involved in making a product come to work pursuing a variety of individual goals. It’s good if these goals can be balanced and good business performance can be attained by using joint efforts. It’s obvious, however, that the business and its individual employees don’t have the exact same goals and values. Someone may be saving up for a house, a new car, or a vacation. Another person is motivated by stimulating collaboration with others and personal development. Businesses are focused on earning money and regard their employees as resources that enable them to achieve their goals.
I think we can all agree that few companies (if any) exist for the sake of paying wages to their employees out of the sheer goodness of their hearts. Company goals are different from those of the employees and not always shared by them.
And it seems to me that in this complex symbiosis the company’s goals ultimately take priority over the goals of individual employees. A good company appreciates and loves its resources, but from the business stance, a person (like many other resources) can always be replaced (although it may sometimes be very difficult). One way or another, global goals are not subject to change. And it would be odd to expect this from a business. “How about instead of baking bread, we’ll now start giving musical performances at children’s parties!” On what grounds? If it’ll increase the profit and is easy to implement, then let’s. But no one would go for changing the direction of the business just because baker Volodya loves to sing (and might quit if he doesn’t get to do it soon).
Therefore, the first and most important participant in the production process is the business itself. Since it picks up the tab, it makes sense that it gets to call the shots. What does the business want? The goals may run the gamut, from charity to employing family members (yes, this happens too). But in most cases, the main goal is to improve the welfare of its owners. And preferably do so in the cheapest way possible. “How to spend less and earn as much as possible” is the engine propelling forth the free market.
In our production process of developing features, the business is represented by the product manager. His/Her job is to understand the business objective, formulate it, relay it to the developers — spoon-feeding it to them if necessary — find a compromise, and plan everything out competently. After that, he/she monitors the process, checks the result, and launches it into operation.
His/Her goals are obvious: to get as much work done as quickly as possible, allowing time for experiments, testing the viability of ideas, fixing any possible flaws, and starting to earn money on the product as soon as possible (I’m intentionally omitting the notion of quality, but it’s implied: no one will be buying a sub-par product).
Therefore, the product manager constantly inquired into projected time frames, surveys the current status, puts pressure on the other participants in the process, and seems to want everything done at once. He’s/She’s just trying to figure out how to do things in the most efficient way possible and, ideally, how to accomplish even more and do it faster next time. This is as it should be and a good approach from the business standpoint.
Therefore, we need to convey the importance of the product manager’s goals to all the participants in the process and explain where he’s/she’s coming from. And maybe then the product manager won’t have to breathe down the developer’s neck every half hour, asking him “Well, when will it be ready?!”, thus interrupting him and distracting him from the work at hand.
At Badoo, scheduling is a very important part of the development process. The delivery time for the new feature is determined as early as possible and referred to as the “due date”. It’s the date when the feature should be launched into production. The Due Date depends on many factors: it is affected by almost all the aspects of the product development process, ranging from the degree of detail in the description of the required changes to the method of delivering the code to the end user. Decomposition of tasks, complexity of interface design, testing and its automation, the amount of external interaction, and the architecture of code — all this can radically affect the Due Date. And given that there are people at work at every stage of production, the effect of the human factor on the delivery time is colossal.
Ideally, all team members would grasp the importance of the process, be very motivated and careful throughout, and always succeed. Is this possible? Not always. Especially when it comes to clarifying and sharing common values. But I’m confident that a compromise can always be found if we make sure that the subsequent participants in the process aspire to meet the deadline, focusing on some simple indicator and guided by simple rules.
In our company, the Due Date serves as this indicator. I’ll also tell you how we try to ensure that the developers themselves are striving to achieve the set business goals.
Who’s the next participant in the process? Baker Volodya. In our case, a programmer. What goals can a regular person have, even if we consider that the average IQ in our industry is quite high? Earn money and go to Bali, buy an apartment, save up for his old age, pay a loan, buy a Gibson, leave work early tonight, go to the cinema, and meet a good-looking girl next door. And since we’re talking about an IT crowd, let’s throw in a few more: unload some of the backlog at work, replicate a pesky bug and thus get a break from the boss’ quibbling, learn Erlang, feel around the new Python framework, learn English, assemble a drone on Raspberry Pi, and listen to the podcast about the advantages of Kotlin.
Of course, there are some great employees out there, who genuinely “root for the project” and “understand the business” — after all, we’re all in this together, working for a common cause. But try to leave them unpaid once or twice (I’m not trying to offend anyone — just painting the picture in broad, exaggerated strokes to illustrate my point). What would happen? They would go to Yandex, Facebook, Google, and any other company offering generous salaries, free lunch, and bonus perks in the form of massage and mani-pedi. And they would be right in doing so! Workplace is where the business buys the labour (and brains) of its programmers in exchanges for monetary compensation and is thus based on fiscal relations. And while the goal of the business is to get as much work as possible for the least amount of money, the employees have the opposite goal: to do as little as possible for as much pay as possible.
Of course, there are also other participants involved in the process: designers, copywriters, translators, analysts, testers, release engineers, sysadmins. But firstly, their goals don’t differ much from those of baker Volodya. And secondly, they often play auxiliary, rather than leading roles, covering for the primary troops — the developers — while they charge forward into battle. By the way, some of these job positions may not even exist in this or that company: they are often combined with other roles. In product development, all such personnel act as resources for production managers and programmers, facilitating their job, taking care of routine busywork, and so on.
So, the programmer is the second most important participant in the process after the product manager, who represents the business. Baker Volodya may choose to put all of his time into work if something sparks his interest: he may not sleep or eat or go outside. But a business process spans a wide range of tasks, including many boring and routine ones. So, if Volodya has completed ten tasks that are of interest to him, but not for the business, and only one boring task that’s crucial for the business, it’s tantamount to him having completed only one task. The business’s prime objective is to sell manufactured goods at a competitive price. What technologies are used in the process and how ingenuously Volodya implemented algorithms and baking tricks are all issues of rather secondary importance.
Of course, Volodya doesn’t want to know about any deadlines or coordinate with the product manager, designers, and accountants — he just wants to sit down and immerse himself in his interesting task (with no one interfering). And in these conditions, deadlines, plans, customers, and competitors — all comprise harsh reality, with which Volodya has to put up, but don’t serve as part of the strategic goal, as in the case of the product manager.
Responsibility
How to make it so that the company’s goals, which are so far removed from the goals of Volodya’s baker, are still taken into account in the development process? How to ensure that at all stages, with their many pitfalls, problems and surprises, decisions are made that primarily benefit the company? How to motivate Volodya to comply with the deadline while avoiding problems with architectural planning, over–engineering, and other potential challenges, which may steer him away from the needs of the business?
At Badoo, we refer to this process as the “developer’s responsibility” and stimulate and encourage this responsibility in every way possible. As I have mentioned before, our developer acts as a micro project manager of projects on which he is working. What does this mean, and how do we stimulate it? It’s quite simple: the developer is responsible for compliance with the deadline (the aforementioned Due Date).
This means that the developer himself is in charge of setting the deadline. Of course, he must do this by carefully examining the problem and trying to take into account as many factors as possible in his planning. And of course, he should strive to meet this deadline. But we need to be prepared for a possibility that the developer may fail to meet the deadline. What matters is how to proceed: we consider every nuance that prevents us from meeting the deadline and prepare a response to it (so as to ensure that next time this problem can be avoided).
It’s the developer who should be required to give an answer, because he knows the project better than anyone else. He has set the deadline this time, and he will set it again in the future. He may get it wrong again — that’s OK. The important thing is that this approach improves the engineering culture and stimulates the growth of the developer and the company as a whole. And it’s obvious that a dependable solution needs to be found on how to avoid such problems in the future. Not just to “try to do better next time,” but make it so that it doesn’t happen again, minimizing the human factor as much as possible.
It would be nice if the technical manager upon receiving the Due Date and confirming it would not take his attention off the project until just before the deadline, for that’s risky and postpones the solution of many problems till the last stage (problems that are easier, faster and cheaper to solve immediately ). Instead, the technical manager should periodically check in on each task at agreed upon intervals (so as not to distract the developer from his work) and get an update on the situation, correcting the time frame as needed. A need may arise for a compromise decisions that allows for the deadline to be met, but leave some “polishing” and fine–tuning improvements to the functionality to be done in the future.
It’s also worth mentioning that simply pushing the deadline by an n number of days is not the best solution. How can it be controlled? It’s very simple: the tasks completed before the deadline should also be considered incorrectly planned out. Note that “incorrectly planned” doesn’t mean that everything is bad and the developer should be punished — it just means that it should be noted and brought to the manager’s attention, and the problems that have affected the time frame should be discussed (these may include “creative ecstasy” and unexpected finds during the development process).
Of course, we can’t forget about the Parkinson’s Law, which states that work will take the entire time that’s allotted for it. But first, the most effective way to counteract this is to shorten the time of the task execution by accomplishing something useful before its completion, which fits nicely into the development of a feature process, since we are always working on several projects simultaneously. Secondly, we regard any deviation from the deadline as a premise to undertake a retrospective and stimulate the development of a reliable solution for making a more accurate forecast in the future. And thirdly, even if we have met the deadlines, we must always ask ourselves how it can be done faster next time.
It’s vital to grasp the essence of this: we are not striving to just make everyone observe the Due Date. The development of a feature process (unlike that of baking bread) inherently includes too many uncertainties. Very few tasks are similar to one another: there are no “universal” bread loaves. If the baker failed to do his work on time, it means that either there was a force majeure (the bakery lost power, flour wasn’t delivered on time, etc.) or he is just lazy. On the contrary, in development, it’s rarely possible to meet the deadline, even if one tries very hard. So if the developer didn’t meet the deadline, it doesn’t mean that he screwed up somewhere. The heart of the matter is elsewhere: we look at the reasons why the deadline wasn’t met and evaluate the contributing factors (what affected the time frame: the situation, resources, human laziness, or lack of understanding of business goals). The developer can be very productive, but constantly distracted by minor things that may seem important to him because of the lack of proper focus on the result, (or, alternatively, because we took some time off working on his task to help Vasya down in Shipping, because they’re chums). As a result, the developer may have many reasons that he sincerely considers important. Meanwhile, the result is missing. Here, the manager is called upon to provide ongoing support and adjustment.
So, let’s summarize.
1. The developer sets the deadline for the task in the form of a Due Date. This is the time when the task is supposed to go into production.
2. The technical manager must confirm the Due Date. It would be nice if he did this after first examining the project for himself and immediately pointed out the factors that might affect the future timing. Coaching should start already at this stage.
3. The manager must check on the status with the developer at certain points stipulated in advance: to consider the problems that may have already arisen and the processes that can already be accelerated. Example: “Why did the review of three lines of code take three days?”
4. After the completion of the project, no matter how it goes, a retrospect should take place centred on the question “How do we do this faster next time?”
The Due date is an optimistic forecast. In our company, everyone understands this and knows that the developer needs the manager’s support at all stages of the project. And even if we assume that the developer will have a small surplus of time, which helps him feel more at ease and confident, there’s nothing wrong with that. Our goal is to do things effectively and pragmatically, and not drive anyone into the ground, because we have to keep working together on plenty of cool projects.
Examples
The following situations can be considered as examples describing good and not so good solutions. Obviously, these solutions are not the only right/wrong ones, but I hope that the essence is easy to grasp.
1. The task was reopened too many times, because the testers kept finding a lot of bugs, which led to unnecessary time costs in all the adjacent stages: context switching, waiting for the task to make it down queues, etc. A bad solution is to yell at the testers, fire them, and hire new ones. A good solution: cover the code with unit tests, in order to receive feedback about the quality of the code faster next time; work on methodologies and practices to improve the quality of the product.
2. The designer made a overly complicated design of the new feature, so that the buttons had to literally be drawn from scratch, which took too much time. A bad solution is to ask the designer not to do this again. A good solution is to create guidelines for your app and have standard components in place, give these guidelines to the designers and work in accordance with them.
3. The developer decided to make a new feature on a trendy new framework, which led to changes in other places; as a result, almost everything had to be rewritten. A bad solution is to tell everyone that the framework is no good and never use it again. A good solution: the task should contain minimal amounts of code — only enough to execute this specific task; new approaches, frameworks, etc. should be routed to separate tasks under technical debt along with an investigation, smooth deployment, and so on.
4. In the process of working on fixing a bug, the developer found another old bug and began fixing it, digging into the old code and refactoring half of the project. A bad solution is to forbid correcting bugs and refactoring. A good solution: the task should have minimal code — only that which concerns bug fixing. Despite the fact that XP involves development through refactoring, one needs to think the situation over several times before going into reworking everything. It’s often better to postpone refactoring at this stage. Pragmatic considerations should come first, and not the elegance of code and flawlessness of architecture. If you think that you need to refactor, discuss it with the manager first before getting down to “shoveling” the code.
5. We did everything on time, but two days after the layout we found out that a very important component of the system has been broken by new code. Users could not use the product, and the feature had to be rolled back and repaired. A bad solution is to punish developer and testers. A good solution is to start monitoring this and other important components of the system, cover them with autotests, and complement new features with at least minimal statistics on proper functioning and basic business indicators.
There’s an infinite number of possible situations — one can’t foresee everything. But in resolving a problem, we each time aim at solving a number of similar problems in the future. This approach not only improves the whole project, but also significantly increases the developer’s skill set, since it stimulates him to look at problems more broadly. The developer in this case becomes more experienced in architecture and management areas and feels to be an important part of a single, evolving and constantly improving engineering team.
And it’s good to remember that there should only be one person in charge. Even if there are several developers working on the project, one of them should be responsible for coordination and staying on schedule. Often, this is the most experienced developer on the team. This way, we try to avoid a situation of collective responsibility: after all, if everyone is responsible, then, essentially, no one is responsible.
At Badoo, we also practice the approach where we put in charge not the most experienced, but the youngest and most enthusiastic developer — in order to stimulate his or her growth. In such cases, experienced developers observe all phases of the project and assist in every way by advising and point out mistakes. And even if takes longer to develop a feature (although this doesn’t have to be the case) and increases the number of risks, such an approach is strategically wise, since it fosters the growth of people in the team.
Conclusion
When creating a process, I try to make it so that the system optimizes itself. In the theory of inventive problem solving, there is an approach called the “ideal end result” (IER). It proposes, in solving a problem, to imagine an ideal image of a solution, when the necessary action takes place without any costs, complications, and undesirable effects.
In the development of a feature, it often happens that we demand something from the developer, try to control it, surround ourselves with more and more indicators to gain confidence that everything is going according to plan. But the more people, the more tasks, and the more indicators are involved, the more difficult it is to manage the process. As a result, one may arrive at a situation where there’s no time for anything but for charts and conversations, and yet things are still not going very well.
In addition, there are a lot of factors that affect the developer’s motivation and stimulate his understanding and adoption of the company’s business goals: business prospects, understanding the project’s importance for the company, desire for smooth implementation and operation, subjective satisfaction with the customer, etc. A lot of this is difficult formalize and measure. And it’s even more difficult sometimes to convey the value to a specific performer. Oftentimes, even a very good developer doesn’t notice when the product trends change direction and needs some kind of clear and simple mechanism that indicates the right direction.
Accordingly, I consider the Due Date as one of the main tools for stimulating the developer’s IER at all stages. It goes through the whole process and makes it necessary to invent solutions to avoid a ton of problems in the future. It allows us to delegate responsibility without resorting to multiple KPIs. It’s comprehensible and accessible to almost everyone. And it guides us all towards the key business goal: to making as much as possible as quickly as possible. And whether it can also be done cheaply depends on the solutions that we use, and therefore, on all of us.
And how do you do in your company?
