Differences

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

--- how_do_we_deal_with_constant_interruptions [2018/09/18 06:12] – Fixed to be clear about planable vs truly unplanned hpsamios
+++ how_do_we_deal_with_constant_interruptions [2020/07/20 10:47] (current) – Improved readability hans
@@ Line 3: / Line 3: @@
 Or "How do I plan when all my work is cannot be planned?"
-====== Premise ======
+A base question 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”.
-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?”
-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” (defocuses, increase [[:how_do_we_control_work-in-progress_wip|WIP]], etc). The more of it that we can treat as planable, the better off we’ll be. But the problem is that most people don’t take the time to really understand what is truly unplanable. Work that comes from ticketing systems is often treated as “unplanable” 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.
-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?”
@@ Line 17: / Line 15: @@
 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?”
+  * “How do we triage (part of work intake process) to determine what goes through to “unplanable” versus what needs to be prioritized and planned?”
-  * “How much capacity do the teams have that we can plan for versus truly unplanned work?” and start allocating capacity to the different levels of work (in particular, planned vs unplanned work).
+  * “How much capacity do the teams have that we can plan for versus truly unplanned work?” We can then start to allocate capacity to the different levels of work (in particular, planned vs unplanned work).
-  * “How often do we need to meet to understand / schedule the priority (do WSJF etc) of plan-able work?”
+  * “How often do we need to meet to understand and schedule the priority of planable work?”
-  * And the most important question of all “What do we have to change to make more work plan-able, so we can improve delivery?”
+  * And the most important question of all “What do we have to change to make more work planable, 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 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:
-{{  :wiki:from_reactive_to_proactive.png?400  }}
+{{  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.