In the world of product development, the key factor in deciding an approach, Kanban, Scrum, Lean XP, whatever is the degree of complexity of the outcome you're trying to achieve. The Cynefin framework is a great visual aid for this - my favourite interpretation of it is this one:

In brief (very brief)

• Starting in the bottom right corner we have Simple work, where we are applying best practice because there are unlikely to be any surprises.

• Rotating anticlockwise we have Complicated work where we need to do some analysis.

• Then Complex where experimentation and user feedback is critical.

• And then Chaos where initially we just need to knee-jerk react in order to buy time to carry out the rest of the work in one of the previous three modes.

• There is also a time when Disorder reigns supreme - when you don't have enough information to understand what domain you are working within - here you need to gather information to enable you to categorise the type of work before starting.

Agile working operates best in the Complicated and even more so in the Complex domains, Waterfall working can operate well in the Simple domain. But when you’re tempted to think the work is Simple, ask yourself whether it really is, or whether your positivity bias may be misleading you - ask a colleague what they think. If in any doubt, Waterfall could be a serious trap to get suckered into at the start of the work.

In the Complicated domain, Kanban is often employed. Scrum is most commonly used in the Complex domain. But choosing your approach is also dependent on the size of your team (>9 could mean either Kanban working or scaling Scrum), how many teams you have (multiple could lead you to adopt LeSS), team maturity etc. And some approaches can be combined to a greater or lesser degree - Scrumban for example is Kanban, but with Scrum events being overlayed, largely for stakeholder management purposes.

Different frameworks have different characteristics that distinguish different ways of working for the team, users and stakeholders. At a very high level:

• Scrum / LeSS are PUSH models. The team commits to a certain body of work at the start of a Sprint, communicates to the users and stakeholders what they’re going to do and then do their best to do it. Each item of work moving from Backlog to Refined to Implementing to Done can be pushed, because the expectation is that the team will collaborate to ensure it all gets done.

• Kanban is a PULL model. There is a continuous flow of prioritised work and the focus is on throughput / cycle time. It’s basically an approach to creating the most effective (prioritised work) and efficient (shortest time from being started on to being completed) “production line”. There is therefore a similar emphasis on team work and collaboration - not to complete a body of work in a Sprint, but to ensure any work started is completed as quickly as it is feasible to do (anything else is regarded as “waste”). The pull element comes from the characteristic of the team alerting each other when they have completed an element of work such that when a teammate is available to work on it in the next stage of development they pull it into that stage (only when they are free to work on it). The time work spends waiting to be worked on is regarded as a non-value added stage in the process. Over time, the team identify where these non-value adding elements occur and take steps to reduce or remove them completely in order to increase speed of throughput.
  
  

The three pillars of Scrum

Open

The Scrum cycle

Iterative and incremental development