Software Engineering

Module 1
By
Prof. Santosh V. Kadam
Watumull Institute Of Engineering & Technology

[Link] Kadam ,WIET 1

Introduction To Software
Engineering and Process Models

Module 1.3
Agile process model:
1. Extreme Programming (XP)
2. Scrum
3. Kanban

[Link] Kadam ,WIET 2

[Link] Kadam ,WIET 3
[Link] Kadam ,WIET 4
 Agile Methodology
• According to the dictionary, it is an adjective that means to move quickly
& easily. Its application is no different from when organizations use it.
• Agile methodology is a set of values and principles that ought to be
followed to become Agile.
• It is an approach to software development where team interaction,
customer collaboration, and responding to change are the key themes.
• In addition to that, Agile methodology provides us with a framework
where continuous improvements happen at different stages of the
software development life cycle.
• The Agile model was primarily designed to help a project to adapt to
change requests quickly. So, the main aim of the Agile model is to
facilitate quick project completion. To accomplish this task agility is
required.
• Agility is achieved by
1. Fitting the process to the project, removing activities that may not be
essential for a specific project.
2. Also, anything that is waste of time and effort is avoided.
• In Agile Methodology, the entire project is finished in mini-projects so
the team has better control over the deliverables and the team morale
5
remains high. It, in turn, leads to high ROI.
Agile Manifesto

[Link] Kadam ,WIET 6

 Agile Manifesto
• [Link]
1. individuals and interactions over processes and
tools;
2. working software over comprehensive
documentation;
3. customer collaboration over contract
negotiation; and
4. responding to change over following a plan.

[Link] Kadam ,WIET 7

[Link] Kadam ,WIET 8
[Link] Kadam ,WIET 9
 Characteristics of Agility
• Agility in Agile Software Development focuses on the
culture of the whole team with multi-discipline, cross-
functional teams that are empowered and self organizing.
• It fosters shared responsibility and accountability.
• Facilitates effective communication and continuous
collaboration.
• The whole-team approach avoids delays and wait times.
• Frequent and continuous deliveries ensure quick feedback
that in in turn enable the team align to the requirements.
• Collaboration facilitates combining different perspectives
timely in implementation, defect fixes and
accommodating changes.
• Progress is constant, sustainable, and predictable
emphasizing transparency.
[Link] Kadam ,WIET 10
Principles of Agile Methodology

[Link] Kadam ,WIET 11

Principles of Agile Methodology
12 main principles in Agile methodology: -
1. Customer satisfaction through early and continuous delivery of useful
software - It means letting the customer know the progress by the
distribution of values to the customers. Which, in turn, is achieved by
fulfilling the highest priority requirements first.
2. Welcome changing requirements, even late in development - This
implies flexible adaptation to the changing needs of the customer. In
addition to this, providing them a competitive advantage to external
changes.
3. Frequently Delivered Software (weeks rather than months)- This
provides immediate value to the customer by delivering working features
timely.
4. Work together - i.e., Close and daily cooperation between Business
people and Developers by keeping documentation and requirements
lightweight.
5. Trust and Support - Projects are successful around motivated individuals
who should be trusted.
6. Face to Face conversation - Oral communication is preferred to rule out
any discrepancies and be on the same page.
7. Working Software - It is the primary measure of progress and should be
delivered timely. [Link] Kadam ,WIET 12
8. Sustainable development - Agile methodology maintains
the work-life balance among the team members and
promotes happiness by avoiding exhaustion.
9. Continuous Attention- Means consistent attention to
technical excellence and good design enhances the agility
of any team.
10. Simplicity - It is the art of maximizing the amount of
work not done—is essential. It uses the Pareto principle or
the 80/20 rule that says that typically 80% of your results
may come from only 20% of your efforts.
11. Self-organizing teams - The scrum team has autonomy
and responsibility to meet the goals of the sprint.
12. Reflect & Adjust - At regular intervals team reflects on
how to become more productive and then adjusts
accordingly. The retrospective meetings ensure the
implementation of the lessons learned during the project
into the next iteration.
[Link] Kadam ,WIET 13
 Agile : Principle Techniques
• User stories
Simpler than use cases
• Metaphors
Overall design of software based on user stories,or
common vision
• Spike
Prototype,simple program to explore the potential
• Refactor
Refined ,made structured without affecting
behaviour,imptove efficiency,structure,etc.

[Link] Kadam ,WIET 14

The above picture depicts the Strategy & Execution Model in an Agile
project. Here-
•Each level represents a strategic goal that has to finish in different periods.
•Story Level Items (part of Strategy) include Tasks & Stories;
•In addition to the above, Portfolio Items (part of Execution) includes
Features, Initiative/Epic & Theme.
•A task may take hours or days to finish;
•Whereas a feature may require weeks to get completed.
•Moreover, the upside-down triangle on the right depicts this timeframe. 15
[Link] Kadam ,WIET
• The main characters in a general Agile methodology
are as below. Terminologies & definitions used are :
• Product backlog: a list of requirements provided by the
customer in the form of Epic, Features, Stories, etc.
generally captured in an excel sheet format.
• Epic: Large level requirements/ needs of the business.
• Features: Divisions of Epic, precisely defines the needs
of the customer.
• Stories: It refers to the detailed definition of each
requirement/ Feature.
• Tasks: Defines the solution of each Story. They are the
actions taken on “Story”.
[Link] Kadam ,WIET 16
[Link] Kadam ,WIET 17
 Example
• Consider that a customer wants to build an online shopping
platform where users can buy clothes for all ages. The online
shopping platform will develop in 2 Releases – The Core
functionalities will go in Release 1, and Release 2 will feature the
rest of the backlog items.
• Epic is a big story that will help the end-user to resolve a
business problem. e.g., As a registered user, I should be able to
buy clothes using various payment options. If you carefully look,
you will see that this talks about “registration”, “payment
options”, and “buying”. Epics can span across Releases, so in
current, e.g., we can have Credit Card payment in release 1,
while PayPal or bank transfer can be in release 2.
• Features define the characteristics of the product. A Feature
needs to fit in a single release, though it can span across multiple
Sprints. e.g., for the above Epic, the Features can be defined as
“User Registration”, “Payment Via Credit Cards”. “Payment Via
PayPal”, etc.
[Link] Kadam ,WIET 18
• Stories are smaller pieces of functionality, and they directly
map to an epic. The story needs to fit in a single sprint. e.g., for
User registration Feature, we can have the following stories:
• Story 1: As a new customer, I should be able to Register on the
website using my First Name, Last Name, Email ID, and
Password
• 2nd Story: As a new customer, I should be able to register to the
site using my social credentials (Facebook, Google, and Twitter)
• Story 3: As a new customer, I should be aware of any errors that
need to be corrected while filling up the registration form
• Tasks: Tasks define the actual work that needs to be done to
complete a story. Usually, to complete a story, we may need the
help of multiple members of a Scrum Team. Therefore, a Story
is divided into tasks, and the assignment of each task to one
member happens. Once all these tasks finish, we can mark the
story as “Done” or “Completed”.
• Story: As a new customer, I should be able to Register on the
website using my First Name, Last Name, Email ID, and
Password.
[Link] Kadam ,WIET 19
Development Tasks: - Some of the typical development
tasks can be:
• Task 1: Create a UI Form that can accept First Name, Last
Name, Email Id and Password fields
• Task 2: Create a Backend DB table, that can store
customer information
• Task 3: Password Encryption
• Task 4: User Registration API
QA Tasks : - Some of the typical QA tasks can be:
• Task 6 : Create test cases for the story
• Task 7 : Create Automation Scripts for the story
• Task 8 : Execute functional test cases
• Task 9: Identify and Create test data required for the
story

[Link] Kadam ,WIET 20

 Advantages of Agile Methodology
• Enhanced Quality - Firstly, since the integration of testing happens during the
cycle, there are regular checkups to see that the product is working during the
development. Therefore, it enables the Product Owner to make changes as and
when needed.
• Better Customer Experience - Secondly, there is continuous interaction between
stakeholders and the team during the entire Agile process. It enables the team to
understand the client's vision and produce high-quality products. It, in turn, helps
in gaining customer's trust and increased satisfaction.
• Transparency - Thirdly, the entire project in Agile methodology involves regular
client meetings, and all the other details are transparently available to all the
team members.
• Early & Predictable Delivery - In addition to the above, since sprints occur on a
fixed schedule (1- 4 weeks), it's easy to predict the timing of project completion
and can save on costs too. Therefore, the product owner can review the
deliverable as early as within three weeks, and he can provide feedback if
something has not gone according to his expectations.
• Ease of doing transactions - Moreover, Scrum methodologies allow for flexible
adaptation to the changing customer requirements. A continuous reprioritization
happens by refining the Product Backlog and adapting to the new customer
needs.
• Continuous Engagement - Finally, the Iterative nature of Agile methodology
implies that the features are delivered incrementally. It happens by continuously
keeping the team and resources engaged in what they are best. 21
 Disadvantages
• Due to lack of formal documents, it creates
confusion and important decisions taken
during different phases can be misinterpreted
at any time by different team members.
• Due to the absence of proper documentation,
when the project completes and the
developers are assigned to another project,
maintenance of the developed project can
become a problem.

[Link] Kadam ,WIET 22

• All Agile methodologies work on the above
model that mainly depicts how sprints run one
after another. They all follow a "plan-design-
build-test-review" approach.

[Link] Kadam ,WIET 23

 Agile methodologies
• Scrum
• Kanban Software Development
• Extreme Programming (XP)
• Lean
• Dynamic Systems Development Method
(DSDM)
• Feature Driven Development (FDD)
• Crystal

[Link] Kadam ,WIET 24

 Scrum
• Scrum is one of the most commonly used Agile methodologies.
• Scrums have gained popularity within the Agile software development
community because they are simple and have a proven productivity rate.
• Scrum focuses on Team.
• It is a method that concentrates specifically on how to manage tasks
within a team-based development environment.
• Scrum believes in enabling & empowering the development team and
suggests working in small teams (say- 7 to 9 members).
Principle of Scrum
• The fundamental principle of Scrum is that by dividing time and projects,
you can enhance an organization's effectiveness and productivity.
• Scrum makes the process of development less complicated by making
the information transparent. Which, in turn, helps the team to overcome
the disadvantages of waterfall model like :
1. Under & overestimation of time
2. Lack of progress report
3. Inability to adapt to changes, etc.
[Link] Kadam ,WIET 25
• The Scrum framework is a part of the Agile methodology, which
is a practice that involves managing a project by dividing it into
multiple phases and repeating a cycle of planning, executing
and evaluating at every phase.
• Scrum's cycles are called sprints and typically last between two
and four weeks, with the entire work reviewed after each
sprint.
• The people involved in the process have one of three roles: the
product owner, who is the person representing the company,
the Scrum master, which is the project manager, and a team of
people who execute the tasks.
• Scrum is especially useful in the software development sector,
as it gets a team to focus on a smaller goal and then integrate it
with the project's main objective.
• However, its characteristics make it suitable for a wide variety
of projects in different industries, especially those that require
a quick turnaround for high-priority requests and constant
changes that the project development team needs to adapt to
easily.
[Link] Kadam ,WIET 26
 Example
If you have to construct your house, what would be your
strategy? First, we will make the list of all requirements
as below-
• Buy a piece of land/ empty plot
• Hire an architect
• Get the map of the house passed
• Hire contractor
• Buying construction material
• Hire labor to construct
• Suggest customizations
This list of requirements is known as “Product Backlog”.

[Link] Kadam ,WIET 27

• Now, the architect confirmed that they would come over for the
discussion on Week2, Day 1 from today so you will start prioritizing your
tasks from the above list and put some timeline around it. e.g. -
• Week 1 – Finish the purchase of the land, registry, considering legal
formalities, etc.
• Week 2, Day 1 – Meet architect, list your design requirements.
– Day 3 - finalize the design, suggest modifications
– Day 5 - pass the map
• Week 3, Day 1 - hire contractor, share the house design
– Day 3 - get estimated material needed from the contractor
– Day 5- buy the material
• Week 4 - Construction starts
• You may like to capture these activities along with timelines in a
separate document. Which, in turn, will ensure the timely completion of
all the activities. This document is known as "Sprint Backlog".
• Whereas, the process of defining objectives to achieve is known as
"Sprint Goal" or "Increment" in Scrum.
For example – for Week 2, Day 1, you kept an objective to meet the
architect & finalize the design. It is Increment.

[Link] Kadam ,WIET 28

 Scrum Framework
• Roles
Product Owner,Scrum Master,Development Team
• Meetings, or "ceremonies“
Sprint Planning,Sprint Review,Sprint
Retrospective, and Daily Scrum Meeting
• Artifacts
Product Backlog,Sprint Backlog and Burndown
Chart

[Link] Kadam ,WIET 29

 Roles and responsibilities in Scrum
• It consists of three positions, and their responsibilities are as follows:
Scrum Master:
• The Scrum Master is responsible for making sure that the Scrum Team
adheres to the values and principles of Agile methodology.
• Additionally, the scrum master ensures the adherence to the processes
and practices that the team agreed they would use.
The responsibilities of a Scrum Master include:
• Clearing obstacles
• Establishing an environment where the team can be effective
• Addressing team dynamics
• Ensuring a good relationship between the team and the Product Owner
as well as others outside the team
• Protecting the team from outside interruptions and distractions.
• Helps the PO maintain the product backlog.
• Assisting in the determination of the definition of done (DOD) for the
product.
• Coaching the team, within the Scrum principles.
• Promoting self-organization within the team 30
Facilitation of Scrum Events like
1. Daily Scrum Meetings
2. Sprint Planning Meetings
3. Sprint Review Meetings
4. Sprint Retrospective Meeting

[Link] Kadam ,WIET 31

Product owner:
• The Product Owner in a product development team is responsible for
managing the product backlog to achieve the desired result that a team
seeks to accomplish.
Key activities to accomplish this include:
1. Clearly expressing Product Backlog items.
2. Ordering the items in the Product Backlog to best achieve goals and
missions.
3. Optimizing the value of the work the Development Team performs.
4. Ensuring that the Product Backlog is visible, transparent, and clear to
all, and shows what the Scrum Team will work on next.
5. Ensuring the Development Team understands items in the Product
Backlog to the level needed.
• The creation of the Product Owner role as part of the Scrum framework
happened to address the challenges that product development teams
faced.
For instance, multiple & conflicting directions or no direction at all
concerning what to build.

[Link] Kadam ,WIET 32

Scrum Team:
• Scrum Team is also known as the “Development team”. It
usually consists of Developers. Testers, Designers, etc.
• They are the ones who work on Product Backlog items.
• According to the Scrum Guide, the scrum team should be
between three to nine people and should have all the skills
necessary to deliver the product.
Main characteristics of the Scrum Team:
1. Scrum Teams are self-organizing. They decide how to turn
the backlog into a potentially releasable functionality.
2. Development teams are cross-functional, with all the skills
necessary to create the product increment.
3. Scrum Team doesn’t give any titles to the development
team, regardless of the work they perform.
4. Scrum team doesn’t recognize any sub-teams, regardless
of cross-domain folks that are present (e.g., BA, tester,
developer, etc.)
[Link] Kadam ,WIET 33
 Processes of Scrum
The processes that constitute the Scrum framework are:
1. The product owner creates a list of all the tasks involved in
completing the project and their priority, called a product backlog
2. The Scrum team analyzes the product backlog and divides all major
tasks into smaller, easier to manage ones
3. The team then creates a sprint backlog and decides how it's going
to be implemented
4. The length of each sprint is determined, with the average duration
being between two and four weeks
5. The team usually holds daily meetings for the entire duration of a
sprint, with each member sharing their daily updates and the
project manager analyzing the project's progress based on the
newly received information
6. At the end of each sprint, the product owner and the organization's
stakeholders review the results

[Link] Kadam ,WIET 34

[Link] Kadam ,WIET 35
• Sprint: Scrum Event that is time-boxed to one month or less, that serves as a
container for the other Scrum events and activities. Sprints are done
consecutively, without intermediate gaps.
• Scrum Values: a set of fundamental values and qualities underpinning the
Scrum framework; commitment, focus, openness, respect and courage.
• Sprint Backlog: Scrum Artifact that provides an overview of the development
work to realize a Sprint’s goal, typically a forecast of functionality and the work
needed to deliver that functionality. Managed by the Developers.
• Sprint Goal: a short expression of the purpose of a Sprint, often a business
problem that is addressed. Functionality might be adjusted during the Sprint in
order to achieve the Sprint Goal.
• Sprint Planning: Scrum Event that is time-boxed to 8 hours, or less, to start a
Sprint. It serves for the Scrum Team to inspect the work from the Product
Backlog that’s most valuable to be done next and design that work into Sprint
backlog.
• Sprint Retrospective: Scrum Event that is set to a time-box of 3 hours, or less,
to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan
for improvements to be enacted during future Sprints.
• Sprint Review: Scrum Event that is set to a time-boxed of 4 hours, or less, to
conclude the development work of a Sprint. It serves for the Scrum Team and
the stakeholders to inspect the Increment of product resulting from the Sprint,
assess the impact of the work performed on overall progress toward the
Product Goal and update the Product backlog in order to maximize the value of
the next period.
[Link] Kadam ,WIET 36
• Product Backlog- Here, the Product owner meets the client and takes
down all the requirements. A document referred to as Product Backlog
captures these requirements.
• Sprint Backlog – Now, the Product Owner shares this Product Backlog
with the Sprint team (consists of Scrum Master, Developers, and testers)
in a meeting referred to as the “Sprint Planning” meeting.
• In sprint planning, the entire team agrees to complete a sub-set of
product backlog items. This agreement is called the Sprint Backlog & its
basis the team’s velocity/ capacity & the length of the sprint.
• The vital point to note here is, once the team has finalized the Sprint
backlog, they cannot change it within the Sprint. If any change is required,
it either goes to the next sprint, or the cancellation of the current sprint
happens.
For instance, the team may decide to release software in 3 iterations
(each iteration is referred to as “Sprint” in the world of Scrum)
• First Iteration– Story 1 and 3 will be released (Sprint 1)
• Second Iteration - Release of Story 2, 4 and 6 will happen(Sprint 2)
• Third Iteration – Story 5 will be released (Sprint 3)

[Link] Kadam ,WIET 37

• Daily Scrum- The Scrum Master conducts a daily meeting of
the duration of 15 minutes with the Sprint team to ensure
progress is on track. This meeting is “Daily Scrum”. It broadly
discusses the below pointers-
– What did you accomplish since the last meeting?
– What are you working on until the next meeting?
– What's getting in your way?
• Sprint Review- At the end of each phase or “Sprint” – Scrum
Master organizes a meeting referred to as the “Sprint
Review” meeting. In this meeting, the Product owner reviews
the product and assess whether the product is as per client
expectations or not. It is an informal meeting & is kept to less
than 4 hours a week for a 4-week sprint.
• Sprint Retrospective meeting is conducted to discuss “What
went well during the Sprint” and “What needs
improvement”. This meeting takes place after the sprint
review but before the next Sprint Planning Meeting. Its
duration can be of a maximum of 3 hours for a 4-week sprint.
[Link] Kadam ,WIET 38
Burn-down Chart:
• A chart which shows the amount of work which is thought to remain
in a backlog.
• Time is shown on the horizontal axis and work remaining on the
vertical axis.
• As time progresses and items are drawn from the backlog and
completed, a plot line showing work remaining may be expected to fall.
• The amount of work may be assessed in any of several ways such as
user story points or task hours.
• Work remaining in Sprint Backlogs and Product Backlogs may be
communicated by means of a burn-down chart.
Burn-up Chart:
• A chart which shows the amount of work which has been completed.
Time is shown on the horizontal axis and work completed on the
vertical axis.
• As time progresses and items are drawn from the backlog and
completed, a plot line showing the work done may be expected to rise.
The amount of work may be assessed in any of several ways such as
user story points or task hours.
• The amount of work considered to be in-scope may also be plotted as a
line; the burn-up can be expected to approach this line as work is
[Link] Kadam ,WIET 39
completed.
Burndown chart example
Sprint Duration: 2 Weeks
No. of Days per Week: 5
No. of Hrs. per Day: 6
No. of Resources: 6
Hence, total remaining effort
at the beginning of sprint is
2*5*6*6 = 360 hrs.
Therefore, in an ideal scenario,
36 hours of work gets reduced in the remaining
work and the burn-down chart looks as follows

As the burn-down chart is drawn daily, and the

slippage is known early, corrective actions can
be taken to meet the sprint time line. Suppose,
the team stretches to meet the timeline,
the burn-down chart looks as follows -

[Link] Kadam ,WIET 40

[Link] Kadam ,WIET 41
[Link] Kadam ,WIET 42
[Link] Kadam ,WIET 43
 Applicability of Scrum
• In the complex situations where the outcome
is unknown at the beginning, and the
approach should be to adapt & evolve in the
process.
• Scrum works on a time-boxed iterative
approach.
• The main focus of this approach is working
incrementally rather than all at once.

[Link] Kadam ,WIET 44

 Advantages of Scrum methodology
• It's adaptable and flexible. Scrum is suitable for a wide variety of
environments and situations that don't initially have clearly identifiable
requirements and require a flexible approach.
• It encourages creative approaches. With Scrum teams working together
and analyzing ideas from all its members, creativity is encouraged and
new ideas are likely to appear.
• It involves low costs: Adopting the Scrum approach can be cost-effective
for an organization, as it usually requires less documentation and control.
• It usually leads to better quality work. Having everyone on the team
take full responsibility and ownership of their work can create a
productive environment that leads to high-quality end results.
• It improves customer satisfaction. Having everyone on the team working
to the best of their abilities and constantly adjusting based on internal
and external feedback can result in products and solutions that are
popular with customers.
• It typically results in more satisfied employees. With everyone on the
team taking full responsibility for their work, the Scrum framework
makes it more likely that the employees involved in a project are
motivated and satisfied.
[Link] Kadam ,WIET 45
 Disadvantages of Scrum framework
• It requires extensive training. Although using the Scrum framework can
potentially deliver quick and high-quality results, it requires a well-
trained and skillful team to properly implement it. Before committing to
Scrum, everyone within the team needs to understand the benefits and
particularities of this approach for the project to be a successful one.
• It can be difficult to scale. Using the Scrum approach for large projects
can be challenging, as implementing it on a bigger scale requires
extensive training and precise coordination. Although ways to adapt
Scrum to bigger projects have been developed, they're usually difficult to
understand and implement.
• It may require major transformations within the organization. Adopting
the Scrum framework sometimes means that the company needs to
undergo some organizational transformations for this decision to be a
successful one. Some parts of the process may require different
departments to collaborate and work as a team, with the company
needing to manage and organize these collaborations in a way that
allows that to happen.
• It requires the use of small teams. The Scum methodology usually works
best with teams of at least three people but no more than 10. Although
this can promote collaboration and teamwork, some organizations may
find it difficult to rearrange their workforce into teams. 46
• It can be difficult to integrate with a classic project management
approach. Although it's usually a good solution for projects that need
constant adjustments, the Scrum approach may not be suitable for
projects that require predictability and a well-defined plan. However,
these kinds of projects can be approached by using a hybrid solution
that encapsulates some of the advantages of classic, long-term
planning and those of the Scrum framework.
• It is not related to the project's deadline. Although adopting the
Scrum methodology involves many smaller deadlines for everyone
involved, it doesn't offer any support for the project meeting its overall
deadline. Although this approach increases the odds of everyone
involved working to the best of their abilities and meeting
expectations, the project manager and stakeholders also need to make
sure that the project is on track to be completed on time.
• It requires experienced personnel. Adopting the Scrum methodology
involves extended periods of intense work and everyone involved
needs to have experience and skills to quickly and successfully perform
their own tasks. Everyone on the team needs to be able to execute and
provide educated feedback on the results and overall process.

[Link] Kadam ,WIET 47

 Extreme Programming (XP)
• Kent Beck developed this, and it has evolved as a highly
disciplined method of continuously delivering high-quality
software.
• Beck insisted that in order to write code, you have to write a
test for it first.
• He also defined the idea that code should be written by pairs of
programmers. According to him, the main programmer
describes the code to the other programmer and stimulates
further ideas.
• Extreme programming (XP) is one of the most important
software development frameworks of Agile models.
• It is used to improve software quality and responsiveness to
customer requirements.
• The extreme programming model recommends taking the best
practices that have worked well in the past in program
development projects to extreme levels.
• The Extreme Programming teams are quite small. Usually, they
include from 2 to 12 persons. 48
 Good practices that can be taken to
extreme level
• If code review is good.
Pair Programming
• If Testing is good.
Test driven Development
• If Incremental programming is good.
New increment every few days
• If Simplicity is good
Create Simplest Design
• If Design is good
Everybody will design daily (Refactoring)
• If Architecture is important
Everybody will define and refine the architecture
• If integration testing is important
Build and design integration tests several times a day

[Link] Kadam ,WIET 49

Extreme Programming involves −
• Writing unit tests before programming and keeping all of
the tests running at all times. The unit tests are automated
and eliminates defects early, thus reducing the costs.
• Starting with a simple design just enough to code the
features at hand and redesigning when required.
• Programming in pairs (called pair programming), with two
programmers at one screen, taking turns to use the
keyboard. While one of them is at the keyboard, the other
constantly reviews and provides inputs.
• Integrating and testing the whole system several times a
day.
• Putting a minimal working system into the production
quickly and upgrading it whenever required.
• Keeping the customer involved all the time and obtaining
constant feedback. [Link] Kadam ,WIET 50
XP methodology works on five core values :-
1. Simplicity – First is Simplicity. Which in simple words means
avoiding the waste and only doing what’s needed & asked.
2. Communication – Second is Communication, which means
having face-to-face communication to clear any doubts. In
other words, it means to be on the same page.
3. Feedback – Third is Feedback, which means providing
constructive feedback, which is workable for future
improvements. One can achieve this by focusing on the
changes needed & implementing them.
4. Courage – Fourth is Courage, which means adapting to the
changes & not making excuses for the failure. In addition to
this, being truthful about the estimates & progress of the
project.
5. Respect- Fifth is Respect. This means everyone deserves
respect as an individual team member.

[Link] Kadam ,WIET 51

 Best practices
• Coding
• Testing
• Listening
• Designing
• Feedback

[Link] Kadam ,WIET 52

53
Process of XP

[Link] Kadam ,WIET 54

[Link] Kadam ,WIET 55
• Planning – The first stage of the process is to start collecting the
requirements from the customers in the form of user stories. The value
of each user story is then estimated, which should roughly help the team
to understand how long it will take to implement a story. XP practices
used here are:-
– Planning Game
– On-Site Customer
• Design – Second is Design. Having a simple design of a system ensures
fewer dependencies & early deliveries. The addition of any extra
functionalities can happen later as well. Additionally, if some stories need
more research in terms of technicality, a short time-boxed period is
assigned called Spike. XP practices used here are:-
– Refactoring
– Simple Design(KIS-Keep it Simple)
– Use of CRC Cards(Class Responsibility collaboration
• Coding – Third is coding. This is the core of any process. The actual
coding of software starts here. In other words, the team sits together &
starts working incrementally to deliver the end product. XP practices
used here are:-
– Pair programming
– Collective code ownership
– Coding Standards
[Link] Kadam ,WIET 56
• Testing – Towards the end, the code is tested first
& run later, after fixing the bugs. Following
practice supports it
– Continuous integration
– Test first
– Iterative development
• Release – Finally, the customer valued product is
released & project velocity is computed to keep a
tab on the progress. Measurement of Project
velocity happens, which is a quantifying criterion
of the amount of work accomplished in a project.

[Link] Kadam ,WIET 57

List of Extreme Programming Practices

[Link] Kadam ,WIET 58

• The Planning Game
The main planning process within extreme programming is
called the Planning Game. The game is a meeting that
occurs once per iteration, typically once a week.
The Planning Game is toqQuickly determine the scope of the
next release by combining business priorities and technical
estimates. As reality overtakes the plan, update the plan.
• Short Releases
You should put a simple system into production quickly, and
then release new versions in very short cycles. Every release
should be as small as possible, so that it is −
1. Achievable in a short cycle
2. Contains the most valuable and immediate business
requirements
3. A working system
[Link] Kadam ,WIET 59
 List of Extreme Programming Practices
• Pair Programming – It implies two team members sit on the same
computer & work together. The driver writes the code & the observer
reviews each line of code when it's written. This, in turn, helps in quick
identification of areas of improvisation.
• On-Site Customer – The XP customer is highly engaged with the team &
is available on-site to provide regular feedback.
• Test-First – Implies testing the code first & then running it later after
fixing the bugs. It helps in reduced effort & less number of errors during
the production.
• Iterative Development – It is also known as incremental design which
means doing work in small increments & building it up further.
• Refactoring – Its primary focus is to remove the duplication of various
processes.
• Simple Design – Keeping the system design as simple as possible will
ensure the smooth running of the process.
• Planning Game – The stories are used to describe end-user requirements
& the planning process.
• Coding Standards – Establishing standardized rules of code for all of the
team members. [Link] Kadam ,WIET 60
List of Extreme Programming Practices
• Continuous Integration – This means testing of small codes happens
immediately before adding them to a more significant project. It
ensures that error detection happens early on.
• 40- Hour week – As the name suggests, every team member is
required to work for 40 hours a week. Therefore, maintaining a
work-life balance.
• Collective code ownership - This means everyone owns the code in
the team & that everyone is allowed to exert a "positive" duty to
make the changes to the code as necessary. Hence, it reduces the
dependency on any one developer.
• Metaphor – This means a simple layman explanation of how the
code works, i.e., the ability to explain the system to the new people
without flooding them with technical terms.

[Link] Kadam ,WIET 61

There 5 roles in Extreme Programming:
1. Tracker/Manager
2. Customer
3. Programmer.
4. Tester
5. Coach
• Customer involvement in the process of software development is
extremely high. The customer participates in all team meetings including
the most important ones – the planning games. He is not just a
stakeholder, but a team member. The client is the only person who writes
user stories and estimates the final product. Such degree of customer
involvement is required because XP projects develop in strict periods.
• Strong communication inside of Extreme Programming teams is also
caused by short terms of XP projects. The team members usually work in
the same office to have an ability to discuss any issue of the project. Such
discussions save lots of time.
• Extreme Programming has the shortest iterative cycles among other
Agile methodologies. Usually, they last only one week. That is why XP
developers have invented lots of new practices like pair programming
and planning game to raise the productivity of their work.
[Link] Kadam ,WIET 62
 Manager
• In Extreme Programming, the major responsibilities of the manager are −
1. Define the rules of planning game.
2. Familiarize the team and the customer on the rules of the planning game.
3. Monitor the planning game, fix any deviations, modify the rules if and
when required.
4. Schedule and conduct release planning and iteration planning meetings.
5. Participate with the team while they estimate in order to provide
feedback on how reality conformed to their prior estimates, both at team
level and individual level that eventually help them to come up with
better estimates next time.
6. Ensure that the team is working towards the next release as they progress
through the iterations with committed schedule and committed
functionality.
7. Track functional testing defects.
8. Track the actual time spent by each team member.
9. Adapt an ability to get all the required information without disturbing the
team’s work. The Manager is Accountable for these Responsibilities.

[Link] Kadam ,WIET 63

 Customer
• In Extreme Programming, the customer role is as crucial as the
developer role as it is the customer who should know what to program,
while the developer should know how to program.
• In Extreme Programming, the customer is required to be in constant
communication with the team and speak as a single voice to the team.
This is required since −
• Customer could be multiple stakeholders.
• Customer can be a team with the following potential members −
– Product Managers,Marketing, Sales,Business Analysts,End Users, their
Managers, Business/System Operations
The Major Responsibilities of the Customer are −
• Write user stories
• Write functional tests
• Set priorities on the stories
• Explain stories
• Decide questions about the stories
• The customer is accountable for these responsibilities.

[Link] Kadam ,WIET 64

 Developer
• The role of developer is the most important one in Extreme Programming. To be
a developer in Extreme Programming, you need to be accustomed with the
following −
• Developer Rights
– You have the right to know what is needed, with clear declarations of priority.
– You have the right to produce quality work at all times.
– You have the right to ask for and receive help from peers, superiors, and customers.
– You have the right to make and update your own estimates.
– You have the right to accept your responsibilities instead of having them assigned to
you.
• Developer Skills
– Pair Programming
– Communication – that is necessary and to the sufficient detail
– Always use the metaphor to use the right names
– Code only what is required.
– Maintain simplicity
• Collective Ownership
– If someone changes the code that you wrote, in whatever part of the system, you
have to trust the changes and learn. In case the changes are wrong-headed, you are
responsible for making things better, but be careful not to blame anyone.
– Be prepared to acknowledge your fears. Remember that you are part of a team and
courage is required for the success of Extreme Programming. 65
• Major responsibilities that you will be accountable for −
– Estimate stories
– Define tasks from stories
– Estimate tasks
– Write unit tests
– Write code to pass the written unit tests
– Perform unit testing
– Refactor
– Integrate continuously

Tester
Major responsibilities that you will be accountable for -
• Help the customer choose and write functional tests.
• Run the functional tests regularly.
• Report the test results.
• Ensure the testing tools run well.
[Link] Kadam ,WIET 66
 Coach
• Extreme Programming is the responsibility of everyone in the
team. However, if the team is new to Extreme Programming,
the role of a coach is crucial.
The responsibilities of the coach are −
1. Understand, in depth, the application of Extreme
Programming to the project.
2. Identify the Extreme Programming practices that help in
case of any problem.
3. Remain calm even when everyone else is panicking.
4. Observe the team silently and intervene only when a
significant problem is foreseen and make the team also see
the problem.
5. See to that the team is self-reliant.
6. Be ready to help.

[Link] Kadam ,WIET 67

 Advantages of XP
• Time-saving :Firstly, it allows the organizations to save time required for
project execution because XP focuses on the timely delivery of final products.
• Cost-Effective :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 : The developers who prefer to use this methodology create
extremely simple code that can be improved at any moment.
• High Visibility :The whole process in XP is visible and accountable. Developers
commit what they will accomplish and show progress.
• Misunderstanding the business and/or domain : Making the customer a part
of the team ensures constant communication and clarifications.
• Constant feedback is also the strong [Link] is necessary to listen and make any
changes needed in time.
• XP assists to create software faster thanks to the regular testing at the
development stage.
• Extreme Programming contributes increasing employee satisfaction and
retention.

[Link] Kadam ,WIET 68

 Extreme Programming disadvantages
• 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 the occurrence of similar bugs in the
future.
• This methodology does not measure code quality
assurance. It may cause defects in the initial code.
• XP is not the best option if programmers are
separated geographically.
[Link] Kadam ,WIET 69
• Applications of Extreme Programming (XP): Some of the projects
that are suitable to develop using the XP model are given below:
• Small projects: XP model is very useful in small projects consisting
of small teams as the face-to-face meeting is easier to achieve.
• Projects involving new technology or Research projects: This type
of project face changing requirements rapidly and technical
problems. So XP model is used to complete this type of project.
• Extreme Programming should be applied to systems that have no
constant functionality features. If the system should often change
its functions it requires the use of Extreme Programming method.
• Moreover, the XP method will succeed in situations where other
approaches to software development will be useless.
• It is also a good solution for risk issues.

[Link] Kadam ,WIET 70

Difference between XP & Scrum:
• Scrum works on iterations which are 2-4 weeks
long whereas XP iterations are 1-2 weeks long.
• Scrum doesn't allow changes in the sprint once
started. Unlike XP, which enables the introduction
of new features. These features can replace a
feature on which the work is yet to begin.
• XP works on strictly high priority, unlike Scrum.
• XP prescribes engineering practices like
refactoring, simple designs, pair programming,
etc., unlike Scrum.
• Roles in XP are the customer, the developer, the
tracker & the coach, unlike Scrum, where the
primary roles are of SM, PO & Scrum team.

[Link] Kadam ,WIET 71

 Kanban
• A Toyota engineer Taiichi Ohno invented the Kanban
framework.
• The Japanese word "Kan" means "Visual" & "Ban" means
"Cards". Hence, Kanban focuses on a visualized workflow where
work is broken down into smaller tasks and displayed on the
Kanban board.
• It helps in maintaining transparency in the team.
Principle of Kanban:
The main principles on which Kanban works:-
1. Visualizing what you do.
2. Cap the Work-In-Progress activities.
3. Enhance the flow by pulling the next most prior thing from the
backlog.
4. Continuous Improvement by inspecting blockers and adapting
to the ever-changing conditions, resources & customer
demands.
[Link] Kadam ,WIET 72
The core concept of Kanban includes:
• Visualize Workflow
- Split the entire work into defined segments or states,
visualized as named columns on a wall.
- Write each item on a card and put in a column to indicate
where the item is in the workflow.
• Limit WIP
- Assign explicit limits to how many items can be in progress
at each workflow segment / state. i.e., Work in Progress (WIP) is
limited in each workflow state.
• Measure the Lead Time
- Lead Time, also known as cycle time is the average time to
complete one item. Measure the Lead Time and optimize the
process to make the Lead Time as small and predictable as
possible.
This concept of Kanban is a direct implementation of a Lean Pull
Scheduling System. An item can move to the next segment /
state only when it obtains a slot in there.
[Link] Kadam ,WIET 73
• Lead time is the amount of time that passes from
the point a new work item is requested to the
point it is completed.
• In Kanban, it’s recommended to measure lead
time once a team member has committed to a
new work request .

[Link] Kadam ,WIET 74

• Cycle Time is the amount of time a team/ person spends actually
working on a work item up until it is ready for delivery.
• While lead time measures the whole process since the arrival of new
demand, cycle time analyzes those areas of the process where teams
are actively adding value to the work at hand.
• In other words, on a Kanban board, the cycle time metric usually
collects data whenever the work item moves to "in progress".

[Link] Kadam ,WIET 75

 Process of Kanban
Kanban Board consists of:-
• Columns – Each column represents the progress status, e.g., “To-Do”,
“Doing”, “Done”.
• Visual Cards – the Main feature of any Kanban board is Stickies, cards,
etc.
• WIP limit – Maximum number of cards that are workable at any point in
time.
• Commitment Point – The step where tasks are picked up from Stories/
backlog.
• Delivery Point – It is the point where the end customer gets the final
product.

[Link] Kadam ,WIET 76

A Kanban board can be more detailed in terms of the information provided
through columns. e.g., In the image above, "Assignee" & "Archive" columns
are also added to further detail the process.
It implies that depending upon the need, the enhancement of the
complexity of any Kanban Board takes place by adding more columns into it.

[Link] Kadam ,WIET 77

Example from our testing world:-
• First, the user requirements are collated & collected in the
form of a Product Backlog. After that, the curation of a
Kanban Board happens, which has stickies on it – a visual
representation of tasks.
• After that, say our story is to “test a product” then various
tasks under it can be Design, Development, and Test case
creation, Test Execution, etc.
• Finally, these tasks are pulled from the backlog/stories &
moved to the “To-Do” column; it is the Commitment Point.
• As soon as, the team starts working on a particular task, it
moves to "In-Progress".
• During the process, capping of the maximum number of tasks
that can be carried out at any given time happens. It is known
as the WIP limit.
• As soon as the tasks finish, they move to the next column,
"Done". It is a Delivery Point.

[Link] Kadam ,WIET 78

• Kanban swimlanes are horizontal lines that split a
Kanban board into sections.
• Teams usually use them to visually separate different
work types on the same board and organize
homogenous tasks together.

[Link] Kadam ,WIET 79

Advantages of Kanban
Following are the main advantages of Kanban:-
Ease of use:
• Kanban is a very simple and easy to understand approach, which makes it
practical for the management of a company to apply effectively. You do
not have to be an expert to work with the Kanban approach.
Promotes continuous and sustainable improvements in the various
functions of the company:
• Kanban approach not only consists of manual guidelines or cards but also
draws visualizations of the process outputs which makes the analysis of
work easier. This could also highlight other potentially uncertain areas
where additional focus is needed.
Flexibility - Firstly, this means there are no prescribed phase durations, and
priorities are reassessed continuously based on the most recent
information.
Continuous Delivery - The Second advantage is delivering small portions of a
project continuously to the customer. Which, in turn, helps in
synchronizing the future iterations with the updated business
requirements.
Adaptability:
• Kanban encourages maximal adaptability, which is incredible for more
extensive ventures that require ongoing changes. 80
Collaboration:
• Kanban advances collaboration and makes the whole team
work together to convey the ideal outcomes.
Low Overheads:
• Supervision of the use of a Kanban board, cards, and analysis of
output is easier as compared to most methods/approaches to
project management.
Reduces costs :
• Kanban stands out by highlighting process issues and solving
them. Kanban system upgrades the flow and management by
directly helping the company to engage the company’s existing
systems i.e. just in time (JIT) and make to order etc. which
decreases carrying or holding costs
Reduction of Waste - The Kanban system focuses on the reduction
of waste in all its forms: over-production, unnecessary motion,
defects, over-processing, and waiting. In terms of software
development - Work that is not needed, incorrect work, etc.
[Link] Kadam ,WIET 81
Disdvantages of Kanban
• An outdated Kanban board that can lead to issues in the development,
can make the board overcomplicated,
Cannot be used independently:
• Kanban is not a methodology that can be connected autonomously, or
maybe it can be combined with other forms and frameworks of a
company like JIT, make-to-order, and scrum, etc., making these
frameworks more obvious.
Does not fit into a dynamic environment:
• Kanban approach assumes the plans that are stable and consistent to a
certain level, it may become feeble in industries where the activities are
not still.
The inability for an iteration:
• Building software in iterations is a foundation for most development
processes, which is not integral to Kanban at a ticket level. You can build
iteration on top of Kanban, but it often ends up being its own separate
process.
Lack of timing:
• There are no timeframes associated with each phase, which can be
disadvantageous.
[Link] Kadam ,WIET 82
 Difference between Kanban & Scrum
• The time-boxed sprints are optional in Kanban, unlike
scrum where iterations are time-bound to 2-4 weeks.
• Work is pulled from the backlog, as a single unit, as
and when needed, unlike Scrum where we pick up
batches of work from the product.
• In addition to the above, the client can add new
features during an ongoing iteration, unlike Scrum,
where no addition of new features can happen once
an iteration starts.
• Multiple teams share the Kanban board.
• Moreover, there are no defined roles in Kanban like
Product Owner (PO), Scrum Master (SM) or Scrum
team, etc.
[Link] Kadam ,WIET 83
 Scrum Kanban
Scrum prescribes roles. In Kanban, roles are optional.
Product backlog is to be prioritized. Prioritization is optional.
Sprints are to be time-boxed. You can Time-boxed iterations are optional.
choose the length of the sprint, but once
chosen, the same length is to be
maintained for all the sprints.
Scrum team needs to commit to a Commitment is optional.
particular amount of work for the sprint.
Cross-functional teams are prescribed. Cross-functional teams are
[Link] teams are allowed.
Uses velocity as default metric for Uses lead time (cycle time) as default
planning and process improvement. metric for planning and process
improvement.
Items such as stories, tests must be No particular item size is prescribed.
broken down so that they can be
completed within one sprint.

[Link] Kadam ,WIET 84

Sprint backlog shows what tasks are to Tasks are defined at workflow level. WIP
be executed during the current sprint. is limited per workflow state.
These tasks are displayed on Scrum
board. Scope of the sprint is fixed. WIP is
limited per unit of time (WIP limit is the
velocity).
Additions/Changes cannot be done Additions /changes can be done if WIP
within a sprint. limit is not crossed.
New Scrum board is set at the beginning Kanban board is persistent.
of every sprint.
Daily meetings need to be conducted. Daily meetings are optional.
Burn-down charts are prescribed. No particular chart is prescribed

[Link] Kadam ,WIET 85

 Scrum Kanban

Scrum master, product owner, and No set roles are defined. Roles are not
Team Roles
team members make a scrum team required to be cross-functional
The vertical columns in the active Vertical columns of Kanban Board reflect
scrum of a Scrum task board are workflow stages like backlog, to do, In
used to reflect each stage of the Progress and Done. But in Kanban, it has
Work Boards
workflow of the project. Each task’s a limit for maximum stories. Limited
progress is mentioned under the “To stories can be present there on board for
do” column. that particular column.
Release method At the end of each sprint. Continuous delivery
The team should not bring in and out
the tasks during the sprint. Changes Changes and modifications can happen
Philosophy
in Sprint delivery need to go through any time by the team working on it.
proper channels.
Regular fixed-length sprints (i.e.,
Cadence Continuous flow
two weeks)
Release At the end of each sprint if approved Constant delivery or at the team's
methodology by the product owner discretion
[Link] Kadam ,WIET 86
 Practices Scrum Kanban XP

Iterative Increments are

Approach Short Iterations
Increments Iterative
Continuous
Time 2-4 weeks 1-6 weeks
Delivery

Team Size 5-9 Small to medium Small team, 2-12

Suitable Project
All types All types Smaller projects
size
Sprint, Product
User stories,
Backlog, Sprint Kanban board,
Major Practices refactoring, pair
Backlog, Scrum stickies
programming
meetings

[Link] Kadam ,WIET 87

 Traditional Software Development Agile Software Development

It is used to develop simple software. It is used to develop complicated software.

In this methodology, testing and

In this methodology, testing is done once
development processes are performed
the development phase is completed.
concurrently.

It follows a linear It follows an iterative organizational

organizational expectation structure. structure.

It provides less security. It provides high security.

Client involvement is less as compared to Client involvement is high as compared to

Agile development. traditional software development.

It provides all the functionality needed by

It provides less functionality in the software.
the users.

It supports a changeable development

It supports a fixed development model.
model.

It is used by freshers. It is used by professionals.

88
Development cost is less using this Development cost is high using this
methodology. methodology.

It majorly consists of five phases. It consists of only three phases.

It is less used by software development It is normally used by software development

firms. firms.

The expectation is favored in the Adaptability is favored in the agile

traditional model. methodology.

Agile software development methodologies

are casual. In other words, customers who
Traditional software development work with companies that utilize Agile
approaches are formal in terms of software development approaches are more
communication with customers. likely to interact with them than customers
who work with companies that use traditional
software development methodology.

For starters, typical software development

approaches employ a predictive approach.
There is full specification and prediction of Here, a flexible approach is used as the 89
Examples
Examples
•Office productivity suites
•Sky
•Data management software
•Phillips
•Media players
•JP Morgan Chase
•Security programs

Models based on Agile Software

Development-
Models based on Traditional Software
•Scrum
Development-
•Extreme Programming (XP)
•Spiral Model
•Crystal
•Waterfall Model
•Dynamic Systems Development Method
•V Model
(DSDM)
•Incremental Model
•Feature Driven Development (FDD)
•Adaptive Software Development (ASD)

[Link] Kadam ,WIET 90