Hans Samios' Personal Lean-Agile Knowledge Base

... absolutely #noabsolutes ...

User Tools

Site Tools

Trace:
how_does_a_team_initially_get_control_of_work

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
how_does_a_team_initially_get_control_of_work [2018/09/18 06:26] – hpsamioshow_does_a_team_initially_get_control_of_work [2020/06/10 12:47] (current) – ↷ Links adapted because of a move operation hans
Line 45: Line 45:
  
   - All Team work must go through the PO for prioritization. Many times work will come to the Team because someone knows someone else, or there is an old “work assignment” procedure in place, or the Team member just wants to do the work. To make sure we gain visibility etc., we have to channel all work through the Product Owner. This is not just something you do at the beginning of “being a Team” but rather something that is a standard practice. But the practice is a good and useful habit to get into right now.   - All Team work must go through the PO for prioritization. Many times work will come to the Team because someone knows someone else, or there is an old “work assignment” procedure in place, or the Team member just wants to do the work. To make sure we gain visibility etc., we have to channel all work through the Product Owner. This is not just something you do at the beginning of “being a Team” but rather something that is a standard practice. But the practice is a good and useful habit to get into right now.
-  - Update the Team scope. This means that for new work items you need to compare this work item to the current definition of Team scope. If it is in the Team scope, then it’s just normal work and so we continue. If it isn’t, then we need discuss with PM team to see if Team scope needs to be adjusted. Again, if the Team scope is changed, then it continues with the Team. If it is not, then you need to determine how to transfer work to responsible party for this and future similar items. Responsibility for the work item remains with the Team until this transfer discussion has been completed.+  - Update the Team scope. This means that for new work items you need to compare this work item to the current definition of Team scope. If it is in the Team scope, then it’s just normal work and so we continue. If it isn’t, then we need discuss with Product Management team to see if Team scope needs to be adjusted. Again, if the Team scope is changed, then it continues with the Team. If it is not, then you need to determine how to transfer work to responsible party for this and future similar items. Responsibility for the work item remains with the Team until this transfer discussion has been completed. In this way we also ensure that work that used to be done by Team members does not get dropped when the Agile Team is formed - see [[How Do We Ensure Critical Work Does Not Get Dropped as We Kick Off Teams?]] for more information.
   - Work to understand what items that are unplanned (real break-ins) versus something that can be planned. From a Team perspective the more work we can plan, the more we can control and the more effective we can become. For many IT organizations which are driven by ticketing systems it often looks like all work suddenly appears. But the reality is that often the tickets come from known work such as projects that the business want. In other cases, a ticketing system will specify a date to be done (and the date is often “immediately”) but from a business perspective we don’t really need it now and so we could schedule it at some time in the future. The Team should look at incoming work and try to figure out how to plan more work.   - Work to understand what items that are unplanned (real break-ins) versus something that can be planned. From a Team perspective the more work we can plan, the more we can control and the more effective we can become. For many IT organizations which are driven by ticketing systems it often looks like all work suddenly appears. But the reality is that often the tickets come from known work such as projects that the business want. In other cases, a ticketing system will specify a date to be done (and the date is often “immediately”) but from a business perspective we don’t really need it now and so we could schedule it at some time in the future. The Team should look at incoming work and try to figure out how to plan more work.
   - Establish a triage person. Often it is difficult for Teams to sit back from the barrage of inputs coming into the Team and, while we would like to get these in front of the PO for prioritization, perhaps the ticket really only will take a couple of minutes to do and there really is no benefit to creating a backlog item etc. Or perhaps there is some level of technical evaluation required to classify the item so the Product Owner can understand how to prioritize the work. Rather than have the whole team being driven by these interrupts, a common practice is to set up one person on the Team that functions this way. This allows the Team to focus their efforts. Another common practice is to make this a rotating position, so that one person doesn’t get burned out.   - Establish a triage person. Often it is difficult for Teams to sit back from the barrage of inputs coming into the Team and, while we would like to get these in front of the PO for prioritization, perhaps the ticket really only will take a couple of minutes to do and there really is no benefit to creating a backlog item etc. Or perhaps there is some level of technical evaluation required to classify the item so the Product Owner can understand how to prioritize the work. Rather than have the whole team being driven by these interrupts, a common practice is to set up one person on the Team that functions this way. This allows the Team to focus their efforts. Another common practice is to make this a rotating position, so that one person doesn’t get burned out.
Line 52: Line 52:
 Again, the idea is that the Team increasingly gets control of their work, and in particular their intake system, so that can structure that process to deliver value faster. As you get control of work you will typically find that more and more work can be planned which provides opportunities for Teams to improve delivery (see [[:how_do_we_deal_with_constant_interruptions|How Do We Deal With Constant Interruptions]] for more of this thinking). Pictorially this is represented as: Again, the idea is that the Team increasingly gets control of their work, and in particular their intake system, so that can structure that process to deliver value faster. As you get control of work you will typically find that more and more work can be planned which provides opportunities for Teams to improve delivery (see [[:how_do_we_deal_with_constant_interruptions|How Do We Deal With Constant Interruptions]] for more of this thinking). Pictorially this is represented as:
  
-{{  :wiki:getting_control_of_work.jpg?600  }}+{{  getting_control_of_work.jpg?600  }}
  
 (Thanks to [[https://twitter.com/stevenesanchez|https://twitter.com/stevenesanchez]] for this picture) (Thanks to [[https://twitter.com/stevenesanchez|https://twitter.com/stevenesanchez]] for this picture)
Line 83: Line 83:
   - Features for a quarter. After the Program and Teams prioritize all the Train features, Teams will bring what they think they can complete in a quarter given an understanding of their capacity and velocity.   - Features for a quarter. After the Program and Teams prioritize all the Train features, Teams will bring what they think they can complete in a quarter given an understanding of their capacity and velocity.
  
-====== Want To Know More ======+====== Want To Know More? ======
  
 While this discussion is written from the perspective of a Team operating in a Team-of-Teams (SAFe Program) context, in reality the thinking applies to just about all Teams as they kick-off. Lets face it, when we kick off a Team, most people on the Team have work that doesn't just simply go away so working Team scope and work intake system is something that should be done. And while the Team might not be operating in a Program, the considerations (improvement, understanding capacity, common modeling of artifacts, etc) are useful in any situation where there is more one Team operating. While this discussion is written from the perspective of a Team operating in a Team-of-Teams (SAFe Program) context, in reality the thinking applies to just about all Teams as they kick-off. Lets face it, when we kick off a Team, most people on the Team have work that doesn't just simply go away so working Team scope and work intake system is something that should be done. And while the Team might not be operating in a Program, the considerations (improvement, understanding capacity, common modeling of artifacts, etc) are useful in any situation where there is more one Team operating.
 +
 +Related information:
  
   * [[:how_do_we_deal_with_constant_interruptions|How Do We Deal With Constant Interruptions]]   * [[:how_do_we_deal_with_constant_interruptions|How Do We Deal With Constant Interruptions]]
 +  * [[How Do We Ensure Critical Work Does Not Get Dropped as We Kick Off Teams?]]
 +  * [[why_should_we_work_harder_to_eliminate_the_effect_of_dependencies|Why Should We Work Harder to Eliminate the Effect of Dependencies?]]
  
-Thanks to [[https://twitter.com/stevenesanchez|Steve Sanchez]] for his help in this materials.+Thanks to [[https://twitter.com/stevenesanchez|Steve Sanchez]] for his help with these materials.
  
 {{tag>FAQ Team SAFe ProgramManagement PIPlanning FirstSprint}} {{tag>FAQ Team SAFe ProgramManagement PIPlanning FirstSprint}}
  
  
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/how_does_a_team_initially_get_control_of_work.1537277213.txt.gz · Last modified: 2020/06/02 14:29 (external edit)