|
|
|
|
|
|
Agile software development is a programming
and project management approach which provides:
- Rapid delivery of production-quality code through
a higher quality of communication and focus.
- A communication model which earns a rare level of
trust between management and development teams.
- Fully tested and documented, production-quality
code delivered incrementally like clockwork.
- Delivery cycles typically of only 1 to 4 weeks -
I prefer 1 to 2 weeks - which drives the rate of
learning and potential ROI.
Key Concepts
- Agile is an umbrella term for the ideas of an
evolving collection of authors, consultants and
practitioners. Their shared goal is to improve the
traditional software development process which is
widely understood to be dysfunctional.
Agile commonly includes Lean, Scrum, XP and other
popular brands. For more information see
The Agile Alliance and
The Agile Manifesto.
The Agile Manifesto and Agile software development,
I find are best understood through one critical
distinction:
Software Development is more like R&D than
manufacturing or construction.
R&D respects a discovery process while
manufacturing and construction respects consistency,
documentation and,
when Lean, very disciplined continuous improvement.
With that in mind, the big, upfront,
detailed software specification is typically a wasteful
planning exercise that confuses speculation with
valuable specification. You can't specify what is not
yet discovered. But such a specification continues
to be demanded by management because of a fallacious
standard of professionalism. When we can laugh at
such foolishness, we can appreciate the alternative
without defensiveness or fear of being considered
unprofessional. That is the heart of the challenge
in transforming into an Agile organization.
- Lean is a term derived from the Toyota Production
System (TPS) which has evolved over many decades and
today is the envy of all industries.
Lean software development is included under the
Agile umbrella as a foundation discipline.
Lean focuses on value, flow, elimination of waste,
optimizing the whole, transparent communication,
continuous improvement and more.
For it's application to software development, see
the works of Mary and Tom Poppendieck.
-- and --
"
Implementing Lean Software Development:
From Concept to Cash".
- Scrum, a metaphor from the game of Rugby, is a
framework for communication and focus among members
of a cross-functional, self-organizing and self-managing
creative team; also between that team and those paying
for their creativity - the other stakeholders.
Those stakeholders include business management and
customers.
The term was originally used in a 1986
Harvard Business Review article authored by two
Japanese academics to describe the way Japanese
electronics industry innovation was progressing so
rapidly. This metaphor was adopted by
Ken Schwaber and
Jeff Sutherland at Easel Corp. in 1993.
Scrum was introduced widely at OOPSLA in '95
and has become a worldwide phenomenon.
One of my students noted that it's just
"an interaction model". Indeed it is - it's an
interaction discipline that wraps good business
discipline and good engineering discipline.
Lean principles and practices derived from the ideas
of W. Edwards Deming provide much of that good
business discipline. And eXtreme Programming (XP)
principles and practices make a valuable contribution
to good software engineering discipline.
- Extreme Programming (XP) was coined and
popularized by Kent Beck, Ron Jeffries and others.
XP is a widely recognized Agile category comparable
only to Scrum in worldwide recognition.
It focuses primarily on best engineering practices
done in an iterative and incremental way.
This includes: pairing, test driven development/design,
continuous integration, automated continuous testing,
code review, code simplification, and much more.
A good resource for getting started with XP is:
Extreme Programming: A gentle introduction.
Also see the writings of Kent Beck.
- Kanban was introduced by David J. Anderson
at Corbis in 2006 as an Agile innovation for their
sustaining engineering activity. It changes
the Scrum/XP time-boxed iteration into a pipeline with
a flow of work tuned to the development team's capacity.
It simplifies some aspects that can fit situations like
he describes on his blog entry Kanban in Action.
Jeff Patton describes the Kanban approach and context
in more detail in Kanban Development Oversimplified.
|
|
|