SCRAP can be teeny tiny too. Some version of this happens daily.
”I can’t get into the blahblah system - I don’t have access. I put in a request for access the other day.”
P: The request/support process (is this SCRAP? a nice example of “one man’s SCRAP….is another’s _____”)
A: That we can’t just reach out to people directly ←-there we go….A is the most common kind.
How many people does this happen to, how frequently, how much time is wasted? Add that shit up. At least think about that. The pile includes some boulders for sure, but many pebbles, and of sand.
SCRAP’s stealth is one of its powers. There is a section on this topic.
Great example. The SCRAP is created because the system has been optimized by the support team, not optimized for the delivery of value to the customer.
Here is a scenario that could result in an org in which the SCRAP paradigm was at work. For you, @TLooy , I have dropped in some OODA terms to show how if we have decided to use OODA as our model of adaptive behavior&learning (selecting a model for adaptive behavior&learning) is a part of the system of continual SCRAP eradication -Part III of the book). I have read a lot of Boyd stuff but you go far deeper so help me if this is off.
(Observe) Team identifies the problem (which we know is potential SCRAP) item related to the approval process. So the team has a potential SCRAP item in their team pile.
(Orient) The team makes sense of the SCRAP from their perspective. The SCRAP acronym is a diagnostic model (map) to make sense of what they observe, confirm that it is or isn’t SCRAP, what kind, etc. Since we have a collection of patterns, knowledge about the kinds and examples of SCRAP from elsewhere, it also acts as part of a compass - what we might target, and what might need escalation. In this example, there are at least 2 things jumping out: (a) the Process or Rule SCRAP they see via the delays and (b) the Assumptions they are making about it (e.g., that they can’t reach out to people directly and must wait)
(Decide) The team now, having made sense of the SCRAP, decide to do 2 things:
SCRAP report for the process or Rule SCRAP they see goes to the support team pile.
In their team, break the Assumption that they are making to solution at their level. They find a way to overcome the delay by calling up someone’s buddy in the support org (or countless other ways to not allow process to be a bottleneck)
(Act) They execute those 2 things.
The SCRAP report is added to the support team’s pile. Matybe something happens, maybe not. Over time that pile gets bigger, garnering more attention.
They test whether their tactical problem solving overcomes the blocker. If it works, they remember or record that practice for next time
btw- replace OODA above with your preferred model of good improvement/learning cycle.
I LOVE this video as it covers one of my pet peeves about lean done poorly. “value added activities” missing the ‘yellow bricks’ that he describes or how to deal with them. I love the bricks concept.
What you describe is more PDCA than OODA. PDCA is linear - planned and managed. It’s sufficient for complicated systems like manufacturing, but insufficient for complex systems.
OODA contains double loop learnings throughout. OODA is not really a decision making tool, it is primarily a re-orientation model. It’s Destruction/ Creation. It results in better decisions and outcomes, coming out of better aligned Orientations.
Within an organization where there is SCRAP, there is conflict or tension or waste. There is a mis-alignment of Orientations, of mental models or goals/objectives.
Thanks Tom- I started a focused discussion on how SCRAP and OODA might be used together, and offered 1 way. Would love your thoughts there and I will link this discussion in there. SCRAP and OODA - how do they relate?
Good discussion, this is a massive issue. My wife deals with it all the time at First American. But what Tom pointed out, couldn’t this also be a Structure issue? Because the Support team has their structure and they need everything tracked and processed, and don’t see a need to adapt or change. I guess it depends, if it’s the support team saying they want better SLA’s, etc.. and need to improve then it’s probably process or assumption. But if it’s the rest of the organization wanting change, it’s more likely structure. “Well our offshore team, has to do….” So if the offshore team isn’t meeting the needs of the organization, what other solutions? These type of things are interesting, and most likely it’s an issue that leadership doesn’t see as a true problem. “Well, just wait a few days…. t’s not a big deal” and the path of least resistance is to not push for change. It gives the person an excuse for not being accountable. “I couldn’t get it done in time because I didn’t have access.” - Definitely an interesting simple example, that shows the nuance and the need to have honest discussions to get to the root cause.
It takes me awhile to digest your posts here so sorry for the delay.
Here is my first pass at addressing my perception of the relationship between SCRAP and OODA:
SCRAP is the elimination of waste and the breaking of constraints within a system whereas the OODA is a multitasking, interrupt driven, double loop learning operating system used in eliminating SCRAP.
This shows me the importance of getting together in person to have deep and meaningful discussions to explore these issues. I want to hear more from your perspective
I’m looking forward to the things that @GeorgeSchlitz comes up with to enable powerful discovery sessions.