WIP limits and the idea swarming around completing original commitments ARE compatible with the desire to promote continuous “flow”. Limits help promote focus on planned work (aside from things like hotfixes or emergencies) by setting “gates” to when work can be pulled into a sprint. That focus alleviates bottlenecks, identifies true throughput, and gives a more complete picture to what a team can do.
For example, Team X was pulling in an average of ~75% scope increase halfway through their sprint. That means that something was either not planned correctly or they just kept pulling in work when devs finished their part. Pulling in work is FINE (because it should be accounted for), especially if the sprint was originally planned within the velocity expectations for the team. BUT a team can’t keep pulling in work if the process is becoming backed up at some point. And, sometimes the new work was even getting done before the originally committed work was getting done!?! There has to be a point where we say “hold up… let’s clean things up before shoveling more on.”
I liken these observations to two things:
I order one pizza… but my pizza is late because the place decided to give me a free calzone too. And the calzone comes out first, potentially delaying the pizza that I ordered an expected in the first place.
Or I dug a hole to lay cement near a stream I have dammed-up which will need repaired in a couple of weeks. - I expect a certain amount of water to collect in the hole, and I have only one sump pump available to handle the water. But, my contractors decide it’s time to work on dam repairs - which is next on the list… but more water than my pump can handle rushes into the hole, and this delays the laying of the cement - causing a headache.
Some groups may or may not ever reach this type of a point of hard limits, swarming, etc. in the near future. But, what is important is that key players utilize tools and math (metrics) to drive and expand the conversation - showing that what is worked on is measured in numerous ways. HOW something is worked on, impacts iterative delivery and releases of a team(s). - Having these KPIs visible and complete shows the whole story and helps closely related feature teams level-set (rather than live in silos).
In all, in every framework… it isn’t about the process itself… but, the outcome of the process. A question could be: are we delivering effectively and then inspecting & adapting/adjusting the process to keep doing so?
Usable, timely, quality, and value delivery is what is most important. The process should create a clear and observable superhighway for teams to travel from idea/request to delivery.