Bringing a set of practices into this
common system also 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 together appropriately.
Governance and compliance. The
Essence kernel allows you to define
life cycles easily in a practice-independent way. Having a selection of
different life cycles is incredibly useful when tackling a domain as complex as the IoT—particularly when
the life cycles can be combined with
whichever set of practices the team
wants to use, ensuring that appropriate governance is applied without
compromising the other aspects of
the team’s way of working.
Using the Essence kernel makes
it very easy to assemble a number of
life cycles, each built using the same
building blocks but addressing a different context and containing its own
contextualized checkpoints. For example, Munich Re11 defined a family
of life cycles, each addressing a different context:
˲ Exploratory: A lightweight agile development life cycle for experiments,
proof of concept, and small creative
˲ Feature growth: A rigorous engineering life cycle to support rapid feature growth with a strong architectural
˲ Maintenance and small enhancements: A lightweight life cycle to enable
the continuous flow of small enhancements and bug fixes for a
fixed, funded period of time (
typically a year)
˲ Support: A support-focused life
cycle to aid in the transition be-
tween the development and support
The ability to capture checkpoints
and life cycles in a practice-indepen-
dent way is incredibly powerful. It lib-
erates the practices, allowing them
to be used where appropriate and not
constraining them to any predefined
type or style of development. It also
makes it possible to address the entire
Io T methods space with a minimal, ex-
tensible, evolving set of practices, and
allows teams to get the help they need
without compromising their agility or
Note that Essence is generic enough
to support a waterfall life cycle, as well
as agile approaches.
Building a practice library. It is easy
to see how the use of Essence would
readily allow the assembly of a comprehensive practice library containing all the practices needed for a particular domain in a way that empowers
teams to select just the practices they
need to build their methods. Over the
past few years, working in many areas of software development, including embedded systems, financial systems, telecommunications, modems,
and many other areas affected by the
IoT, Ivar Jacobson International (IJI;
start has built an Essence-based practice library). Its library caters to both
the craft and engineering ends of the
The practice library is constantly
evolving as more and more practices
are captured in the Essence language.
At press time, IJI has essentialized
close to 30 practices, including:
˲Agile essentials, such as daily
stand-ups, product ownership, and agile retrospectives,
˲Common agile practices such as
Scrum, user stories, and continuous flow,
˲Proven architectural practices
such as Use-Case 2.0, architectural essentials, and component-based development, and
˲ Life cycles such as the ones defined
by Munich Re, discussed earlier.
Parallel to these efforts, existing
methods such as dynamic systems development method (DSDM) and the
Unified Process are being essentialized.
8, 10 An essentialized method is
first structured in terms of its inherited practices, and then each practice
is essentialized without changing its
All of these practices are built on top
of the kernel and can be assembled to
prime the pump for the methods that
your teams will use. For example, organizations have used these practices
to create lightweight agile methods,
robust software engineering methods,
pull-based flow methods, and flexible
method families. They have been used
to create both agile and waterfall methods that share many of the same practices but apply them with a very different emphasis.
What is powerful here is that these
methods all share the same foundation and can adapt to changing circumstances by dropping and adding
practices. The methods can also share
practices, helping the teams—and the
software they produce—to align and
collaborate with one another.
To make the practices accessible
and easy to learn, they are all available
in card and electronic formats. Easy-to-use tools are available for practice and
card creation, for method composition and publication, and for practice
exchange and community building.
These tools make it easy to extend ex-
The new Object Management Group (OMG) standard Essence9 is designed to support
organizations and communities in becoming learning organizations with empowered
teams that own their own ways of working and share their practices.
In addition to liberating the practices by enabling them to play well together,
Essence does the following:
˲ Makes methods significantly lighter by focusing on the essentials.
˲ Helps teams measure progress and health in a method-independent way.
˲ Allows organizations to build a library of practices from which teams can select the
ones needed for a particular solution (some teams need a “big” method, while others
need only a small one).
˲ Helps organizations build “forever” learning organizations.
Essence provides a foundation for software engineering methods. This foundation
helps in two ways: enables teams to understand and visualize the progress and health
of their endeavors, regardless of their ways of working; and, allows teams to easily
share, adapt, and plug and play their practices to create the innovative ways of working
that they need to excel and continuously improve.
It guides developers in achieving measurable results and reusing their knowledge in
It helps executives lead programs and projects in balanced ways, without more
governance than necessary, and develop learning organizations.