Agile manifesto - Agile - What is it?

Agile Manifesto
The meeting

Utah 2001

Who

The 17 people in attendance were Kent Beck, Mike
Beedle, Arie van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries,
Jon Kern, Brian Marick, Robert C. Martin, Stephen J.
Mellor, Ken Schwaber, Jeff Sutherland, and Dave
"Pragmatic" Thomas.

Motive

The reason we met was to see whether there was anything in
common between the various light methodologies: Adaptive
Software Development, XP, Scrum, Crystal, Feature Driven
Development, Dynamic System Development Method
(DSDM), and "pragmatic programming.” None of us was
interested in merging the practices to create a "Unified Light
Methodology (ULM)."

We Agreed On 4 Things

1. We agreed at the first level, on the need to respond to
change. We agreed that agile reflected our intent, and
permits discussion of heavier-agile methodologies for larger
and life- critical projects.
2. We agreed at the second level, on four core values, as
described in the manifesto.
3. We agreed at the third level (just barely), on twelve more
detailed statements consistent with those four values.
It was clear we would not agree on the fourth level, detailed
project tactics.
4. We agreed it was healthy for the industry, and to continue
to innovate and compete in the world of ideas, to discover a
larger set of agile software practices.

Agile Alliance Is Born
With the new agreements in place and the adoption of the
term agile, the 17 member Agile Alliance was officially born.
Successful Software Development
* The industry largely disagrees on the determinants of
success.
* Best Approach = Say What You Stand For

4 Choices

* Attend to people on team as individuals. Avoid talking to roles in the

process chart.
* Attend to interactions between individuals. New solutions come to life in
discussions between people. The quality of the interaction matters.
* We prefer to use an undocumented process with good interactions than a
documented process with hostile interactions.
* "Working software over comprehensive documentation."
The working system is the only thing that tells you what the team has built.
Running code is ruthlessly honest.

-Documents showing the requirements, analysis, design, screen
flows, object interaction sequences charts are handy as hints. The
team uses them as aids in reflecting on their own experience, to
guess what the future will look like. The documents serve as markers
in the game, used to build an image of the unreliable future.
-The result of gathering requirements, designing, coding, and
debugging the software, reveals information about the
development team, the development process, and the nature of
the problem to be solved.

-Those things together with the running final result provide the
only reliable measure of the speed of the team, the
shortcomings of the group, and a glimpse into what the team
really should be building.
-"Customer collaboration over contract negotiation."

NOTE
The third value describes the relationship between the
people who want the software built and those building the
software.
The distinction is that in properly formed agile development,
there is no "us" and "them," there is only "us."
Saying, "there is only us" refers to the fact that both are
needed to produce good software.

Collaboration
-Community
-Amicability
-Joint decision making
-Rapidity of communication.

Pays To Collaborate
-Good collaboration can save a contract situation when it is
in jeopardy.
-Good collaboration can sometimes make a contract
unnecessary. Either way, collaboration is the winning
element.

Agile Planning
“Building a plan is useful. Referring to the plan is useful until it
gets too far from the current situation. Hanging onto an
outdated plan is not useful.”

* "Responding to change over following a plan."

* The final value is about adjusting to fast-breaking project changes.
* Building a plan is useful, and each of the agile methodologies
contains specific planning Scrum, DSDM and Adaptive Software
Development call for time boxed development with reprioritization
after (not within) each timebox (XP allows reprioritization within the
timebox). The timeboxed periods are in the 2 - 4 week range. The
timeboxing guarantees that the team has the time and peace of
mind to develop working software. The relatively short development
phases, what Scrum calls "sprints," allow the project sponsors to
change priorities to match their needs.

Being Agile
The 100-Person Project Vs. The 10-Person Project

* Agile 100-person project uses a heavier methodology than
the agile 10-person project.
* It might be possible to drop 90 people from the 100-person
project, keep the 10 best people, and then run an agile 10person project that delivers the same system in the same time
frame.

* The point is that we agree that methodologies do not come
in ones or twos, but in dozens, each tuned to the situation
and project at hand, and each agile. This thought is not
captured in the Manifesto.
* Some of the people in the room recommend agile
methodologies primarily for high-flux situations. My
experience is that rude surprises pop up on even supposedly
stable projects.

“These are the sentences we agreed on, and my
commentary on each.” Alistair Cockburn

1. Our highest priority is to satisfy the customer through early
and frequent delivery of valuable software.

…We are interested in delivering software that is fit for purpose.

Agile development is focused on delivering
-Delivering early allows for quick wins and early feedback
about the requirements, the team, the process, as we have
seen throughout this book.

-Delivering frequently allows for continued wins for the team,
rapid feedback, and mid-project changes in project
direction and priorities.
-Duration used for deliveries needs to be negotiated on a
project-by-project basis, because delivering updates on a
daily or weekly basis can cause more disturbances to the
users than it is worth.

-This Statement emphasizes delivering those items that have
greatest value to the customers. With consumer mood
changes, intensive competition, and stock market swings, it is
nearly impossible to guarantee a revenue stream for a
project that takes a year or longer to deliver.

-This statement indicates that value will be delivered early, so
that in case the sponsors lose funding, they will not be left
with a pile of promissory notes, but with working software that
delivers something of value to the buyers.

2. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.

 If the users can accept changes every month, and the
development team can match the ongoing requests for
changes, then the shorter feedback cycle is better.

3. Working software is the primary measure of progress.

This principle puts it firmly
-Rely on the honesty that comes with running code rather than on
promissory notes in the form of plans and documents.
-You are welcome to use other measures of progress as well, but
working code is the one to bank on.
-Agile methodologies place a premium on getting something up
and running early, and evolving it over time.

In Model-Driven Development, two pieces of working code
must be demonstrated.
-One is the executable model, which is evaluated for fitness
to the user needs.
-The other piece of working code to be demonstrated is the
mapping algorithm that generates the final code. This one is
more easily overlooked. A number of projects created a
gorgeous executable model, and then couldn't get the
code-generation algorithm to work properly in time.

4. Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
Agile processes can take on late-changing requirements because
-Early and frequent delivery of running software,
-Use of iterative and timeboxing techniques,
-Continual attention to architecture
-Willingness to update the design.

If your company can deliver quickly and respond to latebreaking information, and your competitor's company can't,
then your company can out-maneuver your competitors on
the software front. This often translates to a major difference
in the marketplace.

5. Business people and developers work together daily
throughout the project.

5. Business people and developers work together
daily throughout the project.

-The industry is littered with projects whose sponsors did not
take the time to make sure they got what they needed.

-The word "daily" refers to the sweet spot, where discussions
are ongoing and on- demand. Daily discussions are not
practical on most projects, which means that the project is
not sitting at the sweet spot.
-The statement indicates that the longer the time to get
information to and from the developers, the more damage
to the project.

6. Build projects around motivated
individuals. Give them the environment and
support they need, and trust them to get
the job done.
-We would rather see motivated, skilled people
communicating well, and no process at all, than a welldefined process and unmotivated individuals.

-Individuals make projects work. Their motivation relates to
the pride-in-work, amicability and community on the project.

7. The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.

8. The best architectures, requirements, and
designs emerge from self-organizing teams.
-We insist that the architecture be allowed to adjust over
time, just as the requirements and process are.
-An architecture locked down too hard, too early, will not be
able to adjust to the inevitable surprises that surface during
implementation and with changing requirements.
-An architecture that grows in steps can follow the changing
knowledge of the team and the changing wishes of the user
community.

9. Continuous attention to technical excellence
and good design enhances agility.
-A tidy, well-encapsulated design is easier to change, and that
means greater agility for the project.
-To remain agile, the designers have to produce good designs to
begin with - and -also have to review and improve their design
regularly, to deal with the better understanding of their design that
comes with time and clean up from when they cut corners to meet
a short-term goal.

MANAGING TECHNICAL DEBT
-Ward Cunningham sometimes compares cleaning up the
design with paying off debts. Going further, he discusses
managing the technical debt on the project.
-Making hasty additions to the system corresponds to
borrowing against the future, taking on debt. Cleaning up
the design corresponds to paying off the debt.

-Sometimes, he points out, it is appropriate to take on deb
and make hasty changes, in order to take advantage of an
opportunity. Just as debt accumulates interest and grows
over time, though, so does the cost to the project of not
cleaning up those hasty design changes.
-Cut corners in the design, he suggests, when you are willing
to take on the debt, and clean up the design to pay off the
debt before the interest grows too high.

10. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
There are two sides to this statement.
-One relates to social responsibility side,
-Second to project effectiveness.

-People tire as they put in long hours. Their rate of progress
slows, not just during their overtime hours, but also during their
regular hours. They introduce more errors into their work.

-Diminishing returns set in with extra hours. This is part of the
non-linearity of the human component.
An alert and engaged staff is more agile than a tired,
slogging staff, even leaving aside all of the social
responsibility issues.
-Long hours are a symptom that something has gone wrong
with the project layout.

11. Simplicity--the art of maximizing the amount of work not
done--is essential.
-Simplicity is essential. That much is easy to agree on. The
notion of simplicity is so subjective, though, that it is difficult to
say anything useful about it. We were therefore pleased to
find we could all sign up for this statement.
-In the design of development processes, simplicity has to do
with accomplishing while not doing, maximizing the work not
done while producing good software.
-Jon Kern reminds us of Pascal's remark: “This letter is longer
than I wish, for I had not the time to make it shorter.” That
comment reveals the difficulty of making things simple. A
cumbersome model is easy to produce. Producing a simple
design

“Simple, clear purpose and principles give rise to complex,
intelligent behavior.” that can handle change effectively is
harder. Complex rules and regulations give rise to simple,
stupid behavior.” Dee Hock

12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly.
It is fitting to end where we began. How light is right for any
one project? Barely sufficient, and probably lighter than you
expect.

Agile manifesto - Agile - What is it?

More Related Content

What's hot

Viewers also liked

Similar to Agile manifesto - Agile - What is it?

Recently uploaded

In this document

Agile manifesto - Agile - What is it?