Over the past few months I have spoken with people from a number of teams who have found themselves facing a large amount of uncertainty in their mission, their precise roadmap has been unclear, and the technical details of how to achieve it foggier still.
This is a common scenario for teams, particularly in start-ups where there is a significant rate of development (or growth) and a large amount of risk and uncertainty in the roadmap ahead.
Often, I hear these teams say that they should use Kanban because planning is difficult with such uncertainty. I can understand the logic and thinking that leads people to this conclusion, but I'd like to challenge it:
One of the rules of Scrum is that in each Sprint the team produces a potentially releasable increment [of product]. To achieve the Sprint Goal teams typically implement Product Backlog Items, but there is no requirement that PBIs be the only work that a team can complete, nor even that they are completed at all in achieving a Sprint Goal. It would be unusual, but conceptually a Sprint Goal could be achieved without a single PBI being done.
If we contrast this to a Kanban or continuous flow approach where the focus shifts towards progressing individual cards rather than the greater goal, we can start to see that Scrum is in fact ideally suited for environments where there are a lot of unknowns, and a lot of uncertainty.
If Kanban teams try and optimise their flow as you would expect a team practicing continuous flow to do (since WIP, cycle times and lead times would be key metrics), they will soon struggle as a consequence of the uncertainty and unknowns; it is difficult to achieve 'flow' when it's not clear what work needs to be done, or indeed how work can be done.
This leads to an interesting conclusion that would be echoed by many leading Scrum Masters worldwide; Scrum is ideally suited and intended for environments that are complex, and therefore have many unknowns. This is in stark contrast to the common view that scope is fixed within a Sprint.
It is this latter view that I believe leads many to defer to Kanban and continuous flow when there are many unknowns. The irony is that this leads teams to consistently choose a way of working that isn't suited to the problem space that they are in.
There is, however, a further level of uncertainty where not even a Sprint Goal can allow for the flexibility in scope required. This is particularly rife where there is no concept of a product, yet and so there's a lot of experimentation and trial-and-error in trying to build something that gains traction in a market.