This document outlines an agenda for an Agile 101 training session. It includes exercises to teach Lean and Agile principles using a penny game. It then covers what Agile is and isn't, the Agile manifesto and principles, an introduction to Scrum framework including artifacts and roles. Planning, daily stand-ups, sprints, and retrospectives are discussed. A Lego Scrum game simulation is described to illustrate a Scrum process over three sprints with optimization of the team.

1. August, 2016
Agile 101

2. 2
Working Agreements

3. 3
Agenda
Lean Thinking with Penny Game
Agile Thinking with Scrum2
Agile- What it is and isn’t, and Why should we care?a
Agile Manifesto (Values) and Principlesb
Introduction to Scrumc
Artifacts in Scrumf
1
Agile Roles and Responsibilitiesd
Various levels of Planning in Scrumg
Scrum Ceremoniesh
Lego Scrum Gamee

4. 4
What are Lean Principles? And How do we implement them in Agile
Lean Principles Implementation in Agile
Eliminate waste Retrospectives, Feedback loops at every iteration
Amplify learning Retrospectives, Feedback loops at every iteration
Decide as late as possible Iteration Planning every 2 weeks
Deliver as fast as possible Short Iterations
Empower the team Servant Leadership, Team Collaboration
Build integrity in Build Quality In: Continuous Testing & integration
See the whole Cross functional teams, breaking down Silos
Principles
Values
Process
Practices
(kata)

5. 5
Exercise: The Penny Game
• Learn how to achieve more, by
doing less
• Work in your groups:
One timekeeper and
rest doing work
Time box: 15 Minutes

6. 6
Exercise: The Penny Game (Continued)
Round 1:
• Each person flips all pennies,
one at a time
• Pass all the pennies to the next person
when you are done
• The time keeper will record the total
time it takes everyone to flip all coins

7. 7
Exercise: The Penny Game (Continued)
Round 2:
• Flip each penny, one at a time
• Pass each penny to the next person,
one at a time
• The time keeper will record the total
time it takes everyone to flip all coins

8. 8
Exercise: The Penny Game (Continued)
RETROSPECTIVE:
Which way worked better?
Why do you think that is?

9. 9
Agenda
Lean Thinking with Penny Game
Agile Thinking with Scrum2
Agile- What it is and isn’t, and Why should we care?a
Agile Manifesto (Values) and Principlesb
Introduction to Scrumc
Artifacts in Scrumf
1
Agile Roles and Responsibilitiesd
Various levels of Planning in Scrumg
Scrum Ceremoniesh
Lego Scrum Gamee

10. 10
The Real World…
3 things we wish were true:
• The customer knows EXACTLY what he wants
• The developers know EXACTLY how to build it
• NOTHING will change along the way
3 things we actually live with:
• The customer discovers what he wants
• The developers discover how to build it
• Many things change along the way

11. 11
What is Agile?
• A philosophy about software development
• A collection of Values and Principles that uphold that philosophy
• A grassroots movement to change software development
• Buzz Words:
• Iterative
• Incremental
• Progressive Elaboration
• Empowering
• Collaborative
• Experimentation
• Transparent
• Efficient

12. 12
Definition of Agile
Agile
“An iterative, incremental and disciplined approach to development of
Products and Services, that emphasizes people, results, collaboration
and responsiveness. It transcends mere practices and techniques.”
“Using fast decision cycles to succeed under conditions of uncertainty
and to create value.”

13. 13
Agile Is a Value Driven Model

14. 14
Waterfall Vs Agile

15. 15
Agile requires Iterative and Incremental Delivery of Value

16. 16
Deliver “Slices of Value”

17. 17
What Agile is NOT
Assumptions
about Agile

18. 18
Common Misconceptions about Agile
“Agile is cowboy
programming with
little
documentation”
“Our IT group is
agile…”
“It can’t work
because we use
_____”
“Our company
adheres to SOX,
HIPAA, FDA,
CMMI, or (insert
compliance here)”
01 02 03 04 05
“I can’t commit to
a date because we
are agile”

19. 19
Assumptions about Agile
Agile Is Agile Isn’t
Disciplined Cowboy coding
Just Enough Documentation No documentation
Continuous planning No plan or process
Value Sooner Guaranteed faster
Self-organizing teams No management
Highly collaborative Magic or a silver bullet
Iterative Won’t work with Waterfall
For the whole organization Just for techies
Documentation is NOT obsolete.
Documentation that doesn’t add value IS.

20. 20
Why Agile?
Source: VersionOne State of Agile Survey 2016

21. 21
Benefits of Agile
Source: VersionOne State of Agile Survey 2016

22. 22
Agenda
Lean Thinking with Penny Game
Agile Thinking with Scrum2
Agile- What it is and isn’t, and Why should we care?a
Agile Manifesto (Values) and Principlesb
Introduction to Scrumc
Artifacts in Scrumf
1
Agile Roles and Responsibilitiesd
Various levels of Planning in Scrumg
Scrum Ceremoniesh
Lego Scrum Gamee

23. 23
Agile Manifesto – The Values

24. 24
Agile Principles

25. 25
Break #1

26. 26
Agenda
Lean Thinking with Penny Game
Agile Thinking with Scrum2
Agile- What it is and isn’t, and Why should we care?a
Agile Manifesto (Values) and Principlesb
Introduction to Scrumc
Artifacts in Scrumf
1
Agile Roles and Responsibilitiesd
Various levels of Planning in Scrumg
Scrum Ceremoniesh
Lego Scrum Gamee

27. 27
Exercise: Application of Agile Principles
• Identify few scenarios from your past experience where you noticed application of a specific Agile principle.
• Discuss your findings with group which principle was applicable in what context.

28. 28
Scrum Framework: Artifacts and Events
24h
SPRINT
POTENTIALLY
SHIPPABLE
INCREMENT
SERVICE & PRODUCT
ADOPTION BACKLOG
SPRINT BACKLOG
SPRINT DEMO
SPRINT RETROSPECTIVE

29. 29
SCRUM – The Process at a Glance
SERVICE &
PRODUCT
ADOPTION
BACKLOG
SERVICE & PRODUCT
ADOPTION BACKLOG
BURNDOWN
SPRINT
BACKLOG
SPRINT
BACKLOG
BURNDOWN
IMPEDIMENT
LIST
SERVICE & PRODUCT
ADOPTION BACKLOG
DELTA REPORT
SPRINT
RETROSPECTIVE
INCREMENT
SPRINT
REVIEW
• Business Value Proposition & Funding
• Contractual agreement
• Product / Service Strategy and Vision
• Product / Service Backlog and Bundles
• Initial Scrum backlog/s (Service & Product
Adoption)
• Initial Scrum release plan/s
• Resource Ramp Up
SPRINT ‘0’
RELEASE n
SCRUM
PROCESS
SPRINT
PLANNING
MEETING
UPDATE
BACKLOG
DAILY SCRUM /
DAILY WORK
SPRINT
RETROSPECTIVE

30. 30
SCRUM – The Process I
SPRINT PLANNING
MEETING
The work to be performed during the
Sprint is planned at the Sprint Planning
Meeting. Collaborative work of the
entire Scrum Team leads into a working
plan.
What can be delivered in the Increment
resulting from the upcoming Sprint?
How will the work required to deliver the
Increment be achieved?
SPRINT
PLANNING
MEETING
UPDATE
BACKLOG
INCREMENT
SPRINT
REVIEW
SPRINT
RETROSPECTIVE
DAILY SCRUM /
DAILY WORK
SCRUM
PROCESS

31. 31
SCRUM – The Process II DAILY SCRUM CYCLE /
DAILY WORK
The Daily Scrum is a 15-minute time-
boxed event for the Scrum Team to
synchronize activities and create a plan
for the next 24 hours. Team members
explain:
What did I do yesterday that helped the
Team meet the Sprint Goal?
What will I do today to help the Team
meet the Sprint Goal?
Do I see any stumbling blocks that
prevent me or the team from meeting
the Sprint Goal?
SCRUM
PROCESS
SPRINT
PLANNING
MEETING
UPDATE
BACKLOG
INCREMENT
SPRINT
REVIEW
SPRINT
RETROSPECTIVE
DAILY SCRUM /
DAILY WORK

32. 32
SCRUM – The Process III
INCREMENT / FINISHED
WORK
The Increment is the sum of all the
Backlog items completed during a
Sprint, including the value of the
Increments of all previous Sprints. At
the end of a Sprint, the new Increment
must be “Done“.
The resultant increment must be in a
useable condition regardless of whether
the Service and/ or Product Owners
decide to actually release it.
SCRUM
PROCESS
SPRINT
PLANNING
MEETING
UPDATE
BACKLOG
INCREMENT
SPRINT
REVIEW
SPRINT
RETROSPECTIVE
DAILY SCRUM /
DAILY WORK

33. 33
SCRUM – The Process IV
SPRINT REVIEW
A Sprint Review is held a the end of a
Sprint to inspect the Increment and
adapt the Service & Product Adoption
Backlog if needed. During this meeting,
the Scrum Team and stakeholders
collaborate about what was done in the
Sprint.
The Sprint Review is not a status meeting.
SCRUM
PROCESS
SPRINT
PLANNING
MEETING
UPDATE
BACKLOG
INCREMENT
SPRINT
REVIEW
SPRINT
RETROSPECTIVE
DAILY SCRUM /
DAILY WORK

34. 34
SCRUM – The Process V
SPRINT RETROSPECTIVE
The Sprint Retrospective is an
opportunity for the Scrum Team to
inspect and create a plan for
improvement to be carried out during
the next Sprint. The Sprint
Retrospective occurs after the Sprint
Review and prior to the next Sprint
Planning.
Purpose: Inspect how the last Sprint
went with regard to people,
relationships, process and tools.
SCRUM
PROCESS
SPRINT
PLANNING
MEETING
UPDATE
BACKLOG
INCREMENT
SPRINT
REVIEW
SPRINT
RETROSPECTIVE
DAILY SCRUM /
DAILY WORK

35. 35
SCRUM – The Process VI UPDATE SERVICE &
PRODUCT ADOPTION
BACKLOG
The Service and Product Adoption
Backlog is an ordered list of everything
that might be necessary in the service
and the specific product. It is the single
source of requirements of any changes
to be made to the service and specific
product.
The Service and Product Adoption
Backlog is dynamic, it is never complete.
It constantly changes to identify what
the end-to-end service and specific
product need to be appropriate,
competitive and useful.
SCRUM
PROCESS
SPRINT
PLANNING
MEETING
UPDATE
BACKLOG
INCREMENT
SPRINT
REVIEW
SPRINT
RETROSPECTIVE
DAILY SCRUM /
DAILY WORK

36. 36
In Summary:
• Each sprint has a fixed duration “time-box”
• Each sprint delivers working, fully tested code
• Only the team can do a pull from backlog
• Team cannot plan to exceed their capacity
• Team sync up on sprint goals during daily standup
• Core team size cannot be dynamic
• Team stays together for extended duration
Scrum is lightweight yet, like rugby, needs rules to ensure correct
flow.
It is the responsibility of the Scrum Master to ensure adherence to
the agreed rules.
Scrum Values
Commitment, courage, focus, openness and respect

37. 37
Agenda
Lean Thinking with Penny Game
Agile Thinking with Scrum2
Agile- What it is and isn’t, and Why should we care?a
Agile Manifesto (Values) and Principlesb
Introduction to Scrumc
Artifacts in Scrumf
1
Agile Roles and Responsibilitiesd
Various levels of Planning in Scrumg
Scrum Ceremoniesh
Lego Scrum Gamee

38. 38
SCRUM - Team
SERVICE OWNER
A person responsible for
maximizing the value of the
Service and the work of the
Scrum Team (Service Backlog
and determination of
priorities)
SCRUM TEAM
Professionals who do the work for
delivering a potentially releasable
Increment of “Done“ software at the
end of each Sprint. The software is
coded and tested. Self-organizing,
cross-functional
SCRUM MASTER
A person ensuring that Scrum is understood
and enacted. Expert in the Scrum Process and
monitors the Scrum Team progress
PRODUCT OWNER
A person responsible for
ensuring Product adoption of
the Service and maximizing
the value of the Product
(Product-specific Backlog and
determination of priorities)
SUPPORTING SMEs
Professionals who work on the
enabling elements of a Service
and/or Product Adoption
SERVICE ANALYST
A person who defines Service
Level Requirements, Use Cases
and User Stories.
Supports UAT.
BUSINESS ANALYST
A person who defines Product
Adoption Level Requirements,
Use Cases and User Stories.
Supports UAT.
AGILE COACH
A person leading and coaching the
organization in its Agile and Scrum
adoption.
PROGRAM MANAGER
(SERVICE AND PRODUCT)
A person who manages and resolve
Interdependencies and aligns
enabling activities to support team.
Also involved in monitoring and
tracking of velocity and other health
indicators

39. 39
Break #2

40. 40
Agenda
Lean Thinking with Penny Game
Agile Thinking with Scrum2
Agile- What it is and isn’t, and Why should we care?a
Agile Manifesto (Values) and Principlesb
Introduction to Scrumc
Artifacts in Scrumf
1
Agile Roles and Responsibilitiesd
Various levels of Planning in Scrumg
Scrum Ceremoniesh
Lego Scrum Gamee

41. 41
Lego Scrum Game: Goal- Make Money based on Quantity, Batch Size & Price
Sys Admin
provisions team
with environment
Business Owner adjusts
Market Demand in each sprint
Team tries to
make money by
creating batches
(user stories) in
each sprint

42. 42
Lego Scrum Game: Three Sprints Simulations
• Sprint 1: Cyclical value delivery–
with Scrum
• Sprint 2: Agile Transformation –
optimizing Scrum team
• Sprint 3: Optimizing flow of value

43. 43
Lego Scrum Game: Characters in the game
• Each Scrum teams have characters
associated: 4 Dev, 2 Testers, 1 Scrum
Master and 1 Product/Service Owner
• Each scrum team has 3 Ops team
members: 1 Release Engr, 1 Sys
Admin, and 1 Security Engr
• Each Scrum team has 1 Business
Owner associated.

44. 44
Lego Scrum Game: Definition of Done
• Each package contains:
• one Lego animal
• one chocolate candy
• Type of animal as per user story.
• Each animal has a label with a
unique number between 1 & 120
• white numbered labels in all sprints
Sample animals:
A lion and a horse

45. 45
Lego Scrum Game: A Batch = A User Story Shippable As A Deployment Package
• LEGO animal = software tasks
• Chocolate = user documentation
User Story
Deployment
package
Five small
individual
packages
with a
LEGO dog
and a
chocolate

46. 46
Lego Scrum Game: Sprint 1- Cyclical Value Delivery with Scrum
Rules for Sprint 1:
• Sys Admin creates development environment for team
• Dev creates animal
• QA labels animal with a unique numbered label & attaches a chocolate to put it into small package with that chocolate.
• QA will create Deployment Package (“batch”) with such small packages
• QA hands off the deployment package to Release Engineer.
• Security Engineer then conducts security checks at Operations table.
• Scrum Team and Ops team both operate within the boundaries of their roles.
Product/Service Owner instructions:
• Product/ Service Owner specifies work for the sprint, e.g. 1 batch of dogs, 2 batches of cats, etc.
• Once batches produce desired quantity, Release Engineer takes deployment package to Business Owner.
Scrum Master manages time-box:
• Planning: 2 min
(to plan work for the sprint)
• Execution: 8 min (to hand-off deployment package and run security checks. If possible, Demo: 2 min, and Retrospective: 1 min)

47. 47
Lego Scrum Game: Sprint 1- Group Level Debriefing

48. 48
Lego Scrum Game: Sprint 2- Optimizing the Scrum Team
Rules for Sprint 2:
• Dev and QA are not siloes anymore
• Cross-train Developers and Testers
• Everyone now creates animal and attaches a chocolate to it
• Invite Sara Security into Scrum Team – learn about security issues before implementation.
• Security Engineer tells what not to put into the Deployment Package
• Everyone puts white label on the animal with a unique numbered white label & puts it into small package with that chocolate.
• First release into production. Only release engineer can deploy.
• Everyone will create Deployment Package (“batch”) with such small packages
• Everyone hands off the deployment package to Release Engineer.
• First release into production. Only release engineer can deploy, since packages are bug-free.
Product/Service Owner instructions, same as sprint 1:
• Product / Service Owner specifies work for the sprint, e.g. 1 batch of dogs, 2 batches of cats, etc.
• Once batches produce desired quantity, Release Engineer takes it as deployment package to Business Owner.
Scrum Master manages time-box:
• Planning: 2 min
(to plan work for the sprint)
• Execution: 8 min (to hand-off deployment package and run security checks. If possible, Demo: 2 min, and Retrospective: 1 min)

49. 49
Lego Scrum Game: Sprint 2- Group Level Debriefing
How was your experience?
What was different in Sprint 1 and Sprint 2?

50. 50
Lego Scrum Game: Sprint 3- Optimizing the system with Agile Transformation
Rules for Sprint 3:
• Improving the flow:
• Dev and OPs are not siloes anymore
• Building T-shaped skills
• At the start of Sprint 3, players will cross-train each other and exchange red & green labels to indicate
completion of cross-training on their name tags. Now they are able to play additional roles in the overall process.
• Right after the cross-training is complete, introduce two more changes to the game:
• Batch size = 1
• Team agreed to move to “one-piece flow”, no more large user stories
• Simplified deployment process
• Now instead of building a task in a small package and then assembling all tasks in a deployment package,
the task will be built directly in a single deployment package –for a simplified, automated deployment.
• Everyone who has been cross-trained by Robert Release Engineer can now deploy into production.
• Accelerating the Feedback
• Simplifying deployments
• Continuous Delivery

51. 51
Lego Scrum Game: Sprint 3- Group Level Debriefing
How was your experience?
What was different in Sprint 1, Sprint 2 & Sprint 3?

52. 52
Agenda
Lean Thinking with Penny Game
Agile Thinking with Scrum2
Agile- What it is and isn’t, and Why should we care?a
Agile Manifesto (Values) and Principlesb
Introduction to Scrumc
Artifacts in Scrumf
1
Agile Roles and Responsibilitiesd
Various levels of Planning in Scrumg
Scrum Ceremoniesh
Lego Scrum Gamee

53. 53
Artifact: Product/Service Backlog
• Owned by Product Manager (Service Owner)
• Ordered list of all desired features
• Expressed such that each item has value to users
• Estimated – in points - by the team
• Reprioritized as needed

54. 54
Artifact: Sprint Backlog
• Owned by TEAM
• A group of User Stories selected BY TEAM from Product / Service Backlog to complete in a Sprint
• All tasks necessary to deliver each User Story are identified and estimated in hours
• Stories are estimated in story points, which establishes team level Velocity
Product / Service backlog

55. 55
Artifacts: Scrum Board, Sizing Board and Burndown Chart
-200
-100
0
100
200
300
400
500
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual

56. 56
Artifact: User Stories
• Features in a Product Backlog are expressed in User Stories.
• A User Story describes a single feature in terms of a user interaction in a way that
specifies the role, the requirement and the purpose.
• User story has multiple Acceptance Criteria (AC’s) associated with it.
User Stories should be:
• Independent
• Negotiable
• Valuable
• Estimate(able)
• Sized
• Testable
As a <user role>, I want <requirement> so that <purpose>
The 3 C’s of A User Story©:
Card –
The User Story can fit on an index card
Conversation –
User Stories are a promise for a future conversation
Confirmation -
Team needs to understand what it will take for customer to
accept User Story
©Ron Jeffries

57. 57
Artifact: The Release Plan
Description
• Once Product/Service Backlog is created & groomed, team groups stories for a “Release” (a time-box)
• Team will use initial capacity (or known velocity) to organize stories into Sprints for that Release
• Release Plan is created during Service/Product level planning and re-visited at each Sprint planning
Timing & Duration
• Sprint 0 (last week), from 4 hours to 3 days, depending on scope and sizes of portfolio items

58. 58
Scrum requires Definitions of Ready & Done
Ready
• Enterprise definition
• Team-level definition
• Prevents teams from committing to work that
cannot be completed in Sprint
Done
•What should Product / Service Owner
check to mark a story as done?
•Enterprise-level definition
•Team-level definition
Ready Example
• No known dependencies
• Story & Acceptance criteria defined and understood
• All tools and skills required are on the team
• Story can be or is sized
• Story will take less than half a sprint to complete
Done Example
• Acceptance criteria met
• No known defects
• Relevant and necessary documentation updated
• Test cases automated
• Integration testing complete
• Scheduled for Release

59. 59
Agenda
Lean Thinking with Penny Game
Agile Thinking with Scrum2
Agile- What it is and isn’t, and Why should we care?a
Agile Manifesto (Values) and Principlesb
Introduction to Scrumc
Artifacts in Scrumf
1
Agile Roles and Responsibilitiesd
Various levels of Planning in Scrumg
Scrum Ceremoniesh
Lego Scrum Gamee

60. 60
Planning is continuous- begin with the end in mind

61. 61
Agenda
Lean Thinking with Penny Game
Agile Thinking with Scrum2
Agile- What it is and isn’t, and Why should we care?a
Agile Manifesto (Values) and Principlesb
Introduction to Scrumc
Artifacts in Scrumf
1
Agile Roles and Responsibilitiesd
Various levels of Planning in Scrumg
Scrum Ceremoniesh
Lego Scrum Gamee

62. 62
Event: Backlog Grooming
Description
• Product/Service Owner continuously grooms stories to refine product/service backlog for next sprints
• Ideally, teams will have anywhere from 2-5 sprints worth of stories that meet “Definition of Ready”
• A healthy, groomed backlog is the responsibility of the whole team
• For each story, the team sizes how big it is relative to other stories on the backlog
• Story Points are neither consistent nor normalized from team to team
• Story Points are indicators of effort, complexity and risk
• Relative “points” are the most common unit of sizing:
• 1, 2, 3, 5, 8, 13, 20 (modified Fibonacci series)
Timing & Duration
• Usually mid-Sprint or weekly
• 2-4 hours per Sprint

63. 63
Event: Sprint Planning
Description
• Meeting to elaborate, task out high value stories that meet “Definition of Ready”
• Task Board is built with stories TEAM has accepted into Sprint
• Tasks meet Acceptance Criteria of User Story
• Sprint Goal is defined and committed to
Timing & Duration
• Beginning of each Sprint (same time)
• 2-4 Hours
Attendees
• Team, Product/Service Owner & Scrum Master
Artifact
• Committed Sprint Backlog & Task Board

64. 64
Event: The Daily Stand Up
Description
• Daily team meeting to answer the following questions:
• What did we do yesterday to get closer to our Sprint Goal?
• What will we do today to get closer to our Sprint Goal?
• Is anything blocking our way from meeting our Sprint Goal?
Timing & Duration
• Daily (same time)
• 15 Minutes or less
Attendees
• Scrum Master
• Team Members
• Product/Service Owner
Artifact
• Updated Task Board

65. 65
Event: Sprint Demo
Description
• Team demonstrates working software (accepted Stories) to stakeholders for feedback.
• Review improvements and impediments from the Sprint, update Product/Service Backlog
• Update release plan based on Sprint results
Timing & Duration
• End of each Sprint (same time)
• 1 hour
Attendees
• Team Members
• Product/Service Owner
• Scrum Master
• Stakeholders

66. 66
Event: Sprint Retrospective
Description
• THE most important Scrum event
• Team meets to evaluate the last Sprint to identify what went well and what they can improve
• Actions and commitments are made to improve performance
Timing & Duration
• End of each Sprint (same time)
• As long as it takes
Attendees
• Team Members
• Product/Service Owner
• Scrum Master
Artifact
• Added to backlog to
capture improvement/action for the team

67. Thank You