The Judo way
The story was about a small tree in a strong wind. The strong wind could uproot big trees but couldn't do the same to small trees. How so?
The teacher explained that the small trees are flexible so they can bend and move with the wind, therefore the wind can never exercise it's full force on them. But the big trees aren't as flexible and their only way to take the force of the wind is to develop deeper roots, stronger trunks and branches. So you don't have to be a big strong tree to take on an opponent such as the strong wind if you can move with the wind.
This analogy completely flew over my 11 year old head at the time, but I remembered the story and came to understand it a few years ago.
The point of the story, and the philosophy of Judo, is to achieve maximum efficiency with minimum effort (similar to the Pareto principle or the 80/20 rule). The best way to do so is not to fight the incoming force but to use or steerer it in a direction that puts you in an advantageous position. The key to understanding the power of this philosophy is to understand that you can replace the word "force" with anything else, and to accept that an advantageous position might not be exactly what you want but a step in that direction.
In the case of the story, if your goal is to stay in the ground then it's much easier to be flexible and move with the wind. You could also develop deeper roots and a stronger trunk but that requires more effort than moving with the wind and eventually a stronger wind could come along and uproot you.
I've used this philosophy to attain personal, and professional, goals which range from losing weight to chaining our process at work - things I previously thought were too laborious to be practical.
For example, at work we use the Scrum methodology and it's not a good fit for us. The development team is increasingly unhappy about the work we do, and the time we get to work on things that aren't part of a sprint. So we read about other methodologies and composed a list of things we would like to borrow from them to improve our process.
We can't just change the process on our own, we have product managers and Scrum masters on which these changes depend on too. So how do we go about implementing those changes?
We could form a document and a slideshow, collect all the evidence and studies to support our proposed process changes, and present everything to management. They are rational people, they will understand and accept our proposal, right?
While this sounds reasonable I can tell you right away that it will most likely fail. And the worst part is that not only will your process be rejected but all the improvements that could be applied to the current process that are bundled with it will be thrown out as well.
The problem is that management often doesn't know, and can't understand, the price of this process - the tech dept piling on, the extra hours, the emergencies on a Friday night which could have been avoided, the endless planning meetings to hack around self imposed system limitations. They either don't see those problems, don't feel them directly, or think they are a badge of honor for you. Your team is shipping value, customers are happy, things get done, so why change something that works and introduce uncertainty the process?
The Judo way to do it would be to point out one issue the team felt during the last sprint at each retrospective meeting and propose the process improvement you want to solve it. This is using Scrum against itself - the retrospective meeting is here to solve process problems so the issues your raised have to be discussed and acted upon. If your solution is accepted, or something similar to it, you will be one step closer to your goal.