http:www.agilemodeling.comessaysagileSoftwareDevelopment.htm

1
http//www.agilemodeling.com/essays/agileSoftwareD
evelopment.htm
Agile is an iterative and incremental
(evolutionary) approach to software
development which is performed in a highly
collaborative manner by self-organizing
teams with "just enough" ceremony that produces
high quality software in a cost effective and
timely manner which meets the changing needs of
its stakeholders.
2
http//agilemanifesto.org/
Manifesto for Agile Software DevelopmentWe are
uncovering better ways of 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 contract negotiation Responding to change
over following a plan That is, while
there is value in the items on the right, we
value the items on the left more.
3
Principles behind the Agile Manifesto We follow
these principles Our highest priority is to
satisfy the customerthrough early and continuous
deliveryof valuable software. Welcome changing
requirements, even late in development. Agile
processes harness change for the customer's
competitive advantage.
4
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale. Business
people and developers must work together daily
throughout the project. Build projects around
motivated individuals. Give them the environment
and support they need, and trust them to get the
job done.
5
The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.
Working software is the primary measure of
progress. Agile processes promote sustainable
development.
6
The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential. The best
architectures, requirements, and designs emerge
from self-organizing teams. At regular
intervals, the team reflects on how to become
more effective, then tunes and adjusts its
behavior accordingly.
7
http//msdn.microsoft.com/en-us/architecture/bb404
166.aspx
Agile Development Agile methods are a set of
development processes intended to create software
in a lighter, faster, more people-centric way.
You may have heard of Extreme Programming, Scrum,
Dynamic Systems Development Method (DSDM),
Adaptive Software Development, Crystal, Feature
Driven Development and Pragmatic Programming that
have been appearing since the mid nineties, many
as a consequence of the need for alternatives to
more traditional heavyweight methodologies. In
2001, several of the most prominent proponents of
those "lightweight methodologies" started the
Agile Alliance and released the Agile Manifesto,
a statement of the values shared by them, for
those contemplating new agile development
processes.
8
Regardless of the chosen agile process, many
teams can benefit by using some core practices
(for example, frequent iterations, unit testing,
and refactoring). In this set of pages you'll
find guidance and ideas on how to set up your
agile environment using available Microsoft
technologies.
9
http//agilesoftwaredevelopment.com/
Nurturing the self-organizing team Scrum is a
team empowerment framework. Scrum is an agile
product management process that is based on the
clear separation of what's and how's - Product
Owner is responsible for what's, the development
team is responsible for how's. This clear
separation puts big bet on the team's ability to
self-organize and figure out what exactly process
and practices are best for it.
10
In my practice I've seen teams that gelled
successfully, communicated with their customers
frequently and were indeed able to self organize
to whatever was needed for the frequent delivery
of good software wanted by the customers.
However, I also experienced teams that are
struggling despite the credit from management.
Their Product Owner (or Product Owner teams) were
able to fix the product priorities for a sprint,
they did explicitly tell that they want less
features and more quality, they did allow their
teams to work on architecture as much as they
needed and still the quality wasn't on par with
the expectations. The testers tested according
to the scripts (and not according to what the
user might want do), POs often were able to find
obvious bugs during the sprint review demos, etc.
Despite all the trust credit these teams just
didn't self-organize.
11
http//steve-yegge.blogspot.com/2006/09/good-agile
-bad-agile_27.html