A Process With the Right Degrees of Freedom – the Lagom Process?

We have discussed a few times earlier the need to use the
right abstractions, or the right degrees of freedom, to solve a problem. The
best solution is something that exactly fits the problem domain, being it the
right size screwdriver, a software platform or a programming language. Often
times our languages, tools and platforms have too many – or even worse too few
- degrees of freedom and we have to put in extra work to compensate for the superfluous
or missing degrees. To quote from our earlier posts:

So
to generalize the “harmfulness” theory, we need to refer to the degrees of
freedom in the problem statement, in the domain intention. A programming
feature is harmful in proportion that it has more degrees of freedom than in
the domain intention that it is used to solve. By degrees of freedom we mean
the potential parametrizations (arguments, properties, attributes, or
parameters) for the abstraction and the gamut of their values. This latter is
determined by the parameter type: the range of possible parameter values can be
small for enumerated types, or very large, for example the “parameter” is a
statement list as in a loop. Harmfulness is related to excess degrees of
freedoms: more parameters than necessary, or larger parameter types than
necessary for the purposes of the problem intention.

We can expand this idea to also apply to the actual process
being used. If a process adds more steps, tasks, deliverables – in summary more
work – that is required, we think of the process as getting in the way and not
helping. The process is causing extra work, it causes errors, and it adds
complexity. In fact a lot of the processes that are popularized today is
actually compensating for missing degrees of freedom in other areas. We need to
work around the lack of power by copying information, reworking and repeating. For
example, because we have no good way to transfer the domain intentions between
the domain expert and programmer, the industry has come up with many ways to
compensate for this problem in the process. Examples include modeling,
customers on site, prototyping, iterative development, storyboarding, meetings,
specs, use cases and user stories to name just a few.

What are the right degrees of freedom for an ideal process? It
could be something that helps make the right tradeoff of change and progress. In
other words, when a change is needed, we not only allow the change, but also implement
the change in a way that ensures progress. Here we use “a change” fairly broadly.
From the dictionary:

A transformation or transition from one
state, condition, or phase to another

A change early in a project could be from an idea of a new
product to something tangible, for example a prototype. A change later in a
project could be to refine the functionality of a user interface. The tradeoff
between change and progress is important because we need to organize the work
so that every change also ensures progress. We
wrote earlier about a process idea from Christopher Alexander that is now
surfacing in a different field, namely architecture. Alexander suggests a new
type of process he refers to as “making” where the customer, architect and
builder are collaborating during the entire process and refines the degrees of
freedom continuously to make something that exactly fit the customer’s needs.

Jimmy Nilsson has
some similar ideas. He argues that Extreme Programming is sometimes perceived
as too rigid or too extreme. Rather, he suggests a “Lagom Process”.
(Lagom is a Swedish word that means something like “just right for this
situation”. He describes the process as “It’s
probably influenced by Agile, but it’s built up of the pieces that together
form a mix that is lagom for the team and project at hand. That’s it.”

On a similar topic, Jeremy and I met with Ivar Jacobson last week.
Ivar described how he is now rethinking
the whole Unified Process approach into something completely different. It is
clear that over the last few years it has been a challenge to separate the
domains, or concerns, of the Unified Process. Per Kroll,
who is responsible for the Rational Unified Processes, and his team is also trying
to address this. Reading the current process is like reading source code. We compared
source code in a previous
post to encryption – contributions from multiple separate domains are
intermingled together in the description – and the result is very hard to read,
understand and maintain. Ivar has some new ideas that separate the domains of
the practices from each other. A practice is described using a set of process
cards each including activities, competencies and artifacts. It is great to see
that separation of domains is also finding its way into process thinking. And
hopefully as we strive for radical simplification in the way we build and use
software, our processes will also be radically simplified.