Starban. Flexible development methodology, gamification and many more buzz words
Since the post is not short and even inappropriate pictures do not make it easier to read, then let us first of all designate the target audience.
Well, there is a methodology that was invented by a team of programmers “for themselves,” but which, in our opinion, it would be interesting to try others. Inside the team, a small economic model of market relations is recreated, and priorities are regulated by the exchange rate of the command currency. .
IT world has invented many approaches to building a software development process, borrowing the best ideas from their pre-industrial colleagues. At a certain stage of our professional development, we faced problems of motivation, quality management and visualization of work for the team and the customer. Taking all the best from all the best that we have taken, we organized work on medium-sized projects in the form of a starban.
')
The long journey through the commercial software development universe has confronted us with many approaches to project management. We saw waterfalls, we worked on RUP , tried to apply basic concepts of MSF , but the warmest memories left flexible methodologies. In the framework of one project, which lasted 2 years, we switched from scrum to kanban, divided and merged teams, bent Goldratt and Toyota to fit our needs.
From the scram we took the methods of team communication and the assessment of tasks in dimensionless (conditional) units. The process iteration is just as important, but can be regulated. Also, the visualization of the current work (tactical planning) is perfectly detailed in the scram. Kanban is good at applying the theory of constraints, the flexibility of setting them up for changes within a team, and visualizing current work on a strategic map. It is difficult to completely separate these two methodologies, since they are rarely found in the canonical incarnation. Many programmers, for example, have difficulty evaluating tasks in a story point, so tables for converting man-hours to story points are often created, or the score is immediately put in hours. Instead, we decided to evaluate the tasks based on their current project value and called this quantity stars. So the name starban appeared.
OK, we have a project in which 5-15 people are involved, with the need to tighten strategic planning and several tired programmers who perceive any task as a routine. The rest perceive any task as a burden and set as a goal the formal closure of tasks with minimization of effort. The right, as they say, underline.
First of all, it should be noted that starban is not a complete software development methodology, but a set of extensions, allowing to increase productivity and not allow the project to plunge into a crisis. A tired developer can leave the project and take with him unique undocumented knowledge . The manager can merge to the offer better, and then understand the current status of the project can be quite problematic. The testing department will close the task and build acceptance testing in such a way as if all users of the product have completely read the instructions and vowed to never break the cat's grave. The development department swears at the testing department, shifting the responsibility to analysts and collecting large-scale meetings, where you can listen for 2 hours, make meeting hours for 1 hour and schedule the next meeting already with the stakeholder to retell it all again.
The stick and gingerbread are rarely balanced, since each team member needs an individual combination of these components. So, let us consider in order the complementary rules, the observance of which brought us peace of mind, and the project has an indelible benefit.
Even if there are only 4-5 developers in a team, there is a reason to divide them into 2 teams, since more than 3 people are unlikely to be able to simultaneously develop one feature (user story). Most of the features are occupied by 1-2 people, the third can at this time be engaged in preparing for the development of the next functional.
If we average, our experience, for some reason, always showed that the ideal teams always consisted of three people. Perhaps this is a subjective value, but our colleagues also often came to the same conclusion. Being a universal autonomous unit is difficult and bad due to the lack of external control over the decisions made, and a larger team can block itself. In addition, each team member should know what others are doing.
The board must perform the following functions:
The board is an important part in optimizing the process and should be as informative as possible.
The leftmost column is the project's Roadmap, sorted by task priority. It should also contain global technical tasks for the maintenance and modernization of the development infrastructure. It may also contain an urgent request for the correction of the functional, but it must follow the same rules as the other cards. For ourselves, we have adopted two rules - the cards in this column are separated by color and for each card its numerical priority is presented, which will help when sorting in the project management system. This column should be filled to the maximum extent possible so that all participants can see the expected result of development and take into account future needs when performing current tasks. The priority of the task can be changed by the stakeholder (the customer, his representative, the owner of the software being developed). When the priority changes, it can immediately estimate the losses - the release of which features will shift due to its changes.
The next column, product backlog, contains tasks for changing functionalities, bugs, and technical tasks that are formalized as user stories. Detailing here can be different, as well as types of tasks. For example, the merging of branches in the version control system may relate to a specific user story, but it can also be a separate card being evaluated, depending on the context. The priority in this column ceases to play a role, and the order of extracting tasks must be adjusted by the manager using the "star rating". We'll talk about the stars later, while it is worth knowing that it is more profitable for teams to take more star cards into their development. On this column, you can enter a limit on the number of cards simultaneously in it to avoid speculation. We tried the cat tray rule when the number of cards should be 1 more than the number of mini-teams involved in development (the number of trays, if you keep several cats at home, should also exceed their number by one).
With a lack of tasks in this column, a pre-planning should be carried out. Representatives of each team, a manager and, if necessary, a customer representative are involved in the pre-planning. Developers share estimates of the complexity of the task, the customer or manager assesses its relevance to the project. In this case, the final assessment in the stars puts the manager based on current priorities and the situation on the project. Tasks can also be added and evaluated by the manager individually, but it is worth doing this only with critical bugs. Do not forget about color coding in this column as well - this will give a quick glance at the board to see whether to wait for the release of new features, product stabilization in the near future, or the team is busy with the development infrastructure. OK, we will assume that all of them are able to decompose and evaluate tasks, and the colors chosen are suitable for color blind.
The following four columns are divided horizontally. Each team owns a piece of the board and keeps records on it. When a team has a need to take the next card from the product backlog for development, it carries out planning - it decomposes the task into tasks, finds out the implementation details, and estimates the implementation dates. The task is taken “to work” - and all the cards are placed here. The decomposition should be sufficiently detailed in order for the rule to be observed: one person for one task. Another good thing is the hierarchical numbering <feature number>. <Task number> or color division by features.
How to keep the team from capturing unnecessary tasks for which there are no free hands? Do I need to do this? Is there a limit on the number of cards? Rather, it should be regulated by the star-market method, which will be discussed later, but if problems arise, you can easily introduce Goldratt restrictions. For tasks in the "in work" column, you can use badges - these are additional noticeable markings for the cards from a distance. Stickers with bold characters - suitable. Examples: "!" - the task is in work longer than the initial assessment; "?" - on the task there is a question that requires holding a meeting with other teams. You should update this part of the board as often as possible and follow the badges on the tasks.
When the activity for the task is completed, it is moved to the "check" column. The testing team sees that all the monochrome feature tasks have passed to the test and begins testing. Bugs on the board can be displayed by stickers to cards or simply add an icon.
At the end of testing and the absence of bugs tasks are transferred to the column “done”. Here you can group them back into a feature, usually just gluing the cards together with a ladder. Some badges, such as overdue terms, may still be useful here. Periodically, as part of the acceptance procedure, the team arranges a demonstration of the tasks that have reached this column for the product owner or responsible analyst. Accepted tasks in the detail column “product backlog” are moved to the “accepted” column.
Column "accepted." If there are a lot of bugs in the system (and we are talking about long-running projects, so bugs in the tracker will be decent) and there is no point in evaluating everyone, this column contains the current course of bugs assessment in stars, common to all teams. For example, a quarter of a star for one bug or a star for each bug. It is advisable not to change this number in a single release, so try to choose in advance the balance between the new functionality and product stabilization. It is worth mentioning that this column mentions only the bugs that came from the backlog, but not those that were created during the testing of the features implemented by the team. But everywhere there are exceptions.
With the release of the next product release, all the cards from “accepted” are transferred to the “accepted” column common to all commands and are marked with the number of the next version. The easiest way to visualize this is by sorting by version number, color-coded by version number, or grouping within a column.
Something else in the end. There is a conveyor with waiting areas and without them. You may encounter the fact that new tasks cannot be transferred to testing due to limitations, but they are already ready. This situation may arise for various reasons. If a team does not want to fix bugs according to their features for testing, then these are team problems, and you should not give them the opportunity to transfer new tasks to testing before closing old ones. If the testing department does not cope with the flow of tasks or has poorly distributed priorities, then you can assign an additional price in the stars for testing the features - and then one of the teams can take this feature for testing. This approach will also help to share knowledge between the teams.
It can also be reformulated as “one board for everything.” It so happens that the board with the Roadmap product is shared with the scram-board, and the distribution of features by releases is not visualized at all. This has its advantages, for example, a roadmap can be illustrated in the form of a real map, showing the dependence of elements instead of not always obvious numerical priorities or a flat list. OK, no one limits you in space (to be more precise - no one limits you in space-time)!
A magnetic marker board with an area of ​​2-3 square meters is quite enough to make a two-dimensional model of a large project with all the necessary columns and there is still room for decoration. If you use the electronic version with scaling, then nothing prevents to detail the tasks to any necessary limit. In terms of the timeline, the blackboard will look like “months -> weeks -> days -> months”.
What are the tasks to be evaluated in hours or in story point? There are many attempts to determine the story point and methods of evaluation in dimensionless quantities (elephants, parrots). Most of them lead to the concept of complexity and ultimately to the internal (and sometimes officially approved recorded) construction of the table of correspondence SP -> hours. After walking between projects, you can meet at the beginning an estimate at the rate of 1 SP == 8 hours for the team, and then, in the next room, you can see 20 SP == 8 hours of work for 1 person. Sometimes dependence is non-linear. And there is never an understanding from the first, what is this story point. Everything, as the books say, in comparison. It would be something to compare.
“Star point” or simply “star” is the dimensionless amount of the assessment of tasks in a project based on their current significance for the project. You can draw an analogy with money. There is a team of developers who continuously work at a contract rate in the stars. The manager offers a new task - you need to add versioning to the product and make the version assignment semi-automatic when building on the build server. Offers a price of 10 stars. Programmers evaluate the task and understand that it is easier to fix 10 bugs, which are now estimated at 1 star for each. Since the version designation is urgently required by the support service for fixing errors, this functionality takes precedence over product stabilization, so the manager assigns a price of 20 stars and the first free developer quickly takes this task for himself or his team to earn 20 stars at once.
After some time, the project manager realizes that the developers have pounced on major tasks, and the support service has received many complaints about minor errors when working with the application. These can be typos, the lack of sorting in the list forms, and many similar minor but unpleasant flaws. Since it is too expensive to bargain for individual errors, the manager makes a decision and announces to the team - from Tuesday to the end of the week, any closed bug is evaluated in a threefold ratio. There is no need to give direct instructions, and the development team itself will change the development vector in order not to miss the chance to earn extra stars.
It may seem that programmers have no motivation to miss important or complex tasks, but this is not the case.
When the next card is accepted by the manager, its value in the stars is transferred to the account of the developer or the team that was involved in the implementation. The beauty of the stars is that they can not only save, but also spend. There is some problem called economy, several other problems follow from it - inflation, market, speculation.
This is both good and bad at the same time. And, unfortunately or fortunately, the biggest friend of a man is buried in this very point. The project manager must launch market relations among the employees involved in the project and regulate the system, not through authoritarian instructions, but with an invisible hand.
What can you spend the stars? It all depends on the project and the company, intangible motivation is different. You can not take into consideration time off, xbox one, gym and boat trips for every five hundred stars - after all, this is your company provides to its employees without any conditions. Inside the project there is a lot of other routine that can be a commodity. Not all tasks are interesting, but interesting ones may not be so relevant, and this makes it a low priority. Two teams can look at the same task. You can arrange a bid for this task and the one who will give more stars - has the right to take it for execution. Does the team have a blockage on feature bugs, but would you like to take on some task that does not fit into the limitations of the column? Let him sell bugs on the feature to another team! And so on the price agreed. Or let them buy an extra slot in the column for the week. But if they are late in terms, they will be fined in stellar equivalent so that the next month they will get only the most unpleasant tasks (other teams will pay off from them). Someone does not like merzhit, and someone to write tests. For the lack of tests, a new penalty is imposed, but it is possible to find someone who writes these tests for half the cost of the fine. An example with a load of a testing team and a self-check of tasks is also suitable.
The task of the manager is to keep the balance of the stars, without devaluing them and transparently indicating priorities, manipulating the market. You need to set certain rules, such as the exchange rate of bugs for the stars, but at the same time show constant flexibility and support the initiatives of the team. If someone decides to sell his turn to wash the coffee machine - why not! Commission for operations with stars? Can. But it is desirable to keep the desire to receive more stars, because otherwise nothing will work.
If this item still causes difficulties, then the board game from Mosigra and Habrahabr " Startup " can give good ground for reflection and once again please your colleagues who are tired of xbox one and yachting.
Yes. You just need to remember this. Updating versions of libraries used, revisions, CI and CD setup, VCS setup, team-wiki support, task tracker modification. These tasks should be taken into account in the total amount of work, they should have their priority and value in the stars. The team will acquire the skills of DevOps , and the project will save a little.
Oh yes. Software development is an area where skepticism is a necessary quality for the survival of both the specialist and the project. Well, starban is more likely for those who managed to learn the bitterness of disappointment in the canonical Agile, but also knows about the existence of a special place in hell where you continue to work as a programmer, alone on a project, with a manager who has 4 more projects. And you may have one more. Or on one project you have one team, and on the other a completely different one, partly staffed by the customer. In a word, it would be better for you to behave decently in this life.
Flexible development methodologies were created to solve specific tasks - protecting developers from the customer, ensuring pipeline processing of tasks, adaptability to changing requirements. There are useful practices that are always beneficial to use regardless of the specific methodology. Starban tried to put them together to make the development of the project comfortable and interesting for all participants in the process. At the same time, it remains adaptive to different conditions. It so happens that there are only a couple of developers on a project, but they can also organize a star competition by replacing the team test with a personal one. The board can adapt to the realities of problem statement and the possibility of formalization in the project. No one bothers to even tie starban to a specific project - if you can submit tasks within a single backlog (which is often the case in the IT department of production companies) and fit on one board, the project is only a conditional divider.
In the end, everyone will get the software development process he deserves.
- You are a software developer, development team leader, project manager or equivalent.
- More than one programmer is working on the project, preferably more than three.
- You have tried all these scars and edjails, felt their beauty, but there are certain complaints about the dogmatic following of the methodology. Probably, nobody is involved in setting the processes at all and the tasks simply “pile on”.
- The team is tired (from the project, from the stress, ...) and soon everyone will expect whips and gingerbread.
Well, there is a methodology that was invented by a team of programmers “for themselves,” but which, in our opinion, it would be interesting to try others. Inside the team, a small economic model of market relations is recreated, and priorities are regulated by the exchange rate of the command currency. .
Preamble
IT world has invented many approaches to building a software development process, borrowing the best ideas from their pre-industrial colleagues. At a certain stage of our professional development, we faced problems of motivation, quality management and visualization of work for the team and the customer. Taking all the best from all the best that we have taken, we organized work on medium-sized projects in the form of a starban.
')
History reference
The long journey through the commercial software development universe has confronted us with many approaches to project management. We saw waterfalls, we worked on RUP , tried to apply basic concepts of MSF , but the warmest memories left flexible methodologies. In the framework of one project, which lasted 2 years, we switched from scrum to kanban, divided and merged teams, bent Goldratt and Toyota to fit our needs.
From the scram we took the methods of team communication and the assessment of tasks in dimensionless (conditional) units. The process iteration is just as important, but can be regulated. Also, the visualization of the current work (tactical planning) is perfectly detailed in the scram. Kanban is good at applying the theory of constraints, the flexibility of setting them up for changes within a team, and visualizing current work on a strategic map. It is difficult to completely separate these two methodologies, since they are rarely found in the canonical incarnation. Many programmers, for example, have difficulty evaluating tasks in a story point, so tables for converting man-hours to story points are often created, or the score is immediately put in hours. Instead, we decided to evaluate the tasks based on their current project value and called this quantity stars. So the name starban appeared.
When do you need STARban
- There is a project with not always ready or clear TK, which must be presented in a tangible and evaluable form.
- The size of the project is sufficient so that the team does not have time to follow the changes in the project made by other participants and the current status of the project.
- Problems of collective responsibility (Why should I do this? Zakomichu so, maybe the tester will not find?
- Decreased motivation over time due to the transition of the project to the status of support or due to overqualified. (too good to work, too ugly to engage in prostitution).
OK, we have a project in which 5-15 people are involved, with the need to tighten strategic planning and several tired programmers who perceive any task as a routine. The rest perceive any task as a burden and set as a goal the formal closure of tasks with minimization of effort. The right, as they say, underline.
First of all, it should be noted that starban is not a complete software development methodology, but a set of extensions, allowing to increase productivity and not allow the project to plunge into a crisis. A tired developer can leave the project and take with him unique undocumented knowledge . The manager can merge to the offer better, and then understand the current status of the project can be quite problematic. The testing department will close the task and build acceptance testing in such a way as if all users of the product have completely read the instructions and vowed to never break the cat's grave. The development department swears at the testing department, shifting the responsibility to analysts and collecting large-scale meetings, where you can listen for 2 hours, make meeting hours for 1 hour and schedule the next meeting already with the stakeholder to retell it all again.
The stick and gingerbread are rarely balanced, since each team member needs an individual combination of these components. So, let us consider in order the complementary rules, the observance of which brought us peace of mind, and the project has an indelible benefit.
Princes of development STARban
Division into teams
Even if there are only 4-5 developers in a team, there is a reason to divide them into 2 teams, since more than 3 people are unlikely to be able to simultaneously develop one feature (user story). Most of the features are occupied by 1-2 people, the third can at this time be engaged in preparing for the development of the next functional.
If we average, our experience, for some reason, always showed that the ideal teams always consisted of three people. Perhaps this is a subjective value, but our colleagues also often came to the same conclusion. Being a universal autonomous unit is difficult and bad due to the lack of external control over the decisions made, and a larger team can block itself. In addition, each team member should know what others are doing.
Using the board to visualize project progress and teams
The board must perform the following functions:
- Show the most complete Roadmap project. The team will see what the product is heading for and use it when developing to apply the most strategic solutions. The owner of the product can adjust priorities on the same scheme and at the same time understand that additional urgent tasks will affect the deadline of others.
- Illustrate the stack of immediate tasks to develop. This gives an incentive to complete the current tasks. Tasks for development should be evaluated in SP.
- Display the status of the current execution of tasks by teams. This will allow team members to coordinate their actions, inform other team members about the problem, and see the current status. The manager based on the dynamics of this data can see the problem and interfere with its solution.
- Finished tasks can be divided into versions with the release of the next release, which will allow you to navigate the functionality of a product release.
The board is an important part in optimizing the process and should be as informative as possible.
The leftmost column is the project's Roadmap, sorted by task priority. It should also contain global technical tasks for the maintenance and modernization of the development infrastructure. It may also contain an urgent request for the correction of the functional, but it must follow the same rules as the other cards. For ourselves, we have adopted two rules - the cards in this column are separated by color and for each card its numerical priority is presented, which will help when sorting in the project management system. This column should be filled to the maximum extent possible so that all participants can see the expected result of development and take into account future needs when performing current tasks. The priority of the task can be changed by the stakeholder (the customer, his representative, the owner of the software being developed). When the priority changes, it can immediately estimate the losses - the release of which features will shift due to its changes.
The next column, product backlog, contains tasks for changing functionalities, bugs, and technical tasks that are formalized as user stories. Detailing here can be different, as well as types of tasks. For example, the merging of branches in the version control system may relate to a specific user story, but it can also be a separate card being evaluated, depending on the context. The priority in this column ceases to play a role, and the order of extracting tasks must be adjusted by the manager using the "star rating". We'll talk about the stars later, while it is worth knowing that it is more profitable for teams to take more star cards into their development. On this column, you can enter a limit on the number of cards simultaneously in it to avoid speculation. We tried the cat tray rule when the number of cards should be 1 more than the number of mini-teams involved in development (the number of trays, if you keep several cats at home, should also exceed their number by one).
With a lack of tasks in this column, a pre-planning should be carried out. Representatives of each team, a manager and, if necessary, a customer representative are involved in the pre-planning. Developers share estimates of the complexity of the task, the customer or manager assesses its relevance to the project. In this case, the final assessment in the stars puts the manager based on current priorities and the situation on the project. Tasks can also be added and evaluated by the manager individually, but it is worth doing this only with critical bugs. Do not forget about color coding in this column as well - this will give a quick glance at the board to see whether to wait for the release of new features, product stabilization in the near future, or the team is busy with the development infrastructure. OK, we will assume that all of them are able to decompose and evaluate tasks, and the colors chosen are suitable for color blind.
The following four columns are divided horizontally. Each team owns a piece of the board and keeps records on it. When a team has a need to take the next card from the product backlog for development, it carries out planning - it decomposes the task into tasks, finds out the implementation details, and estimates the implementation dates. The task is taken “to work” - and all the cards are placed here. The decomposition should be sufficiently detailed in order for the rule to be observed: one person for one task. Another good thing is the hierarchical numbering <feature number>. <Task number> or color division by features.
How to keep the team from capturing unnecessary tasks for which there are no free hands? Do I need to do this? Is there a limit on the number of cards? Rather, it should be regulated by the star-market method, which will be discussed later, but if problems arise, you can easily introduce Goldratt restrictions. For tasks in the "in work" column, you can use badges - these are additional noticeable markings for the cards from a distance. Stickers with bold characters - suitable. Examples: "!" - the task is in work longer than the initial assessment; "?" - on the task there is a question that requires holding a meeting with other teams. You should update this part of the board as often as possible and follow the badges on the tasks.
When the activity for the task is completed, it is moved to the "check" column. The testing team sees that all the monochrome feature tasks have passed to the test and begins testing. Bugs on the board can be displayed by stickers to cards or simply add an icon.
At the end of testing and the absence of bugs tasks are transferred to the column “done”. Here you can group them back into a feature, usually just gluing the cards together with a ladder. Some badges, such as overdue terms, may still be useful here. Periodically, as part of the acceptance procedure, the team arranges a demonstration of the tasks that have reached this column for the product owner or responsible analyst. Accepted tasks in the detail column “product backlog” are moved to the “accepted” column.
Column "accepted." If there are a lot of bugs in the system (and we are talking about long-running projects, so bugs in the tracker will be decent) and there is no point in evaluating everyone, this column contains the current course of bugs assessment in stars, common to all teams. For example, a quarter of a star for one bug or a star for each bug. It is advisable not to change this number in a single release, so try to choose in advance the balance between the new functionality and product stabilization. It is worth mentioning that this column mentions only the bugs that came from the backlog, but not those that were created during the testing of the features implemented by the team. But everywhere there are exceptions.
With the release of the next product release, all the cards from “accepted” are transferred to the “accepted” column common to all commands and are marked with the number of the next version. The easiest way to visualize this is by sorting by version number, color-coded by version number, or grouping within a column.
Something else in the end. There is a conveyor with waiting areas and without them. You may encounter the fact that new tasks cannot be transferred to testing due to limitations, but they are already ready. This situation may arise for various reasons. If a team does not want to fix bugs according to their features for testing, then these are team problems, and you should not give them the opportunity to transfer new tasks to testing before closing old ones. If the testing department does not cope with the flow of tasks or has poorly distributed priorities, then you can assign an additional price in the stars for testing the features - and then one of the teams can take this feature for testing. This approach will also help to share knowledge between the teams.
Exponential Board Timeline
It can also be reformulated as “one board for everything.” It so happens that the board with the Roadmap product is shared with the scram-board, and the distribution of features by releases is not visualized at all. This has its advantages, for example, a roadmap can be illustrated in the form of a real map, showing the dependence of elements instead of not always obvious numerical priorities or a flat list. OK, no one limits you in space (to be more precise - no one limits you in space-time)!
A magnetic marker board with an area of ​​2-3 square meters is quite enough to make a two-dimensional model of a large project with all the necessary columns and there is still room for decoration. If you use the electronic version with scaling, then nothing prevents to detail the tasks to any necessary limit. In terms of the timeline, the blackboard will look like “months -> weeks -> days -> months”.
Star rating
What are the tasks to be evaluated in hours or in story point? There are many attempts to determine the story point and methods of evaluation in dimensionless quantities (elephants, parrots). Most of them lead to the concept of complexity and ultimately to the internal (and sometimes officially approved recorded) construction of the table of correspondence SP -> hours. After walking between projects, you can meet at the beginning an estimate at the rate of 1 SP == 8 hours for the team, and then, in the next room, you can see 20 SP == 8 hours of work for 1 person. Sometimes dependence is non-linear. And there is never an understanding from the first, what is this story point. Everything, as the books say, in comparison. It would be something to compare.
“Star point” or simply “star” is the dimensionless amount of the assessment of tasks in a project based on their current significance for the project. You can draw an analogy with money. There is a team of developers who continuously work at a contract rate in the stars. The manager offers a new task - you need to add versioning to the product and make the version assignment semi-automatic when building on the build server. Offers a price of 10 stars. Programmers evaluate the task and understand that it is easier to fix 10 bugs, which are now estimated at 1 star for each. Since the version designation is urgently required by the support service for fixing errors, this functionality takes precedence over product stabilization, so the manager assigns a price of 20 stars and the first free developer quickly takes this task for himself or his team to earn 20 stars at once.
After some time, the project manager realizes that the developers have pounced on major tasks, and the support service has received many complaints about minor errors when working with the application. These can be typos, the lack of sorting in the list forms, and many similar minor but unpleasant flaws. Since it is too expensive to bargain for individual errors, the manager makes a decision and announces to the team - from Tuesday to the end of the week, any closed bug is evaluated in a threefold ratio. There is no need to give direct instructions, and the development team itself will change the development vector in order not to miss the chance to earn extra stars.
It may seem that programmers have no motivation to miss important or complex tasks, but this is not the case.
Market
When the next card is accepted by the manager, its value in the stars is transferred to the account of the developer or the team that was involved in the implementation. The beauty of the stars is that they can not only save, but also spend. There is some problem called economy, several other problems follow from it - inflation, market, speculation.
This is both good and bad at the same time. And, unfortunately or fortunately, the biggest friend of a man is buried in this very point. The project manager must launch market relations among the employees involved in the project and regulate the system, not through authoritarian instructions, but with an invisible hand.
What can you spend the stars? It all depends on the project and the company, intangible motivation is different. You can not take into consideration time off, xbox one, gym and boat trips for every five hundred stars - after all, this is your company provides to its employees without any conditions. Inside the project there is a lot of other routine that can be a commodity. Not all tasks are interesting, but interesting ones may not be so relevant, and this makes it a low priority. Two teams can look at the same task. You can arrange a bid for this task and the one who will give more stars - has the right to take it for execution. Does the team have a blockage on feature bugs, but would you like to take on some task that does not fit into the limitations of the column? Let him sell bugs on the feature to another team! And so on the price agreed. Or let them buy an extra slot in the column for the week. But if they are late in terms, they will be fined in stellar equivalent so that the next month they will get only the most unpleasant tasks (other teams will pay off from them). Someone does not like merzhit, and someone to write tests. For the lack of tests, a new penalty is imposed, but it is possible to find someone who writes these tests for half the cost of the fine. An example with a load of a testing team and a self-check of tasks is also suitable.
The task of the manager is to keep the balance of the stars, without devaluing them and transparently indicating priorities, manipulating the market. You need to set certain rules, such as the exchange rate of bugs for the stars, but at the same time show constant flexibility and support the initiatives of the team. If someone decides to sell his turn to wash the coffee machine - why not! Commission for operations with stars? Can. But it is desirable to keep the desire to receive more stars, because otherwise nothing will work.
If this item still causes difficulties, then the board game from Mosigra and Habrahabr " Startup " can give good ground for reflection and once again please your colleagues who are tired of xbox one and yachting.
Technical tasks are important
Yes. You just need to remember this. Updating versions of libraries used, revisions, CI and CD setup, VCS setup, team-wiki support, task tracker modification. These tasks should be taken into account in the total amount of work, they should have their priority and value in the stars. The team will acquire the skills of DevOps , and the project will save a little.
Postambula
And we tried scrum, but we did not like
And with us, and so everything works
And the team leader does not want to change anything
The manager said to stop playing toys and write code
We have too few programmers, why is it even necessary?
And here it is not written what to do if ...
... programmers will not want to earn stars
... we always have an urgent bugfix on production
... we misjudge the tasks, is it worth spending time on it?
... everything is on fire, and restrictions do not fix anything
... we have no board
... Migalkin hamsters all the stars and does not want to give them
Oh yes. Software development is an area where skepticism is a necessary quality for the survival of both the specialist and the project. Well, starban is more likely for those who managed to learn the bitterness of disappointment in the canonical Agile, but also knows about the existence of a special place in hell where you continue to work as a programmer, alone on a project, with a manager who has 4 more projects. And you may have one more. Or on one project you have one team, and on the other a completely different one, partly staffed by the customer. In a word, it would be better for you to behave decently in this life.
Flexible development methodologies were created to solve specific tasks - protecting developers from the customer, ensuring pipeline processing of tasks, adaptability to changing requirements. There are useful practices that are always beneficial to use regardless of the specific methodology. Starban tried to put them together to make the development of the project comfortable and interesting for all participants in the process. At the same time, it remains adaptive to different conditions. It so happens that there are only a couple of developers on a project, but they can also organize a star competition by replacing the team test with a personal one. The board can adapt to the realities of problem statement and the possibility of formalization in the project. No one bothers to even tie starban to a specific project - if you can submit tasks within a single backlog (which is often the case in the IT department of production companies) and fit on one board, the project is only a conditional divider.
In the end, everyone will get the software development process he deserves.
Source: https://habr.com/ru/post/240491/
All Articles