Assembling a Way-of-Working
Once practices have been separated, there needs to be some mechanism to compose the practices to form a team's way-of-working.
To enable the practices to be composed, we need a starting point—something that, although practice-independent, provides the basis for the definition and composition of practices. We call this starting point the "software development kernel" or, when using the cards and the card metaphor, the "software development game board." The kernel is a lightweight software development process, which, due to the absence of any concrete practices, is almost completely tacit. Many of the underlying concepts driving modern software development practices are embodied in the kernel. This isn't surprising, since all software development teams handle the same concepts and share the same mission—to develop good software. Having the practices share these common concepts is key to enabling them to be defined separately, yet be seamlessly composed together.
For example, the kernel contains the concept of the "specified system." Every project has to have a shared understanding of what the system is supposed to do—the system's requirements or specification, as it were. This understanding can take many forms and be communicated in many ways, and the kernel doesn't care how this is done—it just reminds you that it has to be done. There are many practices you could use to specify the system, anything from having a quick conversation with the customers to producing a formal system requirement specification. It is up to the team to pick the best practice to meet its—and its customers'—needs.
The kernel also contains the concept of a "backlog," a central concept in Scrum and other management methods. Working from a backlog and prioritizing the work it contains ensures that work is not lost. The presence of the backlog in the kernel lets the kernel be used to guide your software development, even when no practices have been selected. Again, just like specifying the system, how you address the work in the backlog is undefined and limited only by your creativity. Of course, there are practices to help you do this. The kernel provides the mechanism to link these practices together and focus the team on producing working software.
The kernel is the starting point for assembling a team's way-of-working. Practices can then be added to the kernel to assemble the team's way-of-working and make it explicit. Each practice brings its own approach to solving one of the problems of software development. For example, there are many ways of specifying the system to be built: You could use User Stories, Use Cases, or Declarative Requirements. Each of these approaches would be expressed as a different practice and define different things to produce and different things to do. This is illustrated in Figure 2, which shows how a number of different practices can fill the same "holes" in the kernel (in this case, the kernel elements are "specified system" and "specify the system").
At any point in time, the team can select a practice and compose it into its way-of-working. This results in existing cards and guidelines being augmented with the newly selected practices. The infrastructure then adjusts the tools and environment to reflect and support the new set of practices.
Using cards to help assemble and tailor the way-of-working is effective. Cards from the various practices can be compared, arranged, and annotated to provide a snapshot of the team's way-of-working. To compose the process from physical cards, you first identify the hole in the kernel you want to fill, then add one or more practices to fill the hole. Figure 3 shows how different requirements practices can be mixed-and-matched to define a specific way to specify the system.
Once the reasoning and negotiation has been completed, selected practices can be assembled within the electronic environment to capture the resulting way-of-working, and help the team apply the selected practices.
Local practices can easily be integrated into the way-of-working by creating additional cards to represent their products. This lets us align the team's actual way-of-working to the set of cards in use, and keeps the set of cards up-to-date. This provides an easy-to-use mechanism to prevent the project and process from getting out of sync.
