Introduction in Agile May, 2020

Methodology - Scrum
Trainer:
Activitate profesională:
• Senior Trainer în Managementul
proiectelor și Managementul
Timpului, Colors in Projects
Experiență:
• Peste 20 ani în dezvoltarea,
proiectarea și managementul
proiectelor software

• Lector, Facultatea de • Doctorat în informatică

Matematică și Informatică, UBB,
Cluj-Napoca
• Mentor a 3 echipe finaliste
mondiale la Imagine Cup, cea
mai importantă competiție
studențească de dezvoltare de
aplicații software

Ce nu știe multă lume despre mine:

Am un blog dedicat animației scurte (pe care nu l-am mai actualizat
de 3 ani). 

Câteva cuvinte care mă definesc:

Dan Suciu, Ph.D. Învăţ, mă dezvăţ, reînvăţ şi îi ajut pe ceilalţi să facă la fel.
 Conclusions
Scrum Basics
Lean & Kanban
Agile Manifesto
Estimation & Planning
The Agile Mindset

Agenda
The Agile Mindset
The Agile Mindset

Dave Snowden

Cynefin Framework
an approach to making sense of challenges that
surround us in terms of their relative complexity
The Agile Mindset

Ordered Complex Chaotic

The Agile Mindset

Cause ↔ Effect

◼ Exists
◼ Repeatable
◼ Predictable
Ordered
The Agile Mindset

Cause ↔ Effect

◼ Exists
◼ Unpredictable
◼ Unknowns
Complex
The Agile Mindset

Cause ↔ Effect

◼ Indeterminate
◼ Scope undefined
Chaotic
The Agile Mindset
The Agile Mindset

Traditional
Projects
The Agile Mindset

O N O M
L C M B
A E P I
T R L G
I T E U
L A X O
E I U
N S
TEAM

12
...solving a problem...
...creating a solution...
...working with people...
...expressing ideas
in a language...
...following a methodology...

13
The Agile Mindset
Incremental delivery

“The illiterate of the 21st

century will not be those
who cannot read and write,
but those who cannot
Alvin Topfler learn, unlearn, and relearn.”
The Agile Mindset
The Agile paradigm

Scope fixed Budget Time

Agile

Classic
variable
Budget Time Scope
The Agile Mindset
Iterative progress

Jeff Patton: http://www.agileproductdesign.com/blog/dont_know_what_i_want.html

The Agile Mindset
Iterative & Incremental
 Conclusions
Scrum Basics
Lean & Kanban
Agile Manifesto
Estimation & Planning
The Agile Mindset

Agenda
Agile Manifesto
The Agile Manifesto
Agile Manifesto – 2001
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
The Agile Manifesto
Agile Manifesto: The values

Individuals and Interactions over Processes and Tools

Projects are accomplished through people
Agile projects put a heavy emphasis on team work (shared ownership)
Processes and tools will likely to be necessary but they can also get in the way

Working deliverables over Comprehensive documentation

Projects have the goal of creating and delivering value as working deliverables
Some projects are caught up in delivering extensive documentation that is valueless
Teams change and memory is lost thus “barely sufficient documentation” is needed

Over ≠ Instead of ≠ Reject

The Agile Manifesto
Agile Manifesto: The values

Customer collaboration over Contract negotiation

Be flexible and accommodating changes to be closer to your client
Very difficult to vision and define the product upfront
Don’t want to punish our clients for every change
Trial and error approach to collaboration
Doesn’t mean there will be no contract

Responding to change over Following a plan

Traditional project management don’t handle changes very well
Initial plans are sometimes inadequate and the business environment changes
Don’t abandon planning and just react to changes!

Over ≠ Instead of ≠ Reject

Principle 1

Our highest priority is to

satisfy the customer through
early and continuous
delivery of
valuable outcome.

CUT THE SCOPE IN MILESTONES AND

DELIVER AS SOON AS POSSIBLE

BE AWARE THAT OUTPUT IS NOT

NECESSARILY OUTCOME.
Principle 2

Welcome
changing requirements,
even late in development.
Agile processes harness
change for the customer's
competitive advantage
CUSTOMERS DON’T KNOW WHAT
THEY WANT. THAT’S OK.

PRODUCT BACKLOG IS ALWAYS

CHANGING. THAT’S ALSO OK.
Principle 3

Deliver
working versions frequently,
from a couple of weeks to a
couple of months,
with a preference to the
shorter timescale.

ALWAYS PAY ATTENTION TO QUALITY.

DELIVER A FUNCTIONAL VERSION AS

OFTEN AS POSSIBLE.
Principle 4

Business people and

developers
must work together daily
throughout the project.

KEEP STAKEHOLDERS AS CLOSE AS

POSSIBLE.

WORKING TOGETHER MEANS BEING

TRANSPARENT, INSPECTING AND
ADAPTING CONTINUOUSLY.
Principle 5

Build projects around

motivated individuals.
Give them the
environment and support
they need and trust them
to get the job done.
AGILE IS NOT MOTIVATING PEOPLE.
LEADERS AND PROJECTS DO.
ENVIRONMENT MEANS CONTEXT,
CONSTRAINTS AND OBJECTIVES.
TRUST IS ESSENTIAL TO AGILE
PRACTICE.
Principle 6

The most
efficient and effective
method of conveying
information to and within a
development team is
face-to-face conversation.
EFFICIENT MEANS BEING CONCERNED
ABOUT CONSUMED RESOURCES.
EFFECTIVE MEANS BEING CONCERNED
ABOUT GOAL ACHIVEMENT.
INDIRECT COMMUNICATION SHOULD
BE USED WITH PARSIMONY.
Principle 7

Working deliverables
are the primary measure of
progress.

PAY ATTENTION TO ACCEPTANCE

CRITERIA.
MAKE SURE TO DEFINE EXACTLY WHAT
ARE THE DELIVERABLES.
MEASURING PROGRESS IS CRUCIAL TO
AGILE PROJECTS.
Principle 8

Agile processes promote

sustainable development.
The sponsors, developers
and users should be able
to maintain a
constant pace indefinitely.

SUSTAINABILITY REFERS TO BUDGET,

SCOPE AND EFFORT.

AGILE PROJECTS ARE MARATHONS,

NOT 100m HURDLES.
Principle 9

Continuous attention
to technical excellence and
good design
enhances agility.

CONTINUOUS ATTENTION IMPLIES

FROM THE VERY BEGINNING.

TECHNICAL EXCELLENCE IS CHOOSING

THE RIGHTEST SOLUTION DEPENDING
ON PROJECT’S OBJECTIVES.
Principle 10

Simplicity
– the art of maximizing the
amount of work not done –
is essential.

NO UNNECESSARY COMPLEXITY.
Principle 11

The best architectures,

requirements, and designs
emerge from
self-organizing teams.

SELF-ORGANIZING MEANS
COLLECTIVELY ASSUMING AND
PRACTICING
MANAGEMENT PRINCIPLES.
Principle 12

At regular intervals,
the team reflects on how
to become more effective,
then tunes and adjusts its
behavior accordingly.
NEVER GIVE UP ON RETROSPECTIVES.

REFLECTING INVOLVES A GENUINE AND

HONEST CONCERN.

ADJUSTING MEANS A MEASURABLE

IMPROVEMENT.
 Group Activity
Objectives:
Debate about applying Agile principles

Activities:
In groups, choose and discuss about the principles
that seem to be the most difficult to apply in your
day-to-day activity.
Then share and debate your group opinions with
the others.

Duration: 10 minutes
 Conclusions
Scrum Basics
Lean & Kanban
Agile Manifesto
Estimation & Planning
The Agile Mindset

Agenda
Scrum Basics
Metode hibride
Metodologii Agile

10th Annual State of Agile Report, 2016

Scrum Basics
Scrum pillars
▪ The pillars of Scrum
– Transparency
– Inspection
– Adaptation

▪ They refer to
– Process
– Results
Scrum Basics
Scrum roles
▪ Product Owner
– Responsible for maximizing product value
– Managing the Product Backlog
▪ Scrum Master
– Ensure Scrum is understood and used
– Remove impediments
– Facilitate events and coaching
▪ Development Team
– Group of professionals that actually builds the product
– Empowered to manage their own work
– Self-organizing and cross-functional members
Scrum Basics
Scrum process
Scrum Basics
Scrum artifacts ▪ Product Backlog
– Prioritized list of everything might be needed for
releasing the product
– Is never complete and evolves as the product
evolves
– Belongs to the Product Owner
▪ Sprint Backlog
– Items from Product Backlog selected to be
undertaken in the current sprint
– Belongs to the Development Team
▪ Increment
– The Increment is the sum of all the Product Backlog
items completed during a Sprint and all previous
Sprints.
– At the end of a Sprint, the new Increment must be
“Done”.
Scrum Basics
User stories
• A user story is one or more sentences in the everyday/business language that captures what a
user does or needs to do

• Format:
As a [Role], I want [Functionality] So that [Business Value]

• INVEST mnemonic
• Independent – allow to reprioritize in any order
• Negotiable – discuss and make tradeoffs
• Valuable – clear business benefits
• Estimable – team is able to estimate the effort
• Small – easier to estimate and test
• Testable – how do you know when it is done?
 Task Board
Scrum
Scrum Basics
Definition of Ready
▪ The Definition of Ready (DoR) sets out the criteria for the stories needed to make the Sprint succeed
▪ The DoR is drawn up by the Squad, cooperating with the PO
▪ The Squad determines whether Product Backlog items meet the DoR
▪ The PO respects the DoR. That means that a Product Backlog item is only included in a Sprint if it meets
the DoR.
▪ Example:
– Story Statement
– Specification by Example
– Flow chart, if needed
– Use Case, if Acceptance Criteria missing
– Wireframe, if needed, delivered
– UX [mock-up] if needed, delivered
Scrum Basics
Definition of Done

▪ Is a crucial tool for making sure that the developed product is satisfying stakeholders
expectations
▪ The Squad is only finished with a Sprint Backlog item once it meets the DoD
▪ The DoD is drawn up by the Squad
▪ A Definition of Done should exist for:
– User stories
– Releases
– Final project deliverables
Scrum Basics
Acceptance criteria

▪ DoD are not specific for a certain Product Backlog item, but they apply to all

▪ Acceptance Criteria are closely related to the backlog items and refer to functional
requirements, being an important guide for test cases

▪ They are often expressed in a standard format such as:

Given [clearly defined conditions]
When [user or automated action]
Then [expected result]
Scrum Basics
Sprint progress – Burn down charts

• Is a graphical
representation that
shows progress
over a period of
time (one iteration or
more) and help to
determine when the
project or release
should be complete.
• Represents the work
left versus time
Scrum Basics
Sprint planning
▪ Rules
– Duration: timeboxed to maximum 2h/sprint week
– Participants: PO and Development Team (external invitees that may contribute are optional)
– Facilitator: Scrum Master
▪ Goal
– Project predictability
▪ Objectives
– To create a Sprint Backlog
– To get Team commitment for the Sprint
▪ Structure
– Part 1: PO presents the Stories that are prioritized and ready for the Sprint (half of time)
– Part 2: The Team is sizing Stories and slicing them in Tasks, then commits to PO (half of time)
▪ Common traps
– Long and boring meetings with too detailed technical discussions
– Superficial approach, team members do not really understand the requirements
– Wrong and/or manipulated estimations
Scrum Basics
Daily Scrum
▪ Rules
– Duration: timeboxed to maximum 15 minutes
– Participants: Development Team (PO is welcome, but optional and must be silent)
– Facilitator: Scrum Master or a Team member
▪ Goal
– Self-organizing
▪ Objectives
– To have a common Team understanding of the Sprint progress
– To collect impediments and decide who will tackle each of them
▪ Structure
– Each Team member explains what he/she achieved since last Daily Scrum, what he/she will work until
next Daily Scrum and what impediments prevent him/her to work (if any)
▪ Common traps
– Long and boring meetings with too detailed technical discussions
– Superficial approach, team members do not really understand the Sprint progress
– False impediments
Scrum Basics
Sprint review
▪ Rules
– Duration: timeboxed to maximum 1h/sprint week
– Participants: PO and Development Team (stakeholders are welcome, but optional)
– Facilitator: Scrum Master
▪ Goal
– Delivering incrementally
▪ Objectives
– To review and accept the Stories finalized by the Team
– To discuss potential changes of the Product Backlog resulting from the Sprint Review (priorities)
▪ Structure
– Team is organizing a demonstration of finalized Stories
– PO is reviewing and accepting depending on DoD and Acceptance Criteria
– PO and team discuss the results of the Sprint and the consequences on subsequent Sprints
▪ Common traps
– Acceptance Criteria not checked during review (incomplete testing)
– DoD ignored
Scrum Basics
Sprint retrospective
▪ Rules
– Duration: timeboxed to maximum 45mins/sprint week
– Participants: Development Team (PO only if invited by the Team)
– Facilitator: Scrum Master
▪ Goal
– Continuous improvement
▪ Objectives
– To review the efficiency and effectiveness of the teamwork and methods used
– To determine and decide upon action items that will lead to improving Team’s performance
▪ Structure
– Collecting Team member’s opinions about what they should keep doing, stop doing or doing differently
– Discussing and collectively deciding the improvements applied in the next Sprint
▪ Common traps
– Finger-pointing, personal conflicts
– False harmony, avoiding to discuss about “the elephant in the room”
– Failing to identify effective action items
Scrum Basics
Backlog refining meeting (grooming)
▪ Rules
– Duration: timeboxed to a duration negotiated by PO and Team
– Participants: PO and Development Team
– Facilitator: Scrum Master
▪ Goal
– Improving the planning process
▪ Objectives
– To communicate significant changes in the Product Backlog
– To slice backlog items that are too big, then optionally to roughly estimate the resulted Stories
– To collect questions about the Stories that are prioritized for next Sprint
▪ Structure
– Flexible agenda, proposed by Product Owner
▪ Common traps
– Getting into too detailed discussions about backlog items
– Slicing backlog items using technical criteria (Technical Stories instead of User Stories)
Ce este estimarea

GHICESC ESTIMEZ MĂSOR

când... când... când...

EXPERTIZĂ
Nu am idee despre ce Am idee despre Știu exact cum se
e vorba abordare abordează

EXPERIENȚĂ
Nu am mai făcut ceva Am făcut lucruri Am mai făcut exact
similar similare același lucru

DEX: Apreciere a mărimii, valorii etc. pe baza unor date incomplete

Scrum Basics
Relative sizing and story points
▪ Estimation technique that ranks stories by their size relative to each other
and estimates based on those rankings.
▪ Story points are typically expressed using the Fibonacci sequence of numbers
– Using this technique the estimation would be quick because one story it not evaluated from the
scratch, it is evaluated by its position relative to other stories
– It is useful when planning for the next iteration to decide which stories can be completed in that
iteration
▪ Fibonacci Sequence
▪ Guidelines:
– The team should own the definition of story points
– Story points definition should be all-inclusive
– Point sizes should be relative
– When disaggregating, totals don’t need to match
– Estimate should include complexity, effort and risk
Scrum Basics
Poker planning
▪ Planning poker is a consensus-based estimation technique, mostly used to estimate
effort or relative size of user stories. After each player has selected a card, all cards are
exposed at once and consensus is reached in steps.
▪ Advantages:
▪ Minimizing the “bandwagon effect”
(grouping around most popular opinion)
▪ Preventing HIPPO decision making
(Highest-Paid Person Opinion)
▪ Minimizing the “groupthink” effect
(excessive concern for group harmony)
Planificarea preliminară

1
XS S M L XL
Pregătiți o listă de cerințe ale
proiectului cât mai detaliate
xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx
posibil
xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx
2
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
Organizați un spațiu de lucru cu
dimensiuni de tricouri drept coloane
xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx
xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx 3
Solicitați echipei de proiect să
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
estimeze fiecare cerință prin
plasarea ei pe o coloană
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
4
Răspundeți la întrebările adresate de
xxxxxxxxx xxxxxxxxx xxxxxxxxx
echipă, dar nu intrați în foarte multe
xxxxxxxxx xxxxxxxxx xxxxxxxxx
detalii

xxxxxxxxx xxxxxxxxx
xxxxxxxxx xxxxxxxxx
Planificare preliminară
5 XS S M L XL
Pregătiți o a doua rundă folosind
șirul lui Fibonacci 1 2 3 5 8 13 20 40 60 100

6 xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxxxx

Cereți echipei de proiect să xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx
xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx
rafineze estimările
xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx

7 xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx

xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx

Calculați dimensiunea totală a xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx

cerințelor de proiect
xxxxxxxxx xxxxxxxxx xxxxxxxxx
xxxxxxxxx xxxxxxxxx xxxxxxxxx

8 1 10 12 25 40 39 40 40 120 100
Calculați durata estimată de
finalizare folosind intervale de ±25% => interval [254, 424]
toleranță
TOTAL 427 SP 342 - 512 SP
Sprint planning
Estimate ranges
▪ Estimates should be presented in ranges
– to indicate our level of confidence
– to manage stakeholders expectation
▪ As project progresses we can start factoring the velocity of completed iterations and create a
better estimate of the project (stabilized velocity)
 Conclusions
Scrum Basics
Lean & Kanban
Agile Manifesto
Estimation & Planning
The Agile Mindset

Agenda
Lean & Kanban
Case Study: Statewide Automated Child Welfare Information
System (SACWIS)

• Florida: started in 1990, estimated 8 years and $32 million

• In 2002 Florida spent $170 million and estimated to be completed
in 2005 with $230 million

• Minnesota: started in 1999

• completed in 2000 at cost of $1.1 million

• Why? Standardized infrastructure, minimized requirements,

team of 8 capable people
Source: Standish Group
Lean & Kanban
Lean Thinking
Lean principles
Maximize the value (partially work
done, delays, handoffs, etc.)

Facilitate communication early

Allow technical people to
and often, get feedback as soon
make local decisions in order
as possible, and build on what
to be productive and
you learned
successful (opposed to
micromanaging)

Core concepts
Make decisions and Quickly delivering value
commit to things as late to maximize project’s ROI
as possible

Don’t test at the end, use techniques Align the whole system not just one
that embed quality at every step piece, seek for better intergroup
relations
Lean Thinking

Lean Principles are… just Principles

• Eliminate waste does not mean throw away all documentation.

• Amplify learning does not mean keep on changing your mind.
• Decide as late as possible does not mean procrastinate.
• Deliver as fast as possible does not mean rush and do sloppy work.
• Empower the team does not mean abandon leadership.
• Build integrity in does not mean big, upfront design.
• See the whole does not mean ignore the details.
Lean Thinking
Value stream mapping
• Specify value from the standpoint of the end customer
• Identify the value stream for each product family
• Make the product flow
Find value
• So the customer can pull
• As you manage toward perfection
Improve Identify
continuously stream

Allow Make it
customer to
pull flow
Lean Thinking
Value stream mapping
Lunch at
restaurant

Finding a Reading
Ordering Eating Paying
table the menu

2 min 3 min 2 min 30 min 3 min

10 min 10 min 30 min 10 min

Total cycle time = 110 min
Value-added time = 40 min
Cycle efficiency = 40 / 110 = 36%
Lean Thinking
Value stream mapping
Lunch at
fast-food

Finding a
Ordering Paying Eating
table

2 min 1 min 2 min 30 min

5 min 0 min 0 min

Total cycle time = 40 min
Value-added time = 35 min
Cycle efficiency = 35 / 40 = 88%
Lean Thinking
Push versus Pull

Sales
forecast
Kitchen Cook Shelves Seller Counter Customer

Producing based Pushing the stock

on forecast to the customer

Customer
Kitchen Cook Shelves Seller Counter Customer needs

Adaptation On demand
production order
Lean Thinking
Removing waste

Waste Description Example

Partially done work Work started, but not complete Overstocking between process steps

Extra processes Extra work does not add value Unused documentation

Extra features Features not required or ‘nice-to-have’ Gold plating

Task switching Multitasking between projects People assigned to multiple projects

Waiting Delays waiting for reviews and approvals Waiting for reviews

Motion Effort to pass information or deliverables Distributed teams

when team not collocated
Defects Defective documents or software that Requirements defects
needs corrections Software bugs
Lean & Kanban
Cumulative Flow Diagram
Lean & Kanban
WIP and WIP limits

▪ WIP represents the work that has been

started, but has not yet been completed.
▪ Agile approaches aim to limit WIP in
order to reduce the risks of tied-up
capital, rework and bottlenecks in the
project.
▪ A common way to apply WIP limits is
using Kanban boards
 2004 - developed upgrades & fixed production bugs
for about 80 cross-functional IT applications used by Microsoft
An average request took 11 days of engineering

 More than 90 percent of the lead time was queuing, or other

forms of waste.
 The estimation effort was consuming 33-40% of capacity
<
•

14 days

The backlog was eliminated entirely on November 22, 2005!

Lean & Kanban
WIP and WIP limits
 Conclusions
Scrum Basics
Lean & Kanban
Agile Manifesto
Estimation & Planning
The Agile Mindset

Agenda
Scrum Basics
Feedback

http://tiny.cc/uj8gpz
Closing time

▪ Feedback forms
▪ Attendance certificate

dan.suciu@colorsinprojects.ro
Introduction in Agile May, 2020

Methodology - Scrum