People and Processes are Equally Important

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
valuable software.


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

Karl Scotland is a versatile software practitioner with over 15 years of experience covering development, project management, team leadership, coaching and training. For the last 10 years he has been successfully applying Agile methods, and most recently has been a pioneer and advocate of using Kanban Systems for software development. Currently an Agile Coach with Rally Software in the UK, Karl is a founding member of the Lean Software and Systems Consortium and the Limited WIP Society, and has previously championed Agile and Lean Thinking with the BBC, Yahoo! and EMC Consulting. Karl writes about his latest ideas on his blog at
comments powered by Disqus