Chapter 3

Agile Development
What is Agility?
software engineering represents a reasonable compromise between to conventional software engineering for
certain classes of software and certain types of software projects. Agile processes can deliver successful
systems quickly. It stresses on continuous communication and collaboration among developers and
customers.

Agile software engineering embraces a philosophy that encourages customer satisfaction, incremental
software delivery, small project teams (composed of software engineers and stakeholders), informal
methods, and minimal software engineering work products. Agile software engineering guidelines stress on-
time delivery of an operational software increment over analysis and design

 An agile team is able to respond to changes during project development

 Agile development recognizes that project plans must be flexible
 Agility encourages team structures and attitudes that make communication among developers and
customers more facile
 Agility eliminates the separation between customers and developers
 Agility emphasizes the importance of rapid delivery of operational software and de-emphasizes
importance of intermediate work products
 Agility can be applied to any software process as long as the project team is allowed to streamline
tasks and conduct planning in way that eliminate non-essential work products

Agility and the Cost of Change

 Conventional wisdom is that the cost of change increases nonlinearly as a project progresses. It is
relatively easy to accommodate a change when a team is gathering requirements early in a project. If
there are any changes, the costs of doing this work are minimal. But if the middle of validation
testing, a stakeholder is requesting a major functional change. Then the change requires a
modification to the architectural design, construction of new components, changes to other existing
components, new testing and so on. Costs escalate quickly.

 A well-designed agile process may “flatten”the cost of change curve by coupling incremental
delivery with agile practices such as continuous unit testing andpair programming. Thus team can
accommodate changes late in the software project without dramatic cost and time impact.

Agile Processes

 Are based on three key assumptions

1. It is difficult to predict in advance which requirements or customer priorities will change and
which will not
2. For many types of software design and construction activities are interleaved (construction is
used to prove the design)
 3. Analysis, design, and testing are not as predictable from a planning perspective as one might
like them to be
 Agile processes must be adapted incrementally to manage unpredictability
 Incremental adaptation requires customer feedback based on evaluation of delivered software
increments (executable prototypes) over short time periods

Agility Principles
 Highest priority is to satisfy customer through early and continuous delivery of valuable software
 Welcome changing requirements even late in development, accommodating change is viewed as
increasing the customer’s competitive advantage
 Delivering working software frequently with a preference for shorter delivery schedules (e.g., every
2 or 3 weeks)
 Business people and developers must work together daily during the project
 Build projects around motivated individuals, given them the environment and support they need,
trust them to get the job done
 Face-to-face communication is the most effective method of conveying information within the
development team
 Working software is the primary measure of progress
 Agile processes support sustainable development, developers and customers should be able to
continue development indefinitely
 Continuous attention to technical excellence and good design enhances agility
 Simplicity (defined as maximizing the work not done) is essential
 The best architectures, requirements, and design emerge from self-organizing teams
 At regular intervals teams reflects how to become more effective and adjusts its behavior accordingly

Human Factors
 Traits that need to exist in members of agile development teams:
o Competence(Talent,skills,knowledge)
o Common focus(deliver a working software increment)
o Collaboration(peers and stakehoilders)
o Decision-making ability(freedom to control its own destiny)
o Fuzzy-problem solving ability(ambiguity and constant changes,today’s problem may not be
tomorrow’s problem)
o Mutual trust and respect
o Self-organization(themselves for the work done,process for its local,environment,the work
schedule)

Agile Process Models

 Extreme Programming (XP)

 Adaptive Software Development (ASD)
 Dynamic Systems Development Method (DSDM)
 Scrum
 Crystal
 Feature Driven Development (FDD)
 Agile Modeling (AM)

Extreme Programming
Definition

Extreme Programming (XP) is an agile software development framework that aims to produce higher quality
software, and higher quality of life for the development team. XP is the most specific of the agile
frameworks regarding appropriate engineering practices for software development.

 Relies on object-oriented approach

 Key activities
o Planning (user stories created and ordered by customer value)
o Design (simple designs preferred, CRC cards and design prototypes are only work products,
encourages use of refactoring)
o Coding (focuses on unit tests to exercise stories, emphasizes use of pairs programming to
create story code, continuous integration and smoke testing is utilized)
o Testing (unit tests created before coding are implemented using an automated testing
framework to encourage use of regression testing, integration and validation testing done on
daily basis, acceptance tests focus on system features and functions viewable by the
customer)

What is Extreme Programming?

XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop a software.

eXtreme Programming (XP) was conceived and developed to address the specific needs of software
development by small teams in the face of vague and changing requirements.

Extreme Programming is one of the Agile software development methodologies. It provides values and
principles to guide the team behavior. The team is expected to self-organize. Extreme Programming
provides specific core practices where −

 Each practice is simple and self-complete.

 Combination of practices produces more complex and emergent behavior.

XP Values
The five values of XP are communication, simplicity, feedback, courage, and respect and are described in
more detail below.

Communication

Software development is inherently a team sport that relies on communication to transfer knowledge from
one team member to everyone else on the team. XP stresses the importance of the appropriate kind of
communication - face to face discussion with all other stakeholders. The goal is to give all developers a
shared view of the system which matches the view held by the users of the system. To this end, extreme
programming favors simple designs, common metaphors, collaboration of users and programmers, frequent
verbal communication, and feedback.

Simplicity

Extreme programming encourages starting with the simplest solution. Simplicity means “what is the
simplest thing that will work?” The purpose of this is to avoid waste and do only absolutely necessary things
such as keep the design of the system as simple as possible so that it is easier to maintain, support, and
revise. Simplicity also means address only the requirements that you know about;

Feedback

Through constant feedback about their previous efforts, teams can identify areas for improvement and revise
their practices. Feedback also supports simple design. Your team builds something, gathers feedback on
your design and implementation, and then adjust your product going forward.

Courage

Kent Beck defined courage as “effective action in the face of fear” (Extreme Programming Explained P. 20).
This definition shows a preference for action based on other principles so that the results aren’t harmful to
the team. You need courage to raise organizational issues that reduce your team’s effectiveness. You need
courage to stop doing something that doesn’t work and try something else. You need courage to accept and
act on feedback, even when it’s difficult to accept.

Respect

The members of your team need to respect each other in order to communicate with each other, provide and
accept feedback that honors your relationship, and to work together to identify simple designs and solutions.

XP Process

Advantages of Extreme Programming

 The greatest advantage of Extreme Programming is that this methodology allows software
development companies to save costs and time required for project realization.
  Time savings are available because of the fact that XP focuses on timely delivery of final products.

 Extreme Programming teams save lots of money because they don’t use too much documentation.
They usually solve problems through discussions inside of the team.

Simplicity is one more advantage of Extreme Programming projects. The developers who prefer to use this
methodology create extremely simple code that can be improved at any moment.

Disadvantages of Extreme Programming

 Some specialists say that Extreme Programming is focused on the code rather than on design. That
may be a problem because good design is extremely important for software applications.

 It helps sell them in the software market. Additionally, in XP projects the defect documentation is
not always good.

 Lack of defect documentation may lead to occurrence of similar bugs in the future.

One more disadvantage of XP is that this methodology does not measure code quality assurance. It may
cause defects in the initial code.

Industrial eXtreme Programming:

Extreme Programming (XP) is a widely used method for software development. This method is used to
improve the quality of software. However, the use of XP is limited to small and medium organization.
Therefore, Industrial Extreme Programming (IXP) is developed to meet the needs of larger organization
as an evolution of XP. However, IXP is not accompanied by complete procedures and tools needed by
developer. IXP incorporates six new practices that are designed to help ensure that an XP project works
successfully for significant projects within a large Organization.

 Readiness Assessment

 Project Community

 Project Chartering

 Test driven management

 Retrospectives

 Continuous Learning

OTHER AGILE PROCESS MODELS

1. Adaptive Software Development (ASD)

 Self-organization arises when independent agents cooperate to create a solution to a problem that is
beyond the capability of any individual agent.
 Emphasizes self-organizing teams, interpersonal collaboration, and both individual and team learning
 Adaptive cycle characteristics
 o Speculation (project initiated and adaptive cycle planning takes place)
o Collaboration (requires teamwork from a jelled team, joint application development is
preferred requirements gathering approach, minispecs created)
o Learning (components implemented and testes, focus groups provide feedback, formal
technical reviews, postmortems)

2. Dynamic Systems Development Method (DSDM)

 Provides a framework for building and maintaining systems which meet tight time constraints using
incremental prototyping in a controlled environment
 Uses Pareto principle (80% of project can be delivered in 20% required to deliver the entire project)
 Each increment only delivers enough functionality to move to the next increment
 Uses time boxes to fix time and resources to determine how much functionality will be delivered in
each increment
 Guiding principles
o Active user involvement
o Teams empowered to make decisions
o Fitness foe business purpose is criterion for deliverable acceptance
o Iterative and incremental develop needed to converge on accurate business solution
o All changes made during development are reversible
o Requirements are baselined at a high level
o Testing integrates throughout life-cycle
o Collaborative and cooperative approach between stakeholders
 Life cycle activities
o Feasibility study (establishes requirements and constraints)
o Business study (establishes functional and information requirements needed to provide
business value)
o Functional model iteration (produces set of incremental prototypes to demonstrate
functionality to customer)
o Design and build iteration (revisits prototypes to ensure they provide business value for end
users, may occur concurrently with functional model iteration)
o Implementation (latest iteration placed in operational environment)

3. Scrum
Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most
widely-used one.

 A “process framework” is a particular set of practices that must be followed in order for a process to
be consistent with the framework. (For example, the Scrum process framework requires the use of
development cycles called Sprints, the XP framework requires pair programming, and so forth.)
 “Lightweight” means that the overhead of the process is kept as small as possible, to maximize the
amount of productive time available for getting useful work done.

Scrum is:

 Lightweight
 Simple to understand
 Difficult to master

A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into
the three categories of Roles, Artifacts, and Time Boxes. These and other terms used in Scrum are defined
below. Scrum is most often used to manage complex software and product development, using iterative and
incremental practices. Scrum significantly increases productivity and reduces time to benefits relative to
classic “waterfall” processes. Scrum processes enable organizations to adjust smoothly to rapidly-changing
requirements, and produce a product that meets evolving business goals. An agile Scrum process benefits
the organization by helping it to

 Increase the quality of the deliverables

 Cope better with change (and expect the changes)
 Provide better estimates while spending less time creating them
 Be more in control of the project schedule and state

Scrum is a simple framework for effective team collaboration on complex software projects.  The Scrum
Framework poster provides a graphical view of how Scrum is implemented at a team level within an
organization.  The Framework is based off of The Scrum Guide which Scrum co-creators Ken Schwaber and
Jeff Sutherland have written to explain Scrum clearly and succinctly.
The Scrum Framework

Scrum is simple.  It is the opposite of a big collection of interwoven mandatory components. Scrum is not
a methodology. Scrum implements the scientific method of empiricism. Scrum replaces a programmed
algorithmic approach with a heuristic one, with respect for people and self-organization to deal with
unpredictability and solving complex problems.  The below graphic represents Scrum in Action as described
by Ken Schwaber and Jeff Sutherland in their book Software in 30 Days taking us from planning through
software delivery.  

The Roles of the Scrum Team

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams
are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work,
rather than being directed by others outside the team. Cross-functional teams have all competencies needed
to accomplish the work without depending on others not part of the team. The team model in Scrum is
designed to optimize flexibility, creativity, and productivity.

 Process patterns defining development activities

o Backlog (prioritized list of requirements or features the provide business value to customer,
items can be added at any time)
o Sprints (work units required to achieve one of the backlog items, must fir into a predefined
time-box, affected backlog items frozen)
o Scrum meetings (15 minute daily meetings) addressing these questions:

 What was done since last meeting?

 What obstacles were encountered?
 What will be done by the next meeting?
 o Demos (deliver software increment to customer for evaluation).It is important to note that the
demo may not contain all planned functionality.

4. Crystal

 Development approach that puts a premium on maneuverability during a resource-limited game of

invention and communication with the primary goal of delivering useful software and a secondary
goal of setting up for the next game
 Crystal principles
o Its always cheaper and faster to communicate face-to-face
o As methodologies become more formal teams become weighed down and have trouble
adapting to project work vagaries
o As projects grow in size, teams become larger and methodologies become heavier
o As projects grow in criticality some degree of formality will need to be introduced in parts of
the methodology
o As feedback and communication become more efficient the need for intermediate work
products is reduced
o Discipline, skills, and understanding counter process, formality, and documentation
o Team members not on the critical project path can spend their excess time improving the
product or helping people who are on the critical path
 Incremental development strategy used with 1 to 3 month time lines
 Reflection workshops conducted before project begins, during increment development activity, and
after increment is delivered
 Crystal methodologies
o Clear (small, low criticality projects)
o Orange (larger, moderately critical projects)
o Orange Web (typical e-business applications)

5. Feature Driven Development (FDD)

 Practical process model for object-oriented software engineering

 Feature is a client-valued function, can be implemented in two weeks or less
 FDD Philosophy
o Emphasizes collaboration among team members
o Manages problem and project complexity using feature-based decomposition followed
integration of software increments
o Technical communication using verbal, graphical, and textual means
o Software quality encouraged by using incremental development, design and code inspections,
SQA audits, metric collection, and use of patterns (analysis, design, construction)

 Framework activities
o Develop overall model (contains set of classes depicting business model of application to be
built)
 o Build features list (features extracted from domain model, features are categorized and
prioritized, work is broken up into two week chunks)
o Plan by feature (features assessed based on priority, effort, technical issues, schedule
dependencies)
o Design by feature (classes relevant to feature are chosen, class and method prologs are
written, preliminary design detail developed, owner assigned to each class, owner responsible
for maintaining design document for his or her own work packages)
o Build by feature (class owner translates design into source code and performs unit testing,
integration performed by chief programmer)

6. Lean Software Development (LSP)

 Lean software development (LSD) is a translation of lean manufacturing principles and practices to
the software development domain. Adapted from the Toyota Production System,[1] it is emerging with
the support of a pro-lean subculture within the Agile community. Lean offers a solid conceptual
framework, values and principles, as well as good practices derived from the experience, that supports
agile organizations.

 The term lean software development originated in a book by the same name, written by
Mary Poppendieck and Tom Poppendieck.[2] The book restates traditional lean principles, as
well as a set of 22 tools and compares the tools to corresponding agile practices. The
Poppendiecks' involvement in the Agile software development community, including talks at
several Agile conferences [3] has resulted in such concepts being more widely accepted within
the Agile community.

Lean principles

Lean development can be summarized by seven principles, very close in concept to lean manufacturing
principles:

1. Eliminate waste

In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or
the result could be achieved without it, it is waste. Partially done coding eventually abandoned
during the development process is waste. Extra processes like paperwork and features not often used
by customers are waste. Switching people between tasks is waste. Waiting for other activities, teams,
processes is waste. Motion required to complete work is waste. Defects and lower quality are waste.
Managerial overhead not producing real value is waste.

2. Amplify learning

 Software development is a continuous learning process based on iterations when writing code.
Software design is a problem solving process involving the developers writing the code and what
they have learned. Software value is measured in fitness for use and not in conformance to
requirements.

 Instead of adding more documentation or detailed planning, different ideas could be tried by writing
code and building. The process of user requirements gathering could be simplified by presenting
screens to the end-users and getting their input. The accumulation of defects should be prevented by
running tests as soon as the code is written.

 The learning process is sped up by usage of short iteration cycles – each one coupled with
refactoring and integration testing. Increasing feedback via short feedback sessions with customers
 helps when determining the current phase of development and adjusting efforts for future
improvements. During those short sessions both customer representatives and the development team
learn more about the domain problem and figure out possible solutions for further development.
Thus the customers better understand their needs, based on the existing result of development efforts,
and the developers learn how to better satisfy those needs. Another idea in the communication and
learning process with a customer is set-based development – this concentrates on communicating the
constraints of the future solution and not the possible solutions, thus promoting the birth of the
solution via dialogue with the customer.

 Decide as late as possible

 As software development is always associated with some uncertainty, better results should be
achieved with an options-based approach, delaying decisions as much as possible until they can be
made based on facts and not on uncertain assumptions and predictions. The more complex a system
is, the more capacity for change should be built into it, thus enabling the delay of important and
crucial commitments. The iterative approach promotes this principle – the ability to adapt to changes
and correct mistakes, which might be very costly if discovered after the release of the system.

 An agile software development approach can move the building of options earlier for customers, thus
delaying certain crucial decisions until customers have realized their needs better. This also allows
later adaptation to changes and the prevention of costly earlier technology-bounded decisions. This
does not mean that no planning should be involved – on the contrary, planning activities should be
concentrated on the different options and adapting to the current situation, as well as clarifying
confusing situations by establishing patterns for rapid action. Evaluating different options is effective
as soon as it is realized that they are not free, but provide the needed flexibility for late decision
making.

4. Deliver as fast as possible

 In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end
product is delivered without major defects, the sooner feedback can be received, and incorporated into the
next iteration. The shorter the iterations, the better the learning and communication within the team. With
speed, decisions can be delayed. Speed assures the fulfilling of the customer's present needs and not what they
required yesterday. This gives them the opportunity to delay making up their minds about what they really
require until they gain better knowledge. Customers value rapid delivery of a quality product.

5. Empower the team

There has been a traditional belief in most businesses about the decision-making in the organization
– the managers tell the workers how to do their own job. In a "Work-Out technique", the roles are
turned – the managers are taught how to listen to the developers, so they can explain better what
actions might be taken, as well as provide suggestions for improvements. The lean approach follows
the Agile Principle[7] "find good people and let them do their own job,"[8] encouraging progress,
catching errors, and removing impediments, but not micro-managing.

6. Build integrity in

The customer needs to have an overall experience of the System. This is the so-called perceived
integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, its price
and how well it solves problems.

7. See the whole

 Software systems nowadays are not simply the sum of their parts, but also the product of their
interactions. Defects in software tend to accumulate during the development process – by
decomposing the big tasks into smaller tasks, and by standardizing different stages of development,
the root causes of defects should be found and eliminated. The larger the system, the more
organizations that are involved in its development and the more parts are developed by different
teams, the greater the importance of having well defined relationships between different vendors, in
order to produce a system with smoothly interacting components. During a longer period of
development, a stronger subcontractor network is far more beneficial than short-term profit
optimizing, which does not enable win-win relationships.

Agile Modeling

 Practice-based methodology for effective modeling and documentation of software systems in a

light-weight manner
 Modeling principles
o Model with a purpose
o Use multiple models
o Travel light (only keep models with long-term value)
o Content is more important than representation
o Know the models and tools you use to create them
o Adapt locally
 Requirements gathering and analysis modeling
o Work collaboratively to find out what customer wants to do
o Once requirements model is built collaborative analysis modeling continues with the
customer
 Architectural modeling
o Derives preliminary architecture from analysis model
o Architectural model must be realistic for the environment and must be understandable by
developers.