how_do_we_ensure_critical_work_does_not_get_dropped_as_we_kick_off_teams
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
Last revision | |||
— | how_do_we_ensure_critical_work_does_not_get_dropped_as_we_kick_off_teams [2018/09/18 07:17] – created hpsamios | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ===== How Do We Ensure Critical Work Does Not Get Dropped as We Kick Off Teams? ===== | ||
+ | |||
+ | ===== Premise ===== | ||
+ | |||
+ | One of the fears that many organizations have is that, as they "go Agile" and form Teams, important things will get dropped and things will get a lot worse for our customers before they start getting better. This is a well-founded business concern and needs to be addressed. The problem is that many organizations worry about " | ||
+ | |||
+ | * In many instances the people " | ||
+ | * In many instances the people " | ||
+ | * In many instances creating new procedures, handling the management of change required, working though the decisions and so on takes a long time. This means that while we are creating systems that might (probably) won't work, we are going to delay the formation of Teams (" | ||
+ | |||
+ | OK, so interesting, | ||
+ | |||
+ | ===== Guidelines ===== | ||
+ | |||
+ | When we form a Team one of the guideline that is suggested is that Team members "take their work with them" (see [[how_does_a_team_initially_get_control_of_work|How Does a Team Initially Get Control of Work?]] for other guidelines). In other words, if you were the " | ||
+ | |||
+ | Why do we do this? One reason is to ensure that we are increasing overall understanding of all the work that is happening in the team. But other reason is to ensure that we don't lose work. | ||
+ | |||
+ | As we form Teams we start to track work explicitly that the Team is working. We also typically also define a " | ||
+ | |||
+ | * Perhaps the scope of the Team is wrong and we need to adjust that. | ||
+ | * Perhaps the scope is correct, but the work needs to be transferred to a more appropriate place. | ||
+ | * Perhaps the work, given current prioritizes, | ||
+ | * Perhaps the work actually is not that important and we should not be doing it all. | ||
+ | |||
+ | Irrespective of what the outcome is, we need to ensure we know what we do with the work and we need to be explicit and visible in the outcome. In particular we need to insure that if the work is to be done by someone else, that we have a warm hand-off to ensure that this has actually happened. | ||
+ | |||
+ | The general approach determine disposition of the work via a set of filters: | ||
+ | |||
+ | - Should this work be done at all? If no, then inform however asked for it, and move on. | ||
+ | - Is this work within the current scope of the Team? | ||
+ | - If yes, then work through standard Team prioritization (typically through the Product Owner for the Team). Note that like all prioritization, | ||
+ | - If no, then determine who the work belongs to and have an explicit hand-over of not just this work, but also future work of this type. It will then be up to that Team to prioritize and schedule the work and work with stakeholders. | ||
+ | |||
+ | ===== Benefits of This Approach ===== | ||
+ | |||
+ | There are a number of benefits to using this approach to determine where work goes to: | ||
+ | |||
+ | * It is an incremental approach requiring no "big bang" upfront design of new processes (and so is actually an agile approach to the problem:-)) | ||
+ | * It respects existing ways " | ||
+ | * It begins the process of letting the people who do the work have the most say in how the work is done starting that very agile approach of " | ||
+ | * It can be done immediately, | ||
+ | |||
+ | ===== Want to Know More? ===== | ||
+ | |||
+ | * [[how_does_a_team_initially_get_control_of_work|How Does a Team Initially Get Control of Work?]] | ||
+ | * This is a use (modification? | ||
+ | |||
+ | {{tag> | ||
+ | |||
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_do_we_ensure_critical_work_does_not_get_dropped_as_we_kick_off_teams.txt · Last modified: 2020/06/02 14:22 by 127.0.0.1