As we’ve seen in this chapter, there are a lot of similarities between Scrum, XP, and Kanban. No matter where we start as a team, most will start to combine the practices and thinking of one or more of these methods.

Sometimes we do it without realizing, for example, XP’s User Stories have become a universally accepted way to gather Agile requirements. Sometimes we do it explicitly because we want to enhance our Agile adoption with the benefits of a particular practice. An example is when Scrum teams enhance their workflow using Lean principles, something we’ll discuss in Chapter 8, Tightening Feedback Loops in the Software Development Life Cycle.

When we look at the practices that each method presents, we see a spectrum form. At one end of the spectrum, we have Kanban, a simple but nuanced approach for making work visible and then improving our workflow. At the other end, we have XP, where years of practical experience led the founders of that movement to insist on following a specific, disciplined approach.

XP can be too extreme for some as there are a lot of practices to adopt. This is why in his 2nd Edition book Extreme Programming Explained, Kent Beck re-categorized some of those disciplines as primary (ones we can introduce immediately) and others as a corollary (ones that we introduce later when we better understand the context for them).

Lean Software Development and Kanban could be seen as too light—just do what you're doing now, but make it visible and seek to improve it by continuously eliminating waste in our process. Sounds simple, but understanding and optimizing our system isn't as easy as it sounds and requires much practice.

Scrum can be seen as somewhere in the middle. It provides enough of a framework for people to start their journey to becoming great inspectors and adaptors. At the same time, it holds back from prescribing a huge change in technical practices that may cause change phobia.

So, start with Scrum and get used to incremental delivery. Then begin to apply good disciplines that bake quality in from the beginning rather than test for quality later. Do this by conducting a number of experiments to see what works for you in your context. We’ll look at how can do this in Chapter 7, Software Technical Practices are the Foundation of Incremental Software Delivery.

One final thought, we need to consider that most Agile frameworks focus on the delivery of software. Few include explicit phases, either at the beginning for the initiation of product ideas or at the end of release and deployment. We’ll cover techniques for both of these phases in this book, in Chapter 10, Using Product Roadmaps to Guide Software Delivery and Chapter 7, Software Technical Practices are the Foundation of Incremental Software Delivery respectively.