October 15, 2014 at 14:46Starban Flexible development methodology, gamification and many more buzzwords
Since the post is short and even inappropriate pictures do not make it easier to read, then let us first designate the target audience.
Well, there is a methodology that was invented by a team of programmers "for themselves", but which, in our opinion, will be interesting to try for others. Inside the team, a small economic model of market relations is recreated, and priorities are regulated using the intra-team currency exchange rate. .
The IT world has invented many approaches to building the software development process, borrowing the best ideas from its pre-industrial colleagues. At a certain stage of our professional development, we encountered problems of motivation, quality management and visualization of work for the team and customer. Having taken all the best of all the best that we have taken to us, we organized work on medium-sized projects in the form of a starban.
A long journey through the commercial software development universe has confronted us with many project management approaches. We saw waterfalls, worked on RUP , tried to apply the basic concepts of MSF , but the fondest memories were left by flexible methodologies. Within the framework of one project, which lasted 2 years, we switched from scrum to kanban, divided and united teams, bent Goldratt and Toyota to fit our needs .
From scrum we took the team’s methods of communication and assessment of tasks in dimensionless (conditional) units. The iterativeness of the process is just as important, but can be regulated. Also, in scrum, the visualization of the current work (tactical planning) is perfectly detailed. KanbanIt is good for applying the theory of constraints, the flexibility of their adjustment for changes within the team and visualization of the current work on the strategic map. It is difficult to completely separate these two methodologies, since they are rare in the canonical embodiment. Many programmers, for example, have difficulty evaluating tasks in the story point, so tables for translating human hours to story points are often created, or the rating is immediately put in the clock. Instead, we decided to evaluate the tasks according to their current value for the project and called this value stars. So the name starban appeared.
OK, we have a project in which 5-15 people participate, 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 their goal the formal closure of tasks with minimization of efforts. Necessary, as they say, emphasize.
First of all, it should be noted that starban is not a complete software development methodology, but a set of extensions to increase productivity and prevent the project from plunging into crisis. A tired developer can leave the project and take with him unique, undocumented knowledge. The manager can merge better on the offer, and then it can be quite problematic to understand the current status of the project. The testing department will close the task and build acceptance testing so that all users of the product read the instructions completely and swear by the grave of their cat to never violate it. The development department swears with the testing department, transferring responsibility to analysts and collecting large-scale meetings, where you can listen for 2 hours, make meeting minutes for 1 hour and, as a result, schedule the next meeting with the stakeholder to tell him again.
The carrot and stick are rarely balanced, as each team member requires an individual combination of these components. So, we will consider in order complementary rules, the observance of which brought us peace of mind, and the project 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 often, 1-2 people are busy with features, the third one can be engaged in preparation for the development of the next functional at this time.
If we average, then our experience, for some reason, always showed that ideal teams always consisted of three people. Perhaps this is a subjective meaning, but our colleagues also often came to the same conclusion. It is difficult and bad to be a universal autonomous unit due to the lack of external control of decisions made, and a team of a larger composition can block itself. In addition, each member of the team must know what others are doing.
The board should 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 Roadmap of the project, sorted by priority of tasks. It should also contain the global technical tasks of servicing and modernizing the development infrastructure. It may also contain an urgent request to fix the functionality, but it must follow the same rules as the rest of the cards. For ourselves, we adopted two rules - the cards in this column are divided 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 as much as possible so that all participants can see the expected development result and take into account future needs when performing current tasks. The stakeholder alone (the customer, his representative, the owner of the software being developed) can change the priority of the task.
The next column - product backlog - contains functional change tasks, bugs, and technical tasks formalized as user stories. The details here may be different, as well as the types of tasks. For example, merging branches in a version control system may relate to a specific user story, but it may also be a separate evaluated card, depending on the context. The priority in this column ceases to play a role, and the order of extraction of tasks should be adjusted by the manager using a "star rating". We’ll talk about stars later, for now it’s only worth knowing that it’s more profitable for teams to take more star cards to 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,
With a lack of tasks, pre-planning should be carried out in this column. Representatives of each team, manager and, if necessary, customer representative participate in the preplanning. Developers share assessments of the complexity of the task, the customer or manager assesses its relevance to the project. At the same time, the final rating in the stars is set by the manager based on current priorities and the situation on the project. Tasks can also be added and evaluated by the manager individually, but this is only worth doing with critical bugs. Do not forget about the color coding in this column as well - this will allow you to understand if you look for new features in the near future, stabilize the product, or if the team is busy with the development infrastructure. OK, we will assume that everyone knows how to decompose and evaluate tasks,
The next 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 another card from the product backlog into development, it conducts planning - decomposes the task into tasks, finds out implementation details, estimates the implementation time. The task is taken "to work" - and here all the cards are placed. The decomposition should be detailed enough to comply with the rule: one person per task. The hierarchical numbering <feature number>. <Task number> or color division by features is still good.
How to keep a team from capturing unnecessary tasks for which there are no free hands? Is there any need to do this? Is there a limit on the number of cards? Rather, this should be regulated by the star-market method, which will be discussed later, but if problems arise, Goldratt restrictions can be introduced without problems. For tasks from the “at work” column, you can use icons - these are additional notes for cards that are noticeable from afar. Stickers with bold characters are suitable. Examples: "!" - the task is in work longer than the initial estimate; "?" - on the task there is a question that requires a meeting with other teams. You should update this part of the board as often as possible and keep track of the badges on the tasks.
When the activity on the task is completed, it moves to the "check" column. The testing team sees that all the same-color feature tasks have passed the test and begin testing. Bugs on the board can be displayed with stickers on cards or just add an icon.
When testing is completed and there are no bugs, tasks are transferred to the “done” column. Here they can be grouped back into a feature, usually just gluing cards with a ladder. Some badges, such as overdue ones, may come in handy 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 detailing the product backlog column are moved to the accepted column.
The “accepted” column. If there are a lot of bugs in the system (and we are talking about long-playing projects, so there will be decent bugs in the tracker) and there is no sense in evaluating each, this column contains the current rate of bug assessment in stars, common for all teams. For example, a quarter star for one bug or a star for each bug. It is advisable not to change this number within the framework of one release, so try to choose a balance between the new functionality and product stabilization in advance. It is worth mentioning that in this column only bugs that came from the backlog are mentioned, but not those that were created during testing by the features implemented by the team. But everywhere there are exceptions.
Upon the release of the next product release, all cards from “accepted” are transferred to the “accepted” column for all teams and are marked with the number of the next version. The easiest way to visualize this is by sorting by version number, color coding by version number, or by grouping within a column.
One last thing. There is a conveyor with waiting areas and without them. You may find that you cannot translate new tasks into testing due to limitations, but they are ready. This situation can arise for various reasons. If the team does not want to fix bugs according to their feature in testing, then these are team problems, and you should not give them the opportunity to transfer new tasks to testing before closing the old ones. If the testing department does not cope with the flow of tasks or has poorly prioritized, then you can assign an additional price in stars for testing features - and then one of the teams can take this feature for testing. This approach will also help to share knowledge between teams.
It can also be reformulated as "one board for everything." It happens that a board with a Roadmap product is shared with a scrum board, and even the distribution of features by release 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 the 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 enough to make a two-dimensional model of a large project with all the necessary columns and there will still be room for decoration. If you use the electronic version with scaling, then nothing prevents you from detailing tasks to any necessary limit. The board in terms of the timeline will look like "months -> weeks -> days -> months."
How to evaluate tasks - in hours or in story point? There are many attempts to determine the story point and evaluation methods in dimensionless quantities (elephants, parrots). Most lead to the concept of complexity and, as a result, to the internal (and sometimes officially approved) construction of the correspondence table SP -> hours. Taking a walk between the projects, you can first meet the estimate at the rate of 1 SP == 8 hours of the team, and then, in the next office, see 20 SP == 8 hours of work for 1 person. Sometimes the dependence is nonlinear. And there is never a first understanding of what this story point is. Everything, as the books say, is in comparison. It would be something to compare.
A “star point” or simply a “star” is a dimensionless value for evaluating 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 work continuously at a contractual rate in the stars. The manager offers a new task - you need to add versioning to the product and make version assignment semi-automatic when building on a 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 rated at 1 star for each. Since specifying the version urgently requires a support service for fixing errors, this functionality is more priority than product stabilization, so the manager sets a price of 20 stars and the first freed developer hastily takes this task for himself or his team,
After some time, the project manager understands that the developers attacked large tasks, and a lot of complaints about minor errors when working with the application began to come to the support service. This can be typos, lack of sorting in list forms and many similar minor but unpleasant shortcomings. Since bargaining for individual errors is too expensive, the leader makes a decision and announces to the team - from Tuesday to the end of the week, any closed bug is evaluated in a triple coefficient. There is no need to give direct instructions, and the development team itself will change the development vector so as not to miss the chance to earn extra stars.
It may seem that programmers have no motivation to grab important or complex tasks, but this is not so.
When the head accepts the next card, its value in stars is transferred to the account of the developer or team that was involved in the implementation. The beauty of stars is that they can not only be saved, but also spent. There is some problem called the economy; several other problems follow from it - inflation, the market, and speculation.
This is both good and bad at the same time. And, unfortunately or fortunately, the biggest friend of a person 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 directions, but with an invisible hand.
What can you spend stars on? It all depends on the project and the company, intangible motivation is different. You can not take into account days off, xbox one, a gym and boat trips for every five hundred stars - after all, this is your company that provides 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 may not be so relevant and this is why it is of low priority. Two teams can keep an eye on one task. Bidding can be arranged for this task, and the one who gives more stars has the right to take it for execution. The team has a blockage of feature bugs, but would you like to take some kind of task that does not fit into the limitations of the column? Let him sell bugs for a feature to another team! And they’ll agree on a price. Or let them buy an additional slot in the column for a week. But if they are late in time, 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 to merge, and someone write tests. For the lack of tests for new functionality, a fine is imposed, but you can find someone who writes these tests for half the cost of the fine. An example with a busy test team and self-testing tasks is also suitable.
The task of the leader here is to maintain the balance of the stars, without devaluing them and transparently indicating priorities, manipulating the market. It is necessary to set certain rules, such as the exchange rate of bugs for stars, but at the same time to show constant flexibility and support team initiatives. If someone decides to sell a turn to wash a coffee machine - why not! Commission for operations with stars? Can. But it is advisable to keep the desire to get more stars, because otherwise nothing will work.
If this item still causes difficulties, then the board game from Mosigra and Habrahabr “ Startup ” can provide good ground for thought and once again please your colleagues who are tired of xbox one and boat trips.
Yes. You just need to remember this. Updating the versions of used libraries, revisions, setting up CI and CD , setting up VCS , supporting team-wiki, modifying the task tracker. These tasks should be taken into account in the total amount of work, they should have their priority and value in stars. The team will gain DevOps skills , and the project will save a little.
Oh yeah. Software development is such an area where skepticism is a necessary quality for the survival of both a specialist and a project. Well, starban is more likely for those who managed to learn the bitterness of disappointment in the canonical Agile, but also know that there is a special place in hell, where you continue to work as a programmer, one on the project, with a manager who has 4 more such projects. And you probably have one more. Or on one project you have one team, and on the other a completely different team, partially 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 certain problems - protecting developers from the customer, providing pipeline processing of tasks, adaptability to changing requirements. There are useful practices that are always advantageous 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 happens that there are only a couple of developers on the project, but they can also organize stellar competition, replacing the team event with a personal one. The board can adapt to the realities of setting goals and the possibility of formalization in the project.
And in the end, everyone will get the software development process that they deserve.
- You are a software developer, development team leader, project manager, or its equivalent.
- More than one programmer is working on a project, preferably more than three.
- You tried all these scrams and edge-books, felt their charm, but there are certain complaints about the dogmatic following of the methodology. Perhaps you have no one involved in the formulation of processes at all and the tasks are simply “thrown over”.
- The team is tired (from the project, from stress, ...) and soon all the carrots and sticks are waiting for everyone.
Well, there is a methodology that was invented by a team of programmers "for themselves", but which, in our opinion, will be interesting to try for others. Inside the team, a small economic model of market relations is recreated, and priorities are regulated using the intra-team currency exchange rate. .
Preamble
The IT world has invented many approaches to building the software development process, borrowing the best ideas from its pre-industrial colleagues. At a certain stage of our professional development, we encountered problems of motivation, quality management and visualization of work for the team and customer. Having taken all the best of all the best that we have taken to us, we organized work on medium-sized projects in the form of a starban.
Historical reference
A long journey through the commercial software development universe has confronted us with many project management approaches. We saw waterfalls, worked on RUP , tried to apply the basic concepts of MSF , but the fondest memories were left by flexible methodologies. Within the framework of one project, which lasted 2 years, we switched from scrum to kanban, divided and united teams, bent Goldratt and Toyota to fit our needs .
From scrum we took the team’s methods of communication and assessment of tasks in dimensionless (conditional) units. The iterativeness of the process is just as important, but can be regulated. Also, in scrum, the visualization of the current work (tactical planning) is perfectly detailed. KanbanIt is good for applying the theory of constraints, the flexibility of their adjustment for changes within the team and visualization of the current work on the strategic map. It is difficult to completely separate these two methodologies, since they are rare in the canonical embodiment. Many programmers, for example, have difficulty evaluating tasks in the story point, so tables for translating human hours to story points are often created, or the rating is immediately put in the clock. Instead, we decided to evaluate the tasks according to their current value for the project and called this value stars. So the name starban appeared.
When is STARban needed?
- There is a project with not always ready or clear TK, which needs to be presented in a tangible and assessed form.
- The size of the project is sufficient so that the team does not have time to monitor changes in the project made by other participants and the current status of the project.
- Problems of collective responsibility (Why should I do this? I’m zakomich so, maybe the tester can’t find it? Again, someone dumped the build, I'll go while I have lunch. It's not a bug.)
- Decrease in motivation over time due to the transition of the project to support status or due to overqualified. (too good to work, too ugly to engage in prostitution).
OK, we have a project in which 5-15 people participate, 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 their goal the formal closure of tasks with minimization of efforts. Necessary, as they say, emphasize.
First of all, it should be noted that starban is not a complete software development methodology, but a set of extensions to increase productivity and prevent the project from plunging into crisis. A tired developer can leave the project and take with him unique, undocumented knowledge. The manager can merge better on the offer, and then it can be quite problematic to understand the current status of the project. The testing department will close the task and build acceptance testing so that all users of the product read the instructions completely and swear by the grave of their cat to never violate it. The development department swears with the testing department, transferring responsibility to analysts and collecting large-scale meetings, where you can listen for 2 hours, make meeting minutes for 1 hour and, as a result, schedule the next meeting with the stakeholder to tell him again.
The carrot and stick are rarely balanced, as each team member requires an individual combination of these components. So, we will consider in order complementary rules, the observance of which brought us peace of mind, and the project indelible benefit.
Princes of STARban development
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 often, 1-2 people are busy with features, the third one can be engaged in preparation for the development of the next functional at this time.
If we average, then our experience, for some reason, always showed that ideal teams always consisted of three people. Perhaps this is a subjective meaning, but our colleagues also often came to the same conclusion. It is difficult and bad to be a universal autonomous unit due to the lack of external control of decisions made, and a team of a larger composition can block itself. In addition, each member of the team must know what others are doing.
Using the whiteboard to visualize project progress and teams
The board should perform the following functions:
- Show the most complete RoadMap project. The team will see what the product is heading for and use it in development to apply the most strategic solutions. The owner of the product can adjust the priorities in 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 for development. This provides an incentive to complete current tasks. Development challenges 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 instant status. The manager, based on the dynamics of this data, can see the problem and intervene in its solution.
- Ready-made tasks can be divided into versions when the next release is released, which will allow you to navigate the functionality of a particular product release.
The board is an important part in optimizing the process and should be as informative as possible.
The leftmost column is the Roadmap of the project, sorted by priority of tasks. It should also contain the global technical tasks of servicing and modernizing the development infrastructure. It may also contain an urgent request to fix the functionality, but it must follow the same rules as the rest of the cards. For ourselves, we adopted two rules - the cards in this column are divided 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 as much as possible so that all participants can see the expected development result and take into account future needs when performing current tasks. The stakeholder alone (the customer, his representative, the owner of the software being developed) can change the priority of the task.
The next column - product backlog - contains functional change tasks, bugs, and technical tasks formalized as user stories. The details here may be different, as well as the types of tasks. For example, merging branches in a version control system may relate to a specific user story, but it may also be a separate evaluated card, depending on the context. The priority in this column ceases to play a role, and the order of extraction of tasks should be adjusted by the manager using a "star rating". We’ll talk about stars later, for now it’s only worth knowing that it’s more profitable for teams to take more star cards to 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,
With a lack of tasks, pre-planning should be carried out in this column. Representatives of each team, manager and, if necessary, customer representative participate in the preplanning. Developers share assessments of the complexity of the task, the customer or manager assesses its relevance to the project. At the same time, the final rating in the stars is set by the manager based on current priorities and the situation on the project. Tasks can also be added and evaluated by the manager individually, but this is only worth doing with critical bugs. Do not forget about the color coding in this column as well - this will allow you to understand if you look for new features in the near future, stabilize the product, or if the team is busy with the development infrastructure. OK, we will assume that everyone knows how to decompose and evaluate tasks,
The next 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 another card from the product backlog into development, it conducts planning - decomposes the task into tasks, finds out implementation details, estimates the implementation time. The task is taken "to work" - and here all the cards are placed. The decomposition should be detailed enough to comply with the rule: one person per task. The hierarchical numbering <feature number>. <Task number> or color division by features is still good.
How to keep a team from capturing unnecessary tasks for which there are no free hands? Is there any need to do this? Is there a limit on the number of cards? Rather, this should be regulated by the star-market method, which will be discussed later, but if problems arise, Goldratt restrictions can be introduced without problems. For tasks from the “at work” column, you can use icons - these are additional notes for cards that are noticeable from afar. Stickers with bold characters are suitable. Examples: "!" - the task is in work longer than the initial estimate; "?" - on the task there is a question that requires a meeting with other teams. You should update this part of the board as often as possible and keep track of the badges on the tasks.
When the activity on the task is completed, it moves to the "check" column. The testing team sees that all the same-color feature tasks have passed the test and begin testing. Bugs on the board can be displayed with stickers on cards or just add an icon.
When testing is completed and there are no bugs, tasks are transferred to the “done” column. Here they can be grouped back into a feature, usually just gluing cards with a ladder. Some badges, such as overdue ones, may come in handy 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 detailing the product backlog column are moved to the accepted column.
The “accepted” column. If there are a lot of bugs in the system (and we are talking about long-playing projects, so there will be decent bugs in the tracker) and there is no sense in evaluating each, this column contains the current rate of bug assessment in stars, common for all teams. For example, a quarter star for one bug or a star for each bug. It is advisable not to change this number within the framework of one release, so try to choose a balance between the new functionality and product stabilization in advance. It is worth mentioning that in this column only bugs that came from the backlog are mentioned, but not those that were created during testing by the features implemented by the team. But everywhere there are exceptions.
Upon the release of the next product release, all cards from “accepted” are transferred to the “accepted” column for all teams and are marked with the number of the next version. The easiest way to visualize this is by sorting by version number, color coding by version number, or by grouping within a column.
One last thing. There is a conveyor with waiting areas and without them. You may find that you cannot translate new tasks into testing due to limitations, but they are ready. This situation can arise for various reasons. If the team does not want to fix bugs according to their feature in testing, then these are team problems, and you should not give them the opportunity to transfer new tasks to testing before closing the old ones. If the testing department does not cope with the flow of tasks or has poorly prioritized, then you can assign an additional price in stars for testing features - and then one of the teams can take this feature for testing. This approach will also help to share knowledge between teams.
Exponential Board Timeline
It can also be reformulated as "one board for everything." It happens that a board with a Roadmap product is shared with a scrum board, and even the distribution of features by release 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 the 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 enough to make a two-dimensional model of a large project with all the necessary columns and there will still be room for decoration. If you use the electronic version with scaling, then nothing prevents you from detailing tasks to any necessary limit. The board in terms of the timeline will look like "months -> weeks -> days -> months."
Rating tasks in the stars
How to evaluate tasks - in hours or in story point? There are many attempts to determine the story point and evaluation methods in dimensionless quantities (elephants, parrots). Most lead to the concept of complexity and, as a result, to the internal (and sometimes officially approved) construction of the correspondence table SP -> hours. Taking a walk between the projects, you can first meet the estimate at the rate of 1 SP == 8 hours of the team, and then, in the next office, see 20 SP == 8 hours of work for 1 person. Sometimes the dependence is nonlinear. And there is never a first understanding of what this story point is. Everything, as the books say, is in comparison. It would be something to compare.
A “star point” or simply a “star” is a dimensionless value for evaluating 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 work continuously at a contractual rate in the stars. The manager offers a new task - you need to add versioning to the product and make version assignment semi-automatic when building on a 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 rated at 1 star for each. Since specifying the version urgently requires a support service for fixing errors, this functionality is more priority than product stabilization, so the manager sets a price of 20 stars and the first freed developer hastily takes this task for himself or his team,
After some time, the project manager understands that the developers attacked large tasks, and a lot of complaints about minor errors when working with the application began to come to the support service. This can be typos, lack of sorting in list forms and many similar minor but unpleasant shortcomings. Since bargaining for individual errors is too expensive, the leader makes a decision and announces to the team - from Tuesday to the end of the week, any closed bug is evaluated in a triple coefficient. There is no need to give direct instructions, and the development team itself will change the development vector so as not to miss the chance to earn extra stars.
It may seem that programmers have no motivation to grab important or complex tasks, but this is not so.
Market
When the head accepts the next card, its value in stars is transferred to the account of the developer or team that was involved in the implementation. The beauty of stars is that they can not only be saved, but also spent. There is some problem called the economy; several other problems follow from it - inflation, the market, and speculation.
This is both good and bad at the same time. And, unfortunately or fortunately, the biggest friend of a person 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 directions, but with an invisible hand.
What can you spend stars on? It all depends on the project and the company, intangible motivation is different. You can not take into account days off, xbox one, a gym and boat trips for every five hundred stars - after all, this is your company that provides 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 may not be so relevant and this is why it is of low priority. Two teams can keep an eye on one task. Bidding can be arranged for this task, and the one who gives more stars has the right to take it for execution. The team has a blockage of feature bugs, but would you like to take some kind of task that does not fit into the limitations of the column? Let him sell bugs for a feature to another team! And they’ll agree on a price. Or let them buy an additional slot in the column for a week. But if they are late in time, 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 to merge, and someone write tests. For the lack of tests for new functionality, a fine is imposed, but you can find someone who writes these tests for half the cost of the fine. An example with a busy test team and self-testing tasks is also suitable.
The task of the leader here is to maintain the balance of the stars, without devaluing them and transparently indicating priorities, manipulating the market. It is necessary to set certain rules, such as the exchange rate of bugs for stars, but at the same time to show constant flexibility and support team initiatives. If someone decides to sell a turn to wash a coffee machine - why not! Commission for operations with stars? Can. But it is advisable to keep the desire to get more stars, because otherwise nothing will work.
If this item still causes difficulties, then the board game from Mosigra and Habrahabr “ Startup ” can provide good ground for thought and once again please your colleagues who are tired of xbox one and boat trips.
Technical challenges are important
Yes. You just need to remember this. Updating the versions of used libraries, revisions, setting up CI and CD , setting up VCS , supporting team-wiki, modifying the task tracker. These tasks should be taken into account in the total amount of work, they should have their priority and value in stars. The team will gain DevOps skills , and the project will save a little.
Istanbul
And we tried scrum, but we didn’t like it.
And everything works with us.
A team leader does not want to change anything
The manager said that they finish playing toys and write the code
We have too few programmers, why is this even necessary?
And here it’s not written what to do if ...
... programmers will not want to earn stars
... we constantly wedge an urgent bugfix on production
... we misjudge the tasks, is it worth the time at all?
... everything is burning, but the restrictions do not allow to fix anything
... we do not have a board
... Migalkin hamsters all the stars and does not want to give them away
Oh yeah. Software development is such an area where skepticism is a necessary quality for the survival of both a specialist and a project. Well, starban is more likely for those who managed to learn the bitterness of disappointment in the canonical Agile, but also know that there is a special place in hell, where you continue to work as a programmer, one on the project, with a manager who has 4 more such projects. And you probably have one more. Or on one project you have one team, and on the other a completely different team, partially 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 certain problems - protecting developers from the customer, providing pipeline processing of tasks, adaptability to changing requirements. There are useful practices that are always advantageous 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 happens that there are only a couple of developers on the project, but they can also organize stellar competition, replacing the team event with a personal one. The board can adapt to the realities of setting goals and the possibility of formalization in the project.
And in the end, everyone will get the software development process that they deserve.