Differences

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

--- how_do_we_deal_with_constant_interruptions [2018/06/17 16:05] – Added "from reactive to proactive" hpsamios
+++ how_do_we_deal_with_constant_interruptions [2020/06/02 14:22] – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 ====== How Do We Deal With Constant Interruptions? ======
-A base I like to ask of newly formed teams is whether they have a feel for amount of work that is truly “interrupt driven” versus work that is “plan-able”.
+Or "How do I plan when all my work is cannot be planned?"
+====== Premise ======
+A base I like to ask of newly formed teams is whether they have a feel for amount of work that is truly “interrupt driven” versus work that is “planable”.
 The reason I ask this is that while people say they are reacting to trouble tickets “all the time”, what I have found in a practical sense is that while this might be true from the perspective of the source of work, it is not necessarily true in how we deal with the work. The real question we should start with is “how much of the work does the team do in a day that was unknown at the daily stand-up?” If it is one incident (on average) per day, that tells us something. Then expand the question to a week “how much of the work does the team do in a week that was unknown at the that Monday’s daily stand-up?”
-Unplanned work is “bad” (defocusses, increase [[how_do_we_control_work-in-progress_wip|WIP]], etc) so the more of it that we can treat as plan-able, the better off we’ll be. But the problem is that most people don’t take the time to really understand what is truly un-plan-able. Work that comes from ticketing systems is often treated as “un-plan-able” even though the work on these systems is mostly actually not. Truly un-plan-able results from “the system is down” type situations. Most work coming from a ticketing system can be addressed by providing a service level agreement of “response in X days / weeks” and so in reality is plan-able.
+Unplanned work is “bad” (defocuses, increase [[:how_do_we_control_work-in-progress_wip|WIP]], etc) so the more of it that we can treat as plan-able, the better off we’ll be. But the problem is that most people don’t take the time to really understand what is truly un-plan-able. Work that comes from ticketing systems is often treated as “un-plan-able” even though the work on these systems is mostly actually not. Truly unplanable results from “the system is down” type situations. Most work coming from a ticketing system can be addressed by providing a service level agreement of “response in X days / weeks” and so in reality is planable.
 But often you only hear a statement like “we have to deal with everything immediately”. This is statement is correct as far as it goes; the real question is “how?”
-If we start understanding how much is plan-able versus interrupt driven we can start answering questions like:
+====== Becoming More Proactive - Working to Increase Understanding of Work That is Planable ======
+If we start understanding how much is planable versus interrupt driven we can start answering questions like:
   * “How do we triage (part of work intake process) to determine what goes through to “un-plan-able” and what needs to be prioritized?”
@@ Line 16: / Line 22: @@
   * And the most important question of all “What do we have to change to make more work plan-able, so we can improve delivery?”
-In practice you will find that as you look at the intake system, you will probably find there are ways to make work plan-able:
+In practice you will find that as you look at the intake system, you will probably find there are ways to make work planable. You will find you can be more and more proactive about the work you are doing instead of just responding to each new item like it is a crisis. Pictorially:
+{{  from_reactive_to_proactive.png?400  }}
-{{ :wiki:from_reactive_to_proactive.png?400 |}}
+In many ways when you start thinking this way you will find that the more work is planable than at first you think. This will allow you to better shape the demand that comes into your intake system. One place I worked went from thinking that "nothing is plan-able" to understanding that they could plan about 65% of their work. This allowed the Team to get out ahead of the demand and really start investing in improvements. For example, they could reduce incidents by building quality in or build in resiliency through increased automation which in turn allowed them to increase the amount of work that was plan-able.
-In many ways when you start thinking this way you will find that the more work is plan-able than at first you think. This will allow you to better shape the demand that comes into your intake system. One place I worked went from thinking that "nothing is plan-able" to understanding that they could plan about 65% of their work. This allowed the Team to get out ahead of the demand and really start investing in improvements. For example, they could reduce incidents by building quality in or build in resiliency through increased automation which in turn allowed them to increase the amount of work that was plan-able.
+{{tag>FAQ WIP interruptions FirstSprint unplanned planable support}}
-{{tag>FAQ WIP interruptions FirstSprint support}}
-~~LINKBACK~~
-~~DISCUSSION~~