Agile Frameworks

Lecture 2
Agile Frameworks
 Agile represents a philosophy for software development,
emphasizing the value of iterating quickly and often to satisfy
customers. An agile framework can be defined as a specific
software-development approach based on the agile philosophy
connected in the Agile Manifesto
 Agile software development methods support a broad range of
the software development life cycle
 Some focus on the practices (e.g., XP, agile modeling)
 while some focus on managing the flow of work (e.g., Scrum,
Kanban).
 Some support activities for requirements specification and
development (e.g., Feature-Driven Development)
 while some seek to cover the full development life cycle (e.g.,
Dynamic System Development Method, ).
 These methodologies work on the basis of
continued evolution of requirements and solutions
that occurs by establishing collaboration between
self-organizing cross-functional teams.
 A way of encouraging the well-managed and
organized project management process, these
methodologies allow for recurrent inspection and
revision of the tasks.
 Giving a scope to adapt the best engineering
practices, these methods also assist in the delivery
of high-quality software products.
Agile methods
 While there are a number of different
methodologies available, some of the
common ones used are as mentioned below:
1. Scrum
2. Kanban
3. Extreme Programming (XP)
4. Dynamic Systems Development Method
(DSDM) etc
What is Scrum?
• Scrum is an agile process that allows us to focus
on delivering the highest business value in the
shortest time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Teams self-
organize to determine the best way to deliver the
highest priority features.
• Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint.
Sprints
 Scrum projects make progress in a series of
“sprints”
 Typical duration is 2–4 weeks or a calendar

month at most
 A constant duration leads to a better

rhythm
 Product is designed, coded, and tested

during the sprint

Scrum Framework
Roles
Product owner
Scrum Master
Team
Protocols
Sprint planning
Sprint review
Daily scrum meetings s
Artifacts
Product backlog
Sprint backlog
Burndown charts
Product Owner
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the
product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as
needed 
• Accept or reject work results
Scrum master
 The scrum master role was created as part of the Scrum
framework. 
 The role does not generally have any actual authority

(also known as servant-leadership).

 The name was initially intended to indicate someone who

is an expert at Scrum and can therefore coach others.

 The Scrum Master is also responsible for improving

interactions between the Scrum team and the

organization in order to maximize the productivity of the
Scrum team. Finally, the Scrum Master is responsible to
arranges and facilitates the team’s meetings – daily
Scrum planning sessions
The Team
 Typically
5-9 people
 Cross-functional:

Programmers, testers, user experience

designers, etc.
M embers should be full-time
 Teams are self-organizing

Ideally, no titles but rarely a possibility

 Membership should change only
between sprints
Sprint planning
 Team selects items from the product
backlog they can commit to completing
 Sprint backlog is created

Tasks are identified and each is estimated (1-

16 hours)
Collaboratively, not done alone by the
ScrumMaster
 High-level design is considered
The Daily scrum
 Daily 15-minutes Stand-up
 The Development Team uses the Daily
Scrum to inspect progress toward the
Sprint Goal and to inspect how progress is
trending toward completing the work in
the Sprint Backlog.
 The Daily Scrum optimizes the probability
that the Development Team will meet the
Sprint Goal. Every day, the Development
Team should understand how it intends to
work together as a self-organizing team
to accomplish the Sprint Goal
Everyone answers 3 questions

1. What did you do yesterday?

2. What will you do today?
3. Is anything in your way?
The sprint review
 Team presents what it accomplished during
the sprint
 The sprint review is an informal meeting

which the development team, the scrum

master, the product owner and the
stakeholders will attend. The team gives a
demo on the product and will determine what
are finished and what aren't.
Product Backlog?
 the Product Backlog is an ordered list of everything
that is known to be needed in the product.
 The Product Backlog is a continuously improved list,

with the initial version listing only the most

preliminary and well-known requirements (no
necessary well understood). Product Backlog evolved
based on changes in the product and development
environment.
 The Backlog is dynamic and it often changes to

identify what is necessary to make the product

reasonable, competitive, and useful. The Product
Backlog exists as long as the product exists.
Product Backlog Items (PBIs)
 Product Backlog Items (PBIs) are usually
sorted by value, risk, priority, and
necessity. It is a sequence of highest to
lowest priority, with each entry having a
unique order. Product to-do list entries at the
top need to be developed immediately. The
higher the ranking, the more urgent the
product to-do list entry is, the more you need
to think carefully and the more consistent
your opinion on the value.
 sprint backlog
 The sprint backlog is a list of tasks identified by
the Scrum team to be completed during the 
Scrum sprint. During the sprint planning meeting,
the team selects some number of product backlog
items,
 plus plans for delivering product increments for
achieving Sprint goals. Sprint Backlog is the
development team’s expectation of what
functions will be included in the next increment
and what work will be required to deliver those
functions.
 Burn down chart
 A burn down chart is a graphical representation of
work left to do versus time.
 The outstanding work (or backlog) is often on the

vertical axis, with time along the horizontal.

 Using a burndown chart is a means of seeing how

much work is left and how much time there is to

do it in.
How to Read a Burndown Chart

 The burndown chart has several points. There’s an x-axis,

which is the project or iteration timeline. The y-axis is the
work that needs to get done in the project. The story point
estimates for the work that remains is represented by this
axis.
Kanban
 Kanban is a method for managing the creation of products
with an emphasis on continual delivery while not
overburdening the development team.
 Kanban is a visual system for managing work as it moves
through a process.
 Kanban visualizes both the process (the workflow) and the
actual work passing through that process.
 Kanban, also spelt “kamban” in Japanese, translates to
“Billboard” (“signboard” in Chinese
 Kanban is not a software development lifecycle methodology
or an approach to project management. It requires that some
process is already in place so that Kanban can be applied to
incrementally change the underlying process
Principles
 Visualization: The Kanban board is a visualization of
workflows. The design itself is relatively flexible.
However, it is important that stations are clear and the
relevant limit is shown for each column.
 Limitation: Each column may only contain a maximum
number of orders. Only once an order card has moved
right is the team able to take a new card from the left.
This inevitably leads to a more efficient workflow.
 Management: During the work process, blockades and
bottlenecks can emerge. In these kinds of situation, it is
necessary to focus the team on clearing these obstacles.
Apart from that, observing the workflow can help to
correctly distribute capacities for the long term.
principles
 Regulation: Defined process rules are intended to
make workflows clearer and more transparent.
These rules include the setting of limits as well as
determining when a task is considered completed.
Process rules must also be a visual and mutable
part of the Kanban board.
 Feedback: Feedback forms a necessary component

of workflows and is a important for their

improvement. Regular meetings should be held for
this reason. In contrast to Scrum, Kanban does not
provide a strict framework for these meetings.
 Backlog: This list is where project tasks are broken down into individual
cards. This list also houses tasks that the team may want to work on or
will need to work on in the future but shouldn’t be moved into the “To-
Do” list yet. 

 Design: This list serves as the space in which the cards from the backlog
are moved over to become more fleshed out. This is when the team
needs to do more research or design before moving it into progress. 

 To-Do: Once the task is fully fleshed out, it is moved here to signal to

the team that it's ready to be worked on. At this point, a team member is
assigned to own the task and due dates are set.
 Doing: As the team is working on their tasks, they move the cards
to this list. At a glance, the entire team can see who is working on
what at a glance. The cards also make it easy to collaborate and
ask questions about certain tasks thanks to the Comment
functionality. 

 Review/Testing:  When the task is nearly complete, it is moved to

this list for its review or second set of eyes. (In the above
template, the example used is “Code Review” but it can be a
review stage for any work!)

 Done: Once the task is reviewed and approved, it is moved to this

list! 🎉
Scrum Vs. Kanban

1. Scrum stresses on planning. It starts with sprint planning

and ends up with sprint review. There are many meetings
held which help to assure that the team is aligned with the
next steps, priorities, and learnings from previous sprints.
2. It is not possible to add items to ongoing iterations.
3. A sprint backlog is owned by only by a single team.
4. Scrum software development method focuses on the
backlog
5. Scrum master acts as a problem solver.
6. Scrum helps firms to save time and money.
7. The project plan will never disturb even if a team member
leaves the team.
Scrum Vs. Kanban
1. Kanban is open to making changes on the go. It means
there is less rigidity and things can change frequently.
2. New items can easily add if the additional capacity is
available.
3. Multiple teams can share Kanban board
4. Kanban method entirely focuses on process dashboard
5. Kanban encourages every team member is a leader and
sharing responsibility amongst them all.
6. Kanban method focus on continuous improvement,
productivity, and efficiency.
7. If any of the team members exit during development, it
can hurt the project development.
Which Framework is Best?

 With so many different approaches to structuring agile

processes within your organization, you’re probably
wondering how to go about choosing one.
Unfortunately, there is no one-size-fits-all way to
practice agile software development. There are many
factors that may influence which framework you
choose to work with. Such as:
 Company size

 Team structure

 Available resources

 Needs of stakeholders

 Structure/size of your product portfolio

XP–Extreme Programming
 It is the type of Agile Development we develop
software with small team where the software
requirements changes rapidly.
 XP is summed up or based on twelve Practices.

1. The Planning Process :The main planning process

within extreme programming is called the Planning
Game. The purpose of the Planning Game is to guide
the product into delivery. Instead of predicting the
exact dates of when deliverables will be needed and
produced, which is difficult to do. where the
majority of planning for the project takes place.
2) Small Releases :The delivery of the software is done
via frequent releases of live functionality creating concrete
value. The small releases help the customer to gain
confidence in the progress of the project. This helps
maintain the concept of the whole team as the customer
can now come up with his suggestions on the project based
on real experience.
3) Metaphor :System metaphor stands for a simple design
that has a set of certain qualities. First, a design and its
structure must be understandable to new people. They
should be able to start working on it without spending too
much time examining specifications. Second, the naming of
classes and methods should be coherent. Developers
should aim at naming an object as if it already existed,
which makes the overall system design understandable.
5) Simple Design :The best design for software is the simplest
one that works. If any complexity is found, it should be removed.
The right design should pass all tests, have no duplicate code, and
contain the fewest possible methods and classes. It should also
clearly reflect the programmer’s intent.
6) Testing :All code must have unit tests. All code must pass all
unit tests before it can be released. When a bug is found tests are
created.
7) Refactoring: To deliver business value with well-
designed software in every short iteration, XP teams also use
refactoring. The goal of this technique is to continuously
improve code. Refactoring is about removing redundancy,
eliminating unnecessary functions, increasing code coherency,
and at the same time decoupling elements. Keep your code
clean and simple, so you can easily understand and modify it
when required would be the advice of any XP team member.
 Pair Programming :This practice requires two programmers
to work jointly on the same code. While the first developer focuses on
writing, the other one reviews code, suggests improvements, and fixes
mistakes along the way. Such teamwork results in high-quality
software, faster knowledge sharing but takes 
15 to 60 percent more time. In this regard, it’s more reasonable trying
pair programming for long-term projects.
 Collective Ownership: This practice declares a whole team’s
responsibility for the design of a system. Each team member can
review and update code. Developers that have access to code won’t get
into a situation in which they don’t know the right place to add a new
feature. The practice helps avoid code duplication. The
implementation of collective code ownership encourages the team to
cooperate more and feel free to bring new ideas.
 Continuous Integration Developers always keep the system
fully integrated. XP teams take iterative development to another level
because they commit code multiple times a day, which is also called 
continuous delivery. XP practitioners understand the importance of
communication. Programmers discuss which parts of the code can be
re-used or shared. This way, they know exactly what functionality
they need to develop. The policy of shared code helps eliminate
integration problems. In addition, automated testing allows
developers to detect and fix errors early, before deployment.

 40-Hour Week XP projects require developers to work fast, be

efficient, and sustain the product’s quality. To adhere to these
requirements, they should feel well and rested. Keeping the work-life
balance prevents professionals from burnout. In XP, the optimal
number of work hours must not exceed 45 hours a week. One
overtime a week is possible only if there will be none the week after.
 On-site Customer: According to XP, the end customer
should fully participate in development. The customer should
be present all the time to answer team questions, set
priorities, and resolve disputes, if necessary.

 Coding Standards : A team must have common sets of

coding practices, using the same formats and styles for code
writing. Application of standards allows all team members to
read, share, and refactor code with ease, track who worked
on certain pieces of code, as well as make the learning faster
for other programmers. Code written according to the same
rules encourages collective ownership.
 Which value and its related principles are
discourage in IT indudtry of Pakistna
 Is this agile development is fruitfull for

apkistan IT industry to adopt as there is no

environment of
 Id you are asked to build a online banking

app which agile framework you will adopt to

develop that app and justify your selection

 Modern programming methodologies make extensive use of
automated
 testing.
 a. Explain the Test-Driven Development paradigm showing the

benefits of
 adoption
 (9 marks)
 b. Explain the purpose of Unit Testing, how it is used and its

benefits giving
 clear examples.
 (8 marks)
 c. Explain the purpose of Acceptance Testing, its role and

benefits giving
 examples.