Agile Important questions:

13 marks:

1.Agile manifesto and principles:

It was formulated by seventeen software developers who gathered in February 2001 in the
Wasatch Mountains of Utah to try to find common ground for their perceptions of the
software development process.
The mere formulation of the Agile Manifesto implies that though there are agreed upon common
principles and ideas, they can be applied differently by specific development methods.
Indeed, the Agile Manifesto is applied by different agile methods, such as Extreme
Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven
Development, and others.

The 4 Core Values of Agile are:

1. Individuals and interactions over processes and tools
This principle encourages software developers to give high priority to the people who
participate in the development process, as well as to their interaction and communication
when they develop, interact, think, discuss, and make decisions with respect to different
issues related to the software development process and environment.
•Strong players: a must, but can fail if don’t work together.
•Strong player: not necessarily an ‘ace;’ work well with others!
•Communication and interacting is more important than raw talent.
•‘Right’ tools are vital to smooth functioning of a team.
•Start small. Find a free tool and use until you can demo you’ve outgrown it. Don’t assume
bigger is better. Start with white board; flat files before going to a huge database.
•Building a team more important than building environment.
1. Some managers build the environment and expect the team to fall together.
2. Doesn’t work.
3. Let the team build the environment on the basis of need.

2. Working software over comprehensive documentation

This principle affirms that the main goal of software projects is to produce quality software
products. This idea has three main implications
● First, agile software development focuses on the development itself and the creation
of only those documents that are needed for the development process.
● Second, agile software development processes start the product’s actual
development (that is, coding) as soon as possible, in order to get some sense of the
developed product.
 ● Third, from the customers’ perspective, this principle helps ensure that customers
get a bugless high quality system that meets their requirements.

3. Customer collaboration over contract negotiation

● It encourages agile software developers to base their work on ongoing and daily
contact with the customer.
● Such a close contact enables customers to cope successfully with the changes that
characterize software projects.
● Human interrelationships, mainly between customer and management, are
emphasized by this principle of the manifesto.
● This principle also points to a conceptual change with respect to the nature and
formulation of software product contracts
● Key is intense collaboration with customer and a contract that governed collaboration
rather than details of scope and schedule
1. Details ideally not specified in contract.
2. Rather contracts could pay when a block passed customer’s acceptance tests.
3. With frequent deliverables and feedback, acceptance tests never an issue.
4. Responding to change over following a plan
● This principle encourages agile software developers to establish a process that copes
successfully with changes introduced during development, without compromising
the high quality of the developed product.
● Better planning strategy – make detailed plans for the next few weeks, very rough
plans for the next few months, and extremely crude plans beyond that.
● Need to know what we will be working on the next few weeks; roughly for the next few
months; a vague idea what system will do after a year.
● Only invest in a detailed plan for immediate tasks; once plan is made, difficult to
change due to momentum and commitment.
1. But rest of plan remains flexible. The lower resolution parts of the plan can be
changed with relative ease.
The Agile Manifesto, as it has become known, is a very simple and concise declaration that
seeks to turn the traditional view of software development on its head. The manifesto is
based on 12 principles

Principle 1: Our Highest Priority is to Satisfy the Customer through Early and Continuous
Delivery of Valuable Software:
Customers are happier when they receive working software at regular intervals, rather
than waiting extended periods of time between releases.
• Strong correlation between quality and early delivery of a partially functioning system.
1. The less functional the initial delivery, the higher the quality of the final delivery.
•Agile processes deliver early and often.
1. Rudimentary system first followed by systems of increasing functionality every few
weeks.
2. Customers my use these systems in production, or
3. May choose to review existing functionality and report on changes to be made.
4. Regardless, they must provide meaningful feedback.
Principle 2: Welcome Changing Requirements, even late in Development. Agile Processes
harness change for the Customer’s Competitive Advantage.
● The ability to avoid delays when a requirement or feature request changes.
● Participants in an agile process are not afraid of change.
1. Requirement changes are good;
2. Mean team has learned more about what it will take to satisfy the market.
● Agile teams work to keep the software structure flexible, so requirement change impact
is minimal.
● Moreso, the principles of object oriented design help us to maintain this kind of
flexibility.
Principle 3: Deliver Working Software Frequently
● From a couple of weeks to a couple of months, with a preference to the shorter timescale.
● Scrum accommodates this principle since the team operates in software sprints or
iterations that ensure regular delivery of working software.
● The goal of delivering software that satisfies the customer’s needs.

Principle 4: Business People and Developers Must Work Together Daily throughout the
Project.
● Better decisions are made when the business and technical team are aligned.
● An agile project must be continuously guided.

Principle 5: Build Projects around Motivated Individuals. (Give them the environment
and support they need, and trust them to get the job done.)
•An agile project has people the most important factor of success.
•All other factors, process, environment, management, etc., are considered to be second order
effects, and are subject to change if they are having an adverse effect upon the people.
•Example: if the office environment is an obstacle to the team, change the office environment.
•If certain process steps are obstacles to the team, change the process steps.
Principle 6: The Most Efficient and Effective Method of Conveying Information to and
within a Development Team is face-to-face Communications.
•In agile projects, developers talk to each other.
1. The primary mode of communication is conversation.
2. Documents may be created, but there is no attempt to capture all project information in
writing.
•An agile project team does not demand written specs, written plans, or written designs.
1. They may create them if they perceive an immediate and significant need, but they are
not the default.
2. The default is conversation.
Principle 7: Working Software is the Primary Measure of Progress
•Agile projects measure their progress by measuring the amount of working software.
1. Progress not measusred by phase we are in, or
2. by the volume of produced documentation or
3. by the amount of code they have created.
Agile teams are 30% done when 30% of the necessary functionality is working.
Principle 8: Agile Processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
•An agile project is not run like a 50 yard dash; it is run like a marathon.
1. The team does not take off at full speed and try to maintain that speed for the duration.
2. Rather they run at a fast, but sustainable, pace.
•Running too fast leads to burnout, shortcuts, and debacle.
•Agile teams pace themselves.
1. They don’t allow themselves to get too tired.
2. They don’t borrow tomorrow’s energy to get a bit more done today.
3. They work at a rate that allows them to maintain the highest quality standards for the
duration of the project.
Principle 9: Continuous Attention to Technical Excellence and Good Design enhances
Agility.
The right skills and good design ensures the team can maintain the pace, constantly
improve the product, and sustain change.
•High quality is the key to high speed.
•The way to go fast is to keep the software as clean and robust as possible.
•Thus, all agile team-members are committed to producing only the highest quality code they
can.
•They do not make messes and then tell themselves they’ll clean it up when they have more time.
Principle 10: Simplicity – the art of maximizing the amount of work not done – is essential.
•Agile teams take the simplest path that is consistent with their goals.
•They don’t anticipate tomorrow’s problems and try to defend against them today.
•Rather they do the simplest and highest quality work today, confident that it will be easy to
change if and when tomorrow's problems arise.
Principle 11: The Best Architectures, Requirements, and Designs emerge from
Self-Organizing Teams
•An agile team is a self organizing team.
–Responsibilities are not handed to individual team members from the outside.
–Responsibilities are communicated to the team as a whole, and the team determines the best
way to fulfill them.
•Agile team members work together on all project aspects.
–Each is allowed input into the whole.
–No single team member is responsible for the architecture, or the requirements, or the tests, etc.
–The team shares those responsibilities and each team member has influence over them.
Principle 12: At regular Intervals, the Team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
•An agile team continually adjusts its organization, rules, conventions, relationships, etc.
•An agile team knows that its environment is continuously changing, and knows that they must
change with that environment to remain agile.

2.AGILE PROJECT MANAGEMENT:

● Agile project management is an iterative approach to managing software development
projects that focuses on continuous releases and incorporating customer feedback with
every iteration.
● Software teams that embrace agile project management methodologies increase their
development speed, expand collaboration, and foster the ability to better respond to
market trends.
● The Agile methodology allows teams to re-evaluate the work they are doing and adjust in
given increments to make sure that as the work and customer landscape changes, the
focus also changes for the team.
● Agile Project Management is one of the revolutionary methods introduced for the
practice of project management. This is one of the latest project management strategies
that is mainly applied to project management practice in software development.
Therefore, it is best to relate agile project management to the software development
process when understanding it.
● From the inception of software development as a business, there have been a number of
processes following, such as the waterfall model. With the advancement of software
development, technologies and business requirements, the traditional models are not
robust enough to cater the demands.
● Therefore, more flexible software development models were required in order to address
the agility of the requirements. As a result of this, the information technology community
developed agile software development models.
● 'Agile' is an umbrella term used for identifying various models used for agile
development, such as Scrum. Since the agile development model is different from
conventional models, agile project management is a specialized area in project
management.

The Agile Process

It is required for one to have a good understanding of the agile development process in order to
understand agile project management.
4 core values of Agile:
1. Individuals and interactions over processes and tools
“Individuals and interactions over processes and tools” is the first value in the Agile Manifesto.
It basically refers to valuing individuals more highly than processes or tools because it is
individuals who respond to the business/customer needs and take the process forward.
2. Working software over comprehensive documentation:
Documentation is an important part of Agile manifesto – but working software is even more
important. The Agile approach focuses on streamlining data (technical specifications, technical
requirements, technical prospectus, interface design documents, test plans, etc) so that the team
can begin and keep up the pace at work without getting bogged down into the details.
3. Customer collaboration over contract negotiation:
Negotiation is when the customer and the manager/teams work out the details right before the
project delivery. However, in the Agile Manifesto, the customer is not only engaged at the time
of the final delivery. Instead, the Agile approach engaged and collaborated with the customer
throughout the development process.
4. Responding to change over following a plan:
Traditionally, change was seen as an added expense, so it was to be avoided. However, in the
Agile manifesto, change is seen as a potential opportunity to improve, develop better results.

Agile Project Management Principles:

● Customer satisfaction
● Welcome change
● Deliver frequently
● Working together
● Motivate teams
● Face-to-face
● Working software
● Control pace
● Good Design
● Simplicity
● Self Organization
● Reflect and adjust

Scope of Agile Project Management

● In an agile project, the entire team is responsible in managing the team and it is not just
the project manager's responsibility. When it comes to processes and procedures, the
common sense is used over the written policies.
● This makes sure that there is no delay is management decision making and therefore
things can progress faster.
 ● In addition to being a manager, the agile project management function should also
demonstrate the leadership and skills in motivating others. This helps retaining the spirit
among the team members and gets the team to follow discipline.
● Agile project manager is not the 'boss' of the software development team. Rather, this
function facilitates and coordinates the activities and resources required for quality and
speedy software development.

What Is The Agile Project Management Process?

Responsibilities of an Agile Project Manager:

The responsibilities of an agile project management function are given below. From one project
to another, these responsibilities can slightly change and are interpreted differently.
•Responsible for maintaining the agile values and practices in the project team.
•The agile project manager removes impediments as the core function of the role.
•Helps the project team members to turn the requirements backlog into working software
functionality.
•Facilitates and encourages effective and open communication within the team.
•Responsible for holding agile meetings that discusses the short-term plans and plans to
overcome obstacles.
•Enhances the tool and practices used in the development process.
•Agile project manager is the chief motivator of the team and plays the mentor role for the team
members as well.

Agile Project Management does not

● manage the software development team.
● overrule the informed decisions taken by the team members.
● direct team members to perform tasks or routines.
● drive the team to achieve specific milestones or deliveries.
● assign task to the team members.
● make decisions on behalf of the team.
● involve in technical decision making or deriving the product strategy.

3.TRADITIONAL VS AGILE MODEL:

Refer notes:

There are many differences in agile development model when compared to traditional
models:
● The agile model emphasizes on the fact that entire team should be a tightly integrated
unit. This includes the developers, quality assurance, project management, and the
customer.
● Frequent communication is one of the key factors that makes this integration possible.
Therefore, daily meetings are held in order to determine the day's work and
dependencies.
● Deliveries are short-term. Usually a delivery cycle ranges from one week to four weeks.
These are commonly known as sprints.
● Agile project teams follow open communication techniques and tools which enable the
team members (including the customer) to express their views and feedback openly and
quickly. These comments are then taken into consideration when shaping the
requirements and implementation of the software.

4.AGILE SOFTWARE DEVELOPMENT:

In general, agile software development offers a professional approach to software development

that encompasses human, organizational, and technological aspects of software development
processes.
Three Perspectives on Software Engineering:

Software engineering is the profession that applies scientific knowledge to the construction of
software products needed by customers.

A software development method is a set of activities and practices, as well as roles and norms of
behavior, derived from a set of professional aims, which are carried out in a logical and specified
order.

A software development method should address not only the technological aspects, but also the
work environment and the professional framework and has three perspectives

1. The Human perspective, which includes cognitive and social aspects, and refers to
learning and interpersonal (teammates, customers, management) processes.
2. lThe Organizational perspective, which includes managerial and cultural aspects, and
refers to the workspace and issues that extend beyond the team.
3. The Technological perspective, which includes practical and technical aspects, and refers
to how-to and code-related issues.

The Agile Manifesto

1. Individuals and interactions over processes and tools
“Individuals and interactions over processes and tools” is the first value in the Agile Manifesto.
It basically refers to valuing individuals more highly than processes or tools because it is
individuals who respond to the business/customer needs and take the process forward.
2. Working software over comprehensive documentation:
Documentation is an important part of Agile manifesto – but working software is even more
important. The Agile approach focuses on streamlining data (technical specifications, technical
requirements, technical prospectus, interface design documents, test plans, etc) so that the team
can begin and keep up the pace at work without getting bogged down into the details.
3. Customer collaboration over contract negotiation:
Negotiation is when the customer and the manager/teams work out the details right before the
project delivery. However, in the Agile Manifesto, the customer is not only engaged at the time
of the final delivery. Instead, the Agile approach engaged and collaborated with the customer
throughout the development process.
4. Responding to change over following a plan:
Traditionally, change was seen as an added expense, so it was to be avoided. However, in the
Agile manifesto, change is seen as a potential opportunity to improve, develop better results.

Application of Agile Software Development:

Whole team. The practice of Whole Team means that the development team (including all
developers and the customer) should communicate in a faceto-face fashion as much as possible.

Short releases: Agile software development processes are based on short

releases of about two months, divided into short iterations of one or two weeks,
during which the scope of what is to be developed in that iteration is not changed.
At the end of each iteration the software is presented to the customer and the
customer provides feedback to the team and sets the development requirements
for the next iteration.

Time estimations: In agile software development two important practices are performed with
respect to time estimation.
First, the teammate who is in charge of the development of a specific task also estimates the time
needed for its development; this practice increases the team member’s responsibility and
commitment to the project.
Second, development tasks are formulated in a way that allows their time estimation to be set in
hour resolution.

Measures: In order to navigate the development process so that a high quality product is
produced, agile software development processes are accompanied by various measures about
which all the project stakeholders decide according to their needs

Customer collaboration: Agile software development methods encourage the customer to

become part of the development process. The goal is to get ongoing feedback from the customers
and to proceed according to their needs.
Test-driven development. Test-driven software development encourages developers to build
automatic unit and acceptance tests.
In agile software development, both unit and acceptance tests are integrated within the
development process itself.

Pair programming: This practice means that each code is developed by two teammates who sit
together in front of a computer and in an interactive, communication-based process work on a
specific development task

Refactoring: The practice of refactoring encourages teammates to improve code readability

without adding functionality.

CLASSIFICATION OF AGILE METHODS:

● Extreme Programming
● SCRUM
● Dynamic Software Development Method(DSDM)
● Adaptive Software Development
● Crystal
● Lean Software Development
● Feature-Driven Development
● Kanban
1.EXTREME PROGRAMMING:
Two of XP’s practices address the Agile Principles about individuals and teams: The
Planning Game and collective ownership
● Extreme Programming, or XP, is an Agile method that emerged from a project at Chrysler
Corporation in the late 1990s. It was devised by Ward Cunningham, Kent Beck, and Ron
Jeffries.
● It is best known for pair programming, continuous integration, no analysis or design
phase, and no explicit system test and quality assurance department or phase, though
there is a user acceptance test stage for each completed iteration.
● Conservative businesses tend to be afraid of XP because of the lack of visibility into the
development process. However, when the XP Planning Game is used properly, XP does
lend itself to Throughput-based measurement and control and can be used with
Throughput Accounting to calculate profitability and return on investment.
Extreme Programming builds on these activities and coding. It is the detailed (not the only)
design activity with multiple tight feedback loops through effective implementation, testing and
refactoring continuously.
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.

2.SCRUM:
Scrum’s practice, “Scrum teams,” deals with the Agile Principles about individuals and
teams
Scrum is a software management method that can be applied to other Agile methods, such as XP.
It can be used as a management wrapper for other software development lifecycle methods
because it is agnostic to the particular software development lifecycle method
Scrum organizes development work into three levels: Sprints, Releases, and Products. A Sprint is
strictly 30 days (or 4 working weeks). A Release is typically a number of Sprints and may be as
many as 6 to 9 Sprints. A Product is a series of Releases.
The requirements are converted into a list of client-valued functionality known as the Product
Backlog. The Product Backlog can be added to over time and is not necessarily fixed at the start
of a project. For each Release, a subset of the Product Backlog is called off and becomes the
Release Backlog. For each Sprint, a subset of the Release Backlog is called off and becomes the
Sprint Backlog. The Sprint Backlog is indivisible and cannot be altered once agreed. The
development team can then work with absolute certainty on the 30-day Sprint knowing that the
Sprint Backlog cannot change.

3.DSDM:

DSDM’s second principle (empowered teams), directly relates to the Agile Principles about
individuals and teams

DSDM is a rapid application development strategy for software development and gives an agile
project distribution structure. The essential features of DSDM are that users must be actively
connected, and teams have been given the right to make decisions. The techniques used in
DSDM are:

1. Time Boxing

2. MoSCoW Rules

3. Prototyping
The Eight Principles

The eight Principles of DSDM:

1. Focus on the business need

2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build incrementally from firm foundations
6. Develop iteratively
7. Communicate continuously and clearly
8. Demonstrate control
9.
4.Adaptive Software Development

Three of ASD’s philosophies bear directly on the Agile Principles about individuals and
teams: project stakeholders as independent agents, speculation about project mission and
adaptive plans, and the Leadership-Collaboration Management Model.

Adaptive Software Development practices provide ability to accommodate change and are
adaptable in turbulent environments with products evolving with little planning and learning.

Phases of ASD Life Cycle

Adaptive Software Development is cyclical like the Evolutionary model, with the phase names
reflecting the unpredictability in the complex systems. The phases in the Adaptive development
life cycle are −
● Speculate
● Collaborate
● Learn
5.CRYSTAL:
Crystal method is an agile software development approach that focuses primarily on people and
their interactions when working on a project rather than on processes and tools

There are three concepts of this method-

1. Chartering: Multi activities are involved in this phase such as making a development
team, performing feasibility analysis, developing plans, etc.

2. Cyclic delivery: under this, two more cycles consist, these are:

A. Team updates the release plan.

B. Integrated product delivers to the users.

 3. Wrap up: According to the user environment, this phase performs deployment,
post-deployment.

6.FDD:

Two of FDD’s practices (class ownership and feature teams) illustrate the Agile Principles
about individuals and teams

FDD stands for Feature-Driven Development. It is an agile iterative and incremental model
that focuses on progressing the features of the developing software. The main motive os
feature-driven development is to provide timely updated and working software to the client. In
FDD, reporting and progress tracking is necessary at all levels.

FDD Lifecycle
● Build overall model
● Build feature list
● Plan by feature
● Design by feature
● Build by feature

KANBAN:
 ● The Kanban board is used to visualize the workflow. The Kanban board is normally put
up on a wall in the project room. The status and progress of the story development tasks
is tracked visually on the Kanban board with flowing Kanban cards.
● The tasks and stories are represented by Kanban cards. The current status of each task is
known by displaying the cards in separate columns on the board. The columns are labeled
as To Do, Doing, and Done. Each task moves from To Do to Doing and then to Done.
● Kanban Board is updated on a daily basis as the team progresses through the
development.

Lean Software Development:

Two of the tools under LD’s Empower the Team principle (selfdetermination and
motivation) address the Agile Principles about individuals and teams

Lean software development methodology follows the principle "just in time production." The
lean method indicates the increasing speed of software development and reducing costs. Lean
development can be summarized in seven phases.

1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole

Ethics in Agile Teams:

Codes of ethics guide professionals how to behave in vague situations when it is not clear what is
right and what is wrong. The need for a code of ethics arises from the fact that any profession
generates situations that can neither be predicted nor answered uniformly by all members of the
relevant professional community.

Software engineers shall commit themselves to making the analysis, specification, design,
development, testing and maintenance of software a beneficial and respected profession. In
accordance with their commitment to the health, safety, and welfare of the public, software
engineers shall adhere to the following Eight Principles:

1. PUBLIC|Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER|Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public interest.

the fact that the customer is in close interaction with the team and the fact that all the project
stakeholders hear the customers’ requirements, further support the enhancement of this section of
the code of ethics. The acceptance tests that are defined together with the customer further boost
the ability to achieve ethical behavior in this respect.

3. PRODUCT|Software engineers shall ensure that their products and related modifications meet
the highest professional standards possible.

Ethical behavior in this respect is achieved by several agile practices, such as measures, testing ,
and refactoring

4. JUDGMENT|Software engineers shall maintain integrity and independence in their

professional judgment.

Integrity is maintained by the fact that agile team members are encouraged to raise problems
they encounter, to discuss dilemmas, and to express their concerns. Several kinds of
opportunities are provided to agile team members for dealing with these subjects, such as
reflective and retrospective sessions.

5. MANAGEMENT|Software engineering managers and leaders shall subscribe to and promote

an ethical approach to the management of software development and maintenance.

6. PROFESSION Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.

This section talks about the profession of software engineering. The standards that agile software
development sets for the profession emphasize responsibility, accountability, fairness, and trust

7. COLLEAGUES|Software engineers shall be fair to and supportive of their colleagues.

8. SELF Software engineers shall participate in lifelong learning regarding the practice of their
profession and shall promote an ethical approach to the practice of the profession.

This section of the code of ethics looks at the relationships among the individuals in a software
development process and advocates fairness and support among them. This idea is fostered by
the Agile Manifesto.

In conclusion, we emphasize that by making the development process more transparent, agile
software development supports ethical behavior. This is because a more transparent process
means that behaviors are more visible; consequently, norms can be set and adhered to and ethical
behavior is therefore more easily supported. As a result, trust and communication are increased
among team members.

AGILE DESIGN REFER BOOK:

AGILE TESTING:
“testing” is not a phase at the end of the project. Instead, it is an activity that the entire
development team is engaged in throughout the life of the project.
Each Agile method has a unique view of testing and other quality activities. They all place the
responsibility for quality squarely in the hands of the developers. None of the Agile methods
even addresses the concept of independent verification and validation (V&V) beyond the
customer’s acceptance test (although there is no reason why independent V&V cannot be done
on an Agile project).
Testing by the developers is integrated into the development activities in most Agile methods.
This establishes a whole new definition for “coding complete.”
Instead of feeling that they are done when the code compiles and a cursory unit test of some
kind succeeds, the Agile methods expect developers to perform a complete set of tests on their
code.
XP’s “test first” practice calls for developers to write their test cases first, then develop code to
pass the tests.
But even after completing a full battery of tests, the developers’ work is still not done. Peer
reviews are a common element of the Agile methods.
Although each method addresses this subject differently, the result is that (in the methods that
include peer reviews), the developer’s code must clear this additional hurdle in order to be
“done.”
Finally, integration testing is also the responsibility of each developer,.

MORE REFER BOOK

AGILE DOCUMENTATION:

Purpose of a document
To communicate information.
documents as a form of communication are limited by the amount of information they can
convey, because they consist merely of words and have no other cues to help the reader
understand them
The value of a document lies in its persistence.
There are two project-related purposes for which written documents :
1. The first purpose is to provide information in preparation for person to-person
interaction.
2. The other purpose is to record the results of person-to-person interactions

The content of the documentation should aim to provide just enough data and no more, i.e., it
should be sufficient, just, it should have a purpose, it should have an audience for whom the
document is meaningful (and thus to whom the level of detail is appropriate) and it should be
sufficiently accurate.
The documentation should also hold data when appropriate and refer it elsewhere when
appropriate.
Finally, don’t document information when you expect the information to change (unless
documentation is necessary to help make the change).
REFER BOOK

AGILE DRIVERS:
● In ISD, the emergence of agile methods has been explained as arising from the need to
handle change .
● The rationale behind agile methods such as XP and SCRUM that is most cited is their
ability to handle requirement changes, and not necessarily all of the changes that an ISD
team may have to face. Therefore, the first part of the framework identifies a more
comprehensive set of potential sources of change.
● The internal factors incorporate changes that originate from actors within the
development organization .
● Changing customer requirements is irrefutably a major source of change in ISD (Lederer
and Prasad, 1991), and has been described by Forte (1997) as the most common “killer”
of software projects.
● However, this framework lists all of the entities in an ISD team’s immediate
environment, which includes, but is not restricted to, changes arising from the customer.
● Suppliers can be in the form of software and technology vendors and external consultants
or contractors, all of whom may initiate change.
● For example, products from Oracle or Sybase that are used in the development process
will naturally determine certain aspects of the company’s development effort. The
introduction of a rival feature by a competitor product may also drive change.
● The development project’s general environment consists of entities or trends regarding
culture, resources, and politics, which may impact the ISD project, but does not maintain
a close day-to-day relationship with the team.
● Trends such as offshore contracting and the transferral of jobs to low-wage countries such
as India have reduced the demand for highly skilled developers and this will lead to a
shift in human resource trends in the country in which the company operates.
● A team should analyze these sources of change and identify which are applicable to them
and which are not. Some will always be a source of change, such as customer
requirements. However, some depend on the context of the project.
Agile Capabilities:
● Once an ISD team has identified the potential sources of change it faces, it can conduct
an analysis of the ability of its current or future activities to handle such change.
● The literature on agility is complex and often inconsistent. There tends to be overlap
between the concepts of agility, flexibility, and leanness.
● Notwithstanding this, the following conceptualization of agility has been synthesized
from the literature.
Creation:
Agility focuses on “new ways of running businesses,” and “casting off old ways of doing
things” . Agility is “aggressively change embracing”and is “a never-ending quest to do
things better than the competition”.

Proaction:
Golden and Powell (2000) discuss the contrast between proactive and reactive flexibility.
This concept recognizes the fact that an entity is not helpless while waiting for change to
occur and that steps can be taken in advance of change as well as in response to it.

Reaction:
Reaction is the most common interpretation of agility, defined as the ability to adapt to
change. Even within this relatively simple component of agility, there exist different
notions as to what it represents.

Learning:
Learning in an ISD context is where the project team learns from the change process so
as to be more creative, proactive, and reactive during the next cycle. Learning in this
context does not mean learning of skills per se. It only refers to the ability to learn from
change.

AGILE VALUE:

● Identifying and handling change, or in other words being agile, requires resources.
● The cost of developing a prototype and the amount of time taken to run a
prototyping session must be weighed against the number of requirements usually
elicited by such sessions.
● Given the law of diminishing returns, running too many sessions will be very
costly, and the average number of requirements elicited per session will fall.
● Therefore, conducting prototyping sessions only contributes to agility if done in
moderation.
● Through an analysis of the ISD literature, it can be seen that an ISD method can
add value in two ways.
● First, the method can ensure that every part of the system being developed
provides some value to the customer.
● The second means by which a method can add value is through the value attached
to the parts of the method itself.
● A practitioner should not “implement the approach in its entirety,” but should
“make value judgements on what meets their needs” (Boehm and Turner, 2003).