Software Development- The Agile Way

It is all about Common sense.

Audience: Development
Team

What is Agile
Group of software development methodologies based
on iterative development, where requirements and
solutions evolve through collaboration between selforganizing cross-functional teams.

History
Evolved in the mid-1990s as part of a
reaction against "heavyweight"
methods.
Heavily regulated, regimented, micromanaged use of the waterfall model of
development.
Initially, agile methods were called
"lightweight methods."
Common Methods: Scrum (1995),
Crystal Clear, Extreme Programming
(1996), Adaptive Software
Development, Feature Driven
Development, and Dynamic Systems
Development Method (DSDM) (1995)

History
In 2001, 17 prominent figures, at the
Snowbird ski resort in Utah, coined the
terms "Agile Software Development"
and "agile methods", and they created
the Agile Manifesto.
Later, The Agile Alliance, a non-profit
organization that promotes agile
development.
In 2005, Alistair Cockburn and
Jim Highsmith gathered another group
of peoplemanagement experts, this
timeand wrote an addendum, known
as the
PM Declaration of Interdependence.

The Values behind the Agile Manifesto

Individuals and interactions

over processes and tools
Working software over
comprehensive documentation
Customer collaboration over
contract negotiation
Responding to change over
following a plan

The principles behind the Agile Manifesto

Customer satisfaction by rapid, continuous
delivery of useful software
Working software is delivered frequently
(weeks rather than months)
Working software is the principal measure of
progress
Even late changes in requirements are
welcomed
Close, daily cooperation between business
people and developers
Face-to-face conversation is the best form of
communication (co-location)
Projects are built around motivated
individuals, who should be trusted
Continuous attention to technical excellence
and good design
Simplicity
Self-organizing teams
Regular adaptation to changing
circumstances

Problems with Suitability of agile methods

Large scale development efforts (>20
developers), though scaling strategies
and evidence to the contrary have been
described.
Distributed development efforts (non-colocated teams). Strategies have been
described in Bridging the Distance and
Using an Agile Software Process with
Offshore Development
Command-and-control company
cultures.
Forcing an agile process on a
development team

Agile methods / practices

Agile methods

Agile Modeling
Agile Unified Process (AUP)
Agile Data Method
DSDM
Essential Unified Process (EssUP)
Extreme programming (XP)
Feature Driven Development (FDD)
Getting Real
Open Unified Process (OpenUP)
Scrum
Lean software development

Agile practices

Test Driven Development (TDD)

Behavior Driven Development (BDD)
Continuous Integration
Pair Programming
Planning poker
RITE Method

Agile Modeling (AM)

Core Practices:
Active Stakeholder Participation
including direct users, their management,
senior management, operations staff, and
support (help desk) staff.
Model With Others.
Apply The Right Artifact(s).
UML diagram/ER diagram
Iterate To Another Artifact.
Prove It With Code.
Use The Simplest Tools.
Model In Small Increments.
Single Source Information.

Agile Modeling (AM)

Collective Ownership.
Create Several Models in Parallel.
Create Simple Content.
Depict Models Simply.
Display Models Publicly.

Supplementary Practices:
Apply Modeling Standards.
Apply Patterns Gently.
Discard Temporary Models.
Formalize Contract Models.
Update Only When It Hurts.
References:
http://www.agilemodeling.com/practices.htm

Scrum

Iterative incremental framework for

managing complex work (such as
new product development)
commonly used with agile software
development

Key Terms
Product owner
Projects key stakeholder and represents
users, customers and others in the
process.
Scrum Master
Responsible for making sure the team is as
productive as possible.
Product backlog
Prioritized features list containing every
desired feature or change to the product
Sprint: Time-boxed period of software
development focused on a given list of
goals (but with variable scope).

Meetings
Daily Scrum /the daily standup
During the meeting, each team member answers three
questions:
What have you done since yesterday?
What are you planning to do today?
Do you have any problems preventing you from accomplishing
your goal?

Scrum of scrums
Each day normally after the daily scrum.
These meetings allow clusters of teams to discuss their work,
focusing especially on areas of overlap and integration.
A designated person from each team attends.

The agenda will be the same as the Daily Scrum, plus the
following four questions:

What has your team done since we last met?

What will your team do before we meet again?
Is anything slowing your team down or getting in their way?
Are you about to put something in another teams way?

 Sprint Review Meeting

Review the work that was completed and not
completed
Present the completed work to the stakeholders
(a.k.a. the demo)
Incomplete work cannot be demonstrated
Four hour time limit

Sprint Retrospective
All team members reflect on the past sprint
Make continuous process improvements
Two main questions are asked in the sprint
retrospective: What went well during the sprint?
What could be improved in the next sprint?
Three hour time limit

Burn down
Graphical representation of work left to do
versus time.
The outstanding work (or backlog) is often on
the vertical axis, with time along the horizontal.

Burn down Types

sprint burndown chart

Release Burndown Chart
Alternative Release Burndown
Chart

General practices of Scrum

The following are some general practices of Scrum:

Customers become a part of the development team (i.e.,

the customer must be genuinely interested in the output).
Scrum has frequent intermediate deliveries with working
functionality, like all other forms of agile software
processes. This enables the customer to get working
software earlier and enables the project to change its
requirements according to changing needs.
Frequent risk and mitigation plans are developed by the
development team itselfrisk mitigation, monitoring and
management (risk analysis) occurs at every stage and with
commitment.
Transparency in planning and module developmentlet
everyone know who is accountable for what and by when.
Frequent stakeholder meetings to monitor progress
balanced dashboard updates (delivery, customer,
employee, process, stakeholders)
There should be an advance warning mechanism, i.e.,
visibility to potential slippage or deviation ahead of time.
No problems are swept under the carpet. No one is
penalized for recognizing or describing any unforeseen
problem.
Workplaces and working hours must be energized
Working more hours does not necessarily mean
producing more output.

Scrum Methodology

An other view(SCRUM Methodology)

SCRUM Phases
SCRUM has the following groups of phases:
1.Pregame
2.Game
3.Postgame
Pregame
Planning : Definition of a new release based on
currently known backlog, along with an
estimate of its schedule and cost. If a new
system is being developed, this phase consists
of both conceptualization and analysis. If an
existing system is being enhanced, this phase
consists of limited analysis.
Architecture : Design how the backlog items
will be implemented. This phase includes
system architecture modification and high level
design.

SCRUM Phases

Game
Development Sprints : Development of new
release functionality, with constant respect
to the variables of time, requirements,
quality, cost, and competition. Interaction
with these variables defines the end of this
phase. There are multiple, iterative
development sprints, or cycles, that are
used to evolve the system.

Postgame
Closure : Preparation for release, including
final documentation, pre-release staged
testing, and release.

Planning
Development of a comprehensive backlog list.
Definition of the delivery date and functionality
of one or more releases.
Selection of the release most appropriate for
immediate development.
Mapping of product packets (objects) for backlog
items in the selected release.
Definition of project team(s) for the building of
the new release.
Assessment of risk and appropriate risk controls.
Review and possible adjustment of backlog
items and packets.
Validation or reselection of development tools
and infrastructure.
Estimation of release cost, including
development, collateral material, marketing,
training, and rollout.
Verification of management approval and
funding.

Architecture/High Level Design

Review assigned backlog items.
Identify changes necessary to implement
backlog items.
Perform domain analysis to the extent
required to build, enhance, or update the
domain models to reflect the new system
context and requirements.
Refine the system architecture to support
the new context and requirements.
Identify any problems or issues in
developing or implementing the changes
Design review meeting, each team
presenting approach and changes to
implement each backlog item. Reassign
changes as required.

Development (Sprint)
The Development phase is an iterative
cycle of development work. The
management determines that time,
competition, quality, or functionality are
met, iterations are completed and the
closure phase occurs. This approach is
also known as Concurrent Engineering.
Development consists of the following
macro processes :
Meeting with teams to review release plans.
Distribution, review and adjustment of the
standards with which the product will
conform.
Iterative Sprints, until the product is
deemed ready for distribution.

Development (Sprint)
Each Sprint consists of one or more teams performing
the following:
Develop: Defining changes needed for the
implementation of backlog requirements into
packets, opening the packets, performing domain
analysis, designing, developing, implementing,
testing, and documenting the changes. Development
consists of the micro process of discovery, invention,
and implementation.
Wrap: Closing the packets, creating a executable
version of changes and how they implement backlog
requirements.
Review: All teams meeting to present work and
review progress, raising and resolving issues and
problems, adding new backlog items. Risk is
reviewed and appropriate responses defined.
Adjust: Consolidating the information gathered from
the review meeting into affected packets, including
different look and feel and new properties.

Development (Sprint)
Each Sprint is followed by a review, whose
characteristics are:
The whole team and product management are
present and participate.
The review can include customers, sales, marketing
and others.
Review covers functional, executable systems that
encompass the objects assigned to that team and
include the changes made to implement the
backlog items.
The way backlog items are implemented by
changes may be changed based on the review.
New backlog items may be introduced and
assigned to teams as part of the review, changing
the content and direction of deliverables.
The time of the next review is determined based on
progress and complexity. The Sprints usually have a
duration of 1 to 4 weeks.

Closure

When the management team feels

that the variables of time,
competition, requirements, cost, and
quality concur for a new release to
occur, they declare the release
closed and enter this phase. This
phase prepares the developed
product for general
release.Integration, system test, user
documentation, training material
preparation, and marketing material
preparation are among closure tasks.

Comparison of methods

Key Terms

Velocity:
The amount of work that you can do in
each iteration
How much product backlog effort a team
can handle in one sprint.

Impediment
Anything that prevents a team member
from performing work as efficiently as
possible.

Estimation Using Scrum

Involve everybody you think would be part of
the project.
The first step is to break your requirements
into user stories.
User stories is a piece of functionality which
has a functional flow and can be delivered.
User stories are simple, clear, brief
descriptions of functionality that will be
valuable to either a user or purchaser of a
product
User stories: help deferring details till later
They talk problems not solutions They fit
nicely as your Product Backlog items

Scrum Planning
The two levels of planning
Strategic level / Story level / product backlog
Tactical level / Task level / spring backlog

Estimation method

Example

Support in MS visual studio 2008

http://channel9.msdn.com/pdc2008/T
L09/

Support in MS visual studio 2010

A special template is provided to

follow Scrum

Drawback of Agile

No process is guaranteed to
work straight out of box.

References

http://www.agilemanifesto.org
http://agilesoftwaredevelopment.com
http://www.agilesecrets.com/
http://www.agile-softwaredevelopment.com
http://www.agilemodeling.com/
http://www.agilemodeling.com/
http://scrumforteamsystem.com
http://www.agilejournal.com
http://www.youtube.com/view_play_list?
p=E5EAAE9043D08AB4

Further Discussion

A soft copy will be available at:

http://softarchitect.wordpress.com
For Future discussion, join
http://tech.groups.yahoo.com/group/So
ftArchitect/