Scrum is a framework for managing product development that emphasizes iterative work cycles, frequent inspection points, and adaptation to change. It consists of sprints, daily stand-ups, sprint planning, reviews, and retrospectives. Benefits include increased responsibility, reduced risk, motivation, and continuous improvement. However, it can also be verbose with meetings and interrupt development flow if not implemented properly.
2. Agenda
• Software Engineering Challenges
• Agile Methodologies
• Scrum
• In a Nutshell - Ensure We Are All on the Same Page
• Benefits and Opportunities
• Caveats and Pitfalls
• Best Practices
• Alternatives
• Conclusion
7. The Iron Triangle of
Project Management
Quality
?
Deadline
(est.)
Cost
(est.)
Scope
(fixed)
8. Technical Debt
"Shipping first time code is like going into debt. A little debt
speeds development so long as it is paid back promptly with a
rewrite... The danger occurs when the debt is not repaid. Every
minute spent on not-quite-right code counts as interest on
that debt. Entire engineering organizations can be brought to
a stand-still under the debt load of an unconsolidated
implementation..."
Ward Cunningham, 1992
Deadline Pressure
Technical
Debt
Code
quality
Tests
Speed
9. Technical Debt
• Unpredictable
• If you notice it, do not try to hide it!
• Act quickly!
• Its consequences:
Increase in software delivery time
Increase in the number of bugs
Decrease in customer satisfaction
“Degeneration” of the product
Increased maintenance costs
Low performance
Frustration (development team)
10. How to Prevent and Fight It?
• Prevention, prevention, prevention…
• Strict Definition of Done
• Covering code quality as well
• Sonar
• Extreme Programming Techniques
• TDD
• Pair Programming
• Boy Scout Rule
• Clean Code principles
11. The Agile Manifesto
Processes and Tools
Individuals and
Interactions
Comprehensive
Documentation
Working Software
Contract Negotiation
Customer
Collaboration
Following a Plan
Responding to
Change
12. The 12 Principles Behind the
Agile Manifesto
Frequent delivery
Earlyandcontinuousdelivery
Close cooperation between business people and developers
Working Software
Self-organizing teams
The art of maximizing the amount of work not done
Frequent delivery
Earlyandcontinuousdelivery
Motivated, trusted individuals
Self-organizing teams
Welcomechangingrequirements
Welcome changing requirements
Face-to-face conversation
Technical excellence and good design
Adapt quickly to changing realities
Simplicity
Simplicity
Face-to-faceconversation
13. The Iron Triangle of
Project Management
Quality
(fixed)
Deadline
(scheduled)
Cost
(fixed)
Scope
(fine-tuned)
15. Definition of Scrum
“A framework within which people can address complex
adaptive problems, while productively and creatively
delivering products of the highest possible value.”
The Scrum Guide™, Ken Schwaber and Jeff Sutherland
Characteristics:
Lightweight
Easy to understand
Difficult to master
18. Sprint – Iteration
• Goal
• Scope – development
team decides
Team commitment
Product
increment
• Length: 2-4 weeks
Photographer: Vullioud Pierre-André
Source: http://www.freeimages.com/
19. Sprint Board
To Do In Progress DoneUser Story
PBI #1
PBI #2
PBI #3
Impl Impl Test
CRImpl
Impl CR Test
Impl Test Test
CRImpl
20. User Story
• Represents the customer needs
• Customers/users write them
• Informal, non-technical language
• Acceptance criteria
• Size
• Limited
• Estimate
• Time
• Story points
• Quantity
• Complexity
21. Sprint Board
To Do In Progress DoneUser Story
PBI #1
PBI #2
PBI #3
Impl Impl Test
CRImpl
Impl CR Test
Impl Test Test
CRImpl
22. Sprint Board
To Do In Progress DoneUser Story
PBI #1
PBI #2
PBI #3
ImplImpl Test
CR Impl
ImplCR Test
Impl Test Test
CRImpl
23. Sprint Board
To Do In Progress DoneUser Story
PBI #1
PBI #2
PBI #3
ImplImpl Test
CR Impl
ImplCR Test
Impl Test Test
CRImpl
24. Sprint Board
To Do In Progress DoneUser Story
PBI #1
PBI #2
PBI #3
Impl Impl TestCR
Impl
ImplCR Test
ImplTest Test
CRImpl
25. Sprint Board
To Do In Progress DoneUser Story
PBI #1
PBI #2
PBI #3
Impl Impl Test
CRImpl
ImplCR Test
ImplTestTest
CR Impl
26. Sprint Board
To Do In Progress DoneUser Story
PBI #1 PBI #2
PBI #3
Impl Impl Test
CRImpl
Impl CRTest
Impl TestTest
CR Impl
27. Sprint Board
To Do In Progress DoneUser Story
PBI #1 PBI #2
PBI #3
Impl Impl Test
CRImpl
Impl CRTest
Impl Test Test
CRImpl
29. Acceptance Criteria
• Addition to the Definition of Done
• User Story
• Refinement
• Remember the V Model
• User Acceptance Test (UAT)
Defined upfront
• BDD (Behavior Driven Development)
30. Non-Functional Requirements –
NFR
• System level requirements
• It is a good practice to have as many NFRs being part
of the Definition of Done as possible
Quick feedback
• Not always possible nor necessary
New functionality
32. The Scrum Team
Makes efforts in order to deliver at the end
of each sprint the potentially shippable
product increment they have committed to.
• Team members:
Product Owner
Scrum Master
Development Team
Ideal team size: 5 - 10
33. Product Owner
• Responsible to maximize the value of the
product
• Responsible for:
• Product Backlog
• Items
• Unambiguous description
• Prioritization
• Accessible
• Transparent
• Understood by every key stakeholder
One single person!
35. Scrum Master
Servant Leader
• Makes sure Scrum is
• Understood
• Followed
• Interaction
Product Owner
Development Team
Organization
All Stakeholders
36. Development Team
• Self-organizing
• Cross-functional
• There are no titles
• Everyone is a developer
• There are no subgroups
the whole team is responsible for
their commitment
Professionals
38. Sprint Planning
• The Product Owner presents the Sprint Goal and the
Product Backlog Items which need to be completed in
order to reach the goal
• What will be accomplished?
• How?
• Outcome: Sprint Backlog
• In case of 2-week Sprints limited to 4 hours
39. Sprint Review
• Purpose: inspect the product increment
• The development team
• demonstrates the completed work
• answers the questions related to the increment
• Informal
• Open to everyone
• At the end of the Sprint
• In case of 2-week Sprints limited to 2 hours
40. Sprint Retrospective
• Ensures continuous improvement
• Scrum Team identifies and prioritizes
• What worked well
• What could be improved
Outcome: Plan to improve the efficiency of the Scrum Team
• When:
• After Sprint Review, before next Sprint Planning
• In case of 2-week sprints limited to 1.5 hours
People
Interactions
Processes
Tools
41. Daily Scrum
• Purpose:
• Maintain momentum
• Identify impediments
• Improve
communication
within the team
• How:
• Same time
• Same place
• Time boxed: 15
minutes
What did you do yesterday?
1
What will you do today?
What obstacles are in your way or
slowing you down?
2
3
43. Product Backlog
• The single source of product change
requests
• Requirements
• Functionality
• Enhancements
• Bug fixes
• Living document
• Never complete
Refinement
44. Backlog Refinement / Grooming
• Continuous activity
• Development team and
Product Owner
• Items:
• Reviewed
• Extended
• Estimated
• Priority changed when
needed
• No more than 10% of the capacity
of the development team
48. Monitoring Progress - Reports
• Scrum relies on transparency
• Actual state of work packages
Decisions to optimize value and control risk
Sprint burn down
Cumulative flow
Velocity
49. Sprint Burn Down Chart
0
10
20
30
40
50
60
70
80
90
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Ideal Actual
Before schedule
Behind schedule
Sprint
Start
Sprint
End
EstimatedTime(man-days)
Sprint Days
52. Cancelling a Sprint
Sprint goal - obsolete, no longer relevant
Company strategy changed
Important market or technology conditions changed
In the given circumstances it does not make sense to
continue
Who: Product Owner
Rarely makes sense
Short duration of sprints
Demotivating
53. Scalability
• Large project
• A lot of functionality to implement
• Tight deadlines
• Mandatory:
Parallelizable tasks
Several teams
• Approach:
• Work packages independent from each other
• That can be built into the product one after other or at
the same time
• There is enough work to keep everyone busy
54. Scalability – Scrum
• Several Product Owners – only one Product Backlog!
• Coordination
• Chief Product Owner
• Before refinement and planning
• Synchronization between Product Owners is necessary
• Sprint Review
• All teams together
• Separately
• Retrospective
• Sometimes also with the representatives of all teams
• Scrum of Scrums (SOS)
56. Scrum of Scrums
What has your team done since we last met?
1
What will your team do before we meet again?
Is anything slowing your team down on their way?
2
3
Are you about to put anything in another team’s way?
4
Resolve problems and discuss issues on the team backlog.
57. What Scrum of Scrums is Not
“All the ScrumMasters and the project manager
would have a teleconference three times a week
where the ScrumMasters would take turns giving
status reports(!) and complaining about the problems
they had. I was approached by some of the
ScrumMasters asking me if we shouldn’t have the
meeting less frequently since ‘nothing new is being
said. The same problems are being brought up in
every meeting.’”
Morgan Ahlström: Scrum of Scrums – A Communication Thermometer
60. Increased Sense of Responsibility
Development Team
Estimates Decision
Development Team
Set Their
Own Limits
Commitment -
Together
Increased Sense of
Responsibility
61. Less “Single Point of Failure”
Scrum
Cross-Functional
Teams
Attend All
Ceremonies
Team Members
Product Know-How Project Know-How
Less Pressure on
Individuals
65. High Degree of Independence
Scrum Team
Mixed Professional
Background
High Degree of
Independence
Cross-Functional
Teams
66. Extreme Programming
Communication, Team Spirit
Photographer: Sebastian Danon
Sources: http://www.freeimages.com/
Scrum Team
Independent
Problem Solving
Communication
Team Spirit
Pair
Progr
TDDCI
68. Fail Fast and Often
• Does not give the possibility to failure
• Can lead to a mental roadblocks
Most Education Systems Suggest
Hard Work Time Success
69. Learn from Our Failures
Hard Work Time
Success
Failure 1
Failure n
…
?
72. Scrum is Verbose
Scrum ceremonies:
• Sprint planning
• Up to 4 h
• Daily Scrum
• ~10x15 minutes =
2h 30m
• Sprint Review
• Up to 2 h
• Sprint Retrospective
• Up to 1.5 h
Other meetings:
• Backlog Refinement
• Up to 10% ≈ 8 h
Scaled:
• Meetings to discuss, break
down and assign
epics/features to teams
• Scrum of Scrums
*2 week sprints
73. Flow
• Meetings
Agenda
Focus
Participants
• Choose wisely!
Keep it short
Meeting minutes
• Alternatives
• Even if short, they still interrupt
developers in their creative work
Flow
74. Daily Stand-up
• Scrum framework Daily Scrum
• Stand-up became a habit, a ritual, a dogma,
Jon Evans calls it even cargo cult
• Ideal circumstances
• Development team members
• Start working more or less at the same time
• Are collocated
• Are in the same or close time zones
• Kept short (up to 10-15 minutes)
Creative and Productive
Morning Period
Context Switchingor
75. …
The Check-in as Alternative
What did I accomplish yesterday?
1
What do I intend to do today?
Are there any impediments?
2
3
Login
Write
Read
A
s
y
n
c
h
r
o
n
o
u
s
76. Adaptability and Flexibility…
• “Scrum’s roles, artifacts, events, and rules are immutable
and although implementing only parts of Scrum is possible,
the result is not Scrum. Scrum exists only in its entirety and
functions well as a container for other techniques,
methodologies, and practices.“
End Note, The Scrum Guide,
Ken Schwaber and Jeff Sutherland, July 2013
Processes and Tools
Individuals and
Interactions
?
77. No Changes During the Sprint
• Choose the
length of the
Sprints in such a
way that it can
resist change
Sprint
Scrum Master
Guardian
of Scrum
Following a Plan
Responding to
Change
?
79. Agile Keeps People Busy
• Can be very tiring to
the whole
development team
• Being iterative, it
offers some
moments to relax
between sprints –
take advantage of it!
Agile
80. Money, Money, Money…
• Courses
• Workshops
• Certifications
• Cost a bunch of money
• Expire
• Need to be renewed from time to time, for even more
money
• They exist for most specialties but in the case of Scrum it
became outrageously over-dimensioned
• Evangelists, coaches preach for money the new religion
81. Who Became the Scrum Masters?
• Mostly Project Managers
• Often with no technical knowledge
• They have no development experience
• In any case, not with the modern
way of it
Scrum often simply does not work
Servant Leader
I
n
s
t
e
a
d
Manager
82. Scrum Masters Cannot Stand on
the Side Line
• Scrum process – “good enough”
• Scrum Master – sometimes get out of shape
• Remember: agile required continuous improvement!
A Scrum Master cannot stand on the side line
83. Part time and remote work
• Part time work
• Scrum ceremonies eat up the same time
Barely have time for development
• Remote work
• Meetings
Video conferencing
Online real time collaboration tools
Still difficult to follow
84. Lean Principles – 7 Wastes
Partially
Done
Work
Unnecessary
Functionality Hand-offs
Unnecessary
Processes
Delays Defects
Switching
Between
Tasks
Waiting Rework
Movement
85. Kanban, an Alternative
• Goal: improve organizational efficiency
• Kanban: focus on processes
• Lean principles – 7 wastes
• Clearly defined process rules
• Transparency of tasks
• Limit work in progress
• Constantly measure and improve flow
86. Scrum Board
To Do In Progress DoneUser Story
PBI #1
PBI #2
PBI #3
Impl Impl Test
CRImpl
ImplCR Test
ImplTestTest
CR Impl
88. Kanban
• Easy to learn
• Works well with other methodologies
• Extreme programming
• TDD
• Pair Programming
• Continuous Integration
• Efficient at adapting to changes
• Makes continuous delivery possible
89. Kanban
• No roles
• Kaizen meetings
• Anyone can organize
• Only affected team members participate
• Focus: Kanban board
• Does not prescribe estimations
• Difficult to tell when specific tasks are done
• Deadlines – may be written to cards but not necessary
• Puts efficiency before predictability
90. Comparison
Scrum Kanban
Empirical
Lean
Agile
Sprints Continuous flow of work
Limits work in progress
Focus on fast and continuous delivery
Reorganization might be necessary
(cross-functional teams)
Current situation is the starting point
Transparency
Continuous improvement of processes
Roles (SCM, PO) No roles
Estimates Does not prescribe estimates
Predictability Efficiency
92. Contact Information
• Name: Székely Sipos Sándor Zolta
• LinkedIn: https://www.linkedin.com/in/zoltaszekely
• Mail: zzolta@gmail.com
93. Bibliography
• A Scrum Guide, Ken Schwaber and Jeff Sutherland
• Introduction to Scrum, Mike Cohn
• Stand up against the stand-up, Jon Evans
• Lean + Agile vs Seven Wastes in Software Development, V S
S N R Ram Nanduri
• A Scrum keretrendszer és agilis módszerek használata a
Visual Studióval, Csutorás Zoltán, Árvai Zoltán, Novák István
• Essential Scrum, A Practical Guide to the Most Popular Agile
Process, Kenneth S. Rubin
• http://www.adaptiveconsulting.hu/kanban-vagy-scrum
• https://www.linkedin.com/pulse/how-reduce-risk-missing-
nonfunctional-requirements-miller-cbap
96. Copyright Notice
• You are free:
• To Share―to copy, distribute and transmit the work
• To Remix―to modify/adapt the work
• Under the following conditions
• Attribution: you must attribute the work in the manner
specified by the author or licensor (but not in any way
that suggests that they endorse you or your use of the
work)
• Nothing in this license impairs or restricts the author’s
moral rights
• For more information see:
https://creativecommons.org/licenses/by/4.0/
Attribute!
CC BY 4.0