Agile Development

aft
Motivation
• In the modern economy, it is often difficult or impossible to
predict how a computer-based system (e.g., a Web-based
application) will evolve as time passes.
• Market conditions change rapidly, end-user needs evolve, and
new competitive threat emerge without warning (fluid
business environment, pervasiveness of change).
Dr
• In many situations, you won’t be define requirements fully
before the project begins.
• Fluidity implies change, and change is expensive. Particularly
if it is uncontrolled and poorely managed.
• Software engineer must be agile enough to respond to a fluid
business environment.
 Agile Development (cont.)

aft
Disadvantages of Classical methods of software development:
• Huge effort during the planning phase
• Poor requirements conversion in a rapid changing environment
• Treatment of staff as a factor of production
Dr
New method
• Agile Software Development
 Agile Software Development

aft
• Agile methods were developed in an effort to overcome
perceived and actual weaknesses in conventional software
engineering.
• Characteristic of the agile approach: ability to reduce cost
of change throughout the software process.
Dr
• Agile development can provide important benefits, but it is
not applicable to all projects, all products, all people, and all
situations.
Manifesto for Agile Software Development

aft
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
Dr
• Responding to change over following a plan
 Agility and the cost of change

aft
Dr
Figure: Change cost as a function of time in development
• Conventional software development: the cost of change
increases nonlinearly as the project progresses.
• Well designed Agile Process “flattens” the cost of change
curve, allowing a software team to accommodate change late
in software project without dramatic cost and time impact.
 What is an Agile Process?

aft
An Agile Process must be
• Adaptable
• Process adaptability to rapidly changing project and technical
conditions.
• Incremental
• Agile software process must adapt incrementally (change
adaptations with forward progress).
Dr
• Incremental development strategy: software increments
(executable prototypes or portions of an operational system)
must be delivered in short time periods so that adaptations
keeps pace with change (unpredictability).
 Agile Project Management

aft
Qualities
• Minimize risk → short iterations
• Real-time communication (prefer face-to-face) → very little
written documentation
Dr
• Indicated for unpredictable / rapidly changing requirements.
 Agility Principles
The Agile Alliance (A non-profit organization promotes agile

aft
development) defines 12 agility principles for those who want to
achieve agility:
1. Customer satisfaction by early and continuous delivery of
useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than
months)
Dr
4. Close, daily cooperation between business people and
developers
5. Projects are built around motivated individuals, who should be
trusted
6. Face-to-face conversation is the best form of communication
(co-location)
 Agility Principles (cont.)

aft
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity - the art of maximizing the amount of work not
done - is essential
Dr
11. Self-organizing teams
12. Regular adaptation to changing circumstance
 Human Factor in Agile Development

aft
• Agile development focuses on the talents and skills of
individuals, molding the process to specific people and teams.
• Key traits of an agile team
• Competence: encompasses innate talent, specific
software-related skills, and overall knowledge of the process
that the team has chosen to apply.
• Common focus: delivery of a working software increment to
the customer within time promised.
Dr
• Collaboration: team members must collaborate with one
another and all other stakeholders.
• Decision-making ability: team is given autonomy
-decision-making authority for both technical and project issue.
• Fuzzy problem-solving ability: the agile team will
continually have to deal with ambiguity and will continually be
buffeted by change.
Human Factor in Agile Development (cont.)

aft
• Mutual trust and respect
• Self organization
• The agile team organizes itself for the work to be done.
• The team organizes the process to best accommodate its local
Dr environment, and
• The team organizes the work schedule to best achieve delivery
of the software increment.
 Agile Methods

aft
Agile Methods
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Scrum
• Crystal
• Feature Driven Development (FDD)
Dr
• Lean Software Development (LSD)
• Agile Modeling (AM)
• Agile Unified Process (AUP)
 Extreme Programming (XP)

aft
• Most widely used approach to agile software development.
• Proposed by Kent Beck in the mid 1990’s.
• Uses an object-oriented approach as its preferred development
paradigm.
Dr
• Industrial XP: targets agile process specifically for use within
large organizations.
 Core values of XP

aft
1. Communication
• Root causes of failure of a project: Poor communication in
software teams.
• Stress on good communication between all stakeholders-
customers, team members, project managers.
• Customer representative always on site.
Dr
• Use of metaphors for communicating important concepts.
• Continuous feedback.
• Avoidance of voluminous documentation as a communication
medium.
 Core values of XP (cont.)

aft
2. Simplicity
• Restrict developers to design only for immediate needs, rather
than considering future needs.
• Implement a new capability in the simplest possible way.
• Refactor the system to be the simplest possible code with the
current feature set.
• Never implement a feature you don’t need now.
3. Feedback
Dr
• Sources of feedback: the implemented software itself, the
customer, and other software team members.
• Reliable way: a running system that delivers information about
itself.
• The system and the code provides feedback on the state of
development
• Catalyst for change and an indicator of progress.
 Core values of XP (cont.)

aft
4. Courage
• An agile XP team must have a courage (discipline) to design
for today, recognizing that future requirements may change
dramatically, thereby demanding substantial rework of the
design and implemented code.
• Projects are people-centric.
Dr
• Ingenuity of people and not any process that causes a project
to succeed.
 Core values of XP (cont.)

aft
5. Respect
• Respect among team members.
• Respect between other stakeholders and team members.
• Respect for the software itself.
•
Dr
Respect for the XP process.
The XP Process

aft
Dr
XP Practices

aft
Dr
 XP Practices (cont.)

aft
1. Whole Team
• All contributors to an XP project are one team.
• Must include a business representative - the ’Customer’
• Provides requirements
• Sets priorities
Dr• Steers project
• Team members are programmers, testers, analysts, coach,
manager.
• Best XP teams have no specialists.
 XP Practices (cont.)

aft
2. Planning Game
• Two key questions in software development:
• Predict what will be accomplished by the due date.
• Determine what to do next.
• Need is to steer the project.
• Exact prediction (which is difficult) is not necessary.
• Advantages
Dr
• Reduction in time wasted on useless features.
• Greater customer appreciation of the cost of a feature.
• Less guesswork in planning.
 XP Practices (cont.)

aft
3. Customer Tests/Testing
• The Customer defines one or more automated acceptance tests
for a feature.
• Team builds these tests to verify that a feature is implemented
correctly.
• Once the test runs, the team ensures that it keeps running
correctly thereafter.
Dr
• System always improves, never backslides.
• Unit testing.
• Test-first design.
• All automated.
 XP Practices (cont.)

aft
4. Small Releases
• Small in terms of functionality.
• Team releases running, tested software every iteration.
• Releases are small and functional.
• The Customer can evaluate or in turn, release to end users,
and provide feedback.
• Important thing is that the software is visible and given to the
Customer at the end of every iteration.
• Advantages
Dr
• Frequent feedback
• Tracking
• Reduce chance of overall project slippage.
• Disadvantages
• Not easy for all projects
• Versioning issues
 XP Practices (cont.)

aft
5. Simple Design
• Build software to a simple design.
• Through programmer, testing and design improvement, keep
the software simple and the design suited to current
functionality.
• Design steps in release planning and iteration planning.
• Teams design and revise design through refactoring,
Dr
throughout the course of the project.
• Advantages
• Easier to understand what is going on.
• Refactoring and collective ownership is made possible.
• Helps keeps programmers on track.
 XP Practices (cont.)

aft
6. Pair Programming
• Two Developers, One monitor, One Keyboard.
• One “drives” and the other thinks.
• Switch roles as needed.
• Research into pair programming shows that pairing produces
Dr
better code in the same time as programmers working singly.
• Pairing also communicates knowledge throughout the team.
 XP Practices (cont.)

aft
7. Test Driven Development (TDD)
• Teams practice TDD by working in short cycles of adding a
test, and then making it work.
• Easy to produce code with 100% test coverage.
• These programmer tests or unit tests are all collected together.
Dr
• Each time a pair releases code to the repository, every test
must run correctly.
 XP Practices (cont.)

aft
8. Design Improvement/Refactoring
• Continuous design improvement process called ’refactoring’:
• Removal of duplication
• Increase cohesion
• Reduce coupling
• Refactoring is supported by comprehensive testing- customer
Dr
tests and programmer tests.
• Prompts developers to proactively improve the product as a
whole.
• Increases developer knowledge of the system.
 XP Practices (cont.)

aft
9. Continuous Integration
• New features and changes are worked into the system
immediately.
• Teams keep the system fully integrated at all times.
• Daily, or multiple times a day builds.
Dr
• Avoid ’integration related problems’
• Avoid code freezes.
 XP Practices (cont.)

aft
10. Collective Code Ownership
• Any pair of programmers can improve any code at any time.
• No ’secure workspaces’.
• All code gets the benefit of many people’s attention.
• Avoid duplication.
Dr
• Programmer tests catch mistakes.
• Pair with expert when working on unfamiliar code.
 XP Practices (cont.)

aft
11. Coding Standard
• Use common coding standard.
• All code in the system must look as though written by an
individual.
• Code must look familiar, to support collective code ownership.
Dr
 XP Practices (cont.)

aft
12. Metaphor
• The oral architecture of the system.
• XP Teams develop a common vision of the system.
• Define common system of names.
• Ensure everyone understands how the system works, where to
look for functionality, or where to add functionality.
Dr
• Advantages
• Encourages a common set of terms for the system.
• A quick and easy way to explain the system.
 XP Practices (cont.)

aft
13. Sustainable Pace/ 40-Hour Week
• The work week should be limited to 40 hours.
• Team will produce high quality product when not
overly exerted.
• ’Death march’ projects are unproductive and do not produce
Dr
quality software.
• Work at a pace that can be sustained indefinitely.
 XP Criticism

aft
• Unrealistic - programmer centric, not business focused.
• Detailed specifications are not written.
• Design after testing.
• Constant refactoring.
Dr
• Customer availability.
• 12 practices are too interdependent.
 XP Thoughts

aft
• The best design is the code.
• Testing is good. Write tests before code. Code is complete
when it passes tests.
• Simple code is better. Write only code that is needed.
• Reduce complexity and duplication.
Dr
• Keep code simple. Refactor.
• Keep iterations short. Constant feedback.
 Adaptive Software Development (ASD)
• Developed Jim Highsmith and Sam Bayer.

aft
• Proposed for building complex software and systems.
• Focuses on the rapid creation and evolution of software
systems.

Dr
Adaptive Software Development (ASD) (cont.)

aft
• Focus is on human collaboration and team self-organization.
• The characteristics of an ASD life cycle are:
• mission focused,
• feature based,
• iterative,
•
•
•
Dr
timeboxed,
risk driven, and
change tolerant
 Scrum
What is Scrum?

aft
Definition from rugby football: A scrum is a way to restart the
game after an interruption, where the forwards of each side come
together in a tight formation and struggle to gain possession of the
ball when it is tossed in among them.

Dr
 Scrum (cont.)

aft
• Proposed by Jeff Sutherland and Ken Schwaber (1990s).
• Mike Beedle: enhancement of Scrum and combination of
Scrum with Extreme Programming.
• Scrum principles are consistent with agile manifesto and are
used to guide development activities within a process that
incorporates following framework activities:
• requirement,
• analysis,
•
•
•
Dr
design,
evolution, and
delivery
• Scrum focus on the use of a set of software process patterns
that have proven effective for projects with tight timelines,
changing requirements, and business criticality.
 Scrum (cont.)

aft
• Each of the process pattern defines a set of development
actions:
1. Backlog
• A prioritized list of project requirements or features that
provide business value for the customer.
• Items can be added to the backlog at any time.
• The product manager assesses the backlog and updates
priorities as required
2. Sprint
Dr
• Consists of work units that are required to achieve a
requirement defined in the backlog that must fit into a
predefined time-box (typically 30 days).
• The number of sprints required for each framework activity
will vary depending on product complexity and size.
• Changes (e.g., backlog work items) are not introduced during
the sprint (allows team members to work in short-term, but
stable environment).
 Scrum (cont.)

aft
3. Scrum Meeting
• A short (typically 15 minutes) meeting held daily by the scrum
team.
• Three key questions that are asked (by team leader or scrum
master) and answered by all the team members:
1) What did you do since the last team meeting?
Dr 2) What obstacles are you encountering?
3) What do you plan to accomplish by the next team meeting?
• The scrum meeting helps the team to uncover potential
problems as early as possible.
• Daily meeting lead to “knowledge socialization” and thereby
promote a self-organizing team structure.
 Scrum (cont.)

aft
4. Demos
• Deliver the software increment to the customer so that
functionality that has been implemented can be demonstrated
and evaluated by the customer.
• Demo may not contain all planned functionality, but rather
Dr those functions that can be delivered within the time-box that
was established.
Dynamic Systems Development Method (DSDM)

aft
• Provides a framework for building and maintaining systems
which meet tight time constraints through the use of
incremental prototyping in a controlled project environment.
• Uses modified version of Pareto principle - 80% of an
application can be delivered in 20% of the time it would take
Dr
to deliver the complete (100%) application.
• Each iteration of DSDM follows the 80% rule.
Dynamic Systems Development Method (DSDM)
(cont.)

aft
DSDM Life Cycle

Dr
Dynamic Systems Development Method (DSDM)
(cont.)

aft
• Feasibility Study
• Establishes the basic business requirements and constraints
associated with the application to be build, and
• Assess whether the application is a viable candidate for the
DSDM process.
• Business Study
Dr
• Establishes the functional and information requirements that
will allow the application to provide business value.
• Defines the basic application architecture and identifies the
maintainability requirements for the application.
Dynamic Systems Development Method (DSDM)
(cont.)

aft
• Functional Model Iteration
• Produces a set of incremental prototypes that demonstrate
functionality for the customer.
• Gather additional requirements by eliciting feedback from users
as they use the prototype.
• Design & Build Iteration
Dr
• Revisits prototypes build during functional model iteration to
ensure that each has been engineered in a manner that will
enable it to provide operational business value for end users.
• Implementation
• Places the latest software increment into the operational
environment.
 Crystal

aft
• Crystal family of agile methods - created by Alistair Cockburn
and Jim Highsmith.
• Focus is on “ maneuverability”
• A resource limited, cooperative game of invention and
communication, with a primary goal of delivering useful,
working software and a secondary goal of setting up for the
next game.
Dr
• A set of methodologies, each with core elements that are
common to all, and roles, process patterns, work products,
and practice that are unique to each are defined to achieve
maneuverability.
 Crystal (cont.)

aft
• Crystal Family: set of example agile processes that have
been proven effective for different types of projects.
• Agile teams select the member of the crystal family that is
most appropriate for their project and environment.
Dr
 Feature Driven Development (FDD)

aft
• Practical process model for object-oriented software
engineering.
• Agile process model that can be applied to
moderately sized and larger software projects.
• Emphasizes on collaboration among people in FDD team.
Dr
Feature Driven Development (FDD) (cont.)

aft
• FDD manages problem and project complexity using
feature-based decomposition followed by the integration of
software increments.
• The emphasis on the definition of features provide the
following benefits:
• Features (small block of deliverable functionality)
Dr
• Users can describe them more easily,
• Users can understand how they relate to one another more
readily,
• Users can better review them for ambiguity, error, or
omissions.
Feature Driven Development (FDD) (cont.)

aft
• Features can be organized into a hierarchical business-related
grouping.
• Since a feature is a client-valued function (or deliverable
software increment), the team can develop operational feature
every two weeks.
• Features are small.
• Feature design and code representations are easier to inspect
Dr effectively.
• Project planning, scheduling, and tracking are driven by the
feature hierarchy, rather than an arbitrarily adopted software
engineering task set.
 Lean Software Development (LSD)

aft
• LSD has adapted the principles of lean manufacturing to the
world of software engineering.
• Lean principles that inspire the LSD process:
• eliminate waste,
• build quality in,
• create knowledge,
• defer commitment,
•
•
•
Dr
deliver fast,
respect people, and
optimize the whole.
Each of the above principle can be adapted to the software
process.
Lean Software Development (LSD) (cont.)

aft
• For example, eliminate waste within the context of an agile
software project can be interpreted as:
• adding no extraneous features or functions,
• assessing the cost and schedule impact of any newly requested
requirement,
• removing any superfluous process steps,
• establishing mechanism to improve the way team members
find information,
Dr
• ensuring the testing finds as many as errors as possible,
• reducing the time required to request and get a decision that
affects the software or the process that is applied to create it,
and
• streamlining the manner in which information is transmitted to
all stakeholders involved in the process.
 Agile Modeling

aft
• Modeling: process of creating a representation of the domain
or the software.
• Agile Modeling
• Practice-based methodology for effective modeling and
documentation of software-based systems.
Dr
• Collection of values, principles, and practices for modeling
software that can be applied on a software development project
in an effective and light-weight manner.
 Agile Modeling (cont.)

aft
• Agile Modeling Principles
• Model with a purpose
• Use multiple models
• Travel light
• As software engineering work proceeds, keep only those
models that will provide long-term value and jettison the rest.
• Content is more important than representation.
Dr
• Know the models and the tools use to create them.
• Adapt locally
• The modeling approach should be adapted to the needs of the
agile team.
 Agile Unified Process (AUP)

aft
• Developed to provide a framework for the application of UML.
• AUP adopts a “serial in the large” and “iterative in the small”
philosophy for building computer-based systems.
• AUP adopts classic unified process activities - inception,
elaboration, construction, and transition.
• Enables a team to visualize the overall process flow for a
Dr
software project (i.e., a linear sequence of software engineering
activities).
• Within each of the activities, the team iterates to achieve
agility and to deliver meaningful software increments to end
users as rapidly as possible.
 Agile Unified Process (AUP) (cont.)

aft
• Each AUP iteration addresses the following activities:
• Modeling: UML representations of the business and problem
domains are created.
• Implementation: models are translated into source code.
• Testing: the team designs and executes a series of tests to
uncover errors and ensure that the source code meets the
Dr
requirements.
• Deployment: focuses on the delivery of software increment
and the acquisition of feedback from end users.
Agile Unified Process (AUP) (cont.)

aft
• 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 managements tracks and controls the progress of the
Dr team and coordinates team activities.
• Environment management: coordinates a process
infrastructure that includes standards, tools, and other support
technology available to them.