How to tmlidu survive in a scalable scram and keep control over the quality of the code
The technical director of ivi, Evgeny Rossinsky ( eross ), is well known to the participants of our conferences on reports on the technical side of streaming. But today you have before you the decoding of Eugene's report on TeamLead Conf on how Agile-transformation is reflected on team leaders.
Not so long ago, ivi underwent an agile transformation and got a good profit from it in terms of:
')
But the consequences of this creative decision pretty seriously hit the team leaders. The report is about how to deal with it, and what tools to use.
Before transformation
In order to understand what I'm going to talk about, you need to get a little familiar with our product. Then we analyze why we have such a format of teams and why we chose this path.
Development in ivi comes under five major platforms :
And, of course, the backend, without which nowhere. Before we decided to carry out the transformation, our teams were formed according to the competencies.
Guys who know, for example, Swift or Objective C:
It seems to be all right, but there is one problem - the platforms are very different in terms of product and user consumption of content.
This means that each team began to appear its own backlog and its priorities. For example, users of web applications do not like to pay, and content consumption is carried out through an advertising model. The features that are needed for this platform naturally appear in the backlog. Smart TVs are characterized by the fact that they buy well, and the features of the paid model appear.
It turns out the following situation: someone came up with a brilliant idea how to improve the product; wrote a lot of tickets that go to the product managers, each responsible for their platform. Managers pass ideas through the lens of their perception, perhaps they are modernizing something and inserting it into their work plan. The problem here is that one feature can be released on all platforms for more than a year, because “I believe that it is not a priority for my platform”. And in a year, half a year or just a few months, anything can happen to a product - for example, a redesign or a concept change will happen, and this feature should already be rolled out, and it is completely different from all other platforms.
As a result, after some time it turned out that on different platforms we have completely different products with different communication messages and business logic. The user in such a situation begins to get confused, because he does not have a single space in which he feels confident. In addition, it is very difficult to build hypotheses , since it is not always clear on which platform which functionality is better shot. It all depends on the size of the screen, on how people consume content. And it looked like this:
The ingenious productist brings the idea, and the developers on different platforms perceive it rather unfriendly, with the exception of the backend, which in general does not matter what to write.
So, since the company had enough competences regarding what flexible methodologies are, we agreed with the business that we need to remove the barrier between:
interact productively and do one thing in common.
After transformation
This resulted in an architecture with dedicated Value Stream , in which each team deals with a specific business area.
To form a new structure we:
True, before this, we made one such team, by the example of which we held demonstration performances , gashted one feature on all platforms with an excellent time-to-market.
In addition, the feature was chosen very well and was successful on all platforms. Thus, we had an example that showed that everything can be done faster and better . This allowed the entire development team of 130–140 people to understand that it is possible to work differently.
When we determined the value stream, the question arose of what to do with timlidah. Previously, they were the basis for everything in their direction, and now appear value stream and greater influence of business. What have we done? We in each value stream gathered people of different competencies, at least one:
It turned out like an independent team, but it is independent in words and on beautiful slides of Agile-coaches. In fact, everybody forgets about the fact that there is something in common between people who can write in the same programming language - this is their program code, through which they must somehow communicate. For some reason, many are silent about this, but this is really quite a big problem that needs to be remembered.
Suppose you are seating people on different floors or rooms, but the code they write is the same. There is a release cycle and features that should not interfere with each other. There are many problems.
Concepts
We adopted several basic concepts:
We have the value stream commands and platform commands . In value stream, the guys implement a specific feature, and in the platforms there is a team leader, a competence center. Inside the platforms, they can also develop some features, but this is more an architectural look at software development.
We introduced the concept of " Guild ". Placing the same iOS developers in different rooms, we needed to give them a formal sign, and even an informal one, that they remained the same iOS developers, not just participants in the value stream of an ad product, for example. And then with this guild you need to do something and somehow teach people to communicate inside.
The next question was what to do with release cycles . On those platforms where you can roll out as soon as the feature is ready, there are no questions. And in the case of iOS or Android, when due to the specifics of obtaining approve from Apple, it is impossible to send an application to release twice a day, you have to accumulate some packs.
We decided that every platform that cannot be released immediately will be released once every two weeks . We have created a special calendar available to everyone, where the team publishes the date feature freeze and the release date. If, being in the value stream, you want your task to be available to the real user, you should be in time before the feature freeze. I managed - well, I didn't manage - you are waiting for the next train.
Timlid in the new scheme
What has become of our tmlidy? They went according to the classical pattern of awareness of problems that cannot be solved.
At first we ran into denial . Because the team leader for several years gathered a cool team, cultivated each employee, lured someone from competitors. And these specialists are now distributed to jobs that do not always meet their expectations.
Of course, after denial was anger .
There were many scandals, after which bargaining began. Everyone came up with the question: “Let everyone have it your way, and I’ll have it as before, but I will take a marker, write Agile, I will wear a T-shirt with this inscription, but everything will be the same.” Did not work out.
But in the end something happened that I was very much waiting for - people understood why we are doing this. I hope they understood, though maybe they lied. The very first successful case showed a real striking difference between what it was before and how it can be done differently. The halved time-to-market allowed us to define a benchmark for everyone. The next step has taken place, which in the classical model of psychology is called the “ Stockholm syndrome ”. People who adopted the new rules learned to exist in them and began to slowly promote this "religion." I can not say for all tmlidov, but about 30% of them are now active "preachers" of this direction.
Problems and difficulties
Now I will try to more structurally list the difficulties we faced:
Due to the fact that employees were seated in different rooms, verbal communication was lost. For a month it became very difficult , because earlier there was an opportunity to quickly ask a neighbor, for example, what should be inherited from, and immediately get an answer. And now you are sitting in a separate room, around you are people whose technologies you may not like and have no one to consult with. To ask someone a question, you need to write in the chat, and the person who can answer, left - everything, you are left to yourself.
We immediately started having problems with the Code Review , which I consider to be not problems, but a great discovery. We found out that a large number of employees are not independent . Suppose there was an employee who, according to statistics, reviewed the tasks at most the second time, usually the first time everything was fine. And when he left to work on value stream, for some reason, it became 5-6 iterations.
They began to understand, and it turned out that the authoritative opinion of the symbolic figure of the team leader, who controls, centralizes all the information flows in relation to himself, does not have a very good influence on the development of developers. People are lazy , ask for help on all issues and get competent answers. And therefore review passes quickly and cool. Being alone with themselves, many developers had to grow quite significantly above themselves in order to make the same architectural decisions . No one likes to hear five times in a row that your code is not very good. It is frustrating, it makes you consider yourself an insufficiently qualified employee, and can even lead to depression or the belief that maybe the work is bad. But the point is that you need to look at yourself, understand that in the previous mode of operation you did not think about these things, but now you are developing and have to start thinking about them .
On the other hand, we had some very interesting things that, in my opinion, are redundant with respect to the Code Review. In one of the teams there was a rule: in order for the task to pass the review, all team members must accept its decision. When they were all sitting together, they were more or less able to do it, but now they all sat down - some had a daily stand-up meeting at one time, others had some other business - and the review of tasks became a narrow bottleneck. Over and over again, they learned in retrospect that some tasks hung on a review for two weeks and were forced to change something.
Then began: separatism, discrimination and envy .
Previously, a man thought he knew what he wanted to do. And with the division into value stream and platform, a suspicion began to arise that “the neighbor has a better taste”: the tasks are more interesting and the growth is faster. The second problem is that when everyone becomes feature-centered , the quality of the code gets very bad . There are people around you who want to quickly get a result, and it’s not their task to think that it will have to be somehow maintained, modernized, and colleagues shouldn’t break anything from a new feature.
There were situations in which the high speed of development had its opposite side - poor - quality code , which began to multiply in inhuman quantities. When the responsible team leader takes up the correction of these errors and refactoring, it turns out that his life turns into sweeping the garbage for careless employees. The developers quickly succeed, everyone is happy, and they do not notice the titanic work of the Timlid, thanks to which everything actually works. After about two months, each team leader expressed dissatisfaction with the situation.
To solve these problems, we had several meetings with the Timlides first, and then with all the guilds in order to explain to people that it is possible to work differently. If you want to try something else, then with this you need to come to the team lead, and you can easily swap places. The main thing is to agree among themselves.
This is on the one hand. On the other hand, so that there is justice regarding who is engaged in refactoring, and who makes new features, the Timlids started working with backlogs, I will return to this a bit later.
And then the difficulties began with Release Management . The value stream has its own testers, the platforms have their own testers, something is automated, something is not automated, you need to think about how to do a general regression. And then there are deadlines. We voluntarily decided to be released once every two weeks, and what if the partner comes asking him to do everything by tomorrow (and a bag of money, for example), tell him to wait for the next cycle? Still, you need to look for a compromise . And then a beautiful scheme with releases can change a lot.
A good example is the law FZ-54, according to which all purchases on the Internet must be accompanied by sending electronic checks to users and to tax. One may speak at conferences and talk about flexible methodologies and the fact that there are regulations and so on, but as soon as there is a risk of receiving a fine on 70% of your revenue, you switch to a completely different regime and do so that your company is not fined. Such cases are infrequent, but there are. In particular, we had to make a second level of communication in case of changes in the scheme. It is not easy, but possible.
The next problem we faced as a result of the transformation is related to new employees . In my opinion, beginners should be immersed in an environment as close as possible to the one in which it will work. And there, at the expense of the environment, he will quickly obtain the necessary knowledge. And we took the specialists who made up this environment to different floors and rooms. A newcomer’s life in a company becomes a rather serious managerial task, the solution of which must be thought out.
Instruments
Here are the tools we use.
I will begin the story with a route map for a new employee. Unfortunately, this is something that we have not yet learned how to fully automate and, in fact, think over for each employee individually, depending on what he will do.
There was a rather interesting example: we needed to grow a universal tester who would be able to test absolutely all products for an advertising stream. They have a lot in common, but has its own specifics. It's not a secret that a tester who is famously able to test a web application will get lost the first time when working with the toolkit, say, for iOS. For this tester, our director of quality control has built a special route map. According to this map, a new employee in each competency gained knowledge for two weeks, participated in regressions and so on. With developers, the implementation situation is about the same. Thus, even at the interview we find out what the candidate is for and what is interesting to him, and we are trying to choose in which direction to send him.
Of course, at first, a new employee pumps competencies, that is, in our terms, is on the platform team, and then can migrate to the value stream we need. By the way, route maps are good, but their adaptability does not need to be excluded either.
Then we introduced Guild Sync - synchronization of guild actions .
Why do you need it? Everyone listened to Scrum lectures, which talked about the need for a daily stand-up meeting, which allowed them to find out what was going on around them. But our specialist, for example, on the one hand, is a developer for Android, and on the other hand is a member of the product team. If he has to walk and communicate twice a day, he will have some kind of Cargo-cult. At this rate, you can spend a lifetime on the meeting. Definitely, this will annoy people.
If we say that we are based on the feature-centric model, then the daily stand-up meeting is more important in its value stream. But at the same time you can break away from what is happening in the guild. To do this, some guilds hold meetings once a week, some - twice a week. And then timlid methodically thinks about what to talk about. This should not be translated into an empty conversation, it is the development strategy of the technology team, which is the guild. Guild Sync meetings are needed so that everyone understands what technologies the company will use, what strategic decisions are made regarding this platform. There is a partial review of architectural solutions.
In some teams we have more than one Timlid. In general, the definition of team leads is very ambiguous. There are opinion leaders who can be timblists and carry on themselves the solution of some organizational issues. There can be several opinion leaders with management skills in a team. And then they can organize themselves, who is responsible for what. For example, one of the opinion leaders could go to value stream. In this case, you need to synchronize your architectural solutions, which will later determine the development strategy of the entire technological platform.
Then we began to conduct internal and external meetings in certain directions. In general, this is a fairly standard partly HR case, partly a team building case. For internal meetings, sometimes a vote is taken on which topic is the most interesting, speakers are searched either within the company, or we invite someone from the outside, we rent a special room and discuss various important points. On average, we have two internal mitaps per month, but sometimes four. People from other competencies can come to these meetings to listen to how their neighbors live and see if they want to change their specialization. This also happens.
Now the labor market in matters of developers is not very simple. And to retrain a good, intelligent guy from one programming language to another is sometimes much cheaper than taking such a specialist from the market. Therefore, if a person is bored, we welcome the practice of transferring him to another direction , which is interesting to him. And internal mitaps are very helpful to understand what this direction is.
I'll tell you about another interesting point. I collected a small statistic, on the basis of which it turned out that during the Agile-transformation, smoking people were more knowledgeable, and Guild Sync and other meetings are practically not needed by smokers and drinkers.
People working together do not often discuss general everyday topics, somehow it all comes down to work. The teams in which many smoke, Guild Sync is needed less often, because they already discuss everything on a smoke break.
Of course, there are non-smoking tmlids, then they, for example, practice joint dinners , where everyone gathers together at one big table. True, in a team of more than 10 people, this is no longer the case.
The next tool for creating a comfortable environment is rotation . Initially, the biggest problem in all transformations is that people are afraid to ask whether it is possible in a different way. For some reason, it is believed that if the management said to do so, then it is necessary to do so. And only the most courageous and brave go and change something, while the rest think about changing the workplace, believing that they are not valued here. Although they did not even say that they do not like something. Therefore, we held a series of meetings and small trainings on the topic that the company doesn’t matter who exactly works in this or that place; it is important for her to work there and there.
And then we began to apply various motivational methods to attract performers to unpopular tasks. There are tasks that are very difficult to automate. Nobody likes to do them, but they need to be done, because this is, say, reconciliation of data with one of our partners. This partner constantly sends data, a lot of data that we need to process, in a different format. It turns out that once a month you have to greatly upset someone from the developers, because you need not just to run the script, but to understand what is wrong there, fix the script, run it again, etc. Automation such a process gives in badly. In this case, small bonuses , such a kind of “harm” help out great. And there are more people willing to do an unpopular task, and the price of the issue is low.
Guild Chat has become much in demand after people are seated. Some teams have agreed to record the results of some agreements in general chat rooms, so as not to overload tickets, regulations, and so on.
The most interesting thing is that our team leaders learned how to communicate productively with the product owners in the value stream. They began methodically explaining to them that if they made 10 features, and in a certain piece of code, something would need to be changed, then it would take half a year, because initially there would be a number of features. A positive factor is that the product owners took such treatment normally. And in the backlogs, tasks began to appear to refactor and fix their own crutches. And the Timlides breathed out quite seriously, as they realized that their teams remained their teams. They were convinced that they were managing this process in the same way (not in terms of management, but, rather, in terms of communicating to everyone how to do it right).
Teamlead - glue
The main conclusion that we have learned for ourselves is that in a good way the failure or success of any brilliant transformation depends on the people who believe in it .
If you venture something like that, then the focus of your impact should be primarily on the tmlid . Because it is very easy to come up with a beautiful picture from which to speak at the conference, and it’s not easy for people to run away and understand that this is a working scheme.
For example, I realized for myself that after transformation, many Timlides got rid of a large number of “internal running”. Previously, for all, even insignificant and unrelated to management or code, the Timlid was to blame, now with a similar scaling scheme for a number of issues it simply does not come to him. Timlid no longer needs to answer silly questions, because they are asked to the one who developed this feature, to the one who is responsible for the desired value stream. The team leader has fewer incoming distractions, and that's great. The Timlides became calmer , their eyes stopped twitching, and on the whole their self-confidence became higher.
Not so long ago, ivi underwent an agile transformation and got a good profit from it in terms of:
')
- business,
- development speed
- time to market;
- other interesting metrics.
But the consequences of this creative decision pretty seriously hit the team leaders. The report is about how to deal with it, and what tools to use.
Before transformation
In order to understand what I'm going to talk about, you need to get a little familiar with our product. Then we analyze why we have such a format of teams and why we chose this path.
Development in ivi comes under five major platforms :
- iOS,
- Android,
- Web,
- Smart TV,
- Windows + Xbox.
And, of course, the backend, without which nowhere. Before we decided to carry out the transformation, our teams were formed according to the competencies.
Guys who know, for example, Swift or Objective C:
- sit in the same room;
- get tasks from product managers;
- working on them and producing a result.
It seems to be all right, but there is one problem - the platforms are very different in terms of product and user consumption of content.
This means that each team began to appear its own backlog and its priorities. For example, users of web applications do not like to pay, and content consumption is carried out through an advertising model. The features that are needed for this platform naturally appear in the backlog. Smart TVs are characterized by the fact that they buy well, and the features of the paid model appear.
It turns out the following situation: someone came up with a brilliant idea how to improve the product; wrote a lot of tickets that go to the product managers, each responsible for their platform. Managers pass ideas through the lens of their perception, perhaps they are modernizing something and inserting it into their work plan. The problem here is that one feature can be released on all platforms for more than a year, because “I believe that it is not a priority for my platform”. And in a year, half a year or just a few months, anything can happen to a product - for example, a redesign or a concept change will happen, and this feature should already be rolled out, and it is completely different from all other platforms.
As a result, after some time it turned out that on different platforms we have completely different products with different communication messages and business logic. The user in such a situation begins to get confused, because he does not have a single space in which he feels confident. In addition, it is very difficult to build hypotheses , since it is not always clear on which platform which functionality is better shot. It all depends on the size of the screen, on how people consume content. And it looked like this:
The ingenious productist brings the idea, and the developers on different platforms perceive it rather unfriendly, with the exception of the backend, which in general does not matter what to write.
So, since the company had enough competences regarding what flexible methodologies are, we agreed with the business that we need to remove the barrier between:
- product,
- business
- technologies
interact productively and do one thing in common.
After transformation
This resulted in an architecture with dedicated Value Stream , in which each team deals with a specific business area.
To form a new structure we:
- conducted several trainings;
- we determined the main directions for our business;
- in the voluntary-forced broke people on the value stream;
- have begun to implement.
True, before this, we made one such team, by the example of which we held demonstration performances , gashted one feature on all platforms with an excellent time-to-market.
In addition, the feature was chosen very well and was successful on all platforms. Thus, we had an example that showed that everything can be done faster and better . This allowed the entire development team of 130–140 people to understand that it is possible to work differently.
When we determined the value stream, the question arose of what to do with timlidah. Previously, they were the basis for everything in their direction, and now appear value stream and greater influence of business. What have we done? We in each value stream gathered people of different competencies, at least one:
- iOS developer,
- Android developer,
- Javascript developer
- Smart TV Specialist,
- coder,
- to the tester.
It turned out like an independent team, but it is independent in words and on beautiful slides of Agile-coaches. In fact, everybody forgets about the fact that there is something in common between people who can write in the same programming language - this is their program code, through which they must somehow communicate. For some reason, many are silent about this, but this is really quite a big problem that needs to be remembered.
Suppose you are seating people on different floors or rooms, but the code they write is the same. There is a release cycle and features that should not interfere with each other. There are many problems.
Concepts
We adopted several basic concepts:
We have the value stream commands and platform commands . In value stream, the guys implement a specific feature, and in the platforms there is a team leader, a competence center. Inside the platforms, they can also develop some features, but this is more an architectural look at software development.
We introduced the concept of " Guild ". Placing the same iOS developers in different rooms, we needed to give them a formal sign, and even an informal one, that they remained the same iOS developers, not just participants in the value stream of an ad product, for example. And then with this guild you need to do something and somehow teach people to communicate inside.
The next question was what to do with release cycles . On those platforms where you can roll out as soon as the feature is ready, there are no questions. And in the case of iOS or Android, when due to the specifics of obtaining approve from Apple, it is impossible to send an application to release twice a day, you have to accumulate some packs.
We decided that every platform that cannot be released immediately will be released once every two weeks . We have created a special calendar available to everyone, where the team publishes the date feature freeze and the release date. If, being in the value stream, you want your task to be available to the real user, you should be in time before the feature freeze. I managed - well, I didn't manage - you are waiting for the next train.
Timlid in the new scheme
What has become of our tmlidy? They went according to the classical pattern of awareness of problems that cannot be solved.
At first we ran into denial . Because the team leader for several years gathered a cool team, cultivated each employee, lured someone from competitors. And these specialists are now distributed to jobs that do not always meet their expectations.
Of course, after denial was anger .
There were many scandals, after which bargaining began. Everyone came up with the question: “Let everyone have it your way, and I’ll have it as before, but I will take a marker, write Agile, I will wear a T-shirt with this inscription, but everything will be the same.” Did not work out.
But in the end something happened that I was very much waiting for - people understood why we are doing this. I hope they understood, though maybe they lied. The very first successful case showed a real striking difference between what it was before and how it can be done differently. The halved time-to-market allowed us to define a benchmark for everyone. The next step has taken place, which in the classical model of psychology is called the “ Stockholm syndrome ”. People who adopted the new rules learned to exist in them and began to slowly promote this "religion." I can not say for all tmlidov, but about 30% of them are now active "preachers" of this direction.
Problems and difficulties
Now I will try to more structurally list the difficulties we faced:
Due to the fact that employees were seated in different rooms, verbal communication was lost. For a month it became very difficult , because earlier there was an opportunity to quickly ask a neighbor, for example, what should be inherited from, and immediately get an answer. And now you are sitting in a separate room, around you are people whose technologies you may not like and have no one to consult with. To ask someone a question, you need to write in the chat, and the person who can answer, left - everything, you are left to yourself.
We immediately started having problems with the Code Review , which I consider to be not problems, but a great discovery. We found out that a large number of employees are not independent . Suppose there was an employee who, according to statistics, reviewed the tasks at most the second time, usually the first time everything was fine. And when he left to work on value stream, for some reason, it became 5-6 iterations.
They began to understand, and it turned out that the authoritative opinion of the symbolic figure of the team leader, who controls, centralizes all the information flows in relation to himself, does not have a very good influence on the development of developers. People are lazy , ask for help on all issues and get competent answers. And therefore review passes quickly and cool. Being alone with themselves, many developers had to grow quite significantly above themselves in order to make the same architectural decisions . No one likes to hear five times in a row that your code is not very good. It is frustrating, it makes you consider yourself an insufficiently qualified employee, and can even lead to depression or the belief that maybe the work is bad. But the point is that you need to look at yourself, understand that in the previous mode of operation you did not think about these things, but now you are developing and have to start thinking about them .
On the other hand, we had some very interesting things that, in my opinion, are redundant with respect to the Code Review. In one of the teams there was a rule: in order for the task to pass the review, all team members must accept its decision. When they were all sitting together, they were more or less able to do it, but now they all sat down - some had a daily stand-up meeting at one time, others had some other business - and the review of tasks became a narrow bottleneck. Over and over again, they learned in retrospect that some tasks hung on a review for two weeks and were forced to change something.
Then began: separatism, discrimination and envy .
Previously, a man thought he knew what he wanted to do. And with the division into value stream and platform, a suspicion began to arise that “the neighbor has a better taste”: the tasks are more interesting and the growth is faster. The second problem is that when everyone becomes feature-centered , the quality of the code gets very bad . There are people around you who want to quickly get a result, and it’s not their task to think that it will have to be somehow maintained, modernized, and colleagues shouldn’t break anything from a new feature.
There were situations in which the high speed of development had its opposite side - poor - quality code , which began to multiply in inhuman quantities. When the responsible team leader takes up the correction of these errors and refactoring, it turns out that his life turns into sweeping the garbage for careless employees. The developers quickly succeed, everyone is happy, and they do not notice the titanic work of the Timlid, thanks to which everything actually works. After about two months, each team leader expressed dissatisfaction with the situation.
To solve these problems, we had several meetings with the Timlides first, and then with all the guilds in order to explain to people that it is possible to work differently. If you want to try something else, then with this you need to come to the team lead, and you can easily swap places. The main thing is to agree among themselves.
The power of flexible methodologies is that it does not matter to everyone how everything happens, the main thing is that people agree and be happy.
This is on the one hand. On the other hand, so that there is justice regarding who is engaged in refactoring, and who makes new features, the Timlids started working with backlogs, I will return to this a bit later.
And then the difficulties began with Release Management . The value stream has its own testers, the platforms have their own testers, something is automated, something is not automated, you need to think about how to do a general regression. And then there are deadlines. We voluntarily decided to be released once every two weeks, and what if the partner comes asking him to do everything by tomorrow (and a bag of money, for example), tell him to wait for the next cycle? Still, you need to look for a compromise . And then a beautiful scheme with releases can change a lot.
A good example is the law FZ-54, according to which all purchases on the Internet must be accompanied by sending electronic checks to users and to tax. One may speak at conferences and talk about flexible methodologies and the fact that there are regulations and so on, but as soon as there is a risk of receiving a fine on 70% of your revenue, you switch to a completely different regime and do so that your company is not fined. Such cases are infrequent, but there are. In particular, we had to make a second level of communication in case of changes in the scheme. It is not easy, but possible.
The next problem we faced as a result of the transformation is related to new employees . In my opinion, beginners should be immersed in an environment as close as possible to the one in which it will work. And there, at the expense of the environment, he will quickly obtain the necessary knowledge. And we took the specialists who made up this environment to different floors and rooms. A newcomer’s life in a company becomes a rather serious managerial task, the solution of which must be thought out.
Instruments
Here are the tools we use.
I will begin the story with a route map for a new employee. Unfortunately, this is something that we have not yet learned how to fully automate and, in fact, think over for each employee individually, depending on what he will do.
There was a rather interesting example: we needed to grow a universal tester who would be able to test absolutely all products for an advertising stream. They have a lot in common, but has its own specifics. It's not a secret that a tester who is famously able to test a web application will get lost the first time when working with the toolkit, say, for iOS. For this tester, our director of quality control has built a special route map. According to this map, a new employee in each competency gained knowledge for two weeks, participated in regressions and so on. With developers, the implementation situation is about the same. Thus, even at the interview we find out what the candidate is for and what is interesting to him, and we are trying to choose in which direction to send him.
Of course, at first, a new employee pumps competencies, that is, in our terms, is on the platform team, and then can migrate to the value stream we need. By the way, route maps are good, but their adaptability does not need to be excluded either.
Then we introduced Guild Sync - synchronization of guild actions .
Why do you need it? Everyone listened to Scrum lectures, which talked about the need for a daily stand-up meeting, which allowed them to find out what was going on around them. But our specialist, for example, on the one hand, is a developer for Android, and on the other hand is a member of the product team. If he has to walk and communicate twice a day, he will have some kind of Cargo-cult. At this rate, you can spend a lifetime on the meeting. Definitely, this will annoy people.
If we say that we are based on the feature-centric model, then the daily stand-up meeting is more important in its value stream. But at the same time you can break away from what is happening in the guild. To do this, some guilds hold meetings once a week, some - twice a week. And then timlid methodically thinks about what to talk about. This should not be translated into an empty conversation, it is the development strategy of the technology team, which is the guild. Guild Sync meetings are needed so that everyone understands what technologies the company will use, what strategic decisions are made regarding this platform. There is a partial review of architectural solutions.
In some teams we have more than one Timlid. In general, the definition of team leads is very ambiguous. There are opinion leaders who can be timblists and carry on themselves the solution of some organizational issues. There can be several opinion leaders with management skills in a team. And then they can organize themselves, who is responsible for what. For example, one of the opinion leaders could go to value stream. In this case, you need to synchronize your architectural solutions, which will later determine the development strategy of the entire technological platform.
Then we began to conduct internal and external meetings in certain directions. In general, this is a fairly standard partly HR case, partly a team building case. For internal meetings, sometimes a vote is taken on which topic is the most interesting, speakers are searched either within the company, or we invite someone from the outside, we rent a special room and discuss various important points. On average, we have two internal mitaps per month, but sometimes four. People from other competencies can come to these meetings to listen to how their neighbors live and see if they want to change their specialization. This also happens.
Now the labor market in matters of developers is not very simple. And to retrain a good, intelligent guy from one programming language to another is sometimes much cheaper than taking such a specialist from the market. Therefore, if a person is bored, we welcome the practice of transferring him to another direction , which is interesting to him. And internal mitaps are very helpful to understand what this direction is.
I'll tell you about another interesting point. I collected a small statistic, on the basis of which it turned out that during the Agile-transformation, smoking people were more knowledgeable, and Guild Sync and other meetings are practically not needed by smokers and drinkers.
People working together do not often discuss general everyday topics, somehow it all comes down to work. The teams in which many smoke, Guild Sync is needed less often, because they already discuss everything on a smoke break.
Of course, there are non-smoking tmlids, then they, for example, practice joint dinners , where everyone gathers together at one big table. True, in a team of more than 10 people, this is no longer the case.
The next tool for creating a comfortable environment is rotation . Initially, the biggest problem in all transformations is that people are afraid to ask whether it is possible in a different way. For some reason, it is believed that if the management said to do so, then it is necessary to do so. And only the most courageous and brave go and change something, while the rest think about changing the workplace, believing that they are not valued here. Although they did not even say that they do not like something. Therefore, we held a series of meetings and small trainings on the topic that the company doesn’t matter who exactly works in this or that place; it is important for her to work there and there.
And then we began to apply various motivational methods to attract performers to unpopular tasks. There are tasks that are very difficult to automate. Nobody likes to do them, but they need to be done, because this is, say, reconciliation of data with one of our partners. This partner constantly sends data, a lot of data that we need to process, in a different format. It turns out that once a month you have to greatly upset someone from the developers, because you need not just to run the script, but to understand what is wrong there, fix the script, run it again, etc. Automation such a process gives in badly. In this case, small bonuses , such a kind of “harm” help out great. And there are more people willing to do an unpopular task, and the price of the issue is low.
Guild Chat has become much in demand after people are seated. Some teams have agreed to record the results of some agreements in general chat rooms, so as not to overload tickets, regulations, and so on.
The most interesting thing is that our team leaders learned how to communicate productively with the product owners in the value stream. They began methodically explaining to them that if they made 10 features, and in a certain piece of code, something would need to be changed, then it would take half a year, because initially there would be a number of features. A positive factor is that the product owners took such treatment normally. And in the backlogs, tasks began to appear to refactor and fix their own crutches. And the Timlides breathed out quite seriously, as they realized that their teams remained their teams. They were convinced that they were managing this process in the same way (not in terms of management, but, rather, in terms of communicating to everyone how to do it right).
In my understanding, the task of a team leader is, first of all, the definition of a strategy for the development of your software product.
Teamlead - glue
The main conclusion that we have learned for ourselves is that in a good way the failure or success of any brilliant transformation depends on the people who believe in it .
If you venture something like that, then the focus of your impact should be primarily on the tmlid . Because it is very easy to come up with a beautiful picture from which to speak at the conference, and it’s not easy for people to run away and understand that this is a working scheme.
For example, I realized for myself that after transformation, many Timlides got rid of a large number of “internal running”. Previously, for all, even insignificant and unrelated to management or code, the Timlid was to blame, now with a similar scaling scheme for a number of issues it simply does not come to him. Timlid no longer needs to answer silly questions, because they are asked to the one who developed this feature, to the one who is responsible for the desired value stream. The team leader has fewer incoming distractions, and that's great. The Timlides became calmer , their eyes stopped twitching, and on the whole their self-confidence became higher.
The next meeting on the exchange of Timlid wisdom is scheduled for September 24 and 25. We will meet in Saint Petersburg at Saint TeamLead Conf to discuss all sorts of team management problems.
The program is already beginning to form, there are more than 40 applications in the list of submitted reports , and as long as it is possible to add a topic there - the Program Committee accepts applications until August 10 .
Source: https://habr.com/ru/post/417409/
All Articles