• Agile methodology is an approach to project management

• Agile methods attempt to minimize risk and maximize productivity by

developing software in short iterations
• Scrum is a simple approach to the management of complex problems,
providing a framework to support innovation and allow development teams to
deliver high quality product in short time-frames.
• Scrum is a way of thinking that unleashes the creative spirit

Empiricism refers to the continuous inspect/adapt process that allows both workers
and managers to make decisions in real time, based on actual data, and as a result
respond quickly to ever-changing conditions in the surrounding environment, most
importantly the market place in which the software is sold or distributed.

Emergence results from an empirical approach. It implies that all solutions to all
problems will become clear as we work. They will not become clear if we simply talk
about them. Big Up Front Design will only result in Big Wrong Design or at best Big
Working But Totally Inflexible Design. When we allow solutions to emerge it is
always the simplest and the most appropriate solution for the current context that rises
to the surface. Emergence coupled with Empiricism will lead us to the most
appropriate and the most flexible (i.e. changeable) solution.

Self-organization refers to the structure of the teams creating the product of work.
Small multidisciplinary teams are empowered to make the important decisions
necessary to i) create high quality product and ii) manage their own processes. The
thinking here is that those doing the work know best how to do the work. These teams
work in a highly interactive and generative way, emerging the product through
continuous dialog, exploration and iteration. Self-organization works when there are
clear goals and clear boundaries.

In addition to these principles Scrum relies on two core mechanisms: prioritization

and timeboxing.

Prioritization simply means that some things are more important than others. This is
obvious, yet quickly forgotten when the “we need it all now” mindset is entered.
Scrum helps put the focus back on selecting the most important things to do first —
and then actually doing them! Making time to prioritize, and being rigorous about it
are essential to the success of Scrum.

Timeboxing is a simple mechanism for handling complexity. We can’t figure out the
whole system at this time, so let’s take one small problem and in a short space of time,
say one week or one month, figure out how to solve that problem. The results of that
will then guide us towards a solution for the next, bigger problem and give us insight
into the needs of the system as a whole.

Agile methodologies

Extreme Programming It is a programmer-centric methodology that emphasizes

technical practices to promote skilful development through frequent delivery of
working software. XP is characterized as less rigorous then traditional techniques.XP
got its name when its founders asked the question, "what would happen if we took
each technique/practice and performed it to the extreme? How would that affect the
software process?" An example of this is the practice of code reviews. If code reviews
are good, then doing constant code reviews would be extreme; but would it be better?
This led to practices such as pair programming and refactoring, which encourage the
development of simple, effective designs, oriented in a way that optimizes business
value. In truth, full adoption of all of XP's practices requires a high level of discipline,
teamwork, and skill.

One of the characteristic distinctions between XP and other methodologies is its cycle
time and level of ceremony. XP recommends very short iterations between one and
four weeks. XP is also a very low ceremony methodology. Minimal artifacts in an XP
project include story cards, code, and unit tests.

But XP is most commonly known for its technical practices. At the heart of XP are
four core values: communication, simplicity, feedback, and courage. From these
values 13 practices are derived. Theses practices are:

1. Planning Game: Plan work incrementally.

2. Small Releases: Release as quickly as possible to increase time to market, and
get feedback as soon as possible.
3. Metaphor: If possible, define a metaphor for the system being developed. For
example, the shopping cart metaphor is widely used to describe an online
ordering system.
4. Simple Design: Use the simplest design that will work for the functionality
(user story) being implemented. Do not design for things that may never
actually be used.
5. Testing: Test everything, and try to automate the testing if possible.
6. Refactoring: Instead of designing the entire system up front, design as you go,
making improvements as needed. Change the implementation without
changing the interface to the functionality, and use automated testing to
determine the impact of the refactoring.
7. Pair Programming: Programming in teams of two (or three) allow for a
discussion to occur in real-time that addresses requirement, design, testing,
and programming concerns.
8. Collective Code Ownership: Anyone on the team can make a change to any
code at any time.
9. Continuous Integration: The entire code base is constantly being rebuilt, and
retested in an automated fashion.
10. Sustainable Pace: Ideally, team members do not need to work more than 40
hours per week to meet project deadlines. Burning the midnight oil is chunked
by management in favor of consistent, predictable, repeatable delivery.
11. Whole Team: The team functions as a whole. Members are encouraged to be
more generalized than specialized. Learning about all technologies and
requirements is encouraged.
12. Coding Standards: In order to maximize communication, coding standards are
defined by the team, and used to ensure consistent coding practices.
 13. Onsite Customer: Having constant and direct access to the customer allows the
team to work at the fastest possible
speed.

These practices support one another, as

illustrated in Figure 1, and thus care should be
taken when modifying any of them, or deciding
not to include one or more of these practices in
a project.
Another distinction between XP and other Agile
methodologies is its approach to requirements
gathering. The primary requirement artifact in Figure 1. XP Practices. The
XP is the user story. Visibly, a user story is practices in XP support one
nothing more than a note card with a short another and thus care should be
description on it. But user stories actually are taken to understand these
comprised of the card (reminder of promised relationships when modifying XP.
functionality), conversations between
developers and requirements donors, and tests (all types: unit, integration, acceptance,
etc.).

There are two primary types of planning activities that are referred to in XP parlance
as planning games: the release and iteration planning games. And each planning game
is characterized by three phases: exploration, commitment, and steering.

Release planning begins with the customer writing story cards and prioritizing them.
Programmers then estimate the stories from which a velocity can be derived. Velocity
describes how much work the team can accomplish in any given time frame. The
customer then chooses a scope for the release based either on desired functionality or
release date. The steering activities for release planning occur at iteration boundaries
when progress towards the planned release date can be tracked and adjustments can
be easily made.

Iteration planning follows a similar pattern to release planning. Each iteration begins
with developers taking stories and breaking them into tasks. Programmers accept
responsibility for tasks and estimating the tasks that they are responsible for. Each
programmer's load is compared to their historical performance to determine whether
anyone is overcommitted and to allow the workload to be balanced across the team.
Throughout the iteration programmers partner to complete tasks by writing unit tests
and code. Periodically throughout the iteration a member of the team checks on the
progress of the team and communicates this information to all team members so
adjustments can be made.

There are a small number of roles on an XP project. These include:

• Customer—The customer creates and prioritizes the stories that need to be

implemented. Because the customer sets the priorities she controls what will
be delivered in any given release and can control the release date by adding
and removing stories.
• Programmer—Programmers collectively estimate stories, but individually
accept responsibility for tasks which they estimate, write tests, and code.
 • Coach—The coach monitors the software development process, mentors team
members on XP process and techniques, and focuses the team's attention on
potential problems or optimizations.
• Tracker—The tracker monitors the progress of the team and alerts them when
adjustments to the schedule or a re-balancing of tasks might be required.

Scrum:

is a mechanism to restart the game after an accidental infraction - such as the ball
going out of bounds. It's the general idea of a team huddling together to move the ball
toward the goal.

Scrum is a project management framework for managing Agile projects. Its primary
goal is to deliver software that, after each and every iteration, provides the highest
business value. Scrum is based on a 30-day iteration called a "Sprint." Technically
Sprints can be either two or four weeks, but the generally accepted default is usually
four weeks.

A fundamental Scrum principal is that project teams should be self organizing. This
means that team members don't follow a prescriptive plan or set of tasks, but organize
themselves initially based on the goals for the Sprint, and subsequently on a daily
basis through daily scrum meetings. Recommended team size is from four to nine
members.

Every day at the same time, the project team meets to discuss the project. Members
are expected to stand during the entire meeting to encourage short meetings. Meetings
are targeted to complete in 10 to 15 minutes. Each member in turn answers three
questions:

1. What did I do since the last Scrum meeting?

2. What do I plan on doing between now and the next Scrum meeting?
3. Do I have any roadblocks?

Scrum also defines only a small numbers of roles on the team:

Product Owner—The Product Owner is responsible for representing the

customer or user of the product the team is building. Ideally this is the actual
customer, but when the customer is not available for a project, this role is filled by
someone representing the customer's interests; he or she is also responsible for being
the liaison between the project team and the customer.
Scrum Master—Scrum originated as a way to deal with troubled or emergency
projects. The person brought in to refocus the project team is called a Scrum Master.
This role is primarily to facilitate, report, and focus the team on the highest priority
work and to remove any roadblocks that may impede team progress. Certification
training for Scrum Masters exists, supporting three different levels of practice.
 Team Member—All other members of the team are considered general team
members. This includes developers, architects, project managers, testers, database
administrators—everyone. The team concept is important to Scrum and only the key
roles of Scrum Master and Product Owner are called out.

Daily Scrum key point :

An agile process to manage and control development work.
Can be used to wrap existing software engineering practices.
A team-based approach designed to iteratively and incrementally develop
systems when requirements change rapidly
Controls the chaos of conflicting interests and needs.
Improves communication and maximizes cooperation.
By design, Scrum helps the team detect and remove obstacles that get in the way
of developing and delivering products.

Is scalable from single projects to entire organizations.

The Scrum lifecycle is organized by brief development iterations called Sprints.

Lean Software Development

While most of us might joke that Lean Software Development (a.k.a.: Lean) is a new
way to lose unwanted pounds and keep them off, that wouldn't be far from the truth.
Lean is a methodology that aims to trim the fat from the software process, starting
with requirements, and including how business looks at the systems they request.

Lean Software Development promotes seven Lean principles. The methodology

revolves around these principles, and all other aspects of Lean are designed to
reinforce them. The seven principles are:

1. Eliminate Waste: Eliminate anything that does not add customer value.
2. Build Quality In: Validate and re-validate all assumptions throughout the
process. If a metric or practice no longer has value, discard it.
3. Create Knowledge: Use short iterative cycles to provide quick, constant
feedback to ensure the right things are being focused on.
4. Defer Commitment: Don't make decisions until enough is known to make the
decision—a sound understanding of the problem and the tradeoffs of potential
solutions is required.
5. Deliver Fast: Minimize the time it takes to identify a business problem and
deliver a system (or feature) that addresses it. (a.k.a. time to market).
6. Respect People: Empower the team to succeed.
7. Optimize the Whole: Use cross-functional teams to keep from missing
important, possibly critical aspects of the problem and of the system designed
to solve it.
Feature Driven Development

Feature Driven Development (FDD) is the domain model. Creating a model of the
domain is the foundational step for FDD, which requires collecting domain
knowledge from all domain experts (SMEs), and integrating this knowledge into a
unified model representing the problem domain. Once this model and any other
requirements have been evaluated, a rough plan is drawn up to determine what
resources will be needed to build the masterpiece. A small set of features are
identified for a team to work on for a period of time recommended to last no more
than two weeks. Once the initial set of features is delivered, another set is tackled.
Multiple teams can work in parallel on different sets of features, with all activity
being tracked on a per feature basis.

FDD specifies five specific processes that are to be followed, in this specific order:

1. Develop an Overall Model

2. Build a List of Features
3. Plan by Feature
4. Design by Feature
5. Build by Feature

FDD relies on specific roles and responsibilities more than almost any other Agile
methodology. FDD also tends to move away from shared ownership of code and
artifacts that other Agile methods promote, and the team roles reflect this. The nine
roles defined for FDD are:

1. Project Manager—Responsible for all administrative aspects of the project,

including the financial and reporting ones.
2. Chief Architect—Responsible for the overall design of the system, including
running all design sessions, code reviews, and technology decisions.
3. Development Manager—On the hook for the daily development activities.
Coordinating the development team and their activities, and dealing with
resource issues.
4. Chief Programmer—A senior developer involved in ongoing design and
development activities, and is assigned to be responsible for one or more
Feature Sets.
5. Class Owner—A developer who works under the direction of a Chief
Programmer to design, code, test, and document features as they are
implemented.
6. Domain Expert—Any business related stakeholder who can define required
features that the system should provide. These would include clients, users,
and various analysts; anyone who has knowledge of how the business works
that could impact the system.
7. Tester—Responsible for verifying that each feature performs as defined.
8. Deployer—Deals with not only the actual deployment of code to various
environments, but also the definition and/or conversion of data from one
format to another.
9. Technical Writer—Responsible for creating and maintaining all the online and
printed documentation that a user will need for the final system.
Capturing exactly where a feature is in its development cycle is done using a table
that tracks six specific milestones:

1. Domain Walkthough
2. Design
3. Design Inspection
4. Code
5. Code Inspection
6. Promote to Build

These milestones are tracked by the date each is completed and by the Chief
Programmer responsible for that specific feature.

Why Agile?

Agile development methodology attempts to provide many opportunities to assess the

direction of a project throughout the development lifecycle. This is achieved through
regular cadences of work, known as sprints or iterations, at the end of which teams
must present a shippable increment of work. Thus by focusing on the repetition of
abbreviated work cycles as well as the functional product they yield, agile
methodology could be described as “iterative” and “incremental.” In waterfall,
development teams only have one chance to get each aspect of a project right. In an
agile paradigm, every aspect of development — requirements, design, etc. — is
continually revisited throughout the lifecycle. When a team stops and re-evaluates the
direction of a project every two weeks, there’s always time to steer it in another
direction.
The results of this “inspect-and-adapt” approach to development greatly reduce both
development costs and time to market. Because teams can gather requirements at the
same time they’re gathering requirements, the phenomenon known as “analysis
paralysis” can’t really impede a team from making progress. And because a team’s
work cycle is limited to two weeks, it gives stakeholders recurring opportunities to
calibrate releases for success in the real world. In essence, it could be said that the
agile development methodology helps companies build the right product. Instead of
committing to market a piece of software that hasn’t even been written yet, agile
empowers teams to optimize their release as it’s developed, to be as competitive as
possible in the marketplace. In the end, a development agile methodology that
preserves a product’s critical market relevance and ensures a team’s work doesn’t
wind up on a shelf, never released, is an attractive option for stakeholders and
developers alike.