Agile methoologies and scrum - Lean development and Agile methodologies lesson 3

Agile Methoologies and Scrum
francesco mapelli (@mapelli)
University of Insubria
April 29, 2016

Agile Methodologies Scrum References
Agile Methodologies
Scrum
References
francesco mapelli (@mapelli) University of Insubria

Introduction
History
Waterfall issues identied early
Risky and invites failure , Do it twice (Royce, 1970)
Light software development methods in the '90
Scrum
eXtreme Programming (XP)
...
2001 The Agile Manifesto

Introduction
Why a shift in the approach?
In a predictable environment a
theoretical model works better
In a chaotic environment (or when
process is too complex) an empirical
approach works better

Manifesto
Tha Agile Manifesto: Values
Individuals and iteractions over Processess and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Follwing a plan

Manifesto
Tha Agile Manifesto: Principles
Customer satisfaction by early and continuous delivery of
valuable software
Welcome changing requirements, even in late development
Working software is delivered frequently (weeks rather than
months)
Close, daily cooperation between business people and
developers
Projects are built around motivated individuals, who should be
trusted
Face-to-face conversation is the best form of communication
(co-location)

Manifesto
Tha Agile Manifesto: Principles
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Continuous attention to technical excellence and good design
Simplicity - the art of maximizing the amount of work not
done - is essential
Best architectures, requirements, and designs emerge from
self-organizing teams
Regularly, the team reects on how to become more eective,
and adjusts accordingly

Summary
Remember
Agile is a set of principles
Agile does NOT dene a method
Dierent approaches / methodologies can be agile

Introducion
Introduction to Scrum
Scrum is an agile framework
Focus on delivering the highest business value in the shortest
time
Allows rapid and recursive inspection of working software
2 weeks - 1 month
Business sets priorities
Teams self organize to determine the best way to deliver the
highest priority features
Every 2 weeks / 1 month anyone can see real working software
and decide to continue to work or release it

Introducion
Key concepts
Self organizing teams
No specic engineering practices
Simple set of rules that allows generating processes, practices
and solutions
evolutive approach
solutions can and should change in time
Requirements are items of a list called Product Backlog
Product is developed in a series of Sprints

Introducion
Overview

Sprint
Sprint
Scrum projects make progresses in a series of Sprints
Duration: 2-4 weeks or a month
(usually does not change)
Requirements, design, coding, testing during the sprint

Sprint
Not a sequential process
Instead of doing all of one thing at a
time, teams do a bit of everything all
the time

Sprint
No changes during a sprint
Changes should NOT occur during a sprint
If something changes, the next sprint will react to the new
context
Plan sprint duration according to how much time change can
be kept outside of the sprint

Sprint
Potentially shippable product at end of each sprint

Sprint
Worst case
The limited lenght of the sprint allows to limit the damage,
worst case we go back X days
But X days of learning have been mined

Scrum Framework
Scrum Framework
Roles
Product Owner
Scrum Master
Team
Cerimonies
Sprint Planning
Sprint Review
Sprint Retrospective
Daily Scrum Meeting
Artifacts
Product Backlog
Sprint Backlog
Burndown Charts

Scrum Framework - Roles
Roles
Product Owner
Scrum Master
Team

Product Owner
Dene the features of the product
Decide on release date and content
Be responsible for the protability of the product (ROI)
Prioritize features according to market value
Adjust features and priority every iteration, as needed
Accept or reject work result

Product Owner (2)
Voice of the customer (or customer himself)
Business side of the project
Should not interact on technical aspects

Scrum Master
Interface between team and management
Protects the team
Shield the team from external interferences
from committing too muc
from relaxing too much
Responsible for enacting Scrum values and practices
Removes impediments
Ensures that the team is fully functional and productive
Enables close cooperation across all roles and functions

Scrum Master (2)
Facilitator
Helps PO to update the backlog
Encourages improvements in the team
Stimulates solutions and facilitate meetings
Helps the team to dene when a feature is Done
...

Team
Typically 5-9 people
Members should be full-time
May be exceptions (e.g., database administrator)
Teams are self-organizing
Really!
Ideally, no titles but rarely a possibility
Membership should change only between sprints

Team (2)
Should deliver potentially shippable product at end of each
iteration
Cross-functional:
Programmers, testers, user experience designers, etc.

Scrum Framework - Cerimonies
Cerimonies
Sprint planning
Daily scrum meeting
Sprint review
Sprint retrospective

Sprint Planning

Sprint Planning
Toghether with the Product Owner, a sprint goal is identied
Sprint goal is an high-level statement of what value the sprint
will produce
Add functionalities related to booking for customers of the
website
Team selects items from the product backlog they can commit
to completing
Sprint backlog is created
Tasks are identied and each is estimated (usually in hours)
Collaboratively, not done alone by the ScrumMaster
High-level design is considered

Sprint planning, example
Product backlogAs a vacation planner, I want to see photos
of the hotels. - becomes
Code the middle tier (8 hours)
Code the user interface (4)
Write test xtures (4)
Code the foo class (6)
Update performance tests (4)

Daily scrum meeting
15-minutes
Stand-up
Not for problem solving
Whole world is invited
Only team members, ScrumMaster, product owner, can talk
PO can attend or not, depending on the team preferences
Helps avoid other unnecessary meetings
same place, same time

Daily scrum meeting
Everyone answers 3 questions
What did you do yesterday?
What will you do today?
Is anything in your way?
These are not status for the ScrumMaster
They are commitments in front of peers

Sprint review
Team presents what it accomplished during the sprint
we are inspecting how the product is going
Typically takes the form of a demo of new features or
underlying architecture
Informal
2-hour prep time rule
No slides
Whole team participates
Invite the world

Sprint retrospective
Periodically take a look at what is and is not working
we are inspecting how the process is going
Typically 15-30 minutes
Done after every sprint
Scrum Master facilitates the learning
Whole team participates
ScrumMaster
Product owner
Team
Possibly customers and others

Sprint retrospective - how
Whole team gathers and discusses what they'd like to:
Start doing
Stop doing
Continue doing
Other option
What was bad?
What was good?
What action items can we take?

Scrum Framework - Artifacts
Artifacts
Product Backlog
Sprint Backlog
Burndown Charts

Product Backlog
The requirements
A list of all desired work on the project
Ideally expressed such that each item has value to the users or
customers of the product
Prioritized by the product owner
Reprioritized at the start of each sprint
Amount of work is estimated, and re-estimated when
information changes

Product Backlog: example
As a guest, I want to be able to make a reservation
As a guest, I want to cancel a reservation
As a guest, I want to change the dates of a reservation

Sprint Backlog
What should be done to meet the sprint goal?
Things taken from the product backlog and translated into
technical tasks
example: As a vacation planner, I want to see photos of the
hotels.
Code the middle tier (8 hours)
Code the user interface (4)
Write test xtures (4)
Code the foo class (6)
Update performance tests (4)

Managing the Sprint Backlog
Individuals sign up for work of their own choosing
Work is never assigned
Estimated work remaining is updated daily
Any team member can add, delete or change the sprint backlog
Work for the sprint emerges
If work is unclear, dene a sprint backlog item with a larger
amount of time and break it down later
Update work remaining as more becomes known

Burndown Charts
a chart that tracks the remaining work
easily allows everybody to understand
how things are going
can be used to rene the future tasks
and react to current status

Scaling
Scalability
Typical individual team is 5-9 people
Scalability comes from teams of teams
Factors in scaling
Type of application
Team size
Team dispersion
Project duration
Scrum has been used on multiple 500+ person projects

Scaling
Scrum of Scrum
Meeting with members from dierent
scrum teams to update

Scaling
Spotify:
Squads, tribes, guidlds, chapters

Books
Books
Agile Software Development with Scrum - chapter 3

Attribution
Some inspiration and content from
Fornari, S. Lean Development and Agile Methodologies Course
Material
Scrum Presentation, Mountain Goat Software
https://www.mountaingoatsoftware.com/agile/scrum/a-
reusable-scrum-presentation
Scrum Training Series at scrumtrainingseries.com

License
Released under CC
This work is licensed under a Creative Commons
Attribution-ShareAlike 4.0 International License.

Agile methoologies and scrum - Lean development and Agile methodologies lesson 3

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Agile methoologies and scrum - Lean development and Agile methodologies lesson 3

Similar to Agile methoologies and scrum - Lean development and Agile methodologies lesson 3 (20)

Recently uploaded

Recently uploaded (12)

Agile methoologies and scrum - Lean development and Agile methodologies lesson 3