together the practices that best fit the
development task at hand and the
skills of the team members involved.
Further, when necessary, a team can
evolve its method in not only small
steps, but also more radical and bigger
steps such as replacing an old practice
with a better practice (without having
to change any other practices).
Note how the focus is on teams
and the practitioners in teams, rather
than “method engineers,” who create
methods for other people to carry out.
Creating their own way of working is a
new responsibility for a lot of teams,
however, and it is also necessary to
support a team’s ability to do this
across projects. It is also useful, therefore, to provide for groups interested
in creating and extending practices,
outside of any specific project, so they
can then be used as appropriate by
This can be seen as a separation
of concerns: practices can be created and grown within an organization, or even by cross-organization
industry groups (such as is effectively
the case with Extreme Programming
and Scrum); practitioners on project
teams can then adopt, adapt, and apply these practices as appropriate.
What assurance do project teams
have that disparately created practices
can actually be smoothly combined
to produce effective methods? This
is where a new software-engineering
foundation is needed, independent
of practices and methods but able to
provide a common underpinning for
The Kernel Is the Foundation
for Practices and Methods
The first tangible result of the SEMAT
initiative is what is known as the kernel for software engineering. This kernel can be thought of as the minimal
set of things that are universal to all
software-development endeavors. The
kernel consists of three parts:
˲ A means for measuring the progress and health of an endeavor.
˲ A categorization of the activities
necessary to advance the progress of
˲ A set of competencies necessary to
carry out such activities.
Of particular importance is having
a common means for understanding
6 In addition to the full kernel,
the Essence standard also defines
a language that can be used both to
represent the kernel and to describe
practices and methods in terms of
the kernel. Importantly, this language
is intended to be usable by practitio-
ners, not just method engineers; for
basic uses, it can be learned in just a
couple of hours (the alpha state cards
are an example of this).
Of course, this ability to use the
kernel to describe practices is exactly
what is needed as a foundation for
true software-engineering methods.
Practices Built on the Kernel
Enable Agile Methods
A practice can be expressed in terms
of the kernel by:
˲ Identifying the areas in which it
advances the endeavor.
˲ Describing the activities used to
achieve this advancement and the
work products produced.
˲ Describing the specific competencies needed to carry out these activities.
A practice can also extend the kernel with additional states, checklists,
or even new alphas.
The critical point is that the kernel
provides a common framework for
describing all practices and allowing
them to be combined into methods.
Bringing a set of practices into this
common system allows gaps and overlaps to be more easily identified. The
gaps can then be filled with additional
practices and the overlaps resolved by
connecting the overlapping practices
For example, consider two practices: one about using a backlog to
manage the work to be carried out by
a team (advancing the work alpha);
the other about defining requirements using user stories (advancing
the requirements alpha). The backlog
practice does not prescribe what the
items on the backlog must be, while
the user-story practice does not prescribe how the team should manage
the implementation of those stories.
The two practices are thus complementary and can be used together—
but, when so combined, they overlap.
The two practices can be connected in
a smooth and intuitive way within an
overall method by identifying backlog
how an endeavor is progressing. The
SEMAT kernel defines seven dimen-
sions for measuring this progress,
known as alphas. (The term alpha was
originally an acronym for abstract-lev-
el progress health attribute but is now
simply used as the word for a progress
and health dimension as defined in
the kernel. Many other existing terms
were considered, but all had connota-
tions that clashed with the essentially
new concept being introduced for the
kernel. In the end, a new term was ad-
opted without any of the old baggage.)
The seven dimensions are: opportuni-
ty, stakeholders, requirements, soft-
ware system, work, team, and way of
working. These alphas relate to each
other as shown in Figure 1.
Each alpha has a specific set of
states that codify points along the
dimension of progress represented
by the alpha. Each of the states has a
checklist to help practitioners monitor the current state of their endeavor
along a certain alpha and to understand the state they need to move toward next. The idea is to provide an intuitive tool for practitioners to reason
about the progress and health of their
endeavors in a common, method-in-dependent way.
One way to visualize the seven-di-mensional space of alphas is using the
spider chart1 shown in Figure 2. In this
chart, the gray area represents how far
an endeavor has progressed, while the
white area shows what still needs to
be completed before the endeavor is
done. A quick look at such a diagram
provides a good idea of where a project is at any point in time.
The alphas can be made even more
tangible by putting each of the alpha
states on a card, along with the state
checklist in an abbreviated form (see
Figure 3). The deck of all such cards
can then fit easily into a person’s pocket. Although more detailed guidelines
are available, these cards contain key
reminders that can be used by development teams in their daily work,
much like an engineer’s handbook in
A more complete discussion of the
kernel and its application is available
in previous work.
2, 3 The kernel itself is
formally defined as part of the Essence
specification that has been standardized through the Object Management