A 1 Day training that shows you all you need to know about Scrum, the afternoon contains a practical part where we perform several sprints using Lego as our means of production
Best SEO Services Company in Dallas | Best SEO Agency Dallas
Crash Course Scrum - handout
1. Crash Course Scrum
• Hugo Messer: Trainer Ekipa.co
• Arjan Franzen: Trainer ZEN software
2. • The “spaghetti” Game
• Manager vs Team (self)
Power of self organization
3. ToDo In Progress Done
Who are we
Lean
Theory
Kanban
Scrum
Ceremonies
Artifacts
Roles
Overview
Scrum
4. Who are we?
• Arjan Franzen
• In professional software engineering since 2000
(hobby since I was 9)
• Titles & Roles: Engineer, Lead Engineer, Architect,
Development Manager, Scrum master, Agile Coach
• Cheering agile since 2005, lean since 2010
• Hugo Messer
• MBA Erasmus in Rotterdam
• 2005: Start Bridge
• 2008: lived in India 1,5 years
• 2005-2010: cried many times
• 2014: Wrote 6 books about managing remote teams
• 2015: Ekipa.co & start workshops to help others
5. ToDo In Progress Done
Who are we
Agile
Theory
Lean
Kanban
Ceremonies
Artifacts
Roles
Overview
Scrum
6. What have we tried so far?
•Waterfall
•V-Model
•RUP
•Scrum
•Statistics are against us here:
• Normal distribution? No!
8. The Agile Manifesto –
a statement of values (2001)
Process and toolsIndividuals and interactions over
Following a planResponding to change over
Source: www.agilemanifesto.org
Comprehensive
documentation
Working software over
Contract negotiationCustomer collaboration over
14. Lean Thinking
• Eliminate waste
• Build quality in
• Create knowledge
• Deliver as fast as possible
• Defer commitment
• Respect people
• Optimize the whole
15. Agile & Lean Compared
Agile and Lean are not exactly defined but rather are principles and practices
“ Agile focuses on well organized
process which allows frequent
delivery which makes it easy to
adjust the course of development”
“Lean focuses more on limiting
waste (Inc. WIP which is a waste)
and making production and
delivery workflow efficient”
16. ToDo In Progress Done
Who are we
Agile
Theory
Lean
Kanban
Ceremonies
Artifacts
Roles
Overview
Scrum
20. • Kanban (method) = approach to incremental,
evolutionary process improvement for
organizations = change management tool =
managing flow
• Scrum = an iterative and incremental agile
software development framework for
manageing software projects and products or
application development (managing iterations)
Compare Scrum to Kanban
21. • Limit work in Progress (WIP)
• Visualize the workflow
• Manage flow
• Make policies explicit
• Implement feedback loops
• Improve Collaboratively, evolve experimentally
(Scientific Method)
Kanban is Simple
has only 6 key principles
28. Sprints
• Scrum projects make progress in a series of “sprints”
• Typical duration is 2–4 weeks or a calendar month at most
• A constant duration leads to a better rhythm
• Product is designed, coded, and tested during the sprint
29. Sequential vs. overlapping development
Source: “The New New Product Development Game” by Takeuchi
and Nonaka. Harvard Business Review, January 1986.
Rather than doing all of
one thing at a time...
...Scrum teams do a little
of everything all the time
Requirements Design Code Test
30. No changes during a sprint
• Plan sprint durations around how long you can
commit to keeping change out of the sprint
Change
31. ToDo In Progress Done
Who are we
Agile
Theory
Lean
Kanban
Ceremonies
Artifacts
Roles
Overview
Scrum
32. Product owner
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Accept or reject work results
33. The ScrumMaster
• Represents management to the project
• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
34. The team
• Typically 5-9 people
• Cross-functional:
• Programmers, testers, user experience designers, etc.
• Members should be full-time
• May be exceptions (e.g., database administrator)
35. The team
• Teams are self-organizing
• Ideally, no titles but rarely a possibility
• Membership should change only between
sprints
39. Sprint planning
• Team selects items from the product backlog they
can commit to completing
• Sprint backlog is created
• Tasks are identified and each is estimated (1-16 hours)
• Collaboratively, not done alone by the ScrumMaster
• High-level design is considered
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 fixtures (4)
Code the foo class (6)
Update performance tests (4)
40. Sprint planning meeting
Sprint prioritization
• Analyze and evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint goal
(design)
• Create sprint backlog (tasks) from
product backlog items (user
stories / features)
• Estimate sprint backlog in hours
Sprint
goal
Sprint
backlog
Business
conditions
Team
capacity
Product
backlog
Technology
Current
product
42. The daily scrum
• Parameters
• Daily
• 15-minutes
• Stand-up
• Not for problem solving
• Whole world is invited
• Only team members, Scrum Master, product owner, can talk
• Helps avoid other unnecessary meetings
43. Everyone answers 3 questions
• These are not status for the ScrumMaster
• They are commitments in front of peers
What did you do yesterday?
1
What will you do today?
2
Is anything in your way?
3
44. The sprint review
• Team presents what it accomplished during the sprint
• 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
45. Sprint retrospective
• Periodically take a look at what is and is not working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
• Scrum Master
• Product owner
• Team
• Possibly customers and others
47. Start / Stop / Continue
• Whole team gathers and discusses what they’d like to:
Start doing
Stop doing
Continue doing
This is just one
of many ways to
do a sprint
retrospective.
48. ToDo In Progress Done
Who are we
Agile
Theory
Lean
Kanban
Ceremonies
Artifacts
Roles
Overview
Scrum
50. 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 sprintThis is the
product backlog
51. A sample product backlog
Backlog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a
reservation.
3
As a hotel employee, I can run RevPAR reports
(revenue-per-available-room)
8
Improve exception handling 8
... 30
... 50
52. The sprint goal
• A short statement of what the work will be focused
on during the sprint
Database Application
Financial services
Life Sciences
Support features necessary for
population genetics studies.
Support more technical indicators
than company ABC with real-time,
streaming data.
Make the application run on SQL
Server in addition to Oracle.
53. Managing the sprint backlog
• Individuals sign up for work of their own choosing
• Work is never assigned (push vs pull)
• Estimated work remaining is updated daily
54. Managing the sprint backlog
• Any team member can add, delete or change the
sprint backlog
• Work for the sprint emerges
• If work is unclear, define a sprint backlog item with
a larger amount of time and break it down later
• Update work remaining as more becomes known
55. A sprint backlog
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Write the foo class
Mon
8
16
8
12
8
Tues
4
12
16
8
Wed Thur
4
11
8
4
Fri
8
8
Add error logging
8
10
16
8
8
58. Hours
40
30
20
10
0
Mon Tue Wed Thu Fri
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Mon
8
16
8
12
Tues Wed Thur Fri
4
12
16
7
11
8
10
16 8
50
59. Definition of Done
• Stories allowed to move to done when they comply to this definition
• “Done” or “Done Done”
• Example:
• Code Complete
• Unit tests written and executed
• Integration tested
• Performance tested
• Documented (just enough)
60. ToDo In Progress Done
Who are we
Agile
Theory
Lean
Kanban
Ceremonies
Artifacts
Roles
Overview
Scrum
62. • Form teams of 4-6 people
• Each Team 1 lego box
• There is 1 Product Owner (who is also a trainer)
Scrum in Practice
Rules
63. • Pre-game (50 min)
• Organizing teams
• Defining the Process
• Project chartering
• Building the Backlog
• Estimating
• Game (3 sprints)
• Sprint Planning (3min)
• Sprinting (7min)
• Sprint Reviewing (5min)
• Post-game
• Debriefing
Phases
64. • All teams will be building a single product – they are not
competing, rather they work for the same vendor.
• The product is a CITY with certain features.
• The main building elements are LEGOs, though any
other material can be used in addition.
• The PO is the main decision maker of the product – it is
my city.
• I will be involved in the development process by being
available to answer questions and provide feedback.
Goals
65. What to build
• 1 storey-buildings (several)
• 2 storey-buildings (several)
• Shop
• School
• Hospital
• Kindergarten
• Bus Stop
• Intersection
• Park
• River
• Bridge
66. Debriefing
• What did you observe?
• How did it feel being on a scrum team?
• How did the short iterations go?
• How accurate were the estimations (provided the Release Burndown is there)
• What would we have done differently from the beginning, if we had another chance to
play the game?
• How did it feel after the first sprint when almost all items required re-work?
• What did the scrum master do?
• How will your strategy change, if you know the Product Owner is unavailable during
sprints?
• How did inter-team communication go? Where there any dependencies? How were they
resolved?
• What did students learn?
68. Scalability
• Typical individual team is 7 ± 2 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
72. To DevOps
Customer
Delivery team
Constant flow of new features into production
Operation + Release
Analysis + Design
Integration + QADevelopment
Testing + DemonstrationCustomer
Centralized QA Centralized
IT Operations
Agile team
The Last Mile
73. “If it hurts, do it more often”
Infrequent releases
Effort peaks,
High risk
Change
Time
Frequent Releases
Smaller releases,
Less risk
Change
Change
Time
74. Development / DevOps Culture
• Continuous Improvement
• Ideas are experimented with (Kata) instead of squashed
• Feedback instead of fire fighting
• Visualized overview instead of unread documents
• Team Autonomy instead of Centralized control
• Eliminate all costly work handover
• Context , not Control
• Tribes, Guilds, Chapter
• System owners/ Architects
• Loosely coupled & tightly aligned
75. Is it Continuous
• ‘How long does it take to change a single line of code?’
• Small releases
• Continuous Integration
• Branching/Merging
• Continuous Deployment
• Automated tests
• DevOps
79. 84
uc my real User Story
Administrator
User
General requirement
Configure recorder
Record Stuff
External System
Interface with
recorder
My Real User Stories: Roles and Systems
80. User Story
• Always use the Narrative
• Always describe the benefit
• User Stories in central
location (not email)
• Dan North article
81. User Stories: Pitfalls
• Describe the problem, not the solution
• As a Home owner
• I want to Shovel Snow
• So that I can get out of my driveway to get to work
• Problems!
• Better:
• As a home owner
• I want my driveway to be cleared of snow
• So that I can drive in and out of my driveway to get
to work
82. 1. Focus on the user
2. Use stories to facilitate a conversation
3. Story writing is teamwork
4. Keep your stories simple and concise
5. Progressively decompose
6. Don’t forget the acceptance criteria
7. Consider grouping user stories into themes
8. Use paper cards
9. Keep your stories visible
10. Some things aren’t stories
Roman Pichler’s 10 tips for user stories
