Two Sides of the Same Coin
Karl Scotland explains why people and processes are equally important in software development.
One of the most valued statements from the Agile Manifesto is
“individuals and interactions over processes and tools”. This is
often abbreviated to “people over process” with a common
interpretation being that the human aspects of software development
are the primary areas we should be focussing on for improvement.
However, this is counter to the ideas of W. Edwards Deming, who
said “a bad process will beat a good person every time”. Similarly,
Don Reinertsen has said he prefers “people times process” because
if either is zero, then the product is zero.
People and process are two sides of the same coin, both equally
important in understanding how to improve capability to deliver
This side of the coin is about taking a group of people, who
form a team in order to develop a capability. Peter Senge wrote in
‘The Fifth Discipline’ that “the fundamental learning units in an
organisation are working teams (people who need one another to
produce an outcome)”. Creating teams in this way allows people to
iteratively learn about the way that they work so that they can
incrementally develop their capability in order to improve the
outcomes that they produce.
This is the basis of all the popular Agile methods such as Scrum
or Extreme Programming, which all recommend creating
cross-functional and co-located teams, collaborating with high
bandwidth communication. Thus, the people side suggests that
forming outcome-focussed teams, rather than activity-focussed
siloes, will result in an improvement.
This side of the coin is about taking a vision, which is
developed into a product in order to deliver value. Mark Denne and
Jane Cleland-Huang wrote in their book ‘Software by Numbers’ about
“an ROI-informed approach to software development in which software
is developed and delivered in carefully prioritized chunks of
customer valued functionality”.
Taking this approach means that a product will maximise its
value through being iteratively refined piece by piece in order to
incrementally deliver functionality.
This is the basis of Lean approaches such as Kanban, which
focuses on creating an explicit understanding of the process in
order to learn how to deliver valuable pieces of software more
effectively by modelling and visualising the work and associated
policies. Concepts such as Minimal Marketable Features and User
Stories help break down the work into smaller pieces. Thus, the
process side suggests that continuously delivering
small pieces of functionality with minimal delays, rather than
waiting to release large batches of features, will result in an
People and Process
It is when we put these two sides together that we can achieve
significant improvement. The iterative loops of learning about both
the team and the product link into each other, enabling product
value to rapidly flow through capability teams. This is the
development nirvana we are trying to reach.
This model also gives some insight into why the “Waterfall”
model, described by Winston Royce in his 1970 paper ‘Managing the
Development of Large Software Systems’, has proved to be
unsuccessful. It is not because the simple workflow described was
inherently wrong, but because the workflow has typically been
implemented with specialist siloes rather than capability teams,
and with large rather than small batches. It is both sides of the
coin that should be the focus of learning and improvement in order
to help us on our journey to the nirvana of product development