Agile development

Agility:

Agility refers to the ability of teams and organizations to quickly and effectively respond to change.
It is about being flexible, adaptive, and proactive in addressing challenges and opportunities. Agility
enables teams to deliver value continuously, improve processes, and meet customer needs more
effectively.

Agile Process

The Agile process involves breaking the project into small, manageable parts called "iterations" or
"sprints." Each sprint is a short period (usually 1-4 weeks) where the team plans, develops, tests, and
reviews a piece of the project. The goal is to have a working part of the software at the end of each
sprint.

Agile Software Development

Agile Software Development is a software development methodology that values flexibility,

collaboration, and customer satisfaction. It is based on the Agile Manifesto, a set of principles for
software development that prioritize individuals and interactions, working software, customer
collaboration, and responding to change.

Agile Software Development is an iterative and incremental approach to software development that
emphasizes the importance of delivering a working product quickly and frequently. It involves close
collaboration between the development team and the customer to ensure that the product meets
their needs and expectations.

Principles of Agile Software Development

Agile principles are the foundational guidelines that drive Agile project management and software
development. These principles are part of the Agile Manifesto

Customer Satisfaction: The highest priority is to satisfy the customer through early and
continuous delivery of valuable software.

Welcome Change: Even late in development, Agile processes harness change for the
customer's competitive advantage.

Frequent Delivery: Deliver working software frequently, with a preference for shorter
timescales, from a couple of weeks to a couple of months.

Collaboration: Business people and developers must work together daily throughout the
project.

Motivated Individuals: Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.

Face-to-Face Communication: The most efficient and effective method of conveying

information within a development team is through face-to-face conversation.

Working Software: Working software is the primary measure of progress.

Sustainable Pace: Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.

Technical Excellence: Continuous attention to technical excellence and good design

enhances agility.

Simplicity: Simplicity—the art of maximizing the amount of work not done—is essential.

Self-Organizing Teams: The best architectures, requirements, and designs emerge from self-
organizing teams.

Reflect and Adjust: At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behaviour accordingly.

The Agile Software Development Process

Requirements Gathering: The customer’s requirements for the software are gathered and
prioritized.

Planning: The development team creates a plan for delivering the software, including the features
that will be delivered in each iteration.

Development: The development team works to build the software, using frequent and rapid
iterations.

Testing: The software is thoroughly tested to ensure that it meets the customer’s requirements and
is of high quality.

Deployment: The software is deployed and put into use.

Maintenance: The software is maintained to ensure that it continues to meet the customer’s needs
and expectations.
Agile Process Models

1) Extreme programming (XP)

2) Scrum
3) Dynamic system development method
4) Agile modeling (AM)
5) Agile unified process (AUP)

Extreme Programming (XP)

Extreme Programming uses an object-oriented approach as its preferred development paradigm and
encompasses a set of rules and practices that occur within the context of four framework activities:
planning, design, coding, and testing. Key XP activities are summarized in the paragraphs that follow

Planning. The planning activity begins with listening—a requirements gathering activity, that enables
the technical members of the XP team to understand the business context for the software and to get
a broad feel for required output and major features and functionality.

Listening leads to the creation of a set of “stories” or user stories that describe required output,
features, and functionality for software to be built. Each story is written by the customer and is placed
on an index card. The customer assigns a value (i.e., a priority) to the story based on the overall
business value of the feature or function. Members of the XP team then assess each story and assign
a cost—measured in development weeks—to it.
If the story is estimated to require more than three development weeks, the customer is asked to split
the story into smaller stories and the assignment of value and cost occurs again. It is important to note
that new stories can be written at any time. Customers and developers work together to decide how
to group stories into the next release (the next software increment) to be developed by the XP team.

Once a basic commitment is made for a release, the XP team orders the stories that will be developed
in one of three ways:
(1) all stories will be implemented immediately (within a few weeks),
(2) the stories with highest value will be moved up in the schedule and implemented first, or
(3) the riskiest stories will be moved up in the schedule and implemented first.

After the first project release (also called a software increment) has been delivered, the XP team
computes project velocity. Stated simply, project velocity is the number of customer stories
implemented during the first release. Project velocity can then be used to (1) help estimate delivery
dates and schedule for subsequent releases and (2) determine whether an overcommitment has been
made for all stories across the entire development project.
As development work proceeds, the customer can add stories, change the value of an existing story,
split stories, or eliminate them. The XP team then reconsiders all remaining releases and modifies its
plans accordingly.

Design. XP design rigorously follows the KIS (keep it simple) principle. A simple design is always
preferred over a more complex representation. XP encourages the use of CRC cards as an effective
mechanism for thinking about the software in an object-oriented context. CRC (class- responsibility
collaborator) cards identify and organize the object-oriented classes that are relevant to the current
software increment. The CRC cards are the only design work product produced as part of the XP
process.

If a difficult design problem is encountered as part of the design of a story, XP recommends the
immediate creation of an operational prototype of that portion of the design. Called a spike solution,
the design prototype is implemented and evaluated. The intent is to lower risk when true
implementation starts and to validate the original estimates for the story containing the design
problem

A central notion in XP is that design occurs both before and after coding commences. Refactoring
means that design occurs continuously as the system is constructed. In fact, the construction activity
itself will provide the XP team with guidance on how to improve the design.

Coding. After stories are developed and preliminary design work is done, the team does not move to
code, but rather develops a series of unit tests that will exercise each of the stories that is to be
included in the current release (software increment) Once the unit test has been created, the
developer is better able to focus on what must be implemented to pass the test.

Nothing extraneous is added (KIS). Once the code is complete, it can be unit-tested immediately,
thereby providing instantaneous feedback to the developers. A key concept during the coding activity
is pair programming. XP recommends that two people work together at one computer workstation to
create code for a story. This provides a mechanism for Realtime problem solving and real-time quality
assurance It also keeps the developers focused on the problem at hand. In practice, each person takes
on a slightly different role. For example, one person might think about the coding details of a particular
portion of the design while the other ensures that coding standards are being followed or that the
code for the story will satisfy the unit test that has been developed to validate the code against the
story.

As pair programmers complete their work, the code they develop is integrated with the work of
others. In some cases, this is performed on a daily basis by an integration team. In other cases, the
pair programmers have integration responsibility. This “continuous integration” strategy helps to
avoid compatibility and interfacing problems and provides a “smoke testing” environment that helps
to uncover errors early.

Testing The unit tests that are created should be implemented using a framework that enables them
to be automated This encourages a regression testing strategy whenever code is modified As the
individual unit tests are organized into a “universal testing suite”, integration and validation testing of
the system can occur on a daily basis. This provides the XP team with a continual indication of progress
and also can raise warning flags early if things go awry.

“Fixing small problems every few hours takes less time than fixing huge problems just before the
deadline.”
XP acceptance tests, also called customer tests, are specified by the customer and focus on overall
system features and functionality that are visible and reviewable by the customer. Acceptance tests
are derived from user stories that have been implemented as part of a software release.

Scrum

The Scrum Agile model is a framework within the Agile methodology used to manage and complete
complex projects, primarily in software development. Scrum emphasizes teamwork, accountability,
and iterative progress toward a well-defined goal.

Product Backlog
Product Backlog is a repository where the list of Product Backlog Items stored and maintained by the
Product Owner. The list of Product Backlog Items is prioritized by the Product Owner as high and low
and also could re-prioritize the product backlog constantly.

Sprint
A time-boxed period (usually 2-4 weeks) during which the team works to complete a set of Product
Backlog items. Sprints are the core of Scrum, enabling continuous delivery of value.

Sprint Planning
The first step of Scrum is Sprint Planning Meeting where the entire Scrum Team attends. Here the
Product Owner selects the Product Backlog Items (User Stories) from the Product Backlog.
Most important User Stories at the top of the list and least important User Stories at the bottom.
Scrum Development Team decides and provides the effort estimation.
Sprint Backlog
A sprint backlog is a list of work items Sprint Development Team plans to complete during a
project sprint. These items are usually pulled from the product backlog during the sprint planning
session. A clear sprint backlog prevents scope creep by clarifying exactly what your team will be
doing—and not doing—during each sprint.

Daily Scrum
A short, daily meeting (usually 15 minutes) where the team discusses progress, plans for the day,
and any impediments.

• What did you do since the last team meeting?

What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?

Scrum Master
A team leader, called a Scrum master, leads the meeting and assesses the responses from each
person.
The Scrum meeting helps the team to uncover potential problems as early as possible. Also, these
daily
meetings lead to “knowledge socialization” and thereby promote a self-organizing team structure.

Sprint Review
At the end of the sprint, the team holds a sprint review meeting to demonstrate the work completed
during the sprint. The product owner and other stakeholders review the work and provide feedback.
The Product Owner accepts or rejects it.

Sprint Retrospective
After the sprint review, the team conducts a sprint retrospective to reflect on what went well, what
didn’t, and how they can improve in the next sprint.

Advantages
Flexibility and Adaptability: Scrum’s iterative nature allows teams to adapt to changing
requirements.
Continuous Delivery: Regularly delivering working increments ensures that value is consistently
delivered.
Transparency: Scrum promotes transparency through regular communication and visible progress.
Focus on Customer Needs: The Product Owner ensures that the team works on the most valuable
features.
Improved Collaboration: Scrum encourages close collaboration among team members and
stakeholders.
 Dynamic System Development Method
The Dynamic Systems Development Method is an agile software development approach that
provides a framework for “building and maintaining systems which meet tight time constraints
through the use of incremental prototyping in a controlled project environment”.

The DSDM philosophy is borrowed from a modified version of the Pareto principle—80 percent of
an application can be delivered in 20 percent of the time it would take to deliver the complete
application.

DSDM is an iterative software process in which each iteration follows the 80 percent rule. That is,
only enough work is required for each increment to facilitate movement to the next increment. The
remaining detail can be completed later when more business requirements are known or changes
have been requested and accommodated.

The DSDM Consortium is a worldwide group of member companies that collectively take on the role
of “keeper” of the method. The consortium has defined an agile process model, called the DSDM life
cycle that defines three different iterative cycles, preceded by two additional life cycle activities:

1) Feasibility study
2) Business study
3) Functional model iteration
4) Design and build iteration
5) Implementation
Feasibility study—establishes the basic business requirements and constraints associated with the
application to be built and then assesses whether the application is a viable candidate for the DSDM
process.

Business study—establishes the functional and information requirements that will allow the
application to provide business value; also, defines the basic application architecture and identifies
the maintainability requirements for the application.

Functional model iteration—produces a set of incremental prototypes that demonstrate

functionality for the customer. The intent during this iterative cycle is to gather additional
requirements by eliciting feedback from users as they exercise the prototype.

Design and build iteration—revisits prototypes built 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. In some cases, functional model iteration and design and build iteration occur
concurrently

Implementation—places the latest software increment into the operational environment. It should
be noted that (1) the increment may not be 100 percent complete or (2) changes may be requested
as the increment is put into place. In either case, DSDM development work continues by returning to
the functional model iteration activity

DSDM can be combined with XP to provide a combination approach that defines a solid process
model with the nuts and bolts practices (XP) that are required to build software increments. In
addition, the ASD concepts of collaboration and self-organizing teams can be adapted to a combined
process model

Agile Modeling
Agile Modeling (AM) is a practice-based methodology for modeling and documenting software
systems in an agile manner. It provides guidelines and best practices for effective and lightweight
modeling that can be integrated into agile software development processes, such as Extreme
Programming (XP), Scrum, and others. Agile Modeling focuses on creating models that are "just
enough" to fulfill the current needs of the project without unnecessary complexity or over-
documentation

Agile Model Principles

Model with a Purpose: Every model should have a clear purpose. Whether it's to
understand a problem, communicate ideas, or plan a solution, the model should be useful
and focused.

Maximize Stakeholder Involvement: Engage stakeholders in the modeling process. Their

input ensures that the models reflect real needs and that the team has a shared
understanding of the project.

Use Multiple Models: Different models serve different purposes. Agile Modeling
encourages the use of a variety of models (e.g., use case diagrams, class diagrams,
flowcharts) to provide a comprehensive view of the system.
Travel Light: Create models that are just enough to meet the needs of the project at that
time. Avoid over-documentation and unnecessary details that do not add value.

Embrace Change: Agile projects are inherently flexible, and models should be easy to
update as requirements change. Agile Modeling supports iterative refinement of models to
reflect evolving understanding and requirements.

Model in Small Increments: Build models incrementally, evolving them as the project
progresses. This helps to keep the models relevant and aligned with the current state of the
project.
Use Simple Tools: Focus on simplicity in tools and techniques. Whiteboards, sticky notes,
and simple drawing tools are often sufficient and encourage collaboration.

Collaborate with Others: Modeling should be a collaborative effort, involving the entire
team. This ensures a shared understanding and leverages the collective knowledge and
creativity of the team.

Types of Models in Agile Modeling

Use Case Diagrams: To capture functional requirements and interactions between users and
the system.

Class Diagrams: To represent the structure of the system in terms of objects, classes, and
their relationships.

Sequence Diagrams: To model the sequence of interactions between objects or

components within the system.

Flowcharts: To visualize workflows, processes, or algorithms.

Data Models: To define the structure of data within the system.
Benefits of Agile Modeling
Enhanced Communication: Visual models help communicate complex ideas more
effectively among team members and stakeholders.
Flexibility: Models are easily adaptable to changes, supporting the agile principle of
responding to change over following a fixed plan.
Improved Understanding: Modeling helps the team understand the system, identify
potential issues early, and make informed decisions.
 Agile Unified Process
(AUP) is a simplified version of the IBM Rational Unified Process (RUP).

It describes a simple, easy to understand approach to developing business application software using
agile techniques and concepts yet still remaining true to the RUP.

The AUP applies agile techniques including test driven development (TDD), Agile Modeling, agile
change management, and database refactoring to improve productivity

Discipline

1) Model. Understand the business of the organization, the problem domain being addressed by the
project, and identify a viable solution to address the problem domain.

2) Implementation. Transform model(s) into executable code and perform a basic level of testing, in
particular unit testing.

3) Test. Perform an objective evaluation to ensure quality. This includes finding defects, verifying
that the system works as designed, and validating that the requirements are met.

4) Deployment. Plan for the delivery of the system and to execute the plan to make the system
available to end users.

5) Configuration management. Manage access to project artifacts. This includes not only tracking
artifact versions over time but also controlling and managing changes to them.

6) Project management. Direct the activities that take place within the project. This includes
managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with
people and systems outside the scope of the project to be sure that it is delivered on time and
within budget.

7) Environment. Support the rest of the effort by ensuring that the proper process, guidance
(standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed

Philosophies

1) Your staff know what they're doing. People are not going to read detailed process documentation,
but they will want some high-level guidance and/or training from time to time. The AUP product
provides links to many of the details, if you are interested, but doesn't force them upon you.

2) Simplicity. Everything is described concisely using a handful of pages, not thousands of them.

3) Agility. The Agile UP conforms to the values and principles of the agile software development and
the Agile Alliance.

4) Focus on high-value activities. The focus is on the activities which actually count, not every
possible thing that could happen to you on a project.

5) Tool independence. You can use any toolset that you want with the Agile UP. The
recommendation is that you use the tools which are best suited for the job, which are often simple
tools.

6) You'll want to tailor the AUP to meet your own needs