Lean, Agile & Scrum in a chestnut
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
http://www.slideshare.net/GeorgeStamos
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
LEAN DEVELOPMENT
CUSTOMERS WANT MORE
It is not necessary to change.
Survival is not mandatory. W. Edwards Deming
Lean is an Operational
Excellence Strategy that enable
you to change for the better
Kai “change”
zen “good”
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.
MURI (LOAD)
Refers to the tendency to
overload processes in the
hope of achieving more.
Lean thinking maximizes
value creation over
process utilization
MURA (FLOW)
Inconsistent flow can disrupt a system, creating inefficiencies and waste.
Lean decreases lead time by smoothing flow through a system
MUDA (WASTE)
Refers to any non-value
adding activity that a
customer is unwilling to
pay for.
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
Value Stream Map
KANBAN
Visualize the flow
Limit Work in Progress
Optimize Lead Time
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)
The Principles of Product Development Flow by Donald Reinertsen
AGILE SOFTWARE DEVELOPMENT
Defined Process Control
Empirical Process
Controlling Chaos
Agile Manifesto Individuals and interactions
processes and tools
Working software
comprehensive documentation
Customer collaboration
contract negotiation
Responding to change
following a plan
WHY AGILE WORK?
Traditional WoW
› Assumptions
– The customer knows what he wants
– The developers know how to build it
– Nothing will change along the way
And the management
. . .
Result?
Agile Development
› Assumptions
– The customer discovers what he wants
– The developers discover how to build it
– Many things change along the way
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.
SCRUM FRAMEWORK A quick overview of Scrum, its roles and ceremonies
THREE SCRUM ROLES
Product Owner
Scrum Master
Development Team
Product Owner
PO
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
Product Owner
PO Scrum Master
SM
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
Product Owner
PO Scrum Master
SM Development
Team
TM
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
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
Scrum Team
Product Owner
PO Scrum Master
SM Development
Team
TM
SCRUM CEREMONIES
Sprint planning
Sprint Review
Sprint Retrospective
Daily Scrum
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
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
Sprint Retrospective
At regular intervals, the Development
Team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly
Agile Retrospectives: Making Good Teams
Great (Paperback) by Esther Derby (Author), Diana Larsen (Author), Ken Schwaber (Author)
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...
SCRUM Process Overview
SCRUM ARTIFACTS
Product Backlog
Sprint Backlog
Estimation
Release Planning
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
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.
Discussion
• A Stakeholder tells you she needs a bridge
• What is her need?
• A well formulated requirements described
the problem, not the solution
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?
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.
M S A R T M S A R T
Example Requirement R
eq
uir
eme
nt 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
M S A R T M S A R T
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
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:
?
Agile Estimating and Planning (Robert C.
Martin Series) (Paperback) by Mike Cohn (Author)
Release Planning
• Why?
• Release Planning Approaches
– Scope first
– Date first
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)
SCRUM PRACTICES
Product Vision
Sprint Backlog
Release Planning
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.
Helps you move from this....
“I’m glad we’re all agreed then.”
to this . . .
“I’m glad we’re all agreed then.”
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.
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
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.
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
As a <type of user> I want to <do something> so that <I can achieve some business value>.
Example format
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>
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
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"
User Stories Applied: For Agile Software
Development by Mike Cohn (Author)
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