what_should_we_consider_when_forming_a_new_team
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
what_should_we_consider_when_forming_a_new_team [2017/03/06 19:42] – [Background] hpsamios | what_should_we_consider_when_forming_a_new_team [2022/02/23 07:05] (current) – ↷ Links adapted because of a move operation hans | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== What Should We Consider When Forming a New Team? ====== | ====== What Should We Consider When Forming a New Team? ====== | ||
- | ====== Premise ====== | ||
- | When you first bring Scrum into an organization you need to set up teams. Sounds easy, doesn' | + | When you first bring Scrum, agile or Kanban |
This page describes some simple background rules to setting up new teams. | This page describes some simple background rules to setting up new teams. | ||
Line 20: | Line 19: | ||
====== Approach ====== | ====== Approach ====== | ||
- | While it is optimal to keep Scrum Teams together for a period of time (they learn how to work with each-other) changes will happen as people decide they want to work with others, on other things or find they are not suited to the role they have taken on. We need to be open to these discussions so that we can improve the overall team structure of the organization. Often the Scrum Team itself will come up with a proposal to re-configure. But note that these changes should be relatively rare. The general approach to team formation is to "bring work to the team" not "form specific team to do this work". From a management perspective the additional benefit is that it reduces the amount of " | + | While it is optimal to keep Teams together for a period of time (they learn how to work with each-other) changes will happen as people decide they want to work with others, on other things or find they are not suited to the role they have taken on. We need to be open to these discussions so that we can improve the overall team structure of the organization. Often the Team itself will come up with a proposal to re-configure. But note that these changes should be relatively rare. The general approach to team formation is to "bring work to the team" not "form specific team to do this work". From a management perspective the additional benefit is that it reduces the amount of " |
- | For us the basic objective is to set teams up so they generally can take a requirement and turn it into working and improve our delivery, our predictability, | + | For us the basic objective is to set teams up so they generally can take a requirement and turn it into working |
- | We aim to build a series of “functional teams” – a team with members that has membership from code development, | + | We aim to build a series of “functional teams” – a team with members that has membership from code development, |
+ | |||
+ | Sometimes there is a need to form a “component team” where the team is responsible for a component (or more) in a product, and so provide services to functional teams. Pros for component teams is that they potentially reduce duplication. Downside is that they make planning more difficult as there is a dependency set up for just about every requirement where you need to deliver value (see [[why_should_we_work_harder_to_eliminate_the_effect_of_dependencies|Why Should We Work Harder to Eliminate the Effect of Dependencies? | ||
The idea of the “functional team” is hard for many organizations that are used to thinking about setting up teams based on the architecture of the product. Reality is that while the “architecture” approach may seem logical, its is basically the idea of “component” teams in the extreme, which means that every requirement coming into the systems requires extensive dependency management to get something out the door. And we all know that increased dependency leads to increase risk associated with our release of value. The traditional approach is an example of being resource efficient at the expense of being efficient in delivering value to the business. | The idea of the “functional team” is hard for many organizations that are used to thinking about setting up teams based on the architecture of the product. Reality is that while the “architecture” approach may seem logical, its is basically the idea of “component” teams in the extreme, which means that every requirement coming into the systems requires extensive dependency management to get something out the door. And we all know that increased dependency leads to increase risk associated with our release of value. The traditional approach is an example of being resource efficient at the expense of being efficient in delivering value to the business. | ||
Line 33: | Line 34: | ||
* In places where we have worked this, we did not change the reporting structure of any of the people as we went through this process. We basically said “this is your new role”. We then said to (say) development managers who became product owners “as a PO you receive your direction from the product management chain.” Benefit of this approach is that we didn’t have to set up new roles that straight-jacketed people in a new and different way. Downside is that some had a problem with the feeling that there was no formal role. | * In places where we have worked this, we did not change the reporting structure of any of the people as we went through this process. We basically said “this is your new role”. We then said to (say) development managers who became product owners “as a PO you receive your direction from the product management chain.” Benefit of this approach is that we didn’t have to set up new roles that straight-jacketed people in a new and different way. Downside is that some had a problem with the feeling that there was no formal role. | ||
- | * We told people that teams were permanent, that if you have something new that you want done that you bring work to the team, not create a team that will do the work. Idea here is that team can become more than “the sum of the parts” if they stay together. Reality is that in some situations, we made adjustments. See [[blog:what_is_the_effect_of_changing_team_members_on_velocity|What Is The Effect of Changing Team Members on Velocity?]] for more information. | + | * We told people that teams were permanent, that if you have something new that you want done that you bring work to the team, not create a team that will do the work. Idea here is that team can become more than “the sum of the parts” if they stay together. Reality is that in some situations, we made adjustments. See [[what_is_the_effect_of_changing_team_members_on_velocity|What Is The Effect of Changing Team Members on Velocity?]] for more information. |
* If you have a reason to create a team with more than 9 people, you add to the risk associated with having a successful team because the team needs to support a lot more communication in order to synchronize their activities. If you have a team smaller than 5 members, then you are adding to the risk associated with having a successful team in that the team might not have sufficient critical mass. Both these conditions can be made to work, but they are not recommended. In particular I've worked with a couple of teams that were very large - 15 people. What we found was that after attempting to work that way for a while, the teams typically told us that the overhead associated with keeping everyone informed was too much. They typically had a proposal on how to split the team to become more effective and in most cases we (management) simply accepted that proposal. | * If you have a reason to create a team with more than 9 people, you add to the risk associated with having a successful team because the team needs to support a lot more communication in order to synchronize their activities. If you have a team smaller than 5 members, then you are adding to the risk associated with having a successful team in that the team might not have sufficient critical mass. Both these conditions can be made to work, but they are not recommended. In particular I've worked with a couple of teams that were very large - 15 people. What we found was that after attempting to work that way for a while, the teams typically told us that the overhead associated with keeping everyone informed was too much. They typically had a proposal on how to split the team to become more effective and in most cases we (management) simply accepted that proposal. | ||
- | * It is more important to co-locate a Scrum Team than it is to come up with the optimal team. Its not that teams with remote members cannot work, its just a lot harder. This may require some creative approaches to team formation - don't let this become an obstacle. There will be sometimes good reasons for teams to have remote members. Just understand that this makes it harder to be successful as a Scrum Team. | + | * It is more important to co-locate |
* When forming functional teams you don’t need to create teams where every team can do everything. If you have 5 teams (1,2,..5) you are forming, and you have 5 areas of expertise in the product (eg components A,B..E), then the first team might be made up of people with expertise in A, B and E, the second with expertise in B, D and so on. Idea is not to aim for perfection, but create teams that can deliver value in most cases. | * When forming functional teams you don’t need to create teams where every team can do everything. If you have 5 teams (1,2,..5) you are forming, and you have 5 areas of expertise in the product (eg components A,B..E), then the first team might be made up of people with expertise in A, B and E, the second with expertise in B, D and so on. Idea is not to aim for perfection, but create teams that can deliver value in most cases. | ||
- | * If all these disciplines (eg development, | + | * If all these disciplines (eg development, |
- | * Make sure that scare resources are allocated to the "most important work". If some teams are expected to have reduced capacity, lets make sure that its not the ones that are bringing the most value to the product. | + | * Make sure that scarce |
* Where these people are available they can be allocated 50% to two teams (provided they are near to each-other). | * Where these people are available they can be allocated 50% to two teams (provided they are near to each-other). | ||
* The “co-location” issue will often solve itself even if you don’t start out that way. In one shop I worked in, more than 50% of teams we formed had people in locations such as US and India. Basically large number of the teams that were formed that way came back to us and said “we need to stop having remote people as we are not being effective / productive." | * The “co-location” issue will often solve itself even if you don’t start out that way. In one shop I worked in, more than 50% of teams we formed had people in locations such as US and India. Basically large number of the teams that were formed that way came back to us and said “we need to stop having remote people as we are not being effective / productive." | ||
* Product Owner and Scrum Masters have primary role, but also role to help the team. Start assuming 100% allocation to their role then let them adjust based on experience. In the shops I've worked in we did not experience a reduction in productivity when we set teams up this way. The general perception was that productivity improved. | * Product Owner and Scrum Masters have primary role, but also role to help the team. Start assuming 100% allocation to their role then let them adjust based on experience. In the shops I've worked in we did not experience a reduction in productivity when we set teams up this way. The general perception was that productivity improved. | ||
- | ====== | + | ====== |
For more information on the specific roles see: | For more information on the specific roles see: | ||
* [[what_is_the_role_of_the_team|What is the Role of a (Development) Team?]] | * [[what_is_the_role_of_the_team|What is the Role of a (Development) Team?]] | ||
- | * [[what_is_the_role_of_the_product_owner|What is the Role of a Product Owner?]] | + | * [[what_is_the_role_of_the_product_owner_ssa|What is the Role of a Product Owner?]] |
- | * [[what_is_the_role_of_the_scrum_master|What is the Role of a Scrum Master?]] | + | * [[what_is_the_role_of_the_scrum_master_ssa|What is the Role of a Scrum Master?]] |
* [[why_shouldn_t_we_set_up_dedicated_defect_teams|Why Shouldn' | * [[why_shouldn_t_we_set_up_dedicated_defect_teams|Why Shouldn' | ||
* [[why_do_we_form_teams_when_we_transition_to_agile|Why Do We Form Teams When We Transition To Agile?]] | * [[why_do_we_form_teams_when_we_transition_to_agile|Why Do We Form Teams When We Transition To Agile?]] | ||
+ | * [[what_is_the_effect_of_changing_team_members_on_velocity|What Is The Effect of Changing Team Members on Velocity?]] | ||
+ | * [[what_kinds_of_problems_do_you_see_when_agile_teams_churn_team_members_a_lot|What Kinds of Problems Do You See When Agile Teams Churn Team Members a Lot?]] | ||
Also see: | Also see: | ||
Line 62: | Line 65: | ||
- | ~~LINKBACK~~ | ||
- | ~~DISCUSSION~~ |
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/what_should_we_consider_when_forming_a_new_team.1488858163.txt.gz · Last modified: 2020/06/02 14:25 (external edit)