Software Engineering and

Agile Development
Course Code : 7IT1016

1
 MODULE – 4 Syllabus
Agile Software Development:

• Agile methods
• The principles of agile methods
• Plan-driven and agile development, agile specification,
• Overview of Extreme Programming, release cycle, programming practices, Short Cycles, the
iteration plan, the release plan, Acceptance Tests,
• Pair programming

• Agile project management

• The Scrum process

• Scaling agile methods

What is agile?
• Agile is a process that allows a team to more efficiently manage a project by
breaking it down into several stages, each of which allows for consistent
collaboration with stakeholders to promote steady improvements at every stage.

• In software development, agile practices involve discovering requirements and

developing solutions through the collaborative effort of self-organizing and cross-
functional teams and their customer/end user.
Some of the real-life examples of agile model:
• Restaurant orders:
• Preparation of some of the food before opening the shop (sprint planning)
• continuous delivery of orders (adhoc stories)
• number of successful orders (velocity)
• cricket team:
• Run rate (velocity)
• team (scrum team self sufficient)
• over (sprint length)
• captain/ coach (scrum master)
Plan-driven and agile development
Agile Methodology
• Agile methodology is a type of project management process, mainly used for software
development, where demands and solutions evolve through the collaborative effort of
self-organizing and cross-functional teams and their customers.

• It is a combination of iterative and incremental process models

• The main aim is to help a project to adapt to change requests quickly to facilitate quick
project completion by removing unnecessary activities that consume time and effort

• The requirements are decomposed into very small parts that can be incrementally
developed
• Each iterations are short time frames that typically last for 1 to 4 weeks

• Each iteration involves a cross-functional team working in all functions

• At the end of the iteration a working product is demonstrated to the customer

• Multiple iterations are required to release a product or to include new features

• Working software is the primary measure of progress

• An agile process focuses more on code development rather than documentation

Agile Principles

• Customer satisfaction • Face-to-face conversation

• Early and continuous delivery • Functional products

• Embrace change • Technical excellence

• Frequent delivery • Simplicity

• Collaboration of businesses and • Self-organized teams

developers • Regulation, reflection and adjustment

• Motivated individuals
Explanation of Each Principle:
[Link] Satisfaction through Early and Continuous Delivery
Agile prioritizes customer satisfaction by delivering functional software early and frequently. This allows for early
feedback and quality improvement.
[Link] Changing Requirements, Even Late in Development
Agile teams embrace changes as they improve product-market fit. The software is designed to be flexible to
accommodate evolving business needs.
[Link] Working Software Frequently
Agile teams deliver software in short cycles (iterations), typically every few weeks, ensuring progress and quick
feedback.
[Link] People and Developers Must Work Together Daily
Effective collaboration between developers, stakeholders, and customers ensures alignment with business goals and
reduces misunderstandings.
[Link] Projects Around Motivated Individuals
Teams perform best when they are trusted, given autonomy, and provided with the necessary resources and a
supportive work environment.
[Link]-to-Face Communication is Most Effective
Agile values direct conversations over excessive documentation. Quick discussions improve understanding and
decision-making.
[Link] Software is the Primary Measure of Progress
Agile teams focus on delivering functional software rather than excessive planning or documentation. Progress is
measured by what actually works.
[Link] Development with a Constant Pace
Agile teams avoid burnout by maintaining a consistent work pace, ensuring long-term productivity and high-quality
output.
[Link] Attention to Technical Excellence and Good Design
High-quality software enables agility. Agile teams prioritize clean, maintainable code and avoid technical debt.
[Link] – Maximizing the Amount of Work Not Done
•Agile focuses on essential features, avoiding unnecessary complexity, which helps in faster and more efficient
development.
[Link] Best Architectures, Requirements, and Designs Emerge from Self-Organizing Teams
•Agile teams take collective responsibility for decision-making, leading to better, more adaptive solutions.
[Link] Reflection and Adaptation for Continuous Improvement
•Agile teams regularly evaluate their processes and make necessary adjustments to enhance efficiency and effectiveness.
These principles ensure that Agile remains a flexible, efficient, and customer-focused approach to software development
The principles of agile methods
Agile manifesto
Our values:

▪ Individuals and interactions over processes and tools

▪ Working software over comprehensive documentation

▪ Customer collaboration over contract negotiation

▪ Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the
left more.
Examples of Agile Methodology

• Agile Scrum Methodology.

• Lean Software Development.
• Kanban.
• Extreme Programming (XP)
• Crystal.
• Dynamic Systems Development Method (DSDM)
• Feature Driven Development (FDD)
 Plan-driven and agile development
• Different types of software products/services are being developed everyday. IT/Software companies are adopting different

development procedures for the development of good quality software product within less time and less budget. There are

number of approaches for software development. One of them is Plan Driven Development in short PDD. In this article we will

discuss about this Plan Driven Development method. So, let’s start exploring the topic.

• Plan Driven Development (PDD):

• Plan-driven development is a software development method which attempts to plan and develop all of the features a user might

want in the final product and determines how all those features are to be developed. Actually this action plan is based on the

execution of an ordered set of task-specific levels.

• We can say it is an attitude to software engineering wherever it is planned in feature how the development procedure will take

place. It is based on the administration methods of project engineering & an old-style method of handling big software

development ventures. It makes the use of management planning unfolds in measuring progress and making project decisions.
Project plans:

• A plan-driven development project sets out a program for the project, including the available
resources, work breakdowns, work completion schedules etc.

• Organizing the team and roles of different members.

• Risk Analysis and Probabilities, Prospects, Strategies to Arise.

• Hardware as well as software resource requirements.

• Deciding Activities, Deliveries, and Milestones.

• Allotment of people and allocation of their time.

• Monitoring and Reporting systems.

PPD also known as Waterfall or Predictive Development, this method follows a structured and
sequential process with a well-defined plan before development begins.

Key Characteristics:

Detailed Upfront Planning – Requirements and design are fully defined before implementation.

Phased Approach – Development follows strict phases (Requirement Analysis → Design →

Implementation → Testing → Deployment → Maintenance).

Extensive Documentation – Every phase requires documentation to track progress and compliance.

Limited Flexibility – Changes in requirements are costly and difficult to implement.

Best Suited For: Large-scale projects with well-defined, stable requirements (e.g., government or
aerospace projects).
• Advantages:

• Clear structure and predictability

Well-documented process ensures compliance

Easier to manage large teams and regulatory requirements

• Disadvantages:

• Rigid and less adaptable to change

Late testing increases risk of defects in later stages

Long delivery cycles may delay customer feedback

Extreme programming
A popular form of Agile

Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.

▪ New versions may be built several times per day;
▪ Increments are delivered to customers every 2 weeks;
▪ All tests must be run for every build and the build is only accepted if tests run successfully.

Customer involvement means full-time customer engagement with the team. - Specifications through
user stories broken into tasks

People not process : pair programming, collective ownership and a process that avoids long
working hours.

Regular system releases. - release set of user stories

Maintaining simplicity through constant refactoring of code.

The extreme programming release cycle
Examples of task cards for prescribing
medication
XP

CRC Cards:
• Class
• Responsibility
• Collaboration
Refactoring

Programming team look for possible software improvements and make these
improvements even where there is no immediate need for them.

This improves the understandability of the software and so reduces the need for
documentation.

Changes are easier to make because the code is well-structured and clear.

However, some changes requires architecture refactoring and this is much more
expensive.
RISK:

Changes the user does not test:

• If users make changes but don’t test them properly, problems might go unnoticed.

• This can cause unexpected bugs or errors later.

Changes to working software break it:

• When someone modifies software that’s already working, those changes might
accidentally cause parts of it to stop working.

• This breaks functionality and can cause failures.

Examples of refactoring

Re-organization of a class hierarchy to remove duplicate code.

Tidying up and renaming attributes and methods to make them

easier to understand.

The replacement of inline code with calls to methods that have

been included in a program library.
Pair programming
In XP, programmers work in pairs, sitting together to develop
code.
Common ownership
Knowledge spread
Informal review
Refactoring
Similar output to two people coding
• In XP, programmers work in pairs, sitting together to develop code.

• This helps develop common ownership of code and spreads knowledge across the team.

• It serves as an informal review process as each line of code is looked at by more than 1 person. It encourages
refactoring as the whole team can benefit from this.

• Measurements suggest that development productivity with pair programming is similar to that of two people
working independently.

• In pair programming, programmers sit together at the same workstation to develop the software.

• Pairs are created dynamically so that all team members work with each other during the development process.

• The sharing of knowledge that happens during pair programming is very important as it reduces the overall risks to
a project when team members leave.

• Pair programming is not necessarily inefficient and there is evidence that a pair working together is more efficient
than 2 programmers working separately.
Advantages of pair programming

• It supports the idea of collective ownership and responsibility for the system.

• Individuals are not held responsible for problems with the code. Instead, the team has
collective responsibility for resolving these problems.

• It acts as an informal review process because each line of code is looked at by at least
two people.

• It helps support refactoring, which is a process of software improvement. Where pair

programming and collective ownership are used, others benefit immediately from the
refactoring, so they are likely to support the process.
Scrum

Scrum is a way for teams to work together to develop products (often software) in an organized, flexible, and
collaborative way. It helps teams deliver work in small, manageable pieces called sprints (usually 1-4 weeks
long).

Project Manager's job: - Deliver needed system on time within budget

The Scrum approach - manage the iterations

There are three phases in Scrum.

▪ outline planning phase - general picture and architecture

▪ Sprint cycles releasing increments of the system.

▪ The project closure phase - final delivery, documentation and review of lessons learned.
The Sprint cycle
Every 2–4 weeks (a fixed length).

1) Project team with customer: Look at product backlog - select stories to implement

2) implement with all customer communication through scrum master (protecting pgm at this
point)
Scrum master has project manager role during sprint
Daily 15 min meetings
Stand up often
Team presents progress and impediments
Scrum master tasked with removing impediments

3) Review system release with user

Scrum sprint cycle
Scrum terminology
 Scrum benefits

The product is broken down into a set of manageable and understandable chunks.

Unstable requirements do not hold up progress.

The whole team have visibility of everything and consequently team communication is
improved.

Customers see on-time delivery of increments and gain feedback on how the product
works.

Trust between customers and developers is established and a positive culture is created
in which everyone expects the project to succeed.
Distributed Scrum
Scaling agile methods
• Agile methods have proved to be successful for small and medium
sized projects that can be developed by a small co-located team.
• It is sometimes argued that the success of these methods comes
because of improved communications which is possible when
everyone is working together.
• Scaling up agile methods involves changing these to cope with larger,
longer projects where there are multiple development teams,
perhaps working in different locations.
Scaling out and scaling up
• ‘Scaling up’ is concerned with using agile methods for developing
large software systems that cannot be developed by a small team.
• ‘Scaling out’ is concerned with how agile methods can be introduced
across a large organization with many years of software development
experience.
• When scaling agile methods, it is important to maintain agile
fundamentals:
• Flexible planning, frequent system releases, continuous integration, test-
driven development and good team communications.
Practical problems with agile methods
• The informality of agile development is incompatible with the legal
approach to contract definition that is commonly used in large
companies.
• Agile methods are most appropriate for new software development
rather than software maintenance. Yet the majority of software costs
in large companies come from maintaining their existing software
systems.
• Agile methods are designed for small co-located teams yet much
software development now involves worldwide distributed teams.
Contractual issues
• Most software contracts for custom systems are based around a
specification, which sets out what has to be implemented by the
system developer for the system customer.
• However, this precludes interleaving specification and development
as is the norm in agile development.
• A contract that pays for developer time rather than functionality is
required.
• However, this is seen as a high risk for many legal departments because what
has to be delivered cannot be guaranteed.
Agile methods and software maintenance
• Most organizations spend more on maintaining existing software than
they do on new software development. So, if agile methods are to be
successful, they have to support maintenance as well as original
development.
• Two key issues:
• Are systems that are developed using an agile approach maintainable, given
the emphasis in the development process of minimizing formal
documentation?
• Can agile methods be used effectively for evolving a system in response to
customer change requests?
• Problems may arise if original development team cannot be
maintained.
Agile maintenance
• Key problems are:
• Lack of product documentation
• Keeping customers involved in the development process
• Maintaining the continuity of the development team
• Agile development relies on the development team knowing and
understanding what has to be done.
• For long-lifetime systems, this is a real problem as the original
developers will not always work on the system.
 Agile and plan-driven methods
• Most projects include elements of plan-driven and agile processes. Deciding on
the balance depends on:
• Is it important to have a very detailed specification and design before moving to
implementation? If so, you probably need to use a plan-driven approach.
• Is an incremental delivery strategy, where you deliver the software to customers and get
rapid feedback from them, realistic? If so, consider using agile methods.
• How large is the system that is being developed? Agile methods are most effective when
the system can be developed with a small co-located team who can communicate
informally. This may not be possible for large systems that require larger development
teams so a plan-driven approach may have to be used.
Agile principles and organizational practice
Principle Practice
Customer involvement This depends on having a customer who is willing and able to spend time with the development team and who
can represent all system stakeholders. Often, customer representatives have other demands on their time and
cannot play a full part in the software development.
Where there are external stakeholders, such as regulators, it is difficult to represent their views to the agile
team

Embrace change Prioritizing changes can be extremely difficult, especially in systems for which there are many stakeholders.
Typically, each stakeholder gives different priorities to different changes.

Incremental delivery Rapid iterations and short-term planning for development does not always fit in with the longer-term planning
cycles of business planning and marketing. Marketing managers may need to know what product features
several months in advance to prepare an effective marketing campaign.

Maintain simplicity Under pressure from delivery schedules, team members may not have time to carry out desirable system
simplifications.
People not process Individual team members may not have suitable personalities for the intense involvement that is typical of agile
methods, and therefore may not interact well with other team members.
Agile and plan-based factors
System issues
• How large is the system being developed?
• Agile methods are most effective a relatively small co-located team who can communicate informally.

• What type of system is being developed?

• Systems that require a lot of analysis before implementation need a fairly detailed design to carry out this analysis.

• What is the expected system lifetime?

• Long-lifetime systems require documentation to communicate the intentions of the system developers to the support
team.

• Is the system subject to external regulation?

• If a system is regulated you will probably be required to produce detailed documentation as part of the system safety
case.
 People and teams
• How good are the designers and programmers in the development team?
• It is sometimes argued that agile methods require higher skill levels than plan-based
approaches in which programmers simply translate a detailed design into code.

• How is the development team organized?

• Design documents may be required if the team is dsitributed.

• What support technologies are available?

• IDE support for visualisation and program analysis is essential if design
documentation is not available.
 Organizational issues
• Traditional engineering organizations have a culture of plan-based development,
as this is the norm in engineering.

• Is it standard organizational practice to develop a detailed system specification?

• Will customer representatives be available to provide feedback of system

increments?

• Can informal agile development fit into the organizational culture of detailed
documentation?
Agile methods for large systems
1. Large systems are usually collections of separate, communicating systems, where
separate teams develop each system. Frequently, these teams are working in different
places, sometimes in different time zones.
2. Large systems are ‘brownfield systems’, that is they include and interact with a number
of existing systems. Many of the system requirements are concerned with this
interaction and so don’t really lend themselves to flexibility and incremental
development.
3. Where several systems are integrated to create a system, a significant fraction of the
development is concerned with system configuration rather than original code
development.
4. Large systems and their development processes are often
constrained by external rules and regulations limiting the way that
they can be developed.
5. Large systems have a long procurement and development time. It is
difficult to maintain coherent teams who know about the system
over that period as, inevitably, people move on to other jobs and
projects.
6. Large systems usually have a diverse set of stakeholders. It is
practically impossible to involve all of these different stakeholders
in the development process.
Factors in large systems
IBM’s agility at scale model
Scaling up to large systems
• A completely incremental approach to requirements engineering is impossible.

• There cannot be a single product owner or customer representative.

• For large systems development, it is not possible to focus only on the code of the system.

• Cross-team communication mechanisms have to be designed and used.

• Continuous integration is practically impossible. However, it is essential to maintain frequent

system builds and regular releases of the system.
 Multi-team Scrum
• Role replication
• Each team has a Product Owner for their work component and ScrumMaster.
• Product architects
• Each team chooses a product architect and these architects collaborate to design and
evolve the overall system architecture.
• Release alignment
• The dates of product releases from each team are aligned so that a demonstrable and
complete system is produced.
• Scrum of Scrums
• There is a daily Scrum of Scrums where representatives from each team meet to
discuss progress and plan work to be done.
 Agile methods across organizations
• Project managers who do not have experience of agile methods may be reluctant to accept the
risk of a new approach.
• Large organizations often have quality procedures and standards that all projects are expected
to follow and, because of their bureaucratic nature, these are likely to be incompatible with agile
methods.
• Agile methods seem to work best when team members have a relatively high skill level.
However, within large organizations, there are likely to be a wide range of skills and abilities.
• There may be cultural resistance to agile methods, especially in those organizations that have a
long history of using conventional systems engineering processes.
Thank You