AGIL

The Agile Manifesto was signed in 2001 by a group of 17 developers.

They came together to articulate and define the common ground
between improved ways of developing software.

What is agile?
Agility is the ability to respond rapidly to
change. In the case of a footballer, that means
changing direction and position while
maintaining balance and control. When it
comes to software development, agility is
just as desirable. Organisations need to
be flexible in their plans, able to respond
swiftly to opportunities and threats and
pivot in response to feedback.
At the software engineering level,
agile practices all emphasise flexibility
in the face of relentless change: evolving
requirements, fast feedback loops, cross-
functional teams, iterative development
and incremental delivery.
Agile ways of working developed in
response to problems with traditional
project management and development
methods. In the second half of the 20th
century it became clear that software
development was not keeping pace
with business necessity and changing
circumstances. IT projects were being
delivered too slowly, at too high a cost
and with disappointing results. Methods
that attempted to fix cost, time and scope
merely seemed to make the problems
even worse.
In response to this, several companies
began using iterative delivery and just-
in-time planning. These lightweight
methods were developed and refined
and came to be known as 'agile'. The
term is a fairly elastic one, embracing
a broad family, including Scrum, XP
and others (see the Agile timeline).
These have waxed and waned in
popularity, evolved, shifted, combined
and influenced one another. The agile
journey is still in progress and there will
unquestionably be new influences to
develop and explore.

06 ITNOWJune2013

The manifesto went on to describe 12
principles that enshrine delivering value
early and often, using feedback to respond
to change and focusing on quality.
in particular, the manifesto emphasised
that software involves people, and
therefore requires communication and
collaboration as much as excellence of
engineering.
The Agile Manifesto never set out
to prescribe how any of this should be
achieved, leaving practical interpretations
to others.
That explains why 'agile' has become
an unnbrella term sheltering a range of
methods.
An agile timeline
1985
Tom Gilb develops EVO, stressing short
cycles, incremental delivery and fast
feedback.
1986
Barry Boehm works on Spiral, attempting
to combine waterfall with iterative
development.
1990
Rapid Application Development (RAD), a
process involving iterative development
and prototyping, documented in a book by
James Martin.
1992
The Crystal family of methodologies was
described and defined by Alastair Cockburn
Agile Manifesto
We are uncoverinc
developing software by doing it
and helping others do it.
Through this work we have
come to value:
Individuals and interactions over
processes and tools
Working software over
comprehensive documentation
Customer collaboration over con-
tract negotiation
Responding to change over
following a plan
That is, while there is value in the
items on th( • ' •
items on thf
to explain the working practices of
successful teams in software development.
1994
An association of software engineers
decided to create a structured,
independent framework for RAD, which
they called Dynamic Systems Development
Method (D5DM)
1995
Ken Schwaber and Jeff Sutherland present
a paper on Scrum methodology,
discussing advanced development
methods tried at their companies. A fuller
description is published in 2001 Agile
Software Development with Scrum
1996
Rational Unified Rrocess (RUP) became an
June 2013 ITNOW 07

explicit process framework with six best
practices: iteration, requirements
management, component-based
architecture, modeling, quality and change
control.
1997
Feature Driven Development (FDD), a
model-driven process with short iterations,
is developed by Jeff De Luca to help a
Singapore bank project. It is described
in its fully developed form in a 2002
book: A Practical Guide to Feature-Driven
Development.
1999
Kent Beck publishes Extreme Programming
Explained, discussing his work with the C3
team at Chrysler where the team pioneered
process and engineering innovations.
2001
The Agile Manifesto is signed at a
meeting in Utah by 17 developers. Some
of the authors went on to form the Agile
Alliance, a not-for-profit organisation that
promoted software development methods
in accordance with the manifesto's
principies.
2003
Mary and Tom Poppendiek publish Lean
Software Development: An Agile Toolkit
presenting the Lean principles developed
by the Toyota Production System and
applying them to software development.
2007
Kanban is first discussed during an open
session at Agile 2007 describing an
implementation that took place the year
before at Corbis. David Anderson's book
Kanban - Successful Evolutionary Change
for your Technology Business was
published in 2010.
2009
Eric Ries speaks on the development
methods he evolved during his work at
IMVU (and at previous start-ups), relating
software deployment to a 'Minimum Viable
Product' from which businesses can develop
better products through feedback from
customers. His book The Lean Start Up is
published in 2010.
08 ITNOW June 2013
Kanban has five core principles, and benefits
include improvement in lead time, frequent
delivery and a reduction in defects.
Focus on XP
XP takes its name from taking existing best
practices within software
development and pushing them to the
'extreme'. XP intends to produce higher
quality software with fewer defects and at
a lower cost. It relies upon a working team,
a high level of self-discipline and frequent
contact with a customer or customer
representative who can help translate
ideas into something developers
understand.
It explicitly links its values and principles
to a series of practices. As Kent Beck
wrote: 'Values bring purpose to practices,
practices bring accountability to values.'
Five values: communication, simplicity,
feedback, courage, respect
Practices: simple design, refactoring,
TDD, pair programming, collective code
ownership, coding standards, continuous
integration, sit together, informative
workspace, sustainable pace, user stories,
acceptance tests, weekly and quarterly
planning cycles, feedback cycles.
Focus on scrum
Scrum calls itself 'a process framework
within which small teams can design and
sustain complex products to deliver the
highest value effectively'. It's a complicated
dressing up of a much simpler idea -
delivering working software every 30 days.
The cycle of delivery is known as the
'sprint', set to a maximum of 30 days.
The cross-functional development team
commits to what they will be able to deliver
by the end of the sprint. A product owner,
who represents the customer, creates a
product backlog of valuable work in priority
order and accepts or rejects the team's
work in a formal sprint review.
A scrum master assists the team,
runs the process, daily stand-ups and the
retrospective in which the team reflect on
how they are working rather than the work
itself.
Focus on Kanban
Kanban was part of the Toyota Production
System developed in the 1950s. David
Anderson borrowed the idea from
manufacturing and applied it to software
development.
The idea of a visual, pull system was
summarised by Corey Ladas as, 'Don't
write more specs than you can code. Don't
write more code than you can test. Don't
test more code than you can deploy'
Kanban can be implemented easily and
quickly by teams and is explicitly promoted
as evolutionary change. As originally
defined, Kanban has five core principles,
and benefits include improvement in lead
time, frequent delivery and a reduction in
defects.
Visualise workflow
Limit work in progress
Measure and manage flow
Make process policies explicit
Use models to recognise
improvement opportunities.
Focus on lean
Borrowing from the lean ideas developed
for manufacturing, lean software
development focuses on seven principles:
eliminate waste: amplify learning: decide
as late as possible: deliver as fast as
possible: empower the team: build integrity
in: see the whole.
The founding principle, supported by the
others, is eliminating waste. This means
removing everything not valuable to the
customer: unnecessary code, defects, delay
and bureaucracy.
This improves quality and flow, helping
the team (sometimes called the 'work-cell')
deliver quality software more rapidly.
There are various tools which assist the
team in carrying out these principles, from
value stream mapping to queuing theory
and pull systems.
The theory is summed up with the
slogan, 'think big, act small, fail fast: learn
rapidly'.
Copyright of ITNOW is the property of Oxford University Press / USA and its content may
not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's
express written permission. However, users may print, download, or email articles for
individual use.