Channels ▼


Enough of Processes: Let's Do Practices: Part III

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").

[Click image to view at full size]

Figure 2: How different practices can achieve the same objectives.

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.

[Click image to view at full size]

Figure 3: Assemble your way-of-working.

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.