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 revisionNext revisionBoth sides next revision | ||
| what_should_we_consider_when_forming_a_new_team [2017/03/06 19:48] – hpsamios | what_should_we_consider_when_forming_a_new_team [2020/06/10 12:53] – ↷ 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, agile or Kanban into an organization you need to set up teams (see [[why_do_we_form_teams_when_we_transition_to_agile|Why Do We Form Teams When We Transition To Agile?]] to understand why). Sounds easy, doesn' | When you first bring Scrum, agile or Kanban into an organization you need to set up teams (see [[why_do_we_form_teams_when_we_transition_to_agile|Why Do We Form Teams When We Transition To Agile?]] to understand why). Sounds easy, doesn' | ||
| Line 27: | Line 25: | ||
| 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 [[blog:why_should_we_work_harder_to_eliminate_the_effect_of_dependencies|Why Should We Work Harder to Eliminate the Effect of Dependencies? | + | 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 36: | 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 (or failing that, co-timezone) a 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 Team. | * It is more important to co-locate (or failing that, co-timezone) a 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 Team. | ||
| Line 46: | Line 44: | ||
| * 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: | ||
| Line 55: | Line 53: | ||
| * [[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 65: | Line 65: | ||
| - | ~~LINKBACK~~ | ||
| - | ~~DISCUSSION~~ | ||
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/what_should_we_consider_when_forming_a_new_team.txt · Last modified: 2022/02/23 07:05 by hans