AGILE TECHNOLOGIES

UNIT – I
FUNDAMENTALS OF AGILE
The Genesis of Agile

 Traditional development with single-function groups, delayed or weak feedback loops,

frontloaded predictive planning, and a sequential flow from analysis to test is not very successful
in today’s volatile world. This approach delays feedback, learning, and potential return on
investment due to an absence of real working software until late in the game, causing a lack of
transparency, lack of ability to improve, reduction in flexibility, and an increase in business and
technical risks.

 An alternative – cross-functional teams with iterative development – has also existed for
decades, but was not as widely used as the traditional model. Scrum packages proven product-
development concepts in a simple framework, including: real teams, cross-functional teams, self-
managing teams, short iterative full-cycle feedback loops, and lowering the cost of change.
These concepts increase agility and feedback, enable earlier ROI (Return on Investment), and
reduce risk.

Introduction and Background

 Agile software development (also called “agile”) isn’t a set of tools or a single methodology, but
a philosophy put to paper in 2001 with an initial 17 signatories.

Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick

 Agile was a significant departure from the heavyweight document-driven software development
methodologies such as waterfall in general use at the time. A recent survey conducted by Dr.
Dobb’s Journal shows 41 percent of development projects have now adopted agile methodology,
and agile techniques are being used on 65 percent of such projects.

Page 1
 AGILE TECHNOLOGIES

Case Study: - One company to realize these benefits by adopting Scrum is Salesforce.com. Founded in
1999 in a San Francisco apartment, Salesforce.com is one of the true, lasting dot-com-era success
stories. With revenue of more than $450 million and 2,000 employees in 2006, Salesforce.com had
noticed the frequency of its releases had decreased from four a year to one a year. Customers were
getting less and waiting longer to get it; something needed to be done. The company decided to
transition to Scrum. During the first year of making the switch, Salesforce.com released 94% more
features, delivered 38% more features per developer, and delivered over 500% more value to its
customers compared to the previous year (Greene and Fry 2008). In the resultant of two years, revenue
more than doubled to more than $1 billion. With results like these, it is not surprising that so many
organizations have transitioned to Scrum. Or at least tried to.

Agile Manifesto and Principles

Uncovering better ways of developing software by doing it and helping others to do it. The main
manifesto (objectives) of agile are:

 Individuals and Interactions over processes and tools

 Working Software over comprehensive documentation
 Customer Collaboration over contract negotiation
 Responding to Change over following a plan

Individuals and Interactions

 People are the most important ingredient of success. A good process will not save a project from
failure if the team doesn't have strong players, but a bad process can make even the strongest of
players ineffective. Even a group of strong players can fail badly if they don't work as a team. A
team of average programmers who communicate well are more likely to succeed than is a group
of superstars who fail to interact as a team.

 The right tools can be very important to success. Compilers, interactive development
environments (IDEs), source code control systems, and so on, are all vital to the proper
functioning of a team of developers. However, tools can be overemphasized. An overabundance
of big, unwieldy tools is just as bad as a lack of tools.

 Building the team is more important that building the environment. Many teams and managers
make the mistake of building the environment first and expecting the team to work
automatically. Instead, work to create the team, and then let the team configure the environment
on the basis of need.

Page 2
 AGILE TECHNOLOGIES

Working Software

 Software without documentation is a disaster. Code is not the ideal medium for communicating
the basis and structure of a system. Rather, the team needs to produce human-readable
documents that describe the system and the basis for design decisions.

 However, too much documentation is worse than too little. Huge software documents take a great
deal of time to produce and even more time to keep in sync with the code. If they are not kept in
sync, they turn into large, complicated lies and become a significant source of misdirection.

 The two documents that are the best at transferring information to new team members are the
code and the team. The code does not lie about what it does. It may be difficult to extract basis
and intent from the code, but the code is the only unambiguous source of information. The team
holds the ever-changing roadmap of the system in its members' heads. The fastest and most
efficient way to put that roadmap down on paper and transfer it to others is through human-to-
human interaction.

 Martin's First Law of Documentation: - Produce no document unless its need is immediate and
significant.

Customer Collaboration

 Software cannot be ordered like a commodity. You cannot write a description of the software
you want and then have someone develop it on a fixed schedule for a fixed price. Time and time
again, attempts to treat software projects in this manner have failed.

 A contract that specifies the requirements, schedule, and cost of a project is fundamentally
flawed. In most cases, the terms it specifies become meaningless long before the project is
complete, sometimes even long before the contract is signed! The best contracts are those that
govern the way the development team and the customer will work together.

 Successful projects involve customer feedback on a regular and frequent basis. Rather than
depending on a contract, or a statement of work, the customer of the software works closely with
the development team, providing frequent feedback on its efforts.

 The key to this success was the intense collaboration with the customer and a contract that
governed that collaboration rather than trying to specify the details of scope and schedule for a
fixed cost.

Page 3
 AGILE TECHNOLOGIES

Responding to Change

 The ability to respond to change often determines the success or failure of a software project.
When we build plans, we need to make sure that they are flexible and ready to adapt to changes
in the business and technology.

 The course of a software project cannot be planned very far into the future. First, the business
environment is likely to change, causing the requirements to shift. Second, once they see the
system start to function, customers are likely to alter the requirements. Finally, even if we know
what the requirements are and are sure that they won't change, we are not very good at estimating
how long it will take to develop them.

 A better planning strategy is to make detailed plans for the next week, rough plans for the next 3
months, and extremely crude plans beyond that. We should know the individual tasks we will be
working on for the next week. We should roughly know the requirements we will be working on
for the next 3 months. And we should have only a vague idea what the system will do after a
year.

Agile Principles

The below 12 principles are the characteristics that differentiate a set of agile practices from a
traditional process.

 Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software
 Welcome changing requirements, even late in development. Agile processes harness
change for the customer’s competitive advantage.
 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.
 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. 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.

Page 4
 AGILE TECHNOLOGIES

Overview of SCRUM
In rugby, ‘scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged with each
other to get a job done. In software development, the job is to put out a release. Scrum for software
development came out of the rapid prototyping community because prototypers wanted a methodology
that would support an environment in which the requirements were not only incomplete at the start, but
also could change rapidly during development.
Scrum is a development framework in which cross-functional teams develop products or projects in an
iterative, incremental manner. It structures development in cycles of work called Sprints. These
iterations are no more than four weeks each (the most common is two weeks), and take place one after
the other without pause. The Sprints are timeboxed – they end on a specific date whether the work has
been completed or not, and are never extended

At the beginning of each Sprint, a cross-functional Team (of about seven people) selects items (customer
requirements) from a prioritized list. The Team agrees on a collective target of what they believe they
can deliver by the end of the Sprint, something that is tangible and will be truly “done”. During the
Sprint, no new items may be added; Scrum embraces change for the next Sprint, but the current short
Sprint meant to focus is on a small, clear, relatively stable goal

Extreme Programming

 XP stands for extreme programming. It concentrates on the development rather than managerial
aspects of software projects. XP was designed so that organizations would be free to adopt all or
part of the methodology.

XP Development

Page 5
 AGILE TECHNOLOGIES

 XP projects start with a release planning phase, followed by several iterations, each of which
concludes with user acceptance testing. When the product has enough features to satisfy users,
the team terminates iteration and releases the software.

 Users write “user stories” to describe the need the software should fulfill. User stories help the
team to estimate the time and resources necessary to build the release and to define user
acceptance tests. A user or a representative is part of the XP team, so he or she can add detail to
requirements as the software is being built. This allows requirements to evolve as both users and
developers define what the product will look like.

 To create a release plan, the team breaks up the development tasks into iterations. The release
plan defines each iteration plan, which drives the development for that iteration. At the end of an
iteration, users perform acceptance tests against the user stories. If they find bugs, fixing the bugs
becomes a step in the next iteration.

 Iterative user acceptance testing, in theory, can result in release of the software. If users decide
that enough user stories have been delivered, the team can choose to terminate the project before
all of the originally planned user stories have been implemented.

Some Important XP Rules and Concepts


Integrate often - Development teams must integrate changes into the development baseline at least
once a day. This concept is also called Continuous Integration.

Project velocity -Velocity is a measure of how much work is getting done on the project. This
important metric drives release planning and schedule updates.
Feature Driven Development

Feature Driven Development (FDD) was originally conceived by Peter Coad and his colleagues
as a practical process model for object-oriented software engineering. Stephen Palmer and John Felsing
have extended and improved Coad’s work, describing an adaptive, agile process that can be applied to
moderately sized and larger software projects.

FDD adopts a philosophy;

 Emphasizes collaboration among people on an FDD team.

 Manages problem and project complexity using feature-based decomposition followed by the
integration of software increments.

 Communication of technical detail using verbal, graphical, and text-based means.

Page 6
 AGILE TECHNOLOGIES

In the context of FDD, “a feature is a client-valued function that can be implemented in two weeks or
less”. The emphasis on the definition of features provides the following benefits:

 Because features are small blocks of deliverable functionality, users can describe them
more easily; understand how they relate to one another more readily; and better review them for
ambiguity, error, or omissions.
 Features can be organized into a hierarchical business-related grouping.
Since a feature is the FDD deliverable software increment, the team develops operational features
every two weeks.
 Because features are small, their design and code representations are easier to inspect effectively.
 Project planning, scheduling, and tracking are driven by the feature hierarchy, rather than an
arbitrarily adopted software engineering task set.

Coad and his colleagues suggest the following template for defining a feature:

Examples of features for an e-commerce application might be:

1. Add the product to shopping cart

2. Display the technical-specifications of the product
3. Store the shipping-information for the customer

Lean Software Development

Lean Software Development (LSD) has adapted the principles of lean manufacturing to the
world of software engineering. The lean principles that inspire the LSD process can be summarized as
eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people, and
optimize the whole. Each of these principles can be adapted to the software process.

Page 7
 AGILE TECHNOLOGIES

For example, eliminate waste within the context of an agile software project can be interpreted to mean:
o Adding no extraneous features or functions.

o Assessing the cost and schedule impact of any newly requested requirement.

o Removing any superfluous process steps.

o Establishing mechanisms to improve the way team members find information.

o Ensuring the testing finds as many errors as possible.

o Reducing the time required to request and get a decision that affects the software
or the process that is applied to create it.

o Streamlining the manner in which information is transmitted to all stakeholders

involved in the process.

Agile Project Management

 Jim Highsmith, one of the originators of the Agile Manifesto and a recognized expert in agile
approaches, has defined agility in project management by the following statements: “Agility is
the ability to both create and respond to change in order to profit in a turbulent business
environment,” and “Agility is the ability to balance flexibility and stability”.

 Agile project management is conducted through the collaboration of a small, co-located team
that usually consists of the customer/end user, a project manager, a business analyst (or the role
of business analysis) and specialist(s). Specialists could include system developers, subject
matter experts, IT architect and/or the sole person with specific knowledge or expertise who
understands how all the project pieces fit together.

 Agile project management assumes that changes, improvements and additional features will be
incorporated throughout the product development life cycle, and that change, rather than
perceived as a failing of the process, is seen as an opportunity to improve the product and make
it more fit for its use and business purpose.

Design and Development Practices in Agile Projects

The most widely used design methodologies based on the agile philosophy are Extreme
Programming and Scrum.
The development practices in Agile Projects are;

1. Modeling - UML representations of the business and problem domains are created. However, to
stay agile, these models should be “just barely good enough” to allow the team to proceed.
Page 8
 AGILE TECHNOLOGIES

2. Implementation - Models are translated into source code.

3. Testing - Like XP, the team designs and executes a series of tests to uncover errors and ensure that
the source code meets its requirements.

4.Deployment - This context focuses on the delivery of a software increment and the acquisition of
feedback from end users.

5.Configuration and project management - Configuration management addresses change

management, risk management, and the control of any persistent work products that are produced by
the team. Project management tracks and controls the progress of the team and coordinates team
activities.

6.Environment management - Environment management coordinates a process infrastructure that

includes standards, tools, and other support technology available to the team.

Test Driven Development

In test driven development all production code is written in order to make a failing unit test pass. First,
we write a unit test that fails because the functionality it is testing for doesn't exist. Then we write the
code that makes that test pass.

This iteration between writing test cases and code is very rapid, on the order of a minute or so. The test
cases and code evolve together, with the test cases leading the code by a very small fraction.

As a result, a very complete body of test cases grows along with the code. These tests allow the
programmers to check whether the program works. Programming a pair that makes a small change can
run the tests to ensure that nothing has broken. When you write code in order to make test cases pass,
that code is by definition testable.
Continuous Integration

The programmers check their code in and integrate several times per day. The rule is simple. The first
one to check in wins and everybody else merges.

XP teams use non-blocking source control. This means that programmers are allowed to check any
module out at any time, regardless of who else may have it checked out. When checking the module back
in after modifying it, the programmer must be prepared to merge it with any changes made by anyone
who checked the module in earlier. To avoid long merge sessions, the members of the team check their
modules very frequently.

Page 9
 AGILE TECHNOLOGIES

A pair will work for an hour or two on a task. They create test cases and production code. At
some convenient breaking point, probably long before the task is complete, they decide to check
the code back in. They first make sure that all the tests run. They integrate their new code into
the existing code base. If there is a merge to do, they do it. If necessary, they consult with the
programmers who beat them to the check-in. Once their changes are integrated, they build the
new system. They run every test in the system, including all currently running acceptance tests.
If they broke anything that used to work, they fix it. Once all the tests run, they finish the check-
in.

So XP teams will build the system many times each day. They build the whole system from end to end.

Refactoring

 Code tends to rot. As we add feature after feature and deal with bug after bug, the
structure of the code degrades. Left unchecked, this degradation leads to a tangled,
unmaintainable mess.

 XP teams reverse this degradation through frequent refactoring. Refactoring is the

practice of making a series of tiny transformations that improve the structure of the
system without affecting its behavior. Each transformation is trivial, hardly worth doing.
But together, they combine into significant transformations of the design and architecture
of the system.

 After each tiny transformation, we run the unit tests to make sure that we haven't broken
anything. Then we do the next transformation, and the next, and the next, running the
tests after each. In this manner, we keep the system working while transforming its
design.

 Refactoring is done continuously rather than at the end of the project, the end of the
release, or the end of the iteration, or even the end of the day. Refactoring is something
we do every hour or every half hour. Through refactoring, we continuously keep the code
as clean, simple, and expressive as it can be.

Pair Programming

 Code is written by pairs of programmers working together at the same workstation. One
member of each pair drives the keyboard and types the code. The other member of the
pair watches the code being typed, finding errors and improvements. The two interact
intensely. Both are completely engaged in the act of writing software.

 The roles change frequently. If the driver gets tired or stuck, the pair partner grabs the
keyboard and starts to drive. The keyboard will move back and forth between them
several times in an

Page 10
 AGILE TECHNOLOGIES

 hour. The resultant code is designed and authored by both members. Neither can take
more than half the credit.

 Pair membership changes frequently. A reasonable goal is to change pair partners at least
once per day so that every programmer works in two different pairs each day. Over the
course of an iteration, every member of the team should have worked with every other
member of the team, and they should have worked on just about everything that was
going on in the iteration.

 Pair programming dramatically increases the spread of knowledge throughout the team.
Although specialties remain, and tasks that require certain specialties will usually belong
to the appropriate specialists, those specialists will pair with nearly everyone else on the
team. This will spread the specialty throughout the team such that other team members
can fill in for the specialists in a pinch.

 Studies by Williams and Nosek have suggested that pairing does not reduce the
efficiency of the programming staff but does significantly reduce the defect rate.

Simple Design

 An XP team makes its designs as simple and expressive as they can be. Furthermore, the
team narrows its focus to consider only the stories that are planned for the current
iteration, not worrying about stories to come. Rather, the team migrates the design of the
system from iteration to iteration to be the best design for the stories that the system
currently implements.

 An XP team will probably not start with infrastructure, probably won't select the database
first, and probably won't select the middleware first. Rather, the team's first act will be to
get the first batch of stories working in the simplest way possible. The team will add the
infrastructure only when a story comes along that forces it to.

Three XP mantras guide the developer.

 Consider the simplest thing that could possibly work - XP teams always try to find the simplest
possible design option for the current batch of stories. If we can make the current stories work
with flat files, we might not use a database. If we can make the current stories work with a
simple socket connection, we might not use a Web Service. If we can make the current stories
work without multithreading, we might not include multithreading.
 You aren't going to need it - Yeah, but we know we're going to need that database one day. We
know we're going to have to have an Web Service one day. We know we're going to have to
support multiple users one day. So we need to put the hooks in for those things now, don't we?
 Once and only once - XPers don't tolerate duplication of code. Wherever they find it, they
eliminate it.

Page 11
 AGILE TECHNOLOGIES

User Stories

 A user story describes problems to be solved by the system being built. These stories must be
written by the user and should be about three sentences long. User stories do not describe a
solution, use technical language, or contain traditional requirements-speak, such as “shall”
statements. Instead, a sample user story might go like this: Search for customers. The user tells
the application to search for customers. The application asks the user to specify which customers.
After the user specifies the search criteria, the application returns a list of customers meeting
those criteria.

 The specific details of a requirement are likely to change with time, especially once the customer
begins to see the system come together. In XP, we get the sense of the details of the requirements
by talking them over with the customer. But we do not capture that detail. Rather, the customer
writes a few words on an index card that we agree will remind us of the conversation.

 A user story is a mnemonic token of an ongoing conversation about a requirement. A user story
is a planning tool that the customer uses to schedule the implementation of a requirement, based
on its priority and estimated cost.

Agile Testing

 We use the term “tester” to describe a person whose main activities revolve around testing and
quality assurance. You’ll also see that we often use the word “programmer” to describe a person
whose main activities revolve around writing production code.

 A software testing practice that follows the principles of agile software development is called
Agile Testing.

 Each agile team member is focused on delivering a high-quality product that provides business
value. Agile testers work to ensure that their team delivers the quality their customers need. We
use the terms “programmer” and “tester” only for convenience.

Principles of Agile Testing

Testing is NOT a Phase: Agile team tests continuously and continuous testing is the only way to
ensure continuous progress.

Testing Moves the Project Forward: When following conventional methods, testing is
considered as quality gate but agile testing provide feedback on an ongoing basis and the product
meets the business demands.

Page 12
 AGILE TECHNOLOGIES

Everyone Tests: In conventional SDLC, only test team tests while in agile including developers
and BA's test the application.

Shortening Feedback Response Time: In conventional SDLC, only during the acceptance
testing, the Business team will get to know the product development, while in agile for each and
every iteration, they are involved and continuous feedback shortens the feedback response time
and cost involved in fixing is also less.

Clean Code: Raised defects are fixed within the same iteration and thereby keeping the code clean.

Reduce Test Documentation: Instead of very lengthy documentation, agile testers use reusable
checklist, focus on the essence of the test rather than the incidental details.

Test Driven: In conventional methods, testing is performed after implementation while in agile
testing, testing is done while implementation.

Agile Tools

SL NO TOOL NAME USAGE AREA/SCOPE

1 AgileFant Project Life Cycle Management
2 SVN Version Control
3 Jenkins Continuous Integration
4 JUnit Test Driven Development
5 ANT Build Tool
6 QAliber / Cucumber Test Automation

Page 13