What problems Temlida can solve with the game
Hello! My name is Rtishchev Evgeny, in Sbertech I work as an IT systems development manager on projects of the Unified Frontal System. On September 24, I spoke at the Saint Teamlead Conf 2018 conference in St. Petersburg. My report was about a game played in a team that greatly eased my headache as a manager, helped with motivation and discipline. The audience warmly accepted the topic and asked many interesting and valuable questions.
It seemed to me that some points in the report were missed. Therefore, in the article I decided to once again tell about my experiment and share the results. Who was not at the conference and wants to read a story about an alternative tool for rapid Performance Review, managing the team through the game, increasing involvement in product development, and how to combine the concepts of "gamification" and bureaucracy in large companies - welcome .
Then there will be a consistent storytelling about my development as a team leader, conscious problems and mistakes made. I will not hide - the decision will be to introduce a special team game, so if you don’t have the desire and interest to spend 10-15 minutes of your precious time, you can jump over to the “Now all maynat MotC” section and read directly about the essence of the game, miscalculations in the balance and adjustment , and what came of it.
')
When I came to Sbertech, a new internal program was launched, and it was necessary to quickly assemble a mobile development team. A month after my release, my manager (who took me to work) quit, and all his tasks and problems became mine. Frankly, before that I had little experience in managing a team of two people for a year. Rather, it was similar to technical mentoring and mentoring novice developers. The team quickly grew to 11 people, I completely walked away from writing code, working through architecture and other hard tasks. I became subject to emotions and my management principles corresponded to situational management, and I had to look more long-term, develop people in a team, raise new leaders, celebrate and encourage those who are good at drawing, and identify and punish bad guys and lazy people.
I saw a way out in introducing elements of regular management. Those. needed a system with transparent rules of rewards and punishments. At the same time, I really did not want to reduce everything to
banal methods, the reaction to which is always the opposite.
At first I decided to make a list of conditional problems or, more precisely, those things that I would
wanted to improve in the team. For example, I wanted the guys not to be late for the stand-up, prepare for it, listen carefully to each other and help with problem solving. Many do not like stand-ups or daily, because consider it a waste of working time.
The first step was to change the language in which we spoke at the agile-ceremony - we began to hold the stand-in in English. The decision was set to “hurray”: many prepared the text in advance, the duration was reduced (English was laconic and everyone wanted to focus only on the essence).
And then I realized that I need to experiment.
The tendency towards systems thinking prompted me that in order to do something, it was necessary to first formulate the problems or, more precisely, the things that I would like to improve. Then I
outlined the main directions.
In our company there is a line of grades - these are certain levels that have their formal duties, privileges and salary forks. The real alignment of forces often differs from the formal one for obvious reasons: the number of vacancies and their grades is limited, all the guys came to the team at different times and under different conditions, someone showed strong growth in a short time, etc. The enhancement procedure is difficult, rather rare and you need to be well prepared for it, i.e. objectively nominate those people who deserve it. In the first such procedure, I was greatly mistaken: since it was hard for me to remember all the merits or failures of individual guys, I proceeded from my subjective opinion, perhaps in places because of my own predisposition. And this is wrong.
Errors in such situations are very difficult to fix. And I was wrong for the first time (a minute of confession). But negative experience is a good teacher. I realized that we need a clear tool - one simple indicator to see all the achievements and failures of a person, in which areas he grows. Information should always be available and relevant, and there is nothing to worry about being public - then all team members will have fewer questions with the following changes.
When I came, the company worked on a waterfall model - in fact, the bank was the customer, and the team from Sberbank Technologies was an internal contractor. A year later, the company switched to big Agile - the teams became decentralized, focused on developing their own products (which could be submodules of one big
systems). On the shoulders of the owner of the product of such a team, in addition to line management and the service architect (in the case of a technical product), a new function has also been laid - product management, formation of his vision, strategic map of development, specification and prioritization of tasks, as well as responsibility for implementation dates.
And as the owner of the product, I really wanted the team members not only to complete the tasks, but also help the product grow, bring new ideas, take away some of my duties and headaches. For example, it took a lot of time to gather the requirements, their development and decomposition into specific logical and consistent tasks. Another problem was product support and communication with users. Our product is an internal library for developing mobile iOS applications (there is already a whole series of articles on Habr about this). And our customers are other application teams. At some point, the number of our users has reached about 120 developers, designers and managers. And I didn’t even have 12 hours a day to communicate with everyone. I really wanted the team to actively help in this.
For a long time, our Story Point (SP) indicators jumped heavily from sprint to sprint. Each time a similar situation occurred either due to the arriving defects from PROM, or
some unplanned super-important tasks directly from the management. The guys regularly complained and were themselves unhappy, because they could not understand where the time had gone, whether the newly received task was more important than the sprint task, what value it would bring to the product. Added complexity and a common approach to assess defects at 0 SP - I always added to the sprint
a certain number of defects so that they can be exchanged with critical ones that flew right during the sprint.
In two years of working on one product and in the same team, people start to get tired, their eyes lose insane shine and productivity drops.
The solution that had to be invented should have rekindled the light and a little
cheer up the team.
I would like to tell a little more about the team: product owner, analyst (he is a scrum master) and 9 iOS developers. Do you understand now why so wanted to understand the balance of power in such a homogeneous team?
Some social data: we had two girls, and the age of the participants was in
range from 22 to 33. The areas of interest were different, but we tried to arrange
common team activities: regular board games, mini-corporate parties,
joint visits to conferences, etc.
I have always had a huge interest in the game industry. As a child, I lined up whole worlds of Lego cubes, painted simple board games on a piece of paper, took 3D Max to a bit older, then began to learn simple tools for creating computer games - like Dark Basic or Game Factory. I spent a lot of time in MMO, and from the strangest - I made my own version of the game Diablo 2 in the map editor for Warcraft 3 (she even enjoyed success in the city’s local area network).
As you understood, once again I wanted to create a game world and immerse
team members in real-time challenge
Games, by themselves, contain a very useful basis, namely: competitiveness, points and ratings, rules and violations, single and team achievements. Games infect with excitement (which in our case looks like involvement), and also teach the bitterness of defeat and the joys of victory.
It remains for the small - choose the setting, come up with the mechanics and rules, align the balance, as well as work on conditional virality.
The lion's share of my report on Saint Teamlead Conf was devoted to the creation of the game and the implementation of all the necessary points (gameplay, balance problems, the psychology of 4 types of players, etc.). I will not broadcast all the information in the text - I hope that interested readers will wait six months, when olegbunin will make the recordings public (or write to me in private). And you can also come to listen to the tmlid conference on 2 November .
In short, you can get virtual coins for performing certain actions:
1. Closing sprint tasks. This is important and should be encouraged, because this is what business value brings. 1 Story Point brought 1.2 MotC. Why not equal value? It's simple: firstly, the magic number already says that there is a certain coefficient, and having indicated its presence, you can always change it carefully (to adjust the balance). Plus MotC are integers, i.e. it is also an additional incentive to close a larger number of sidepoints. For 3 you get 3 Motc, and for 5 already 6.
2. Correction of defects. If there is no estimate in SP, then let it be in MotC. Different levels of criticality had a different weight in terms of MotC. But again, to encourage the correction of defects (which not all developers will like), one closed bug always brings a fractional number of coins, which could be rounded down, if one does not close another defect.
3. Correcting off-sprint tasks. In addition to the defects, there were other urgent tasks: the build server broke down, the UI tests fell, the urgent and important task flew from the manual, and much more. Now, for them, the person received MotC and thus compensated for the SP in the sprint.
4. Ratings and titles. Already 4 categories were invented: SP champion, contribution maximizer (maximum MotC), sprint hero and team award. The principle of the first two, I think, should be clear from the title, with the rest - more interesting. The sprint hero was chosen by team vote on retro, and this was one of the most honorable awards in the team, both in terms of the number of MotCs and in terms of prestige and importance. Having a team award is key because it shows that not only the personal result is important, but also the overall result of the whole team. Three gradations were invented: a regular sprint, a top sprint and a failed sprint. A sprint was considered normal, if more than 78% of the sprint backlog was closed, if it was 100%, then this is the top sprint. In the case of the top sprint, the whole team received a generous increase. But there was also a reverse side of the coin - this is a disastrous sprint.
MotC matter. Therefore, it was possible to obtain and coins with a negative value. What anti-merits led to this:
Yes Yes. The meaning of the coins is not only in personal ratings, but also in the fact that they could be spent. For this, the activation function was invented. Only positive coins could be activated. There was a whole store in which there were goods and their cost. To control their number was limited.
What was in the store?
There were other positions, but here the most important rule is to guarantee the possibility of their purchase, otherwise there will be an undermining of trust.
During the experiment, at certain moments, problems of primary balance became noticeable.
Which ones?
1. Role models of players. In addition to the developers, there was one analyst in the team, and his possibilities for obtaining MotC were severely limited, since the lion's share of tasks for the storpoints was sharpened for development. Also, the functions of the analyst included part of the administrative tasks that were expensive to constantly monitor. The decision was to introduce the concept of “privileged mining”, i.e. A certain number of MotCs were automatically credited for fulfilling every sprint duties. It is interesting that in the future another imbalance was found: in the absence of an analyst (for example, vacation), someone took over his tasks and, thus, took part of the mining for the privileged mining.
2. The depreciation of tasks. Over time, certain repeatable tasks become easier to perform. For example, we had a procedure for releasing a new version of the framework (our product) - which took about 1.5-2 hours of pure time. With the development of DevOps, its time cost was reduced to 30 minutes. Correspondingly, the remuneration in MotC also fell. Or from time to time there were puzzles on the preparation of new report forms or statuses. It is difficult to do this for the first time, but it is easier to re-perform it - therefore the score in the coins decreased. The team perceived such adjustments adequately.
3. Double points for defects. An example to show that in each team there will be unforeseen situations, and the rules should be “tune”. We sat for a long time on automatic cascade merge (i.e., when the hotfix was infused, automatic merge occurred in the above release-version and develop). At some point we decided to stop this vicious practice because of the constantly hanging merge-conflicts on develop-e and moved on to the idea of ​​duplicating tasks across all versions where you need to spill the changes. This led to the emergence of multiple tasks of the same type in JIRA:
As a result, formally, according to the rules, a player could quickly take and complete 2-3 tasks and get 2-3x coins. It was necessary to make adjustments for such tasks, because their complexity was reduced (but certainly not to zero due to potential conflicts due to changes in individual branches).
4. The idea to promote for working with users. I really wanted to “force” the guys to help our consumers (and this is about 100 application developers, full of stupid and repetitive questions). We tried different approaches: assign attendants, maintain a detailed knowledge base, grow a community of knowledgeable users, and encourage them. But there was a simple solution: I quickly looked through the support chat on Slack once a day and gave the most active consultants from the team a small but pleasant reward in the form of MotC. The guys appreciated
In general, the game is a living process that should change along the way. The main thing is to initially insure and leave yourself the opportunity for organic maneuvers. Changing the mechanics of the game can cause resentment among players. Initially, I was afraid that I would not be able to correctly calculate the balance between the mining and the cost of the “prizes” - therefore I immediately indicated that their number in the store is limited and will be replenished as far as. Plus, as you understand, the supply market is controlled by a monopoly, which can always declare a deficit or inflation!
The whole experiment lasted 9 sprints (4 months). In total, 968 MotC was mined, and 262 was spent. There were 3 top sprints, the same person became a sprint hero 4 times, the distribution of MotC on the team looked like this:
Here it is - the only indicator that I wanted to create.
By the way, the entire database was stored in Numbers (xls for MacOS) and sent to the participants once a week (at the time of the MotC issue on retro). There were 5 pages with end-to-end formulas: the history of mining, the history of purchases, the store of offers, the detailing of the mining and the pivot table.
I was asked a question at the conference - did it take a lot of time to manage it?
The answer is no. On the contrary, I began to spend less time on setting up tasks in JIRA for
every little thing and to synchronize with a notebook, in which I regularly recorded
all delegated tasks. The table called "Detailing" was just
A new kind of notebook in which I could write instructions, and when they were executed
record the reward. Below is an example for one sprint per player:
When the experiment ended, I asked around the guys - everyone was happy with the innovations and confirmed that it was fresh and exciting.
The result is a win-win situation. It became easier for me to manage the development, the guys had new opportunities and a spirit of challenging. Some guys have found for themselves new ways of development and ways to benefit the product. In this case, the whole team tried to get a top result by the end of the sprint.
I'm not trying to prove that this is the right kind of management or an ideal tool - this is just an example of how to diversify your management style and, in a good sense, to “cheer up” a team. Do not be afraid to experiment, and most importantly, always strive to optimize your processes, create new rules and techniques. I would love to listen to your examples or approaches to the Performance Review and team motivation.
Thanks for reading!
PS You can add me as a friend on Facebook or LinkedIn , and also come to listen to a speech on this topic at the next Timlide conference on November 2.
It seemed to me that some points in the report were missed. Therefore, in the article I decided to once again tell about my experiment and share the results. Who was not at the conference and wants to read a story about an alternative tool for rapid Performance Review, managing the team through the game, increasing involvement in product development, and how to combine the concepts of "gamification" and bureaucracy in large companies - welcome .
Intro
Then there will be a consistent storytelling about my development as a team leader, conscious problems and mistakes made. I will not hide - the decision will be to introduce a special team game, so if you don’t have the desire and interest to spend 10-15 minutes of your precious time, you can jump over to the “Now all maynat MotC” section and read directly about the essence of the game, miscalculations in the balance and adjustment , and what came of it.
')
Problems and pain
When I came to Sbertech, a new internal program was launched, and it was necessary to quickly assemble a mobile development team. A month after my release, my manager (who took me to work) quit, and all his tasks and problems became mine. Frankly, before that I had little experience in managing a team of two people for a year. Rather, it was similar to technical mentoring and mentoring novice developers. The team quickly grew to 11 people, I completely walked away from writing code, working through architecture and other hard tasks. I became subject to emotions and my management principles corresponded to situational management, and I had to look more long-term, develop people in a team, raise new leaders, celebrate and encourage those who are good at drawing, and identify and punish bad guys and lazy people.
I saw a way out in introducing elements of regular management. Those. needed a system with transparent rules of rewards and punishments. At the same time, I really did not want to reduce everything to
banal methods, the reaction to which is always the opposite.
At first I decided to make a list of conditional problems or, more precisely, those things that I would
wanted to improve in the team. For example, I wanted the guys not to be late for the stand-up, prepare for it, listen carefully to each other and help with problem solving. Many do not like stand-ups or daily, because consider it a waste of working time.
The first step was to change the language in which we spoke at the agile-ceremony - we began to hold the stand-in in English. The decision was set to “hurray”: many prepared the text in advance, the duration was reduced (English was laconic and everyone wanted to focus only on the essence).
And then I realized that I need to experiment.
Formulate problem areas
The tendency towards systems thinking prompted me that in order to do something, it was necessary to first formulate the problems or, more precisely, the things that I would like to improve. Then I
outlined the main directions.
Ranking team members
In our company there is a line of grades - these are certain levels that have their formal duties, privileges and salary forks. The real alignment of forces often differs from the formal one for obvious reasons: the number of vacancies and their grades is limited, all the guys came to the team at different times and under different conditions, someone showed strong growth in a short time, etc. The enhancement procedure is difficult, rather rare and you need to be well prepared for it, i.e. objectively nominate those people who deserve it. In the first such procedure, I was greatly mistaken: since it was hard for me to remember all the merits or failures of individual guys, I proceeded from my subjective opinion, perhaps in places because of my own predisposition. And this is wrong.
Errors in such situations are very difficult to fix. And I was wrong for the first time (a minute of confession). But negative experience is a good teacher. I realized that we need a clear tool - one simple indicator to see all the achievements and failures of a person, in which areas he grows. Information should always be available and relevant, and there is nothing to worry about being public - then all team members will have fewer questions with the following changes.
Incentives for product development assistance
When I came, the company worked on a waterfall model - in fact, the bank was the customer, and the team from Sberbank Technologies was an internal contractor. A year later, the company switched to big Agile - the teams became decentralized, focused on developing their own products (which could be submodules of one big
systems). On the shoulders of the owner of the product of such a team, in addition to line management and the service architect (in the case of a technical product), a new function has also been laid - product management, formation of his vision, strategic map of development, specification and prioritization of tasks, as well as responsibility for implementation dates.
And as the owner of the product, I really wanted the team members not only to complete the tasks, but also help the product grow, bring new ideas, take away some of my duties and headaches. For example, it took a lot of time to gather the requirements, their development and decomposition into specific logical and consistent tasks. Another problem was product support and communication with users. Our product is an internal library for developing mobile iOS applications (there is already a whole series of articles on Habr about this). And our customers are other application teams. At some point, the number of our users has reached about 120 developers, designers and managers. And I didn’t even have 12 hours a day to communicate with everyone. I really wanted the team to actively help in this.
Planning accuracy and time-killer determination
For a long time, our Story Point (SP) indicators jumped heavily from sprint to sprint. Each time a similar situation occurred either due to the arriving defects from PROM, or
some unplanned super-important tasks directly from the management. The guys regularly complained and were themselves unhappy, because they could not understand where the time had gone, whether the newly received task was more important than the sprint task, what value it would bring to the product. Added complexity and a common approach to assess defects at 0 SP - I always added to the sprint
a certain number of defects so that they can be exchanged with critical ones that flew right during the sprint.
Something fresh and new
In two years of working on one product and in the same team, people start to get tired, their eyes lose insane shine and productivity drops.
The solution that had to be invented should have rekindled the light and a little
cheer up the team.
Little team
I would like to tell a little more about the team: product owner, analyst (he is a scrum master) and 9 iOS developers. Do you understand now why so wanted to understand the balance of power in such a homogeneous team?
Some social data: we had two girls, and the age of the participants was in
range from 22 to 33. The areas of interest were different, but we tried to arrange
common team activities: regular board games, mini-corporate parties,
joint visits to conferences, etc.
Now, all minat MotC
I have always had a huge interest in the game industry. As a child, I lined up whole worlds of Lego cubes, painted simple board games on a piece of paper, took 3D Max to a bit older, then began to learn simple tools for creating computer games - like Dark Basic or Game Factory. I spent a lot of time in MMO, and from the strangest - I made my own version of the game Diablo 2 in the map editor for Warcraft 3 (she even enjoyed success in the city’s local area network).
As you understood, once again I wanted to create a game world and immerse
team members in real-time challenge
Games, by themselves, contain a very useful basis, namely: competitiveness, points and ratings, rules and violations, single and team achievements. Games infect with excitement (which in our case looks like involvement), and also teach the bitterness of defeat and the joys of victory.
It remains for the small - choose the setting, come up with the mechanics and rules, align the balance, as well as work on conditional virality.
For novice game designers
For all novice game designers (who I am), I recommend the book Game Design: the Book of Lenses - it made a huge impression on me and helped me figure out how to create games.
The lion's share of my report on Saint Teamlead Conf was devoted to the creation of the game and the implementation of all the necessary points (gameplay, balance problems, the psychology of 4 types of players, etc.). I will not broadcast all the information in the text - I hope that interested readers will wait six months, when olegbunin will make the recordings public (or write to me in private). And you can also come to listen to the tmlid conference on 2 November .
How to get MotC?
In short, you can get virtual coins for performing certain actions:
1. Closing sprint tasks. This is important and should be encouraged, because this is what business value brings. 1 Story Point brought 1.2 MotC. Why not equal value? It's simple: firstly, the magic number already says that there is a certain coefficient, and having indicated its presence, you can always change it carefully (to adjust the balance). Plus MotC are integers, i.e. it is also an additional incentive to close a larger number of sidepoints. For 3 you get 3 Motc, and for 5 already 6.
2. Correction of defects. If there is no estimate in SP, then let it be in MotC. Different levels of criticality had a different weight in terms of MotC. But again, to encourage the correction of defects (which not all developers will like), one closed bug always brings a fractional number of coins, which could be rounded down, if one does not close another defect.
3. Correcting off-sprint tasks. In addition to the defects, there were other urgent tasks: the build server broke down, the UI tests fell, the urgent and important task flew from the manual, and much more. Now, for them, the person received MotC and thus compensated for the SP in the sprint.
4. Ratings and titles. Already 4 categories were invented: SP champion, contribution maximizer (maximum MotC), sprint hero and team award. The principle of the first two, I think, should be clear from the title, with the rest - more interesting. The sprint hero was chosen by team vote on retro, and this was one of the most honorable awards in the team, both in terms of the number of MotCs and in terms of prestige and importance. Having a team award is key because it shows that not only the personal result is important, but also the overall result of the whole team. Three gradations were invented: a regular sprint, a top sprint and a failed sprint. A sprint was considered normal, if more than 78% of the sprint backlog was closed, if it was 100%, then this is the top sprint. In the case of the top sprint, the whole team received a generous increase. But there was also a reverse side of the coin - this is a disastrous sprint.
Mining negative MotC
MotC matter. Therefore, it was possible to obtain and coins with a negative value. What anti-merits led to this:
- A failed sprint. In the case of performing less than 78% backlog of the sprint, the whole team received negative mining.
- Opening a defect. If there was an unambiguous defect on the poured task, then the negative MotC was earned by the developer who injected the Pull Request, as well as his revisers.
- 3. A cumulative system was additionally invented for being late to a stand-up or not paying attention to colleagues. She acted on the principle of "3 in a row." 3 identical badges collapsed into a new one, at which negative mining took place. There was an amnesty rule: when receiving more than 25 MotC in the sprint, collapse did not lead to negative mining, but the reset of the icons did not occur.
How to spend MotC?
Yes Yes. The meaning of the coins is not only in personal ratings, but also in the fact that they could be spent. For this, the activation function was invented. Only positive coins could be activated. There was a whole store in which there were goods and their cost. To control their number was limited.
What was in the store?
- Opportunity to leave work early or come back later. Most important hodovichok.
- Day of remote work.
- The ability to prioritize the selection of tasks in planning.
- LinkedIn recommendation.
- The choice of the module for development on Swift. All the code was on Objective-C, and the guys would really like to develop in Swift.
- Conference tickets (if available).
There were other positions, but here the most important rule is to guarantee the possibility of their purchase, otherwise there will be an undermining of trust.
Adjustments during the game
During the experiment, at certain moments, problems of primary balance became noticeable.
Which ones?
1. Role models of players. In addition to the developers, there was one analyst in the team, and his possibilities for obtaining MotC were severely limited, since the lion's share of tasks for the storpoints was sharpened for development. Also, the functions of the analyst included part of the administrative tasks that were expensive to constantly monitor. The decision was to introduce the concept of “privileged mining”, i.e. A certain number of MotCs were automatically credited for fulfilling every sprint duties. It is interesting that in the future another imbalance was found: in the absence of an analyst (for example, vacation), someone took over his tasks and, thus, took part of the mining for the privileged mining.
2. The depreciation of tasks. Over time, certain repeatable tasks become easier to perform. For example, we had a procedure for releasing a new version of the framework (our product) - which took about 1.5-2 hours of pure time. With the development of DevOps, its time cost was reduced to 30 minutes. Correspondingly, the remuneration in MotC also fell. Or from time to time there were puzzles on the preparation of new report forms or statuses. It is difficult to do this for the first time, but it is easier to re-perform it - therefore the score in the coins decreased. The team perceived such adjustments adequately.
3. Double points for defects. An example to show that in each team there will be unforeseen situations, and the rules should be “tune”. We sat for a long time on automatic cascade merge (i.e., when the hotfix was infused, automatic merge occurred in the above release-version and develop). At some point we decided to stop this vicious practice because of the constantly hanging merge-conflicts on develop-e and moved on to the idea of ​​duplicating tasks across all versions where you need to spill the changes. This led to the emergence of multiple tasks of the same type in JIRA:
As a result, formally, according to the rules, a player could quickly take and complete 2-3 tasks and get 2-3x coins. It was necessary to make adjustments for such tasks, because their complexity was reduced (but certainly not to zero due to potential conflicts due to changes in individual branches).
4. The idea to promote for working with users. I really wanted to “force” the guys to help our consumers (and this is about 100 application developers, full of stupid and repetitive questions). We tried different approaches: assign attendants, maintain a detailed knowledge base, grow a community of knowledgeable users, and encourage them. But there was a simple solution: I quickly looked through the support chat on Slack once a day and gave the most active consultants from the team a small but pleasant reward in the form of MotC. The guys appreciated
In general, the game is a living process that should change along the way. The main thing is to initially insure and leave yourself the opportunity for organic maneuvers. Changing the mechanics of the game can cause resentment among players. Initially, I was afraid that I would not be able to correctly calculate the balance between the mining and the cost of the “prizes” - therefore I immediately indicated that their number in the store is limited and will be replenished as far as. Plus, as you understand, the supply market is controlled by a monopoly, which can always declare a deficit or inflation!
Results and observations
The whole experiment lasted 9 sprints (4 months). In total, 968 MotC was mined, and 262 was spent. There were 3 top sprints, the same person became a sprint hero 4 times, the distribution of MotC on the team looked like this:
| MotC
| MotC +
| |
| Player 1
| 104
| 86
|
| Player 2
| 203
| 203
|
| Player 3
| 148
| 128
|
| Player 4
| 65
| 47
|
| Player 5
| 172
| 92
|
| Player 6
| 58
| 40
|
| Player 7
| 68
| 68
|
| Player 8
| 95
| 77
|
| Player 9
| 55
| 55
|
Here it is - the only indicator that I wanted to create.
By the way, the entire database was stored in Numbers (xls for MacOS) and sent to the participants once a week (at the time of the MotC issue on retro). There were 5 pages with end-to-end formulas: the history of mining, the history of purchases, the store of offers, the detailing of the mining and the pivot table.
I was asked a question at the conference - did it take a lot of time to manage it?
The answer is no. On the contrary, I began to spend less time on setting up tasks in JIRA for
every little thing and to synchronize with a notebook, in which I regularly recorded
all delegated tasks. The table called "Detailing" was just
A new kind of notebook in which I could write instructions, and when they were executed
record the reward. Below is an example for one sprint per player:
| MotC
| Mining
|
| one
| Proposition X
|
| one
| Help Mac to update the library icon for the demo
|
| 2
| Preparing the repository with the boilerplate for the IC (demo for
leadership) |
| 2
| Preparing an XSD scheme for an example IC, as well as
boilerplate advice |
| 3
| Defect Closure
|
| sixteen
| Conversion 14 SP
|
| four
| SP Maximizer
|
When the experiment ended, I asked around the guys - everyone was happy with the innovations and confirmed that it was fresh and exciting.
The result is a win-win situation. It became easier for me to manage the development, the guys had new opportunities and a spirit of challenging. Some guys have found for themselves new ways of development and ways to benefit the product. In this case, the whole team tried to get a top result by the end of the sprint.
I'm not trying to prove that this is the right kind of management or an ideal tool - this is just an example of how to diversify your management style and, in a good sense, to “cheer up” a team. Do not be afraid to experiment, and most importantly, always strive to optimize your processes, create new rules and techniques. I would love to listen to your examples or approaches to the Performance Review and team motivation.
Thanks for reading!
PS You can add me as a friend on Facebook or LinkedIn , and also come to listen to a speech on this topic at the next Timlide conference on November 2.
Source: https://habr.com/ru/post/427473/
All Articles