BSE 1206: Software

Development
Principles
Software Process Models: Agile Methods
Agile Manifesto - PRINCIPLES
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software
• Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

Source: Principles behind the Agile Manifesto

Agile Manifesto - Principles
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.
What is Agile?
• Agile is a set of values and principles that guide and shape development
• There are a number of agile development methods that embody these values and
principles in their practices:
o Extreme Programming (XP)
o Scrum
o Kanban
o Crystal Agile Framework
o Dynamic System Development Method (DSDM)
o Feature-Driven Development (FDD)
Case Study: spotify
• https://www.youtube.com/watch?v=Yvfz4HGtoPc
• https://www.youtube.com/watch?v=vOt4BbWLWQw
• What did you find interesting? Any thoughts you'd like to put forward or discuss?
Extreme Programming (XP)
XP is a very lightweight incremental software development process
• Originally used for small to medium-sized software projects
• Designed to adapt well to the observed realities of modern software production:
• Short timelines
• High expectations
• Severe competition
• Unclear and rapidly changing requirements
• Based on the idea of continuous requirements
• Principles
o Rapid feedback – from customer
o Assume simplicity – keep designs simple
o Incremental change – small changes keep things manageable
o Embracing change – keep your options open
o Quality work – strive for high quality
What’s so Extreme about it?
Why is it called Extreme?
• The idea was to take the best practices of good software
development to the limit (the extreme)
• If code reviews are good, review code all the time
• If testing is good, test all the time
• If design is important, design all the time
• If simplicity is good, always use the simplest solution possible
• If architecture is important, refine architecture all the time
• If integration is important, integrate all the time
• If short iterations are good, use shortest iterations possible
XP - Practices
Practice Description
Planning game Customers and developers cooperate to produce business value rapidly. The scope of the
next release is quickly determined. When necessary, the plan is updated
Small releases Start with the smallest useful feature set.
Release early and often, adding a few features each time
System Metaphor Use of a simple metaphor for the whole system for easy to remember naming convention.
Simple Design Always use the simplest possible design that gets the job done; uses the fewest number of
classes and methods. Only do what is needed to meet today’s requirements.
Continuous Testing Before programmers add a feature, they write a test for it. Programmers continuously
write unit tests, customers write acceptance tests
Refactoring Restructure the system without changing its behaviour, to improve quality; remove any
duplicate code generated during coding.
Pair Programming All code is written by two programmers at one machine. Essentially, all code is reviewed as
it is written
XP practices
Practice Description
Collective code ownership Anyone can change any code, anywhere, at any time. No single person owns a
module. Improvement of existing code can happen at any time by any pair.
Continuous integration All changes are integrated into the code base at least daily. The tests have to
run 100% both before and after integration.
40-hour week All programmers go home on time. Working overtime is the exception.
On-site customer Development team has continuous access to a real live customer, i.e.,
someone who will actually be using the system. For commercial software with
lots of customers, a customer proxy (pm) will be used instead.
Coding standards Everyone codes to the same standards, in order to ease communication.

Scalability: XP works well with teams up to 12-15 developers. Fails beyond 20. large projects are split into smaller
groups and apply XP within each group.

Environment: Programmers must be located physically close, often in the same room or desk. Iterations 1-3
weeks. End of iteration delivers a working system
Scrum
“Scrum is a lightweight framework that
helps people, teams and organisations
generate value through adaptive solutions
for complex problems”
– Ken & Jeff
• 2020-Scrum-Guide-US.pdf (scrumguides.org)
• A Brief Overview of the Scrum Framework (youtube.com)
• What is Professional Scrum? - YouTube
Foundation of Scrum
• Empiricism:
• knowledge is acquired through experience
• Working through small experiments, learning from that work and adapting
what you are doing and how you are doing it as needed.
• Lean thinking: focus on the core essentials and reduce waste whenever possible
• Transparency: both the process and work artifacts must be visible
• Has three pillars
• Transparency
• Inspection and
• Adaptation
• Trust is the foundation that binds all the elements of scrum together
Scrum values

Source: scrum.org
Scrum team

Product Owner Scrum Master Developers

Scrum Team
• “Accountable for maximizing the
value of the product resulting from
the work of the scrum team”
• Represents customers and external
stakeholders
• Responsibilities include establishing
Product Owner goals, communicating and ordering
product backlog items
Scrum Team
• “accountable for the Scrum Team’s effectiveness. They
do this by enabling the Scrum Team to improve its
practices within the Scrum framework.”
• A servant leader
• Responsibilities include
• Coach team members
• Helping the team focus
• Removing barriers to progress
Scrum Master • Facilitate stakeholder collaboration
• ….
Scrum Team
• “committed to creating any aspect of a
usable increment in each Sprint”
• A self organising team
• Responsibilities include
• Creating a sprint plan
• Adapting their work to the sprint goal
Developers • Holding team members account
• Ensuring quality
The sprint
• The scrum process is composed
of a sequence of sprints

• Usually short (1 – 4weeks) long

Scrum Framework
Measuring Success in Scrum
The key Scrum metric is:
• Velocity: the number of story points done in a given sprint
• What is a user story?
• A user story is an informal, general explanation of a software feature written from the perspective of the
end user. Its purpose is to articulate how a software feature will provide value to the customer.
• “As a [persona], I [want to], [so that].”
• Backlog work items are often user stories – the basic unit of work
• What are story points?
• A measure of the effort required to complete a story in Scrum
Kanban
“Kanban is all about visualising your work, limiting
work in progress, and maximizing efficiency (or
flow). Kanban teams focus on reducing the time it
takes to take a project (or user story) from start to
finish. They do this by using a kanban board and
continuously improving their flow of work”
- https://www.Atlassian.com/agile/kanban/kanban-vs-scrum
Kanban Overview
• A card is used to represent each work
item (task) in a project
• The cards are organised on a Kanban
board
• Multiple columns each represent
stages of workflow
• The stages of workflow represented in
the board will vary across projects
• Done rules are used to move cards to
the next step
• Agile Development with Kanban
(CSCI 3060U Lecture 5) - YouTube
Kanban Overview
• Kanban ascribe to the principle of continuous release and collective ownership
• Releases can happen at anytime and should be frequent
• The entire team is responsible for delivery and for ownership of the Kanban board
• Bottlenecks in a workflow stage can be managed with Work In Progress (WIP) limits – maximum
number of cards in a stage.
• When a WIP limit is reached, the team works collectively to move items in that stage forward
Measuring Success in Kanban
The key Kanban metrics are:
• Lead time: total time from when the client requests an item to when it
is done
• Cycle time: total time it takes for a work item/task to move through
the workflow
• Cumulative Flow Diagram (CFD): visualises the numbers of work items
in each stage over time.
• A CFD is used to identify workflow bottlenecks and understand the
amount of work at each stage
https://www.youtube.com/watch?v=CKWvmiY7f_g
Scrum vs Kanban
Scrum Kanban
Sprint/cycle Sprint (1-4 weeks) Continuously
Release methodology At the end of each Continuously
sprint
Roles PO, SM, dev
Metrics Velocity Lead time, cycle time,
CFD, WIP
Change handling Changes made Change happens
between sprints anytime it is needed