Scrum and XP both explicitly involve the customer, Scrum with the Product Owner role, XP with the customer/business representative on the team. Lean Software Development emphasizes people are at its heart.

Scrum doesn't explicitly mention release planning, it assumes that the Product Owner will manage the backlog and the items nearest the top of the backlog are the ones of most value to the team. It assumes that the Product Owner will manage the backlog and the items nearest the top of the backlog are the ones of most value to the team.

Scrum and XP form batches of work using iterations. The following figure shows the Sprint Backlog—this is the batch in Scrum:

XP encourages its practitioners to err towards the smallest iteration possible. This stimulates incremental delivery thinking and moves teams away from the pitfalls of a mini-waterfall, where you execute a User Story in a series of handoffs just as you would a waterfall project.

Kanban doesn't make use of iterations to batch work. Instead, it focuses on flow; achieved by keeping each work item as small as possible and by limiting the work in progress so that people can focus on one task at a time.

It is designed to work with your existing process, and because of its value-driven mindset, it will start to shift the Development Team's thinking towards delivering something sooner rather than later.

The advantage of using Kanban at a more granular level, work item versus iteration, means that we can be even more adaptive and responsive to change. However, with great power comes great responsibility, and the Kanban approach does require more attention to detail.

For example, to remain this adaptive requires that the customer and team have an innate understanding of the overall objective and whether they are currently tracking towards it.

I often hear people discussing where and when you should use Scrum versus Kanban. For example, because of Scrum's history in product development, it seems the logical choice when developing a new software product or making significant enhancements to an existing one.

For most people, Kanban seems better suited to a more ad hoc backlog, where there is typically little or no coherency between work items. This is often the case when the product is in maintenance mode (some would call this BAU or business as usual). However, we shouldn't let Kanban's apparent simplicity fool us; of the two approaches, Scrum and Kanban, Kanban is probably the more nuanced.

As we'll see in Chapter 8, Tightening Feedback Loops in the Software Development Life Cycle, it can be used just as effectively as Scrum to build products, if not more so. Applying Lean thinking to product development increases flow and works particularly well when the top portion of the Product Backlog is prioritized and well defined.