Lean and agile in a chestnut

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

george.m.stamos@gmail.com

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