🧛🏿 🦑 😬 Scrum - the nuances of using a distributed team 🥡 🚺 ✨

Watching the use of Scrum in a particular team, I concluded that this framework, to put it mildly, is not quite correctly applied. A few years ago, when I first encountered Scrum, I took everything that was happening as some kind of previously unknown mess. Seeing another version of the mess in another company, I decided to read a couple of books on the topic, and then I was lucky to get into a startup as a developer, where Scrum really worked.

Important Scrum Books

Jeff Sutherland: A Revolutionary Project Management Method.
Eric Rhys: Business from scratch. Lean Startup method for quickly testing ideas and choosing a business model
Robert Fitzpatrick: Ask Mom: How to communicate with customers and confirm the correctness of their business idea, if everyone is lying around

If the first two were read in one breath, then the third came to me with great difficulty, I re-read some paragraphs twice. In my opinion, the effect of applying knowledge from the first two books may be weak without applying knowledge from the third.

Important books are not about Scrum

Scrum will not solve all your problems, relying only on this method, you can fail. Books to help manage any team:

Maxim Batyrev: 45 manager tattoos.
Mikhail Khazin, Sergey Scheglov: Stairway to heaven. Dialogues about power, career and world elite.
Robert Green: 48 laws of power.

The first book from the author, whom I greatly respect, will help to deal with typical problems that arise with the Russian leader. It focuses on the real experience of a person who has built a career from a simple sales manager to a member of the board. The second book, despite the apparent inconsistency with the subject, is a fundamental scientific work that explains the principles of the formation of any human communities, describes their laws. The book is worldview, changes the view of the world, "breaks the tower." The third book is very useful and contains numerous real world examples. Some laws of power mentioned in the book are deeply disgusting to me personally, but I admit that I either comply with them or lose them. The first book is very popular, the next two you will not find in any corporate library, because knowledge is not power,knowledge is Power.

Features Scrum

I will not describe Scrum, this is a long time and I’ll only ruin everything. But I note the most important, in my opinion, its features. If you start studying Scrum by reading articles on the Internet, the first thing you will find: in Scrum there is a team of seven people, Scrum master, a board with stickers and sprints. Yes, this is characteristic of Scrum, but does not define it. You can play this role-playing game, but you may not have Scrum at the same time.

The first thing you should pay attention to is whether you have feedback from end users and whether you make changes to the created product based on this information. If not, then rest assured that you do not have Scrum.

The second important feature of Scrum is such an adaptation of the product to the needs of users, which allows us to find out and develop the most popular functionality in the shortest possible time. It is known that MS Word users on average own no more than five percent of the total functionality of this program. If MS Word was developed according to Scrum, then this functionality would be developed primarily in the shortest possible time and for much less money. In addition, the final product quite often is completely different from what was originally conceived, and this is completely normal.

A third important feature of Scrum is the inclusion of innovation versus vanity indicators. In simple terms, vanity indicators are, for example, the number of new users registered per unit of time, or the position of a product on the market in terms of sales, etc. Accounting for innovations is an assessment of the effectiveness of new features in terms of support for these innovations by end users, positive or negative reactions of end users. In history, there are many examples of the fall of large companies due to excessive enthusiasm for vanity indicators, while their competitors kept a correct record of innovation.

The fourth feature of Scrum is its ability to provide self-realization opportunities for team members, eliminating useless work, downtime, burning life.

Another important feature of Scrum is its poor applicability in government projects. Scrum leads to a multiple reduction in the budget and terms of work, and this is not interesting to the state customer. Scrum is incompatible with corruption inherent in any government and any state, is not compatible with strict planning, a waterfall approach, strict technical specifications, detailed technical documentation, accurate forecasts of costs and time.

How accurately do you need to adhere to the Scrum rules?

Think with your own head, do not blindly trust people, no matter how authority they possess. For example, Jeff Sutherland in his book calls for the publication of salaries for team members. Seriously? The publication of salaries will lead to envy, resentment, hatred of some employees towards others, demotivation and even dismissal of some valuable employees. Most companies forbid employees to publish their salaries on pain of dismissal and do the right thing.

Scrum requires the openness of all team members to all, which is necessary for the continuous exchange of information, cooperation of all team members and the exchange of experience, mutual assistance, prompt elimination of problems by joint efforts, and increase the effectiveness of the team. Jeff Sutherland calls for getting rid of employees who do not want to share information, for example, for fear of losing value as an exclusive knowledge carrier, as well as getting rid of “toxic” employees. Blind leadership of this rule can result in the loss of a valuable employee. We must remember that brilliant ideas do not occur to all employees, even if there are a lot of them and they are friendly, but the idea chooses someone who was motivated by competition for a better place in the sun. There are many people, but there are only a few world champions and Nobel laureates. Who do you need in your teamthe next ordinary employee who does not conflict with anyone or the champion who provides the competitive advantages of your company, even with a complex character, let you decide. A simple tip: if you have an intelligent employee, keep the fools away from him and you will not have conflict situations. In addition, the duty of working openly is abused by loafers and loafers who try to sit on the neck of hard workers.

Scrum calls for the destruction of hierarchies. It must be understood that hierarchies are inevitable due to the inequality of people in education, experience, analytical skills, leadership skills, etc. Any stable system in nature has a hierarchical structure. Even if a company destroys hierarchies, they will spontaneously form. See books on power at the beginning of this article.

Do not forget that much that is completely natural and does not require explanation for the American reader is not such for the Russian one. Many practices that are effective in the West do not work for us at all. This may be due, in addition to differences in culture and law, for example, the rather large power of the American employer over the employee. An employer in the USA can fire an employee very quickly, and dismissal there may mean loss of insurance, ability to pay bills, loss of property, even poverty. In our country, the dismissal sometimes does not change anything, and sometimes it is not possible to dismiss. Hence, a different attitude to work, company, boss, competition, self-development, corporate culture. This gives rise to a different understanding of the same text, a different application of the same methods.

Sticker Boards

I can not pass by this phenomenon. If the team is in the same office, this may be a good solution, because it allows all team members to communicate face-to-face. In addition, meetings near the board are standing, which should help to avoid long meetings. However, the information written on stickers by hand is poorly readable and incomprehensible to new members of the team. You cannot attach a file to a sticker, add a description or a link. It is unclear who this or that task is assigned to. Yes, you can specify Jira ticket identifiers on stickers, but this does not solve the problem. You can often notice that more than 20 people gather near the board, despite the fact that the classic Scrum team should have no more than 9 people in it. During such meetings, small groups of employees by interests or specialization are formed,who start independent meetings, interfering with each other. And such meetings, as practice shows, do not pass quickly, despite the fact that they are held on their feet. Instead of three or five columns, you can often see a whole dozen or more on the board. But the most unpleasant in the presence of the board is the lack of a single source of truth, i.e. both a board and a dashboard exist at the same time in Jira. It's time to stop using the boards. Below I will give a description of the rally, which is suitable for both office and distributed teams.both a board and a dashboard exist at the same time in Jira. It's time to stop using the boards. Below I will give a description of the rally, which is suitable for both office and distributed teams.both a board and a dashboard exist at the same time in Jira. It's time to stop using the boards. Below I will give a description of the rally, which is suitable for both office and distributed teams.

Team member roles

Roles of team members can be, for example:

Product owner
Scrum master
Business analyst
Software architect
Software Analyst
UI / UX / Web Designer
Html developer
Front end developer
Back end developer
Full stack developer
DB Developer
Dba
Quality assurance
DevOps Engineer
etc.

Roles can be more or less depending on the type of system, its architecture and the stack of technologies used. Depending on the budget and personal preferences, team members can combine several roles. Due to the small number of tasks in their area, specialists in certain roles can be hired on a part-time basis or participate in several company projects simultaneously.

Real-time team option

Suppose we have a small startup with a limited budget, and we cannot afford one or more people for each role. Jobs are published on upwork, interviews are conducted by SM and SA. To hire team members, you can use the recommendations from my article “Online Testing - Are You Serious?” . The formed team consists of the following remote employees (taken from a real project):

Product owner (PO), aka Business Analyst. It focuses on the product, interacts with customers and investors, knows business processes. Determines the priority of the implementation of a particular feature. He is responsible for finances, transfers money (salary) to team members in accordance with the invoices for the period.
Scrum master (SM), Business Analyst, Software Analyst. , , , , , , (approves) , .
Software Architect (SA), Team Leader , DevOps, DBA. , , GitLab, Jira, Confluence, Jenkins, , Zoom, VPN, .
Web Designer () . Photoshop, Zeplin, Invision, Figma.
HTML Developer () . , HTML CSS Front End Developer / Full Stack Developer, . , , .
Senior Full Stack Developer () , DB Developer. - . MVP Full Stack Developer-. , , . , .
Part-time QA. At the initial stage, you can do without involving professional testers, but as the system grows, they become simply mandatory.

Initially, a team can consist of two people - a PO and a developer, or even one developer, who interacts directly with the customer.

Process

Every day a stand-up is held (a short meeting for 15 minutes no more), which is attended by all team members. Each of the team members briefly answers two questions: “what ticket am I working on” and “what is blocking me”. All meetings are held, if possible, through Zoom or another system that allows video conferencing with a screen demonstration. For meetings, trainings and business meetings, special tickets are created. This motivates SM to shorten the duration of rallies. If rallies last longer than 15 minutes, then SM is doing something wrong.

Columns in the project in Jira (option):

To do | In progress | Code review | QA | Demo ready | Done

Suppose team members live in different time zones from Yekaterinburg to Chicago. The optimal time for the rally may be, for example, 15:00. SM starts broadcasting its screen through Zoom, opens the dashboard of the project in Jira. Then SM includes a ticket filter for a member of the team, and only tickets for this team member become visible.

This employee briefly talks about his tickets in the In Progress column and the difficulties that he faces, about what blocks him. Next, SM switches the filter to another employee. SM ensures that team members perform shortly. In my case, I insisted on a separate ticket to write off the time spent on rallies, and after 2 weeks, SM greatly reduced the duration of the rallies, calculating their cost. If anyone has questions that require additional discussion, they are discussed at a separate meeting, the time of which is determined by SM. The creation of any meeting is accompanied by sending an invitation to the personal calendar to each of the participants. Using the calendar eliminates the need to recount the time of the rally in local time. Having identified and discussed all the problems,having arisen at the moment, SM takes measures to eliminate them, coordinating the actions of all team members.

Development is carried out in stages by sprints for 1 or 2 weeks. The result of each sprint is an intermediate version of the system with some new functionality (features). SM creates, starts and closes sprints.

SA configures the build and deployment to the test bench from any Git branch, which can be called dev. The dev branch is blocked for direct commits, only Merge request (MR) is possible. The developer does MR if he is sure that the quality and completeness of the features are sufficient for use by end users. Unfinished features do not fall into dev, MR is not created.

PO and SM coordinate the requirements, collect all the necessary materials in Confluence, create a specification. Flexible methods push documentation to the background. I came across both systems where there is no documentation, and systems where there is so much of it that nothing can be found in this ocean of information. The situation with an abundance of documentation is exacerbated by the primitiveness of the Confluence search engine. The optimal solution is a compact specification. It is a page in Confluence, in which there is a schematic representation of the interface (mockup) with marks and callouts. Below the image is a description of the functionality and behavior of each element marked in the diagram. The text has links to releases and tickets in Jira. At the bottom of the page there is a discussion in the comments.

Before the start of the sprint, SA forms a backlog, creates new stories and adds them to the future sprint, assigns developers to each story. Developers break stories into subtasks, determine Estimate (estimated projected development time) in hours and minutes. The resulting total subtask time determines the number of Story points at the rate of 1 Story point = 6 hours. Next, the team leader distributes the story among the developers based on the calculation of 8-12 Story points per developer for the sprint. SM starts the sprint.

SM ensures that tickets with interdependence are executed on time. For example, in order to program the front, it is necessary that the layout designer prepares the templates in HTML and CSS, and before that the designer makes a page layout. Thus, tickets should get into the work in a sequence that would allow all team members to work without downtime and mutual expectations.

Before starting to develop a new feature or fix a bug, the developer makes sure that there are changes in the specification, if the ticket contradicts the specification, then either the specification is finalized or the ticket is finalized or canceled.

The developer creates a branch in Git by the name of the story ticket, for example MVP-123. At the end of each subtask, the developer writes to Jira the actual time spent on each of the subtasks. As a TimeSheet, I recommend Tempo. At the end of the reporting period (2 weeks or 1 month), the developer requests approval of the hours worked by SM, forms an invoice for payment, sends it to SM. When all the tasks in the story are ready, the developer moves all the tickets (stories and subtasks) to the Code review column. At the same time, the developer creates the MR of his branch in dev, copies the link to it and places it in the comments to the story ticket, assigns the ticket to the reviewer (senior or team leader). The change of the artist is accompanied by his email notification.

When the team leader noticed new tickets in the Code review, he examines MR and, if he finds flaws, writes them in the comments in GitLab, moves the tickets back to the In Progress column. The developer finalizes the code, adds a comment in GitLab (or in another system), clicks the Resolve discussion in the comments, transfers the tickets to the Code review. A feature of GitLab is the inability to add multiple reviewers. This is often necessary if the changes affect, for example, both the front, back, and the database. BitBucket has this feature.

Sometimes situations arise when several MRs are received and they conflict. The conflict should be resolved by the developer who created the last MR. It merges the dev branch with its current one and resolves conflicts, makes an additional commit.

In some situations, multiple MRs, even in the case of a successful merge, result in the inability to build or the impracticability of part of the unit tests. Sometimes this becomes known after one of the media has stopped working, which blocks, for example, QA. That is, the team lead can conduct a review and accept the MR, but this does not guarantee the success of the assembly or unit tests. To solve this problem, for example, GitLab has the ability to configure Development Pipeline. In essence, this is an automatic assembly and testing of the commit, which is specified in MR. The review code is executed only after the successful execution of the Development Pipeline. If the Development Pipeline crashes with an error, the developer who made the MR fixes the error and makes an additional commit.

Timlid receives the code and accepts MR, and this automatically builds and deploys to the test server. The timlid wraps the code in the QA column.

QA begins testing new changes in accordance with the specification. QA creates manual testing programs. In case of unsuccessful testing, the ticket is transferred to the In Progress column - returned for revision, or a bug ticket is created in Jira, which SM assigns to one of the developers. After the testing is completed successfully, tickets are transferred to Demo ready and, subsequently, the feature is shown at the weekly Demo rally. If the feature is accepted, the ticket is transferred to Done.

If the tasks are not completed by the end of the sprint, they are transferred to the next sprint.

PO and SM determine the set of features (stories) that will fall into a particular release, plan the release date. Prior to the release of QA, regression testing is performed. At the time of release, a special branch is created in Git and is frozen for changes. Changes to releases are possible in exceptional cases and are made through backports. Backport is a special process for making changes to release branches. Some companies create special teams for backports.

At the end of each sprint, a Retrospective rally is held to discuss all the problems that have accumulated during the sprint, identify problems and obstacles that delay the development process, and make decisions on how to remove obstacles. For retro, a special page is set up in Confluence, which records: what we do, what we begin to do, and what we stop doing.

What is necessary for work (option)

Space Slack
Corporate mail in the domain of the company / startup (preferably, but not required). Mail can be configured in such a way that all letters will be redirected to the personal mailboxes of team members.
Zoom
Jira and Confluence, hosted either on their own servers or on the cloud.
Servers dev, test, prod environments, both native and leased, both physical and virtual.
Version control system such as GitLab or BitBucket.
Jenkins or Bamboo, or some other automatic build and deploy system.
VPN for access to environments and any servers.

Where possible, Slack, Jira, Confluence, Gitlab (or Bitbucket), Jenkins (or Bamboo) should be integrated with each other.

Time tracking

A good developer loves his job, seeks to improve his skills, gives all his best. The brain of a young man can be compared with fresh willow twig. Over time, the rod, which is woven into the basket, loses its elasticity and ability to take its previous shape or any other. The brain is also flexible and elastic while young. Few people manage to maintain the flexibility of their brain throughout life and in almost all the years of the most activity and susceptibility occur in young years. It is for this reason that it is important to subject your mind to the greatest stress at an early age, since it will be more difficult to develop in adulthood. It is for this reason that in the first half of your career you have to plow almost for wear, regardless of the size of the reward.

A good developer Self motivated (self-motivated), strives to do more per unit of time, ahead of the estimated time frame, increase your credibility, increase the chances of becoming a senior, team leader, sometimes the chances of getting an option. He is active, generates ideas, constantly explores new technologies, values his time. If the processes are not debugged in the team and the developer is idle without tasks, if the developer performs work that does no good to anyone, if the work does not develop him in any way, then he begins to feel that he is wasting precious time in his life. As a result, he goes to another project. Scrum allows the developer to avoid burning his life, helps him to realize himself, to feel his involvement in an important business.

In some teams, time is not kept and developers do not write off hours, receiving a fixed salary. In some companies, hours are taken into account, but as a justification for a fixed salary, i.e. the developer must work out and write off, for example, at least 40 hours a week. There are companies (or projects) in which the payment is hourly, and the developer receives exactly as much as he earned in accordance with the cost of his hour. Some companies practice hourly pay, but require the use of a time tracker on the computer of a remote developer, which not only calculates the time, but also sends screenshots, screencasts and various parameters of the developer’s activity.

Which way is better? In each case, the best may be any of these or some other. But I prefer hourly pay without using a time tracker and I will explain why later. I consider the lack of time tracking to be harmful, because it can lead to a feeling of unnecessary contribution to the common cause, even the futility of participation in the project. Time management, on the contrary, adds a sense of importance and relevance to the work performed by the developer, helps determine your own pace, motivates you to increase your own efficiency. I want to draw attention to the fact that it is important for the developer that his work be evaluated not only by the speed of the tasks, but also by the quality. Be sure to need a person, a leader who can evaluate the contribution of the developer. Unfortunately, on many projects nobody cares what the developer does,nor how he does it, nor how fast.

Sometimes it happens that the developer's speed is estimated by comparing the previously estimated time and the actual time spent. That is, if the developer is ahead of the estimates, then he is encouraged and vice versa. I believe that such an assessment should be used as inaccurate, indicative, and secondary. A preliminary estimate of time (estimate) can be made only approximately. A more accurate assessment can be made only if such tasks were solved repeatedly, but repeated tasks are not common. Even with extensive experience and high accuracy in predicting runtimes, you will not be immune from surprises. For example, the use of a library that was repeatedly used in other projects had an unpredictable effect on the system, moreover, a bug appears at runtime and the logs do not say anything.If there is no ready-made solution on StackOverflow, you can exceed Estimate several times. You need to understand that Estimate is a rough estimate that can be used as a guide. Exceeding by an Estimate developer, and if it is not systematic, should not lead to criticism from the management.

As a rule, the time actually spent is always less than Estimate. If the tasks are complex and the developer sees that the solution will require a little research, he can specify Estimate with a margin, but he should not abuse it.

SM or team leader, or anyone else on the team should evaluate Estimate's realism. This can only be done by an experienced developer, who, moreover, has the trust of management.

Let the remote developer evaluate the task at 2 hours, and complete it in 1 h 33 min and record this actual time spent in Tempo, transfer the ticket to Code review and take the next one. The question arises, can we trust the developer, because he could do this task in 15 minutes and devote the rest of his time to online games or even other projects? The answer is yes, we can trust. The most important thing that SM should pay attention to is whether the employee is effective, are the financial costs of the employee acceptable per unit of time. Is there such a team speed that will allow you to start MVP before the end of the startup runway. Firstly, the exact time spent on a particular task and even at a given level of quality is simply physically impossible to determine. One developer will take 2 hours to do this,and the other has 15 minutes, since much depends on experience and ability. In addition, in any project there are old-timers and beginners. An old-timer will find a solution in a matter of minutes, while a beginner can spend several days researching. Secondly, the developer can look for a solution not only at the time of writing the code, but also at any non-working time. An idea can visit a person completely unexpectedly and at any time. Evaluating the quality of the idea received and its implementation by simply taking into account the time spent on coding is inefficient. This is one of the reasons for the low efficiency of using time trackers - the developer works not only at the time of writing code directly. In addition, time trackers introduce an element of mistrust, turn the creative process into hard labor.in any project there are old-timers and newcomers. An old-timer will find a solution in a matter of minutes, while a beginner can spend several days researching. Secondly, the developer can look for a solution not only at the time of writing the code, but also at any non-working time. An idea can visit a person completely unexpectedly and at any time. Evaluating the quality of the idea received and its implementation by simply taking into account the time spent on coding is inefficient. This is one of the reasons for the low efficiency of using time trackers - the developer works not only at the time of writing code directly. In addition, time trackers introduce an element of mistrust, turn the creative process into hard labor.in any project there are old-timers and newcomers. An old-timer will find a solution in a matter of minutes, while a beginner can spend several days researching. Secondly, the developer can look for a solution not only at the time of writing the code, but also at any non-working time. An idea can visit a person completely unexpectedly and at any time. Evaluating the quality of the idea received and its implementation by simply taking into account the time spent on coding is inefficient. This is one of the reasons for the low efficiency of using time trackers - the developer works not only at the time of writing code directly. In addition, time trackers introduce an element of mistrust, turn the creative process into hard labor.the developer can look for a solution not only at the time of writing the code, but also at any non-working time. An idea can visit a person completely unexpectedly and at any time. Evaluating the quality of the idea received and its implementation by simply taking into account the time spent on coding is inefficient. This is one of the reasons for the low efficiency of using time trackers - the developer works not only at the time of writing code directly. In addition, time trackers introduce an element of mistrust, turn the creative process into hard labor.the developer can look for a solution not only at the time of writing the code, but also at any non-working time. An idea can visit a person completely unexpectedly and at any time. Evaluating the quality of the idea received and its implementation by simply taking into account the time spent on coding is inefficient. This is one of the reasons for the low efficiency of using time trackers - the developer works not only at the time of writing code directly. In addition, time trackers introduce an element of mistrust, turn the creative process into hard labor.This is one of the reasons for the low efficiency of using time trackers - the developer works not only at the time of writing code directly. In addition, time trackers introduce an element of mistrust, turn the creative process into hard labor.This is one of the reasons for the low efficiency of using time trackers - the developer works not only at the time of writing code directly. In addition, time trackers introduce an element of mistrust, turn the creative process into hard labor.

If SM is not sure of the plausibility of the time actually allocated to the task, he can look into GitLab and compare the code changes made on this task with the time written off. A developer cannot write off 2 hours in 2 lines of code. If SM does not understand programming, he can invite an expert to assess the realism of the time written off, for example, SA. Be that as it may, an adequate developer will not write off unnecessary time, because he understands that realism can be checked, and then the damaged reputation and trust cannot be restored.

When hiring team members, you must be careful and try to select decent people. Unfortunately, we live in an imperfect world, and sometimes people who are interested in easy money and people who are prone to deception sometimes appear on the team. The chances of taking a dishonorable person on the team, unfortunately, are quite large. Suppose a developer deals with the postscript of time. Here it is necessary to determine exactly whether the fact of registration was a deliberate act or inaccuracy of the record. If you think that the developer made the postscript intentionally, think carefully before you charge the postscript, because it is very serious and can poison your relationship. I believe that if the developer is quite effective and useful, then you can close your eyes to the inaccuracy of the time indication. In addition, subject to the foregoing paragraph,it is impossible to accurately determine the real value of the work performed. At the same time, you need to understand that if the developer’s salary is too low, he will find an additional project, he will be out of focus, his productivity will drop, and at some point he will go to this other project. If the employee’s efficiency is low, and besides, postscripts are revealed, fire him with a light heart.

Let's go back to the developer, who completed the task in 1 h 33 min and proceeded to the next one. At the same time, he wrote off 2 hours for the first task as it was at Estimate. SM can easily determine that the time interval between translating the task into In Progress and Code review status is significantly less than the time written off. That is, the fact of registration can be easily established, to pay the attention of the developer to this fact or not, SM determines himself. Of course, the developer can translate tasks into certain statuses in strict accordance with the time written off, despite the fact that he did not work so much. Or he can transfer several tickets to In Progress at once, so that the start time is as early as possible - you need to agree on the sequential translation of tickets into work. In any case, do not worry! Let me remind you, for SM, the benefits are much more important,which this person brings for the money spent on him per unit of time. SM can at any time exclude any team member from the project, but this can lead to unforeseen costs for finding and adapting a new team member, taken in return for the dismissed one.

SM can also point out that the time spent always or almost always coincides with Estimate. For SM, it’s a call to turn a blind eye to it or not, decide for him depending on the situation.

In some cases, in an effort to support the developer, management increases the cost of an hour. This must be done very carefully, as it may have the opposite effect when the developer begins to work less. He will see that the same money can be earned with less effort, and the freed up time can be spent on something else. Keep track of the cost of services in the labor market, while remaining a competitive employer, approach individually, be careful.

Financial relations

Remuneration should be as fair as possible and should motivate employees to increase productivity. Hourly pay is most suitable for this. The employer must pay for any labor costs of employees. Even if the employee worked for only one day and the results of his work were useless, you need to pay his time. The reputation of the employer is one of the most important assets. If the employer does not pay salaries or pays them with long delays, this can lead to high reputation costs, and in some cases, paralyze the hiring of new employees.

Some employers delay salaries until the tickets executed by the developer, for example, pass the test. In some cases, the developer is asked to fix the bug of the new feature at his own expense. All this happens for the reason that employers do not understand the applicability of a particular method of payment for services in different situations. Delay in payment and elimination of deficiencies at one’s expense is permissible during piecework, services rendered by legal entities under a contract, when there is a technical task and terms. But the budget is much larger. If you hire full-time or even part-time employees on your team, never delay your paycheck. If the employee is not happy, then fire him, but do not try to educate or punish the person with delayed salaries for poorly performed work.Pay the employee from the moment of employment to the moment of dismissal and without the slightest delay. This should be the golden rule of the company, since failure to comply with it will inevitably lead to grave consequences for the company.

Scrum - the nuances of using a distributed team