There is safety in numbers. The path to effective teamwork
A team is a group of people who move together towards a common goal, sharing tasks and responsibility for a specific result. Teams are created to solve tasks that one person cannot complete. An effective team achieves a goal in the shortest time possible with minimal costs.
Gather a few people and say: "Now you are a team, we are waiting for the result from you," will not work. People need to organize, give them a sane goal, motivation and solve problems.
Just about this transcript of the report of Evgeny Fedoreyev on TeamLead Conf . In the report, Yevgeny described in stages the process of organizing an effective development team at Banki.ru: about hiring, communicating, sharing knowledge and developing developers and testers within the team and department.
About the speaker : Yevgeny Fedoreyev ( hardj ) has been working on web development for 15 years, 6 of them are in the position of team leader, and now he leads the development of new projects Banki.ru.
The context of the company to know what kind of experience will be discussed. Banki.ru is the largest independent financial portal of the Runet with a monthly audience of more than 8 million unique users.
The IT department employs 50-70 people divided into 7 development teams. All development is conducted in-house, there are no remote developers, so there is no need for relevant processes and metrics.
When preparing for the report, I asked people the question:
- What is the purpose of the development team?
- Develop.
- What does this mean? If a person is sitting, refactor, does not benefit, does not solve business problems - is this also development?
- ... It is necessary to develop effectively.
The concept of efficiency is one for the manager, and another for the developer.
For a manager, effective development is predictable : when the release date of the feature or the deadline for completing the task is known, in order to conduct some kind of business event.
For the developer - this is work with technical debt . This is one of the pains, so how to work with those. Very little time is required for refactoring, for corrections and improvements.
The next performance criterion is the minimum number of bugs. One could write that the criterion is the complete absence of bugs, but we know that this does not happen. In addition, testers are offended, because they will not be needed.
Impressions for the future. I did not specifically write a “thought-out architecture”. It is evil to go deep and think over the architecture in advance, so the development should be a reserve for the future, but without fanaticism.
Any other criteria that each team has.
We started to build development processes in Banki.ru after the company began to develop and grow. There were new partners and projects, and 6-9 backend-developers were not enough. We came to the conclusion that it is necessary to build a development process and formalize it in order to work effectively.
Initially, we had 3 teams, each with 3 backend developers and a manager who was responsible for parts of the site. Backend-developers, besides their work, still designed and connected jQuery-plug-ins, because at that moment there were few people on the front end.
We took two front-end developers and two more testers to live without bugs and thought that this configuration would be enough.
In an ideal world, the development process should look like this.
We assumed that the world is not perfect, and QA will return tasks, since bugs are present in any development, and added two more arrows.
After updating the scheme, we decided that everything was cool and began to work on it - we planned the sprints, and the backend teams set the tasks themselves in the plan. Worked for 2 months and realized that something was wrong.
Our scheme has transformed. Tasks jump like a ball in ping-pong: from QA to the front and back of developers, and even reach managers.
The arrows take a lot of time - the process of delivering the task to the combat servers is too long. It did not suit us. We wanted to minimize the number of arrows, so that tasks were performed faster.
The first thing that came to mind was to ask a question about why we are returning tasks ? Why does the backend, frontend and QA understand the task differently? Why do views differ? We came to the conclusion that we found guilty in the project manager, that he did not fully describe the tasks, and told PM to describe the tasks more fully, in order for everyone to understand what was meant.
We had three backend teams planning. We attracted testers and front-end developers to planning , but for 3 teams there were only 2 front-end developers and 2 testers. Often it was impossible to call them, because someone had to work.
They divided the tasks separately into the frontend and backend , in order to give them to the development in parallel, test faster and not wait for the whole chain.
We thought what to do next. There are a lot of companies and practices on the market, and we began to study, look, dig and reached the feature-team.
This is when the team has all the complete set of people to complete a task:
There are also connections between them, tasks jump and play ping-pong, but connections are much shorter and less time consuming. The entire team participates in planning, it is interested in the result and creates a single picture: what to do and how to deliver the task to the combat mode in a short time.
At that moment we switched to Agile and Scrum: we invited coaches and coaches, held workshops at the company, and started the classic Scrum - two-week sprints, assessment, planning and grooming. Now the tasks go faster into combat mode, but a lot of problems have come out.
At that time, we had 6 problems.
There are problems, we will solve it.
Initially, each team consisted of a front-end developer, a tester, and three backend developers. We took additional front-end developers to the staff - we duplicated the roles .
Introduced weekly meetings on directions . Frontend developers gathered separately every week and discussed new technologies, problem solving and agreed on common practices and approaches. Testers also gathered, conferred, decided how to test, discussed autotests.
Front-end developers introduced a cross-team code-review , when one developer solves the problem in one team and submits it for review to other teams, and after at least two statements, the task goes into testing.
Added autotests. There was one tester in the team and it was impossible to duplicate it, since there were no tasks for such a number. We agreed to help the tester from the other team : he will look after the tasks of the neighboring team, and replace the employee who goes on vacation. This slightly increased the time, but the tasks were tested.
We parsed the task of planning. At the time of the sprints, everyone worked and coded, and in planning, almost for the first time, they opened tasks and figured out what to do, the testers refined the “definition of done” to understand how to test the task.
The process took a lot of time. We decided to sort out the tasks before planning : we invited the developers to see the task in their spare time, to ask questions so that they could come to the planning prepared.
We offered managers to describe the tasks in more detail , but not too much, so as not to dig into a ton of documentation.
We have deliberately allocated an extra hour for the grooming.and not in my spare time. They gathered together with the whole team, discussed the tasks and prepared for planning.
It is a pain. Maybe someone closes them, but at that moment they don’t.
We decided to reduce the sprint capacity from 10 working days to 8 . We thought we would plan for 8 days, and leave the testers for 2 days.
At the beginning of the sprint, while there is time, the tester compiled test cases. In theory, at the beginning of the sprint, while the developers are working, the tester has no tasks. We agreed that at this time the tester can complete all the tasks, create test cases, and when the task arrives for testing, he will run it through the prepared test cases and reduce the time for testing. Globally, this did not help, although the time was slightly reduced.
Reducing the sprint capacity and loading the tester did not help and we thought about how to solve the problem. At that moment we came across a book about the goal and several practices of Maxim Dorofeev . We realized that it’s impossible to shove the “unpicked” and began to plan a sprint from a bottleneck - from testing. On planning, the tester gave an estimate, the sprint capacity was calculated from him, and the task was scored in a sprint for a tester.
Great! We went to the managers to sell this idea:
- We decided to plan from testers. Sprints will close, it will be cool!
- Wait, what will free developers do at this moment? There will be fewer tasks, they will have free time!
- Do you want the sprints to close, so that the development is predictable or the main goal of people to take?
- No, still predictable development. Let's close the sprints.
After the dialogue, one team began to work in a new way. The scheme showed its vitality, we worked on it, closed the sprints and the developers had time.
Namely: to work with those. by duty . In the team there is always a common tech. debt to department. These tasks can be taken to work and tested. As a rule, those. debt is a systemic refactoring. For these tasks, regression testing should be carried out, and the tester should not always perform this command. The testing department singled out special testers who regressed, including the head of the testing department. Tasks for those. The debt was given to testing by other employees and our testers did not suffer.
Disassemble tasks from the backlog and clarify requirements. When the developer had no tasks, he looked backlog, specified the requirements. By the time of planning, the tasks are fully described, all questions are asked, and decisions are made. It remains to clarify the details and everything - the tester evaluates, and the task went.
Help other teams . At that moment, we still practiced helping other teams, in which they had crashed, someone was on vacation or fell ill, and the project was on fire. Separate private tasks can be taken and help other teams.
In addition, there are always holidays, training, participation in conferences, which also need time to prepare. When an employee during working hours is given the opportunity to study something, read Habr, watch a video on work - loyalty rises. We solved this problem, and everyone was comfortable.
We have grocery teams that are doing something new. They have two weeks of planning, sprints, long projects and they come to release in 1-2 months or more.
We have marketing teams that work more responsively: the task came - they did it, the task came - they did it. Let's say the sales department sold the landing page - you have to do it quickly. These teams initially also worked on Scrum and two-week sprints, but it turned out that at the end of the sprint the tasks were completely different than at the beginning. Dissatisfaction with the team, the constant break, sprints are not completed - the situation is unpleasant.
We decided to talk with PM and with the business:
- Guys, we have Agile, Scrum, sprints, processes - let's not throw in new tasks, but we will predictably develop.
- See, we sell a landing, it should be done in 3 days. We are paid a million for it. What are the processes? Money must also be earned!
Million convinced us. We began to think further.
We decided to reduce the sprints to a week - so we can respond faster. It also did not go, because at that moment it wasn’t possible to plan for this team at all.
Then they decided not to plan sprints, but to work on Kanban instead of Scrum : the task came, they took to work, they released. It worked. The team worked more productively because it initially understood that there was no planning, but only tasks to perform.
In order to improve the processes in the team and receive feedback, we began to conduct retrospectives every 2 weeks.: the team gathered, discussed what went well, what did not, what the pros and cons, and worked with it.
At that moment we began to grow, we had new teams: the team leader came, the developers were overgrown, and people have not gotten used to it. During this period, we don’t talk about planning - people see our code for the first time, and it may be bad, for example, we have a little bit of Bitrix. Something with this had to
be done. It was possible to take the same Kanban, so that the developers carried out the tasks as they could, but this is the product team, it must be taught. We decided - let them learn to plan and evaluate tasks, but reduced the sprint to 1 week .
We will increase the time to 2 weeks in 1-2 months, when the team finishes, enters the overall grocery work, adjusts the processes and the developers will be able to properly evaluate the tasks.
Inside the team, developers and testers communicate with each other and share experiences, but this experience is not updated because the team “is brewed in itself.” New experience nowhere to take.
We began to think about what to do about it and introduced weekly Timlide meetings. The purpose of the meetings is to transfer experience from one team to another through tmlidov.
The first meetings were as follows:
- Hello, my name is Eugene, we are now sawing the news.
- Cool!
The next meeting:
- Hello, my name is still Eugene, we continue to cut the news.
- Ok.
Nothing out of the ordinary happens.
Third meeting: Hello ... And all the same.
We realized that we need to change the format. We read books about meetings and
introduced a fixed agenda.
Advantages of such a decision
We liked the format of the meetings and we began to hold them regularly.
We introduced a cross-team code-review . This is a kind of exchange of experience that front-end developers have already practiced, and later the backend guys. It is not necessary to give all the code to the cross-command code-review, just enough important things, for example, shared libraries or common pieces of code. For code-review, we chose only interested teams, there was no mandatory approve.
There are situations when the neighboring team, which deals with banks, asks to finalize the functionality - add fields, and we deal with loans. You can ask another team, but they have their own plan and it is not clear when they will fulfill the request, but you can not wait. In this situation, we help the next team, but on the code-review we give another.
It so happens that the developers are asked to transfer to another direction or change the technology. For example, we have one employee engaged in credit cards for a year and asked to change the area, and another wants to change the technology from UI to Symfony. By agreement, we will organize the transition of developers between teams .
Some companies practice meetings on Fridays: people gather to share experiences, discuss something, tell. We also decided to organize Friday gatherings - we opened a page on the Wiki, where everyone who wants to speak writes the topic of his report.
Everything was cool. At the gathering, the teams told what they were doing, what was new. For example, with one of the teams we had a misunderstanding, no one knew what she was doing. At the Friday meeting, the team told about their work, showed the analyst and everyone understood the meaning of their work. Frontend developers told how the build takes place, discussed general technical topics, for example, how to use Debugger in PHPStorm, how it is deployed.
And then the development topics were over, we switched to psychological ones and the story began to fade. How to further stimulate the developers to tell something?
And here we remembered KPI ! Let's teach each developer how to speak and include in his KPI 2 reports for six months at Friday get-togethers. We thought the idea was cool and everyone would be speaking.
While we were solving problems with efficiency, the company developed and new projects appeared and we had to adapt. That's what we understand from this.
Each member of the team is an independent employee .
We teach people to complete the task completely. For example, when a person does not have enough requirements or access, we want him to find this data himself: go to admins, to PM, ask for a login or password.
- I do not have passwords for integration with partners. - OK, write a letter or say PM.
PM said and again sits a day or two.
- Vasya, what happened? - I wrote PM, but there is no password.
We came to the conclusion that a person should squeeze in order to obtain the necessary data as quickly as possible.
It is important to communicate within the team. Less formalities .
Since we all work in the same office, it is important to minimize the formalities within the team. There are tools like Jira or Slack, which help to communicate with remote workers via the Internet, and here people communicate with each other personally, solve and discuss problems immediately. We even left the weekly Scrum rallies, because they are not needed.
Timlid monitors the mood in the team and solves problems. For example, we have one developer worked for a year. We noticed that the team stopped communicating with him. A person is sitting, doing something, but nobody approaches him - this is already a signal - something is wrong. When people created an instant messaging chat team, the signal screamed like a fire alarm. The developer asks:
- What is happening?
- We are in the team chat!
- Add me there!
- And you do not have an iPhone, we are in iMessage!
After that, I went to the development director and said that I had to do something: the team was demotivated, the great specialist could not work.
We transferred it to another team, and everyone got better: they took a new developer, who joined the team, and the previous one found himself in a new team, worked for 2 years, and received good feedback from the team leader.
Timlid protects the team from "external factors" .
Timlide is a filter that decides what information to allow outside the team, and what not.
I will explain with an example. In the marketing department or in the manual, they always “better” know how much time it takes to develop - they were told by friends that they wrote down the features in a month, and our half-year work. The management does not explain that we have a lot of pitfalls that we solve, but we can not quickly. When this information reaches the team, some developers demotivate, go to themselves.
Be filters between the environment and the team. All information must be dispensed in order not to demotivate developers.
Gather a few people and say: "Now you are a team, we are waiting for the result from you," will not work. People need to organize, give them a sane goal, motivation and solve problems.
Just about this transcript of the report of Evgeny Fedoreyev on TeamLead Conf . In the report, Yevgeny described in stages the process of organizing an effective development team at Banki.ru: about hiring, communicating, sharing knowledge and developing developers and testers within the team and department.
About the speaker : Yevgeny Fedoreyev ( hardj ) has been working on web development for 15 years, 6 of them are in the position of team leader, and now he leads the development of new projects Banki.ru.
What is Banki.ru?
The context of the company to know what kind of experience will be discussed. Banki.ru is the largest independent financial portal of the Runet with a monthly audience of more than 8 million unique users.
The IT department employs 50-70 people divided into 7 development teams. All development is conducted in-house, there are no remote developers, so there is no need for relevant processes and metrics.
The main task of the development team
When preparing for the report, I asked people the question:
- What is the purpose of the development team?
- Develop.
- What does this mean? If a person is sitting, refactor, does not benefit, does not solve business problems - is this also development?
- ... It is necessary to develop effectively.
Development Efficiency
The concept of efficiency is one for the manager, and another for the developer.
For a manager, effective development is predictable : when the release date of the feature or the deadline for completing the task is known, in order to conduct some kind of business event.
For the developer - this is work with technical debt . This is one of the pains, so how to work with those. Very little time is required for refactoring, for corrections and improvements.
The next performance criterion is the minimum number of bugs. One could write that the criterion is the complete absence of bugs, but we know that this does not happen. In addition, testers are offended, because they will not be needed.
Impressions for the future. I did not specifically write a “thought-out architecture”. It is evil to go deep and think over the architecture in advance, so the development should be a reserve for the future, but without fanaticism.
Any other criteria that each team has.
Development process
We started to build development processes in Banki.ru after the company began to develop and grow. There were new partners and projects, and 6-9 backend-developers were not enough. We came to the conclusion that it is necessary to build a development process and formalize it in order to work effectively.
Initially, we had 3 teams, each with 3 backend developers and a manager who was responsible for parts of the site. Backend-developers, besides their work, still designed and connected jQuery-plug-ins, because at that moment there were few people on the front end.
We took two front-end developers and two more testers to live without bugs and thought that this configuration would be enough.
In an ideal world, the development process should look like this.
- The project manager dumps the task into the backend command and they perform it.
- If revision is needed, send the task to the front-end team.
- After completion, the frontend gives it to QA.
- No bugs? - In production.
We assumed that the world is not perfect, and QA will return tasks, since bugs are present in any development, and added two more arrows.
After updating the scheme, we decided that everything was cool and began to work on it - we planned the sprints, and the backend teams set the tasks themselves in the plan. Worked for 2 months and realized that something was wrong.
Our scheme has transformed. Tasks jump like a ball in ping-pong: from QA to the front and back of developers, and even reach managers.
The arrows take a lot of time - the process of delivering the task to the combat servers is too long. It did not suit us. We wanted to minimize the number of arrows, so that tasks were performed faster.
How to shorten the delivery time?
The first thing that came to mind was to ask a question about why we are returning tasks ? Why does the backend, frontend and QA understand the task differently? Why do views differ? We came to the conclusion that we found guilty in the project manager, that he did not fully describe the tasks, and told PM to describe the tasks more fully, in order for everyone to understand what was meant.
We had three backend teams planning. We attracted testers and front-end developers to planning , but for 3 teams there were only 2 front-end developers and 2 testers. Often it was impossible to call them, because someone had to work.
They divided the tasks separately into the frontend and backend , in order to give them to the development in parallel, test faster and not wait for the whole chain.
We tried all the solutions. As a result, the time was reduced, but still did not suit us.
We thought what to do next. There are a lot of companies and practices on the market, and we began to study, look, dig and reached the feature-team.
Feature-team
This is when the team has all the complete set of people to complete a task:
- backend developers.
- front-end developers.
- QA-developers.
There are also connections between them, tasks jump and play ping-pong, but connections are much shorter and less time consuming. The entire team participates in planning, it is interested in the result and creates a single picture: what to do and how to deliver the task to the combat mode in a short time.
At that moment we switched to Agile and Scrum: we invited coaches and coaches, held workshops at the company, and started the classic Scrum - two-week sprints, assessment, planning and grooming. Now the tasks go faster into combat mode, but a lot of problems have come out.
Feature-team issues
At that time, we had 6 problems.
- Bus-factor .
- Long planning . For planning, we allocated half a day or more: we took care of the tasks, went to lunch, then again took them apart. When the planning was over, no one could work and did not want to - the day was lost.
- Unclosed sprints . This is a serious pain - most of the tasks in the sprints did not reach the “Completed” column.
- Different nature of tasks for teams .
- The emergence of new teams .
- Exchange of experience among teams .
There are problems, we will solve it.
Bus factor
Initially, each team consisted of a front-end developer, a tester, and three backend developers. We took additional front-end developers to the staff - we duplicated the roles .
Introduced weekly meetings on directions . Frontend developers gathered separately every week and discussed new technologies, problem solving and agreed on common practices and approaches. Testers also gathered, conferred, decided how to test, discussed autotests.
Front-end developers introduced a cross-team code-review , when one developer solves the problem in one team and submits it for review to other teams, and after at least two statements, the task goes into testing.
Added autotests. There was one tester in the team and it was impossible to duplicate it, since there were no tasks for such a number. We agreed to help the tester from the other team : he will look after the tasks of the neighboring team, and replace the employee who goes on vacation. This slightly increased the time, but the tasks were tested.
Long planning
We parsed the task of planning. At the time of the sprints, everyone worked and coded, and in planning, almost for the first time, they opened tasks and figured out what to do, the testers refined the “definition of done” to understand how to test the task.
The process took a lot of time. We decided to sort out the tasks before planning : we invited the developers to see the task in their spare time, to ask questions so that they could come to the planning prepared.
We offered managers to describe the tasks in more detail , but not too much, so as not to dig into a ton of documentation.
We have deliberately allocated an extra hour for the grooming.and not in my spare time. They gathered together with the whole team, discussed the tasks and prepared for planning.
Unclosed sprints
It is a pain. Maybe someone closes them, but at that moment they don’t.
We decided to reduce the sprint capacity from 10 working days to 8 . We thought we would plan for 8 days, and leave the testers for 2 days.
In reality, it turned out that when a developer sees fewer tasks, then he performs them slowly. 20% fewer tasks in the sprint did not give anything.
At the beginning of the sprint, while there is time, the tester compiled test cases. In theory, at the beginning of the sprint, while the developers are working, the tester has no tasks. We agreed that at this time the tester can complete all the tasks, create test cases, and when the task arrives for testing, he will run it through the prepared test cases and reduce the time for testing. Globally, this did not help, although the time was slightly reduced.
Reducing the sprint capacity and loading the tester did not help and we thought about how to solve the problem. At that moment we came across a book about the goal and several practices of Maxim Dorofeev . We realized that it’s impossible to shove the “unpicked” and began to plan a sprint from a bottleneck - from testing. On planning, the tester gave an estimate, the sprint capacity was calculated from him, and the task was scored in a sprint for a tester.
Great! We went to the managers to sell this idea:
- We decided to plan from testers. Sprints will close, it will be cool!
- Wait, what will free developers do at this moment? There will be fewer tasks, they will have free time!
- Do you want the sprints to close, so that the development is predictable or the main goal of people to take?
- No, still predictable development. Let's close the sprints.
After the dialogue, one team began to work in a new way. The scheme showed its vitality, we worked on it, closed the sprints and the developers had time.
It turned out that developers can do a lot of things when they are free.
Namely: to work with those. by duty . In the team there is always a common tech. debt to department. These tasks can be taken to work and tested. As a rule, those. debt is a systemic refactoring. For these tasks, regression testing should be carried out, and the tester should not always perform this command. The testing department singled out special testers who regressed, including the head of the testing department. Tasks for those. The debt was given to testing by other employees and our testers did not suffer.
Disassemble tasks from the backlog and clarify requirements. When the developer had no tasks, he looked backlog, specified the requirements. By the time of planning, the tasks are fully described, all questions are asked, and decisions are made. It remains to clarify the details and everything - the tester evaluates, and the task went.
Help other teams . At that moment, we still practiced helping other teams, in which they had crashed, someone was on vacation or fell ill, and the project was on fire. Separate private tasks can be taken and help other teams.
In addition, there are always holidays, training, participation in conferences, which also need time to prepare. When an employee during working hours is given the opportunity to study something, read Habr, watch a video on work - loyalty rises. We solved this problem, and everyone was comfortable.
Different nature of tasks for teams
We have grocery teams that are doing something new. They have two weeks of planning, sprints, long projects and they come to release in 1-2 months or more.
We have marketing teams that work more responsively: the task came - they did it, the task came - they did it. Let's say the sales department sold the landing page - you have to do it quickly. These teams initially also worked on Scrum and two-week sprints, but it turned out that at the end of the sprint the tasks were completely different than at the beginning. Dissatisfaction with the team, the constant break, sprints are not completed - the situation is unpleasant.
We decided to talk with PM and with the business:
- Guys, we have Agile, Scrum, sprints, processes - let's not throw in new tasks, but we will predictably develop.
- See, we sell a landing, it should be done in 3 days. We are paid a million for it. What are the processes? Money must also be earned!
Million convinced us. We began to think further.
We decided to reduce the sprints to a week - so we can respond faster. It also did not go, because at that moment it wasn’t possible to plan for this team at all.
Then they decided not to plan sprints, but to work on Kanban instead of Scrum : the task came, they took to work, they released. It worked. The team worked more productively because it initially understood that there was no planning, but only tasks to perform.
In order to improve the processes in the team and receive feedback, we began to conduct retrospectives every 2 weeks.: the team gathered, discussed what went well, what did not, what the pros and cons, and worked with it.
The emergence of new teams
At that moment we began to grow, we had new teams: the team leader came, the developers were overgrown, and people have not gotten used to it. During this period, we don’t talk about planning - people see our code for the first time, and it may be bad, for example, we have a little bit of Bitrix. Something with this had to
be done. It was possible to take the same Kanban, so that the developers carried out the tasks as they could, but this is the product team, it must be taught. We decided - let them learn to plan and evaluate tasks, but reduced the sprint to 1 week .
We will increase the time to 2 weeks in 1-2 months, when the team finishes, enters the overall grocery work, adjusts the processes and the developers will be able to properly evaluate the tasks.
Exchange of experience between teams
Inside the team, developers and testers communicate with each other and share experiences, but this experience is not updated because the team “is brewed in itself.” New experience nowhere to take.
We began to think about what to do about it and introduced weekly Timlide meetings. The purpose of the meetings is to transfer experience from one team to another through tmlidov.
The first meetings were as follows:
- Hello, my name is Eugene, we are now sawing the news.
- Cool!
The next meeting:
- Hello, my name is still Eugene, we continue to cut the news.
- Ok.
Nothing out of the ordinary happens.
Third meeting: Hello ... And all the same.
We realized that we need to change the format. We read books about meetings and
introduced a fixed agenda.
Now we have a wiki page with dates for holding Timlide meetings, where we throw in problems and tasks for discussion during the week.
Advantages of such a decision
- The team leaders are preparing for the meeting because they know the agenda and they understand what will be discussed.
- A wiki page is available to all developers. Each employee can learn the topic of discussion, participate in the process and raise their questions. After the meeting, we fix the decision in the comments, which are also available.
- If some task did not dare after 1-2 months, then you can look in the meeting archive, than the discussion of the problem was decided and kick the team or team lead for non-fulfillment.
We liked the format of the meetings and we began to hold them regularly.
We introduced a cross-team code-review . This is a kind of exchange of experience that front-end developers have already practiced, and later the backend guys. It is not necessary to give all the code to the cross-command code-review, just enough important things, for example, shared libraries or common pieces of code. For code-review, we chose only interested teams, there was no mandatory approve.
There are situations when the neighboring team, which deals with banks, asks to finalize the functionality - add fields, and we deal with loans. You can ask another team, but they have their own plan and it is not clear when they will fulfill the request, but you can not wait. In this situation, we help the next team, but on the code-review we give another.
It so happens that the developers are asked to transfer to another direction or change the technology. For example, we have one employee engaged in credit cards for a year and asked to change the area, and another wants to change the technology from UI to Symfony. By agreement, we will organize the transition of developers between teams .
Some companies practice meetings on Fridays: people gather to share experiences, discuss something, tell. We also decided to organize Friday gatherings - we opened a page on the Wiki, where everyone who wants to speak writes the topic of his report.
Everything was cool. At the gathering, the teams told what they were doing, what was new. For example, with one of the teams we had a misunderstanding, no one knew what she was doing. At the Friday meeting, the team told about their work, showed the analyst and everyone understood the meaning of their work. Frontend developers told how the build takes place, discussed general technical topics, for example, how to use Debugger in PHPStorm, how it is deployed.
And then the development topics were over, we switched to psychological ones and the story began to fade. How to further stimulate the developers to tell something?
And here we remembered KPI ! Let's teach each developer how to speak and include in his KPI 2 reports for six months at Friday get-togethers. We thought the idea was cool and everyone would be speaking.
It turned out that after the introduction of KPI, the developers stopped making reports. Negative appearances appeared for the obligatory performances Programmers decided to sacrifice 100% of KPI implementation, just not to make voluntary-compulsory reports.
findings
While we were solving problems with efficiency, the company developed and new projects appeared and we had to adapt. That's what we understand from this.
- Adjust to the changes and do not dwell on what is accepted, look at the changes and choose the best practices for working with the team. If developers can't work on Scrum — work on Kanban so everyone is happy and happy.
- Constantly monitor and change processes . As team leaders, you must control the processes in the team. The director is no longer up to this, but the developers have not yet come to this. See what happens, improve. Except for you, no one will do it and then you will build a team, which effectively performs its functions.
Principles of an effective team
Each member of the team is an independent employee .
We teach people to complete the task completely. For example, when a person does not have enough requirements or access, we want him to find this data himself: go to admins, to PM, ask for a login or password.
The task must be done by one person - if you took it upon yourself, you must complete it.There have been cases when a developer says:
- I do not have passwords for integration with partners. - OK, write a letter or say PM.
PM said and again sits a day or two.
- Vasya, what happened? - I wrote PM, but there is no password.
We came to the conclusion that a person should squeeze in order to obtain the necessary data as quickly as possible.
It is important to communicate within the team. Less formalities .
Since we all work in the same office, it is important to minimize the formalities within the team. There are tools like Jira or Slack, which help to communicate with remote workers via the Internet, and here people communicate with each other personally, solve and discuss problems immediately. We even left the weekly Scrum rallies, because they are not needed.
Когда у нас появляется проблема, мы ее сразу обсуждаем и решаем.Timlid supports unity in the team .
Timlid monitors the mood in the team and solves problems. For example, we have one developer worked for a year. We noticed that the team stopped communicating with him. A person is sitting, doing something, but nobody approaches him - this is already a signal - something is wrong. When people created an instant messaging chat team, the signal screamed like a fire alarm. The developer asks:
- What is happening?
- We are in the team chat!
- Add me there!
- And you do not have an iPhone, we are in iMessage!
After that, I went to the development director and said that I had to do something: the team was demotivated, the great specialist could not work.
We transferred it to another team, and everyone got better: they took a new developer, who joined the team, and the previous one found himself in a new team, worked for 2 years, and received good feedback from the team leader.
Timlid protects the team from "external factors" .
Timlide is a filter that decides what information to allow outside the team, and what not.
I will explain with an example. In the marketing department or in the manual, they always “better” know how much time it takes to develop - they were told by friends that they wrote down the features in a month, and our half-year work. The management does not explain that we have a lot of pitfalls that we solve, but we can not quickly. When this information reaches the team, some developers demotivate, go to themselves.
Be filters between the environment and the team. All information must be dispensed in order not to demotivate developers.
The collection of the program TeamLead Conf , which will be held on February 25 and 26 in Moscow, in the hottest stage. I'll tell you about the results here, when everything will be tied to the schedule, and regular submissions will come in the mailing list .