Let’s
take a look at the typical Agile Software development workflow. First, we would
like to clarify what we mean by software development. Paulo has a BSc in Computer
Engineering, and a Msc in software Engineering, and all of us have been working with
software development for the last 16 years. You would think it would be easy for us
to describe what software development is. It turns out, though, that whenever we try
to explain what software development is, we use the terms “like” and “similar to”, or
we compare it to another industry.
This debate has been very good for software development. It has generated many new ideas on how to go about developing software , organizing teams, respecting people and evolving practices.
A
quick search about software development online (“software development is”, and “software development is not”) and we realize we are not alone:
Software
development is engineering…
Software
development is
mostly an art…
Software
development is science…
Software
Development is like Manufacturing…
Software
development is
a design activity…
Software
development is
similar to rock-climbing…
Software
development is,
and has always been, a religion…
Software
development is not
an engineering discipline…
Software
Development is not
Anarchy…
Software
development is not
science…
Software
development is not
like manufacturing…
Software
development is not
like many of the "hard" engineering disciplines…
Software
development is not
a simple process to be achieved in one day, it is a complex process…
Software
development is not
a Jenga game…
Software
development is not
a production or a manufacturing activity…
Software
development is not
a religious experience…
Software
development is not
an art…
Perhaps this indicates that software development means
different things to different people. There is nothing wrong with that.
Lately, our industry has been more inquisitive about
software development and the role of the software developer. Much of this is due to the Agile
movement. In the last decade eXtreme Programming, and more recently the
software craftsmanship movements have, in many ways, rekindled the debate about software development.
This debate has been very good for software development. It has generated many new ideas on how to go about developing software , organizing teams, respecting people and evolving practices.
Prior to the influence of Agile, Birrell, N.D 1985 ’s book APractical Handbook for Software Development has a concise definition for software development:
Software development is the process of creating a computer software. It includes preparing a design, coding the program, and fixing the bugs. The final goal of software development is to translate user needs to software product.
The
nice thing about his definition is that it does not compare software development with
something else: engineering, science, art, rock climbing or religion. But in
order to agree with the definition, you have to consider that coding
the program has many activities. For example, writing tests, automating, and integrating
are all part of coding the program. Similarly,
preparing a design is more than just the design of the system; it should also include the requirements
definition, user experience design, and even how to break the work into smaller
workable pieces.
The
problem with this definition is that it has a very narrow final goal: “The
final goal of software development is to translate user needs to software
product.” Similarly to Lean Thinking, we would rather look at the goal beyond the
simple building of a product. The goal is to enable continuous improvement of teams
and processes, in addition to delivering the software product.
In
Lean thinking this is the Kaizen
concept
(translated to English as “continuous improvement”). In Japanese language Kaizen means “change
for good”.
The authors of ScalingLean & Agile Development have a good description for Kaizen:
Kaizen is both a personal mindset and a practice. As a mindset, it suggests, “My work is to do my work and to improve my work” and “continuously improve for its own sake.” More formally as a practice, kaizen implies:1. Choose and practice techniques the team and/or product group has agreed to try, until they are well understood2. Experiment until you find a better way3. Repeat forever
 |  |  |
