Can you Sprint when there are a lot of unknowns?

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.

Everything should be “pulled”; 3 top tips

Pull is often seen as an attribute of Kanban, but it’s something that needs to be present in almost every agile team, regardless of their chosen working practices.

As work progresses through the system — from a concept in somebody’s head to working software in front of the user — it needs to be pulled from one step to another.

It’s quite common though for work to be ‘pushed’ in some key areas. The impact that pushing work will have varies across teams and products, but it can be anticipated as being synonymous to pushing work in Kanban: amongst other things it risks creating bottlenecks while providing no guarantee that anybody even cares that the work is done.

Here’s three key areas to consider:
1. The development team pull work from the Product Backlog during Sprint Planning. Nobody, should have pre-selected the work prior to this session. This is of course distinct from prioritisation, which is the responsibility of the Product Owner, and any other backlog refinement activities.
2. Product Owners (and customers) should be pulling work to production. It may be the engineer who pushes the button, but it should be initiated by demand. If nobody is pulling the work then there is nothing to suggest that the work was valuable.
3. There is a caveat around information radiators, such as Sprint Boards or any progress updates that a Product Owner shares. Things should be transparent across the team and the business and this is unlikely to be achieved if information is only made public when it is explicitly asked for — in this case, the organisation’s value of openness and transparency is the pulling force. Transparency is a value, while ‘pull’ is a practice. Values should always trump practices.