Kanban ideas

We have been talking about Kanban a bit lately in other venues.
Let's talk about some key Kanban ideas in Scrum. Here.
1. Do the most important thing first.
In Scrum, we want the Product Owner to order the work (the PBIs or User Stories) mainly by Business Value.  (Yes, we talk about 'ordered' now, but this is mainly Business Value, looked at from the 'right' time dimension, not 'let's do the low BV things first.')
2. Pull
In Scrum, we only work on things that the PO has 'pulled.'  We don't do what we want, and hope it will sell.  We don't create 'excess' inventory.
Is this perfect?  Well, no. The ideal is that the PO has received an order from 'the customer.'  But this varies by business and by product.
But at least the PO, on behalf of the customer, says he wants it. Now.
3. Flow
Scrum has flow for each story. Anytime flow is stopped, as shown by the Scrum Board, then that impediment should be fixed.
It is true that flow stops for the 15 minute stand-up each day.  This is not really a problem.
How does Toyota do it?  Toyota (Taiichi Ohno) says that the Team must be in sync. As in crew, they must row in sync. That's his metaphor.  Scrum has the same concept, in part as shown in the Daily Scrum.  Toyota does not have 'every single minute' flow. In fact, Toyota is very famous for 'stop the line', where flow is purposefully stopped in a major way. To fix a defect.
So, Toyota and Lean are very mindful about when to have flow, and when to sacrifice flow for other values.
Using a Team that is in sync also enables greater flow. Example: If one person is stuck in any way, the other teammates are there for immediate help. And have every incentive to help, since they want the team to 'win' or be successful.  So, the team concept increases the flow.  Yes, there is a small 'price' perhaps in the Daily Scrum, but it is small compared to the benefit.
4. Minimize WIP
It is good for everything and everyone to minimize Work In Process (WIP). I won't try to explain here why that is so.
Scrum does this first by saying, one product backlog to one Team. And an ordered Product Backlog. And then, that the Team should choose for the Sprint the top items from the Product Backlog, but only so many as it can confidently do in a Sprint (whatever the Sprint length might be).
Some of the reasons for using a Sprint Planning Meeting for this are...
(a) to minimize disruptions during the Sprint,
(b) the inter-connectedness of pieces of work, so that the Team can choose stuff that is reasonably inter-connected, in such a way as to maximize the feedback at the end of the Sprint in the Sprint Review (demo) (we always get feedback...many reasons), and
(c) to allow 'chaos' in at the end of the Sprint. And a possible significant change of direction.
This last one also allows and encourages a serious re-think about the whole direction of the product. We _want_ significant mid-course corrections.  In part, based upon the feedback at the Sprint Review.
In addition, Scrum uses the Scrum Board to minimize WIP. Only the top story (PBI) or two should be in progress at any one time. If a story gets stuck, we can put it down, and pick up the next most valuable story.  But in any case, we minimize WIP.
***
I am quite impressed, as I think about it now, with all these Kanban ideas already in Scrum.  I will try to explain them more later.
And also explain how we might change the Scrum Board to be a slightly different Kanban board.