Why Nine Practices

Scrum provided a minimal framework to support Agile development and Extreme Programming initially proposed twelve core practices.

I’ve distilled that down further into nine essential practices. The first two are what most people think of when they think of Scrum, and the last seven are specific technical practices. These nine practices are designed to help us think about software development in the right way, so we can break the cycle of big releases, which is very much against conventional wisdom.

The nine practices are as follows:

  1. Say What, Why, and for Whom Before How
  2. Build in Small Batches
  3. Integrate Continuously
  4. Collaborate
  5. Create CLEAN Code
  6. Write the Test First
  7. Specify Behaviors with Tests
  8. Implement the Design Last
  9. Refactor Legacy Code

They say people can hold in their heads seven, plus or minus two things at one time, so nine things are about the most anyone can remember. Nine things are also about as much room as I have in this book. These nine practices are the ones I’ve found to be of the highest value but are also the most poorly understood and often misapplied.

You don’t have to adopt all nine practices, but you do have to understand their purpose. If you have other ways to mitigate the issues one of these practice addresses, then you can safely replace that practice. But just like Picasso, you must understand the rules before you can safely break them.

You may notice a common theme throughout these nine practices that suggests building out verifiable behaviors. This helps keep development focused on building the right things and on doing it in a way that’s easily verifiable and supports changeability in the future.

These nine practices help streamline the software development process while still supporting the creation of changeable code. Of course, there are many other practices that support writing changeable code, but these nine provide a solid foundation and a good start for dropping the cost of building and maintaining software.

My goal for this book is to help you think effectively about building software so you can build it more efficiently and your software will be easier to extend later.