Observing 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 perceived 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

“Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland, J.J. Sutherland, et al.

“The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses” by Eric Ries

“The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you” by Rob Fitzpatrick

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 can 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:

“45 tattoos of manager” by Maxim Batyrev

“Stairway to sky. Dialogues about power, career and world elite” by Mikhail Khazin, Sergey Shcheglov

“The 48 Laws of Power” by Robert Greene

The first book from the author, whom I really respect, will help to deal with the typical problems that arise with the team leader or manager. 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 topic, is a fundamental scientific research that explains the principles of formation of any human communities, describes their laws. The book changes the view of the world, “breaks the tower.” The third book is very useful and contains numerous examples from history. 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. The first book is very popular, the next two you will not find in any corporate library, because knowledge is not force, knowledge is Authority.

Scrum Features

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 in the Internet, the first thing you will find: in Scrum there is a team of seven people, Scrum master, sprints, a board with stickers. 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 the adaptation of the product to the needs of end users, which allows us to find out and develop the most important functionality in the shortest possible time. It is known that MS Word users on average know 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 unlike what was originally intended, and this is completely standard for Scrum.

A third important feature of Scrum is the “accounting 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 of 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. There are many examples in history of the fall of large companies due to excessive enthusiasm for vanity indicators, while their competitors kept the right accounting 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 projects of the state customer. 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 terms of reference, 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 they are right.

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 team’s effectiveness. 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 lead to the loss of a valuable employee. It must be remembered that brilliant ideas do not occur to all employees, even if there are many of them and they are friendly, but the idea chooses someone who was motivated by competition for a better place under the sun. There are many people, but there are only a few world champions and Nobel laureates. Who you need in your team, another ordinary employee who does not conflict with anyone, or a champion who provides competitive advantages for 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 should be understood that hierarchies are inevitable due to the inequality of people in education, experience, analytical abilities, leadership qualities, etc. Any stable system in nature has a hierarchical structure. Even if a company destroys hierarchies, they will spontaneously form (see books about power at the beginning of this article).

The Boards

I can not pass by this phenomenon. If the team is in the same office, this may be a good solution, as 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. We 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, we can specify Jira issue identifiers on stickers, but this does not solve the problem. We 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. During such meetings, small groups of interests are formed that 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, we 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 Jira dashboard exist at the same time. It’s time to stop using the boards. Below I will give a description of the meeting, 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 Engineer

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.

Team in real conditions (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 Scrum Master and Software Architect. 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. 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), partly Business Analyst, Software Analyst. It focuses on the team, solves organizational issues, arranges meetings, ensures the observance of the Scrum rituals, forms a backlog, creates stories and appoints performers, approves the time spent by the team members, approves the bills for paying for the services of each team member.

Software Architect (SA), aka Team Leader for developers, DevOps, DBA. Administers servers, environments, GitLab, Jira, Confluence, Jenkins, corporate mail, Zoom, VPN, allocates or blocks access.

Web Designer (designer) on a part-time basis. Interface design using Photoshop, Zeplin, Invision, Figma.

HTML Developer on a part-time basis. Although knowledge of HTML and CSS is a must for Front End Developer / Full Stack Developer, this does not always provide high-quality layout. For this reason, professional HTML Developers are invited to the team who transform the design into templates used in the further development of the front.

Senior Full Stack Developer (developer) for a full day, aka DB Developer. Due to the limited budget, it is not always possible to hire a Front End Developer and a Back End Developer. At the initial stage and to launch MVP, one Full Stack Developer will be quite enough. In addition, the speed of the team at the initial stage may be such that one developer will be enough. In the future, you can increase the team by hiring specialists for different roles.

QA Engineer (QA) on a part-time basis. 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.

The Process

Every day a stand-up is held (a short meeting for 15 minutes no more), at which all team members are present. Each of the team members briefly answers two questions “what issue 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 issues are created. This motivates SM to shorten the duration of meetings. If meetings 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 meeting 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 issue filter for a member of the team, and only issues for this team member become visible.

This team member briefly talks about his issues 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 issue to write off the time spent on meetings, and after 2 weeks, SM greatly reduced the duration of the meetings, 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 recalculate the time of the meeting to local time. Having identified and discussed all the problems that have 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 deploy 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. Agile methods push documentation to the background. I came across both systems where there is no documentation, and systems where is so much that in this ocean of information nothing can be found. 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 issues 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 estimated projected development time (Estimate) 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 lead 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 issues with interdependence are executed on time. For example, in order to program the front end, it is necessary that the layout designer prepares the templates in HTML and CSS, and that the designer already makes a page layout. Thus, issues 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 issue contradicts the specification, then either the specification is changed or the issue is changed or canceled.

The developer creates a branch in Git by the name of the story issue, 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 by SM of the worked hours, forms an invoice for payment, sends it to SM. When all the tasks in the story are ready, the developer moves all the issues (stories and subtasks) to the Code review column. In this case, the developer creates the MR of his branch in dev, copies the link to it and puts it in the comments to the story issue, assigns the issue to the reviewer (senior or team leader). Change of the person responsible for the issue is accompanied by his notification by e-mail.

When the team leader noticed new issues in the Code review, he examines MR and, if he finds flaws, writes them in the comments in GitLab, moves the issues 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 issues 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 end, back end, and the database. BitBucket has such an opportunity.

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 environments has stopped working, which blocks, for example, QA. That is, the team lead can conduct a review and accept 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. If the Development Pipeline crashes with an error, the developer who made the MR fixes the error and makes an additional commit. The code review is executed after the successful execution of the Development Pipeline.

The Team leader receives the code and accepts MR, and this automatically builds and deploys to the test server, wraps the issue to the QA column.

QA begins to test new changes in accordance with the specification. QA creates manual testing programs. In case of unsuccessful testing, the issue is transferred to the In Progress column — returned for revision, or a bug issue is created in Jira, which SM assigns to one of the developers. After the testing is completed successfully, issues are transferred to Demo ready and, subsequently, the feature is shown at the weekly Demo meeting. If the feature is accepted, the issue 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, 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 meeting 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)

Slack space

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 their lives and in almost all the periods of greatest activity and susceptibility occur in young years. It is for this reason that it is important to subject mind to the greatest stresses at an early age, since it will be more difficult to develop it later. It is for this reason that in the first half of career the good developer have to plow almost for wear, regardless of the size of the reward.

A good developer is self motivated, strives to do more per unit of time, ahead of the estimate deadlines, increase his 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 of 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 the above 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, since 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 own pace, motivates to increase 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 quality, but also by speed. 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 can only be made 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 the 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. Estimate is a rough estimate that can be used as a guide. Excessive development by Estimate, and if it is not systematic, should not lead to criticism from management.

As a rule, the time actually spent is always less than Estimate. If the tasks are complex and the developer sees that a little research will be required to solve, he can indicate 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 issue 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 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. It will take 2 hours for one developer, and 15 minutes for another, since a lot depends on experience and abilities. 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 received idea 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.

If SM is not sure of the plausibility of the time actually written off 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 are unfortunately quite large. Suppose a developer has entered an overvalued time. Here it is necessary to determine exactly whether the overvalued fact was a deliberate act or inaccuracy of the record. If you think that the developer made it intentionally, think carefully before you make a complaint, 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, taking into account what was said in the previous 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 get 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 overvalued fact 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 translate several issues to In Progress at once, so that the start time is as early as possible — you need to agree on the sequential translation of issues into work. In any case, do not worry! The benefit that this person brings for the money spent on him per unit of time is much more important. 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, this is a sign of increased attention. SM decides closes or not his eyes.

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 starts working less than before. 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 relationship

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 issues 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. A delay in payment and the elimination of deficiencies at one’s own 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 you are not satisfied by the employe, 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.