This document provides an overview of Lean, Agile and Scrum methodologies for software development. It discusses Lean principles like eliminating waste and respecting people. It describes the origins of Lean in the Toyota Production System. Agile values like individuals and interactions are explained. The Scrum framework is outlined, including the roles of Product Owner, Scrum Master and Development Team. Key Scrum ceremonies like Sprint Planning, Daily Scrum and Retrospective are summarized. Scrum artifacts such as the Product Backlog and Sprint Backlog are also covered at a high level.

1. Lean, Agile & Scrum
in a chestnut

2. George Stamos
Agile/Lean coach and trainer at Intracom Telecoms S.A
Scrum.org/User Profile
MsC in Electronics & Telecommunications Engineering graduate of
Bath University
.
Specialties: Lean, Agile, Scrum, Kanban, Training & Coaching
Scrum Teams, Mentoring Organization’s new Scrum Masters
g_stam77
george.m.stamos@gmail.com
http://www.slideshare.net/GeorgeStamos

3. Agenda
• Lean Development
– Why Lean?
– What Lean is
– History of Lean
– Lean principles
• Agile Development
– Controlling chaos
– Agile manifesto
– Why Agile works
– What makes us Agile?
– Agile frameworks
– Agile philosophy
• Scrum framework
– Roles
– Ceremonies
– Artifacts
• Scrum Practices
– Vision
– User Stories
– User story estimation
– Definition of Ready

4. LEAN DEVELOPMENT

5. CUSTOMERS WANT MORE

6. It is not necessary to change.
Survival is not mandatory.
W. Edwards Deming

8. Lean is an Operational
Excellence Strategy that enable
you to change for the better

9. Kai
“change”
zen
“good”

10. TOYOTA PRODUCTION SYSTEM
• The Toyota Production System historically
has had four basic aims that are consistent
with these values and objectives:
• The four goals are as follows:
– Provide world class quality and service to the
customer.
– Develop each employee’s potential, based on
mutual respect, trust and cooperation.
– Reduce cost through the elimination of waste and
maximize profit
– Develop flexible production standards based on
market demand.

11. MURI (LOAD)
Refers to the tendency to
overload processes in the
hope of achieving more.
Lean thinking maximizes
value creation over
process utilization

12. MURA (FLOW)
Inconsistent flow can disrupt a system, creating
inefficiencies and waste.
Lean decreases lead time by smoothing flow through
a system

13. MUDA (WASTE)
Refers to any non-value
adding activity that a
customer is unwilling to
pay for.

14. Lean Principles
• Eliminate waste
• Build quality in
– Think how to test before starting
• Create knowledge
– Amplify learning
• Defer commitment
– Decide as late as possible
• Deliver as fast as possible
– Learn as fast as possible
• Respect people
– Empower the team
• Optimize the whole
– Improve the entire system

15. Value Stream Map

16. KANBAN
Visualize the flow
Limit Work in Progress
 Optimize Lead Time

17. Lean Software Development: An Agile Toolkit
(Agile Software Development Series) (Paperback)
by Mary Poppendieck (Author), Tom Poppendieck (Author)
This is Lean: Resolving the Efficiency Paradox
Niklas Modig (Author), Pär Åhlström (Author)

18. The Principles of Product Development Flow
by Donald Reinertsen

19. AGILE SOFTWARE DEVELOPMENT

20. Defined Process Control

21. Empirical Process

22. Controlling Chaos

23. Agile Manifesto
Individuals and interactions
processes and tools
Working software
comprehensive documentation
Customer collaboration
contract negotiation
Responding to change
following a plan

24. WHY AGILE WORK?

25. Traditional WoW
› Assumptions
– The customer knows what he wants
– The developers know how to build it
– Nothing will change along the way

26. And the management

27. . . .

28. Result?

29. Agile Development
› Assumptions
– The customer discovers what he wants
– The developers discover how to build it
– Many things change along the way

30. Why Agile works
› Autonomy
– The desire to direct our own lives
› Mastery
– The urge to make progress and get better at
something that matters
› Purpose
– The yearning to do what we do in the service of
something larger than ourselves.

31. SCRUM FRAMEWORK
A quick overview of Scrum, its roles and ceremonies

32. THREE SCRUM ROLES
Product Owner
Scrum Master
Development Team

33. Product Owner
PO

34. What does a product owner do?
• Defines the Product Vision
• Define the features of the product
• Decide on release date and content
• Helps the stakeholders understand
– Product/Feature requirements
– Product/Feature plans
– Business and product/feature risks
• Be responsible for the profitability of the product (ROI)
• Creates and grooms the Product Backlog
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Collaborates on the product
• Accept or reject work results

35. Product Owner
PO
Scrum Master
SM

36. What does a scrum master do?
• Explain Scrum to the organization
• Expert on the Scrum process
• Understand that ScM has no product/feature authority
• Represents management to the project
• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
• Support the team to be more productive in any way he/she can
• Help team to improve the engineering practices
• Works on his/her Scrum impediment list

37. Product Owner
PO
Scrum Master
SM
Development
Team
TM

38. Development Team
A self-organized team that take
collective ownership of the Sprint goal
and sprint backlog. They fight
impediment during the sprint and in
retrospective

39. Development Team
• Cross-functional
• Seven plus or minus two members
• Works with the Product Owner to select the sprint goal
(what) and then specifies the work details (how)
• Self-organizing
• Team takes authority of the sprint
• Team feels empowered
• Team commits to work at sprint planning
• All team members feel responsible for all tasks
• Team constantly improve
• Team works closely together
• Responsible for product quality

40. Scrum Team
Product Owner
PO
Scrum Master
SM
Development
Team
TM

41. SCRUM CEREMONIES
Sprint planning
Sprint Review
Sprint Retrospective
Daily Scrum

42. Sprint Planning
• Occurs at the beginning of every Sprint – Day 1
– It is time-boxed to eight hours for a one month Sprint. For shorter
Sprints, allocate approximately 5% of the total Sprint length to this
meeting
• Some preparation occurs before the Sprint
Planning
– Product owner prioritizes and refines the Product Backlog
– The Product Owner may involve the team in preparation
• Attended by the Product Owner, Scrum Master
and Team
• There are two parts to the Sprint Planning
Meeting: the “What?” part and the “How?” part

43. Sprint Review
• The team demonstrates working software (no
powerpoint!) completed during the sprint.
• Product owner accepts or rejects each backlog
item
- The Scrum team considers the whole product with
respect to the release goal and product vision.
- How does this affect what we do next? The Sprint
Review provides valuable input to subsequent Sprint
Planning meeting
- The team should briefly prepare so the meeting
will be effective

44. Sprint Retrospective
At regular intervals, the Development
Team reflects on how to become more
effective, then tunes and adjusts its
behavior accordingly

45. Agile Retrospectives: Making Good Teams
Great (Paperback)
by Esther Derby (Author), Diana Larsen (Author), Ken Schwaber (Author)

46. Daily Scrum
• Whole world is invited
– Only team members, Scrum Master, Product Owner, can talk
BUT
• Only “committed” people are allowed to talk, others can only listen... so
the Scrum Master and the Team Members are pigs, the others are
chickens...

47. SCRUM Process Overview

48. SCRUM ARTIFACTS
Product Backlog
Sprint Backlog
Estimation
Release Planning

49. Product Backlog
• User stories that fulfill requirements
• A list of all desired work on the project
– A list of user stories prioritized
– Stories in the Product Backlog include features that deliver the Product
Vision
• Ideally expressed such that each item has value to the users or
customers of the product
• Prioritized by the product owner
• The highest prioritized items need to be better detailed and specified
- the team needs to be able to estimate and test these items
• The list of stories is constantly evolving, changing and updating
– Reprioritized at the start of each sprint

50. Requirements
Requirements are the needs that your
product must satisfy. They must answer the
questions What is the need? and Why?
They are descriptions of a problem.

51. Discussion
• A Stakeholder tells you she needs a bridge
• What is her need?
• A well formulated requirements described
the problem, not the solution

52. SMART Requirements
• Simple
Can everybody understand this?
• Measurable
When is the Requirement fulfilled?
• Achievable
Do you have the resources?
• Relevant
Is it really a need for the customer?
• Traceable
Who is the stakeholder or origin?

53. Example Requirement
• Support complains about new features
Some guys at the support office are
complaining that our product is not easy to
use, and they spend too much time on the
support hot-line to get our user to run the
software.
MS A R TMS A R T

54. Example Requirement
Requirement
Need to improve usability: There is the need to make the
product UI more intuitive. There are too many support
requests related to usage of the tool, often associated with
very “simple” problems
MS A R TMS A R T

55. Sprint Backlog
• What we want
– A sprint backlog created by the team,
estimated by the team and owned by the
team.
– Progress in sprint is highly visible.
– Sprint Goal
• A short statement of what the work will be focused on
during the sprint

56. Agile Estimation
• Why do we estimate?
– To plan a release consisting of multiple sprints
– To help the product owner with prioritizing stories
– To estimate how many stories will fit in an iteration
• Relative Estimation: Instead of estimating absolute size
of feature, we estimate their relative proportion, and then
derive the absolute size:
?

57. Agile Estimating and Planning (Robert C.
Martin Series) (Paperback)
by Mike Cohn (Author)

58. Release Planning
• Why?
• Release Planning Approaches
– Scope first
– Date first

59. Succeeding with Agile: Software Development
Using Scrum
by Mike Cohn
Agile Software Development with Scrum (Series
in Agile Software Development) (Paperback)
by Ken Schwaber (Author), Mike Beedle (Author)

60. SCRUM PRACTICES
Product Vision
Sprint Backlog
Release Planning

61. Product Vision
• Start with WHY first
• What do we want to accomplish
• Imagine what the product will be like when
it is ‘finished.’
• Describe this finished state and publish it.
• Use the elevator pitch template.

62. Helps you move from this....
“I’m glad we’re all agreed then.”

63. to this . . .
“I’m glad we’re all agreed then.”

64. iPod Vision
• “In your pocket”
• The iPod will be a portable digital music player
that will hold 5000 songs. It will have a battery
life measured in days, not hours. You will
navigate the thousands of songs with a single
finger. You will sync all your music from your
computer to the iPod in minutes
automatically, so you can have all your music
in your pocket.

65. The vision that inspired a nation
"I believe that this nation should
commit itself to achieving the goal,
before this decade is out, of landing
a man on the moon and returning
him safely to the Earth."
— Pres. Kennedy, May 25, 1961

66. Made to stick
A good book to help you create a catchy vision is
“Made to Stick” by Dan Heath & Chip Heath.
What you want to describe is the bottom line,
the core idea of what you want your product to do.
Don’t fall in the trap of rehashing a generic marketing
line that applies to your entire company - really think
about what you are setting out to achieve with your
product.

67. User Stories
• Requirements are descriptions of needs of
the product - describe the problem
• Requirements are transformed into
multiple User Stories, were each User
Story is a proposal to fully or partially
satisfy the Requirement
• User Stories are proposed solutions from
a user’s perspective
• User Stories have Acceptance Criteria or
Conditions of Satisfaction

69. As a <type of user>
I want to <do something>
so that <I can achieve some
business value>.
Example format

70. Acceptance Criteria
• Answer the question: How will know when we are
done?
• High-level criteria from the perspective of the user or
stakeholder
• There are Positive and Negative criteria
• Collaborate with testers to create good Acceptance
Criteria
Given <context>
When <action>
Then <expected result>

71. Sample User Story
As a Returning Customer I want the
system to remember my details so I
can purchase goods more quickly.
Acceptance criteria:
Scenario: Review Details Before Purchase
Given I’m on the Amazon website
And I’m logged in as a returning customer
When I click the “1-Click” button
Then I should see my order details

72. INVEST model
• Independent:
– Stories are easiest to work with if they are independent
• Negotiable
– A good story is negotiable. It is not an explicit contract for features
• Valuable
– A story needs to be valuable to the customer
• Estimable
– A good story can be estimated
• Small or Sized appropriately
– Good stories tend to be small: at most a few person-weeks
• Testable
– "I understand what I want well enough that I could write a test for it"

73. User Stories Applied: For Agile Software
Development
by Mike Cohn (Author)

74. Definition of Ready
• A Release is done when it satisfies all the
criteria the Product Owner (representing all
stakeholders) requires to ship software to
production
• A User Story is done when it meets the story
acceptance criteria and the team’s quality
standards for being potentially shippable