2. OutlineOutline
What is Scrum?
The Scrum Team
The Scrum Events
The Scrum Artifacts
Organizational Impacts of Scrum
Who uses Scrum
Resources
3. What is Scrum?What is Scrum?
Scrum is a framework for dealing
with complex work such as software
product development.
It’s an alternative to traditional
approaches known and used so far in
manufacturing and construction.
4. The meaning of ScrumThe meaning of Scrum
A rugby scrum
restarts a rugby
game after a
minor
infringement of
the rules.
Understand what
goes on. Who
puts in? How do
you win?
5. Rugby Scrum 101
Instead of "Pause, Engage"
the match official will simply
call "Set".
Putting in the ball
Scrumaging
Scrummaging is
the very
"technical" area
of the game
6. …. Scrum is a flexible, holistic product development
framework within which you can employ various
processes and techniques based on Empirical approach.
It is where a development team:
works as an unit to reach a common goal,
challenges assumptions of the "traditional, sequential approach"
to product Development,
Scrum introduces feedback loops, encouraging us to inspect and
adapt the product that we are building and the processes we’re
using to build that product
Enables teams to self-organize by encouraging physical co-location
or close online collaboration of all team members, as well as daily
face-to-face communication among all team members and
disciplines in the project.
SCRUM definition:
7. … Scrum roles, Scrum events, Scrum artifacts, and
the Scrum rules that bind them together.
Scrum is:
Lightweight
Simple to understand
(but) Difficult to master
Scrum brings challenges to individuals, teams, and
organizations. It is an attempt to put chaos in a box,
making the most of uncertainty.
SCRUM definition consists of:
9. Three pillars uphold every implementation of
empirical process control: transparency,
inspection, and adaptation.
Transparency - Significant aspects of the process must be visible to
those responsible for the outcome. Those performing the work and those
accepting the work product must share common definition of DONE.
Inspection - Scrum users must frequently inspect
Scrum artifacts and progress toward a Sprint Goal to
detect undesirable variances.
Adaptation - If an inspector determines that one or more aspects of
a process deviate outside acceptable limits, and that the resulting product
will be unacceptable, the process being used must be adjusted. An
adjustment must be made as soon as possible to minimize further
deviation.
Scrum prescribes 4 formal inspections and adaptations Sprint
planning, Daily Scrum, Sprint review, Sprint retrospective.
10. Please don’t go there. There are obstacles waiting.
But why? If they are waiting, I won’t let them wait long.
11. Lets get serious about how Scrum works ….Lets get serious about how Scrum works ….
14. The Scrum RolesThe Scrum Roles
Product
Owner
Scrum Master
Business owner /
stakeholder
StakeholdersScrum Team
QA/Testing
Developers
Or Scrum
Product Owner
Stakeholders
15. Stakeholders (Business owners)
Anybody whose interest is positively or negatively affected by
the project OR who can exert an influence on the project.
Examples of Stakeholders in Scrum Project:
Team (Product Owner, Scrum Master, Developers)
Management
Customers
End users
Vendors/Contractors or external contributors
16. Scrum development team
The team model in Scrum is designed to optimize flexibility, creativity, andto optimize flexibility, creativity, and
productivity.productivity.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities
for feedback. Incremental deliveries of “Done” product ensure a potentially useful
version of working product is always available.
17. The Scrum Development Team (DT)The Scrum Development Team (DT)
Self-organizing and cross-functional group of 4 to
7 professionals that choose how best to accomplish
their work and build a potentially shippable
increment fulfilling the definition of “Done” at the
end of each Sprint.
DT is structured and empowered to be self-organizing,
manage their own work & continuously improving their
overall efficiency and effectiveness.
Team determines how to transform Product Backlog
Items into shippable functionalities;
18. Scrum recognizes no titles for DT members other
than DEVELOPER, regardless of the work being
performed by the person; there are no exceptions to
this rule!!!
Scrum recognizes no sub-teams in the DT,
regardless of particular domains that need to be
addressed, like testing or BA; there are NO exceptions
of this rule!!!
Accountability belongs to The Team as a whole – no
matter that DT members may have specialized skills
and areas of focus.
Important notes in regards DT’s work:
19.
20. Product Owner (Product Owner (furtherfurther PO)PO)
PO is the sole person responsible for ROI of development effort.
PO is managing the Product Backlog (further PB) –
Responsible for product vision, clearly expressing PB items,
Ordering the items in the PB to best order to achieve goals and missions;
Optimizing the value of the work the Development team (further DT) performs;
Ensuring that the PB is visible, transparent, and clear to all, and shows what the
DT will work on next;
Ensuring the DT understands items in the PB to the level needed to perform their work.
Represents stakeholder interests, but remains accountable;
Plans product releases and maintains product roadmap;
ONE person, not a committee!!!;
Ultimately responsible for product’s success.
21. Important notes in regards Po’s work:
For the Product Owner to succeed, the entire
organization must respect his/her decisions;
The Product Owner’s decisions are visible in the
content and ordering of the PB
No one is allowed to tell the DT to work from a
different set of requirements;
The DT is NOT allowed to act on what anyone else
says.
The PO may represent the desires of a committee in
the PB, but those who want to change a PB item’s
priority must address the PO.
22. The Scrum MasterThe Scrum Master
(or the most misunderstood and neglected role in Scrum)(or the most misunderstood and neglected role in Scrum)
Manages relationship between Product Owner and
rest of the team.
Ensures Scrum is understood and Scrum theory,
practices and rules are enacted.
SM is a servant-leader for the Scrum Team, he/she
acts as coach, fixer, and gatekeeper;
A leadership role rather than managerial;
Plans individual Sprints together with
team members;
Facilitates all of the Scrum events;
23. Scrum Master protects the team from distractions
and interruptions!
I will protect you
from that bad
wolf and his
endless ideas!
24. Scrum Master Service to the Development Team.
Helps resolve impediments.
Creates an environment conducive to team
self-organization.
Facilitates the processes, helps ppl use Scrum.
Shields the team from external interference and
distractions to keep it in group flow (a.k.a. the
zone).
Enforces time-boxes.
Keeps Scrum artifacts visible.
Promotes improved engineering practices.
And somehow does all this with NO
management power over the team
25. The Scrum Product Owner –
(or the hybrid breed in Scrum Roles )
The Scrum Product Owner serves the organization and the
Development team as one fully operational PO plus all the
above mentioned for SM and in several additional ways:
Leading and coaching the organization in its Scrum
adoption;
Planning Scrum implementations within the organization;
Helping employees and stakeholders understand and enact
Scrum and empirical product development;
Causing change that increases the productivity of the
Scrum Team; and,
Working with other Po’s to increase the effectiveness of
the application of Scrum in the organization.
26. Scrum EventsScrum Events
Prescribed events are used
in Scrum to create regularity
and to minimize the need for
meetings not defined in
Scrum.
All events are time-boxed
events, as every event has a
maximum duration. Once a
Sprint begins, its duration is
fixed and cannot be shortened
or lengthened.
Other than the Sprint itself,
which is a container of all
other events, each event in
Scrum is a formal opportunity
to inspect and adapt
something.
The events are specifically
designed to enable critical
transparency and inspection.
Failure to include any of these
events results in reduced
transparency and is a lost of
opportunity to inspect and
adapt.
27.
28. The Sprint contains and consists of:The Sprint contains and consists of:
The Sprint Planning,
The Daily Scrums,
The development work;
The Sprint Review,
The Sprint Retrospective.
29. Consistent duration throughout project (2 – 4
weeks);
Team composition and quality goals remain
constant (5 – 7 people);
NoNo changes made that affect Sprint Goal!!!;
Scope can be clarified or re-negotiated as more
is learned (new backlog entry is created);
Risk is limited to cost of one sprint.
Scope may be clarified and re-negotiated
between the PO and the DT as more is
learned.
32. SprintSprint PlanningPlanning MeetingMeeting
Time-boxed meeting to determine work
to be done in 1 Sprint – 4 h. max.
First event of every Sprint.
Answers “What will be
delivered in this Sprint?”
Answers “How
the work will be achieved?”
34. Daily Scrum (Standup)Daily Scrum (Standup)
Daily meeting within 15 min. time-box (max).
Each team member answers three questions:
What did I do yesterday?
What will I do today?
What obstacles are in the way?
NOT a status meeting.
Only DT can participate.
35. Sprint ReviewSprint Review
DT demonstrates work done in the Sprint.
PO determines what has been “Done” or “not
Done”.
PO discusses the PB as it stands with projected
completion dates and releases.
Results in a revised Product Backlog
Forms planning for the
next Sprint, timeline,
Potential capabilities.
A Sprint review is held at the end of the Sprint to inspect the
increment and adapt the PB if needed and DT and SH collaborate
about what was done.
36. Sprint Retrospective
Final activity of every Sprint, time for the DT
to inspect itself and create a plan for
improvements to be enacted during next
Sprint.
Team reflects on the Sprint in terms of
people, relationships, process, and tools
Identify what went well and what not so well,
where improvements are needed.
Team plans how to implement improvements
37. Sprint review
meeting inspects on
debts about the
Product
Sprint retrospective
meeting is about the team
to inspect any debts about
the Process.
38. Safety checkSafety check Safety Gradient table histogram
Invisible gun effect…. !!! Boss – subordinates
Classic Scrum retrospectiveClassic Scrum retrospective
What went well – pluses – what to be learn?
What can be improved – deltas – what still puzzles us?
Focused Conversation PrinciplesFocused Conversation Principles – a.k.a. Focused Conversation model.
Objective Questions – what happened?
Reflective Questions – how do we feel about it?
Interpretive Questions – what does it mean?
Decision Questions – what are we going to do about it?
SilentSilent writingwriting - - write down the actions
Timeline RetrospectiveTimeline Retrospective –
Team writes actions.
Some types of Retrospective meetings:
40. Product Backlog (PB)Product Backlog (PB)
An ordered list of everything that might be needed in the product.
PB exists as long as product exists.
PB is a lists all features, functions, requirements, enhancements, and
fixes that constitute the changes to be made to the product in the
future releases.
PB is a single source of requirements and changes to the product;
Requirements never stop changing, so a PB is a living artifact.
Ordered by unique priority – defined by PO after BVD with SH.
Never complete. It evolves as the product and the environment in
which it will be used evolves.
Anyone involved can contribute to it, but….
PO is responsible for the PB, including its content, availability and
ordering/prioritizing.
42. Product Backlog refinement
PB refinement is the act of adding details, estimates, and order to
the items in the PB.
Ongoing process in which items are reviewed and revised.
Takes up to 10% of the DT capacity, the rest is updated and
clarified at any time at the PO’s discretion.
Highest priority items are usually clearer and have the most
details;
More precise estimates are made based on the greater clarity and
increased detail;
Detail on lower priority items deferred until it’s needed.
43. Sprint Backlog (SB)
Set of Backlog items that the Team commits to
delivering in ONE sprint.
SP is a plan with enough detail that changes in
progress, but can be understood in the Daily scrum
(standups).
Forecast by the DT about what functionality will be in
the next increment and the work needed to deliver
that functionality into a “Done” endpoint.
Serves as a real-time picture of how work is
progressing, it makes visible all of the work that the
DT has put into tasks.
Belongs solely to the Development Team
44. Definition of “Done”
A shared understanding of what it means for work to
be complete, to ensure transparency.
Everyone must understand what “Done” means and
when work is considered Done.
Defined at the beginning of the project
Applies globally to the project, in case multiple DT
work on the system or product release;
45.
46. Scrum Organizational ImpactScrum Organizational Impact
Transitioning to Scrum is not always easy –
Resistance to changes is heavy! Very Heavy!
We are used to this –
And now we must start using this -
47. Manifesto for Agile Software
Development
Individuals and interactions over processes and
tools.
Working software over comprehensive
documentation.
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
48. Scrum brings challenges to individuals, teams
and organizations…IF it is not disrupting your
organization, you probable not doing Scrum….
That’s the case most of the time people claim to be
doing Scrum.
49. Difficulty of leaving the traditional understanding of
roles.
Scrum addresses uncertain requirements and
technology risk by grouping people from multiple
disciplines into 1 DT – this means to maximize the
communication bandwidth, visibility and trust.
In the adaptation phase the basic Agile principles may
be destroyed – that’s scary.
Traditional roles change together with cultural
changes.
Commitment to continuous improvement.
Scrum roles, artifacts, events and rules are immutable
and although implementing only parts of Scrum is
possible – The result is NOT SCRUM.
50. Organizational Impacts
1. Simplicity of principles and
apparent easiness of their employment.
2. More transparent communication
with the SHs and more accurate
planning of tasks.
3. Scrum is in fashion! Indeed
WHY TEAMS SWITCH TO SCRUM?
51. IN CONCLUSION:
Scrum is NOT a panacea
to solve all the problems.
…. BUT ….
Scrum principles reveal the
problems, and it IS people who
are to solve them.
54. http://www.scrum.org/
http://www.scrumalliance.org/
All Things Product Owner by Roman Pichler
Agile Project Management with Scrum by Ken Schwaber
Succeeding with Agile: Software Development
Using Scrum by Mike Cohn
A Practical Guide to Distributed Scrum by
Elizabeth Woodward
Agile Retrospectives by Esther Derby/Diana Larsen
Guide to Participatory Decision making by Sam Kaner
The Skilled Facilitator by Roger Schwarz.
ResourcesResources