2. Problems in Software
Industry
•Releases take too
long
•Stabilization takes
too long
•Changes are hard
to make
•Quality is falling
•Death marches are
hurting morale
•People are not
communicating well
2
3. Roots of Scrum
•Lean
•Knowledge
Management by
Nonaka & Takeuchi
•Built-in instability
•Self-organizing
project teams
•Overlapping
development phases
•“Multilearning”
•Subtle control
•Organizational
transfer of learning
3
4. Make your own path
There is no fixed and
•
patented Agile
process, only
Principles and
Values
•Principles and Values
are not something
fixed, they can guide
but not dictate how
things should be
Rules are rigid,
•
Principles and Values
are flexible like Agile
4
5. Scrum is a framework
•The framework
set the basic
rules that a team
uses to play a
game
•Each team has
its own style
•A team needs to
constantly
reinvent itself
5
6. Scrum comes handy
It will help you to build
•
better software in
shorter releases
cycles and with more
quality associated
Scrum is an
•
empirical process;
not a formal, rigid and
out of the box one
•Like a Swiss Army
tool, Scrum is nice,
shiny, easy to use,
made for last,
adaptable and not
6
expensive
7. Scrum four pillars
Scrum rests on four
legs of
•iterative
development that
generates
•increments of
functionality using
•self-organizing
teams that are
cross-functional
7
8. Scrum flow
This flow defines the
different artifacts
and ceremonies
within the Scrum
framework
One important
consideration is that
the flow is based on
an incremental and
iterative process
8
9. Product backlog
•The Product Backlog
contains a prioritized list
of items – user stories
that will be developed by
the team during the
sprint, the current and
the next release
•The Product Backlog is
not static; it increases
when new requirements
arrive and decreases
when user stories have
been completed
9
10. Sprint backlog
•The Sprint Backlog
is the list of user
stories that the
teams commits to
work in an sprint
•This list comes from
the Product Backlog
and should be
changed without the
team consensus and
the Product Owner’s
approval
10
11. Burn down charts
•The Burn Down char
is not exactly a
monitoring tool that
shows productivity
On the contrary, this
•
chart could be used as
a predictive tool for
planning next sprints
•It’s key that the
Scrum Master and the
team keep this chart
updated and know its
meaning
11
14. Team Responsibilities
Estimating size of
•
backlog items
•Committing to
increments of
deliverable software –
and delivering it
• Tracks own progress
Is self-organizing –
•
but accountable to the
Product Owner for
delivering as promised
•Improving constantly
its own processes
14
15. Basic truths about
team motivation
•People are most
productive when they
manage themselves
•People take their
commitment more seriously
than other people’s
commitment for them
•People have many creative
moments during down time
•People always do the best
they can
•Under pressure to “work
harder” developers
automatically and
increasingly reduce quality
15
16. Basic truths about
team performance
•Teams and people do
their best work when
they aren’t interrupted
Teams improve most
•
when they solve their
own problems
•Broad-band, fact-to-
face communications
is the most productive
way for teams to work
together
16
17. Basic truths about
team composition
•Teams are more
productive than the
same number of
individuals
•The optimum size team
is around seven people,
and no more than nine
•Products are more
robust when a team has
all of the cross-functional
skills (development +
QE) focused on the work
•Changes in team
composition often lower
productivity for a time
17