Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
what_should_we_consider_when_forming_a_new_team [2017/03/06 19:42]
Hans Samios [Background]
what_should_we_consider_when_forming_a_new_team [2017/03/06 19:48] (current)
Hans Samios
Line 1: Line 1:
 ====== What Should We Consider When Forming a New Team? ====== ====== What Should We Consider When Forming a New Team? ======
 +
 ====== Premise ====== ====== Premise ======
  
-When you first bring Scrum into an organization you need to set up teams. Sounds easy, doesn'​t it until you starting thinking through the problem. That's when you start to understand that this may not be as easy as you thought.+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'​t it until you starting thinking through the problem. That's when you start to understand that this may not be as easy as you thought.
  
 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 21:
 ====== 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 "​resource allocation"​ activities you have to do (if you have the "​resource spreadsheet"​ with FTE's down to small percentages of allocation, you are in for a treat is you adopt a team structure more oriented to the value delivered).+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 "​resource allocation"​ activities you have to do (if you have the "​resource spreadsheet"​ with FTE's down to small percentages of allocation, you are in for a treat is you adopt a team structure more oriented to the value delivered)
 + 
 +For us the basic objective is to set teams up so they generally can take a requirement and turn it into working software / delivered value and improve our delivery, our predictability,​ and our quality.
  
-For us the basic objective is to set teams up so they generally can take requirement and turn it into working and improve our deliveryour predictability, and our quality.+We aim to build a series of “functional ​teams” – team with members that has membership from code developmentQAproduct management, UX, writers, etc - whatever is required to get the value delivered. This cross-functional group is needed so they can deliver value to “potentially shippable” state including QA and documentation.
  
-We aim to build a series of “functional teams” – a team with members that has membership from code development,​ QA, product management, UX, writers, etc. This cross-functional group is needed so they can deliver value to “potentially shippable” state including QA and documentation. ​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?​]] for more information). For a large product (lots of teams working toward the same product or service release) I’ve found the the ratio of functional vs component teams is about 70:​30. ​+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?​]] for more information). For a large product (lots of teams working toward the same product or service release) I’ve found the the ratio of functional vs component teams is about 70:​30. ​
  
 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 35: Line 38:
   * 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 [[blog:​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 ​(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.
   * 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,​ QA, UX, etc) are not available, the team is not absolved of responsibility for the work. It just means the team will have to determine how to get the relevant expertise and there will be an impact on the amount of value the Scrum team can deliver while they learn how to do these activities. Practically,​ what does this mean? A lot of development shops will have a shortage of quality assurance, documentation,​ functional designers, subject matter experts and so on in comparison to the number of developers that have. There are some approaches which can be taken: +  * If all these disciplines (eg development,​ QA, UX, etc) are not available, the team is not absolved of responsibility for the work required to do a quality delivery. It just means the team will have to determine how to get the relevant expertise and there will be an impact on the amount of value the team can deliver while they learn how to do these activities. Practically,​ what does this mean? A lot of development shops will have a shortage of quality assurance, documentation,​ functional designers, subject matter experts and so on in comparison to the number of developers that have. There are some approaches which can be taken: 
-    * 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 ​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.
     * 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."​ There was good business reasons for forming things this way (for example, the main reason we had for forming teams like this in this shop was that we were often dealing with new people in the remote location. Over time and through the mentoring of the team, the remote people were able to take on work and the team came back and told us they wanted to re-organize due to the overhead of remote communication. When the team told us they wanted to re-org, we let it happen.   * 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."​ There was good business reasons for forming things this way (for example, the main reason we had for forming teams like this in this shop was that we were often dealing with new people in the remote location. Over time and through the mentoring of the team, the remote people were able to take on work and the team came back and told us they wanted to re-organize due to the overhead of remote communication. When the team told us they wanted to re-org, we let it happen.
  • /home/hpsamios/hanssamios.com/dokuwiki/data/pages/what_should_we_consider_when_forming_a_new_team.txt
  • Last modified: 2017/03/06 19:48
  • by Hans Samios