practical scrum - day 1

104
PRACTICAL SCRUM Like us: Visit: Follow me: Tweet: CONSTANT HIGHER MORE LEARNING QUALITY FUN Day 1 www.facebook.com/PracticalAgile www.practical-agile.com @Linkedin @PracticalAgile1

Upload: anat-alon

Post on 23-Jan-2018

281 views

Category:

Business


0 download

TRANSCRIPT

PRACTICAL SCRUM

Like us: Visit: Follow me:Tweet:

CONSTANT HIGHER MORE

LEARNING QUALITY FUN

Day 1

www.facebook.com/PracticalAgile www.practical-agile.com@Linkedin@PracticalAgile1

THE EXPERT

Some Working Agreement

If you want to be here - act like you want to be here

Some Working Agreement

EXERCISE

Let’s Form Teams

What are we going to cover today?

TABLE OF CONTENTS10

31

46

60

83

90

What we thought vs. What we know

What is Agile?

What is scrum?

What is the manager role within agile environment?

What is Lean Thinking?

How does scrum eliminate waste?

Respect the sticky noteOne item per sticky, use a sharpie

“It ain’t what you don’t know that gets you into troubles. It’s what you know for sure that just ain’t so”

Mark Twain

WHAT WE THOUGHT VS. WHAT WE KNOW

What we thought vs. What we know

Requirements

Design

Implement

Test

Acceptance

Analysis

Deliver

WINSTON W. ROYCE 1970

"I believe in this concept, but the implementation described above is risky and invites failure"

01WHAT WE KNOW

The harder we plan and analyze in the beginning, the less there’s change in the project and the more successful the project

WHAT WE THOUGHT

WHAT WE THOUGHT

01WHAT WE KNOW

There is change always and responding to it is vital. Uncertainty is best reduced by learning from actual implementation

02WHAT WE KNOW

It is possible to “collect” or even “know” all the requirements up-front

WHAT WE THOUGHT

02WHAT WE KNOW

Requirements evolve as customers and our knowledge increases – based on experience

WHAT WE THOUGHT

03WHAT WE KNOW

Division of work to specialized teams (specification, design and testing) is efficient

WHAT WE THOUGHT

WHAT WE THOUGHT

03WHAT WE KNOW

Cross-functional teams reduce the amount of handovers and are more productive

04WHAT WE KNOW

Multiple parallel programs speed up the development

WHAT WE THOUGHT

WHAT WE THOUGHT

04WHAT WE KNOW

Multiple programs create big management overhead and risk of overloading the pipeline, R&D works most efficiently in continuous mode

05WHAT WE KNOW

Resource usage and cost optimization is the key to increased productivity

WHAT WE THOUGHT

WHAT WE THOUGHT

05WHAT WE KNOW

Concentrating on value stream optimization, removing waste and sustainable flow increases productivity

06WHAT WE KNOW

It’s possible to transfer information effectively on written documents without much of human contact.

WHAT WE THOUGHT

WHAT WE THOUGHT

06WHAT WE KNOW

Essential knowledge is lost in every handover and human interaction is needed to overcome it.

07WHAT WE KNOW

You can save time by “good-enough” development.

WHAT WE THOUGHT

WHAT WE THOUGHT

07WHAT WE KNOW

Any technical debt will slow development down and thus we don’t allow technical debt to accumulate.

08WHAT WE KNOW

Product development process can be defined as a predictable and repeatable process

WHAT WE THOUGHT

WHAT WE THOUGHT

08WHAT WE KNOW

Product development is an evolving and adaptive process

Wishful thinking

WHAT IS AGILE?

EXERCISE

Rewrite Each Agile Principle With 3 Words

Agile Principle 1-4

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Agile Principle 1-41. Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software

2.Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage

Agile Principle 1-41. Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter timescale

Agile Principle 1-41. Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter timescale

4. Business people and developers must work together daily throughout the project

Agile Principle 5-85. Build project around motivated individuals. Give them the

environment and support they need, and trust them to get the job done

Agile Principle 5-85. Build project around motivated individuals. Give them the

environment and support they need, and trust them to get the job done

6. The most efficient and effective method of conveying information to and within development team is face-to-face conversation

Agile Principle 5-85. Build project around motivated individuals. Give them the

environment and support they need, and trust them to get the job done

6. The most efficient and effective method of conveying information to and within development team is face-to-face conversation

7. Working software is the primary measure for progress

Agile Principle 5-85. Build project around motivated individuals. Give them the

environment and support they need, and trust them to get the job done

6. The most efficient and effective method of conveying information to and within development team is face-to-face conversation

7. Working software is the primary measure for progress

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

Agile Principle 9-12

9. Continuous attention to technical excellence and good design enhances agility

Agile Principle 9-129. Continuous attention to technical excellence and good design

enhances agility

10.Simplicity – the art of maximizing the amount of work not done – is essential

Agile Principle 9-129. Continuous attention to technical excellence and good design

enhances agility

10.Simplicity – the art of maximizing the amount of work not done – is essential

11.The best architectures, requirements, and designs emerge from self-organizing teams

Agile Principle 9-129. Continuous attention to technical excellence and good design

enhances agility

10.Simplicity – the art of maximizing the amount of work not done – is essential

11.The best architectures, requirements, and designs emerge from self-organizing teams

12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

EXERCISE

Command and Control Vs.

Self Manage

Where Scrum Fits?

• In our industry people got used to create and use META solutions to problems.

• The problems we are facing have nothing to do with technology, it is a people issue.

• In this land the basic assumption is that there is no META solution, just an empirical framework to allow inspect & adapt cycles.

• This experience is frustrating for those who are looking for predefined processes and final answers.

• ENTER AT YOUR OWN RISK!!!

WHAT IS SCRUM?

"Scrum is a team of eight individuals in Rugby. Everyone in the pack acts together with everyone

else to move the ball down the field in small incremental steps. Teams work as tight,

integrated units with whole team focusing on a single goal."

EXERCISE

What Would You Do ?

THE ORIGIN OF SCRUM

• Toyota lean concept

• The new, new software development game [Takeuchi & Nonaka, 1986]

• Iterative & incremental development

• Jeff Sutherland• Ken Schwaber

• Understanding that we cannot predict the future

• One size does not fit all

• Constant improvement

• Transparency & Visibility

• Team work

SCRUM PRINCIPLES

• Deliver business value fast (max. 30 days)

• Prioritizing

• Empirical approach

• Fun !!!

SCRUM PRINCIPLES

THE HIGH MOON STUDIO

SCRUM PROCESS OVERVIEW 3 Roles:

Product owner

Scrum Master

Team 4 Ceremonies :

Sprint Planning

Daily

Sprint review

Retrospective 3 Artifacts:

Product Backlog

Sprint Backlog

Burndown Charts

PRODUCT OWNER (PO)• Defines the features of the product• Defines release dates and content• Responsible for ROI• Prioritizes feature according to value• Can change features and priority

once every predefined interval• Decides what will be worked on in

each iteration• Accepts or rejects results

SCRUM MASTER (SM)• Scrum - A framework for

managing the development lifecycle of software products

• Master - A skilled practitioner of a particular art or activity

• A Scrum master - the leader of the Scrum process (& team)

What does it means “The leader of the scrum process”?• Coach the team with Scrum• Coach the PO with Scrum• Help Facilitate effective ceremonies• Helps removing impediments• Help the team grow • He is standing at the nexus between:

The product management that believes that any amount of work can be done

Developer’s that have the willingness to cut quality to support the managements belief

The English verb “to manage” was originally derived from the Italian maneggiare, meaning to handle and

train horses

The SM has no authority over the team or the PO

WHAT IS THE MANAGER ROLE WITHIN AGILE ENVIRONMENT?

A change in Manager’s roleStop:

• Assign task and verify completion• Micro manage to have the “illusion of control”• Makes decisions for the team• Limit the information & resources available to the team

Start:• Trust the team to get the job done• Gather data• Coach - observe and ask questions• Challenge• Give feedback

CAT HERDERS?

SCRUM TEAM• Self organizing• Typically 5-9 people • Cross functional (Preferably a

feature team)• Provide estimate for the tasks• Decides how much it can do• Decides how to reach the sprint

goal (within the project’s boundaries)• The team is responsible for the

outcome

EXERCISE

Cross Functional Vs.

Specializing Team

Round 1

Round 2

CONCEPT CHANGE • Decides what it can do• Decides how to do it• Responsible for the quality• If the job is successful the team

gets the credit• If the job is not DONE the team

is responsible

ALL OF US ARE SMARTER THAN

ANY OF US

THE TEAM IS WRONG?

• Let the team fail• Create an environment where it

is ok to fail• Failure amplifies learning• Where failure is allowed,

innovation and experiments are encouraged

• Increases trust

THERE IS NO FAILURE ONLY FEEDBACK

EXERCISE

The story aboutOfer Eini and EBay

(completely imaginary)

Ofer wants to know: Can your team build this skeletal system for him? The unions marketing division wants to set the press conference to one month, do you agree? What should he announce in this conference ?

EXERCISE

Debate in your teams and decide: what do you tell Ofer ?

WELL DONE!

“A lack of transparency results in distrust and a deep sense of insecurity”

Transparency Stop taking risks for our customers (without even letting them know)

Share the risk

Maximize the chances of success

Create a common interest

Know (not assume) the status of our projects - share it with the customer

How encourage transparency? Avoid the 90% done syndrome

Face hard facts - Early

Working Software - unfinished work is waste

Track progress with burn down charts

What Reduces Visibility?

Gantt charts

Hierarchy

Low Quality

Core code

What Reduces Visibility?

Core Code AKA infrastructure or legacy code

Most functionality depends on it

Usually fragile, does not have a test harness

only a few people really know it

Changes are time consuming

Becomes a bottleneck

“Once you put on a suit, no one tells you the truth anymore”

[Philip Crosby – 1995 – Reflections on quality]

Hierarchy

Technical Debt

Time

Work left 20

10 12 14 16 18

Low Quality

KEN SCHWABBER, “SCRUM ET AL”

What is Definition of Done (DoD)Terms of satisfaction of the product owner

Defined by the PO with the team

reflecting the technical abilities of the team

Items that are not Done “do not count”

This is just one example

Expending the Definition of Done over time

Designed

Coded

analyzed

Unit tested

Perf. tested

Code coverage

Live

Deployable

Acc. tested

This is just one example

Expending the Definition of Done over time

Undone Undone UndoneUndone

Stabilization sprint(s)

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Undone = risk

Undone = no visibility Can we

release ?

Unfinished Unfinished Unfinished

“THE TOYOTA STYLE IS NOT TO CREATE RESULTS BY WORKING HARD. IT IS A SYSTEM THAT SAYS THERE IS NO LIMIT TO PEOPLE’S CREATIVITY. PEOPLE DON'T GO TO TOYOTA TO 'WORK' THEY GO THERE TO ‘THINK'." Taiichi Ohno

Lean Thinking Continues Improvement Respect for People

[Mindset]My work is to do my work and to improve my work

Waste Value

Opportunity for improvement

Traditional improvement

EXERCISE

Exercise: The Name Factory

••

••

Round 1

Context Switch

Round 2

No Context Switch

Kaizen - Reduce Waste

Value:

The moments of actions or thoughts creating the product that the customer is willing to pay for

Total value time

Total cycle time= Value ratio____________

Waste:

All other moments or actions that do not add value but consume resources

Detect and Eliminate Waste1. Overproduction of features

2. Waiting and delay

3. Handoff

4. Extra process

5. Partially done work

Detect and Eliminate Waste6. Task Switching

7. Defects

8. Under-realizing people’s potential

9. Knowledge scatter

10. Wishful thinking

EXERCISE

Find one example of waste from your work and design an experiment to try eliminate it

Over Production of Features1. Features or services the

customer doesn’t want

2. Large engineering documents, more detailed designs than can be quickly implemented

3. Duplication of data

* THIS IS ONLY EXAMPLE

Wave

Waiting and Delay 1. For clarification

2. Documents

3. Approval

4. Components

5. Other groups to finish something

* THIS IS ONLY EXAMPLE

Handoff1. Giving a specification from an analyst to an engineer

2. Giving a component to another group for testing

* THIS IS ONLY EXAMPLE

Over Processing 1. Relearning, lose of information

2. Forced conformance to centralized process checklists

3. Recreating something made

* THIS IS ONLY EXAMPLE

Partially Done Work – WIP \ DIP 1. Designs documented but not built

2. Things built but not integrated or tested

3. Things tested but not delivered

* THIS IS ONLY EXAMPLE

Task Switching1. Interruption

2. Multitasking on 3 projects

3. Partial allocation of a person to many projects

* THIS IS ONLY EXAMPLE

Under-realizing People1. People only working to single speciality job

2. Do people have the chance to change what they see is waste

* THIS IS ONLY EXAMPLE

Information Scatter or Loss

1. Information spread across many separate documents

2. Communication barriers such as walls between people, or people in multiple locations

Wishful thinking 1. “We MUST follow the plan”

2. “The estimate cannot increase; The effort estimate is what we want it to be, not what it is now proposed”

3. “We’re behind schedule, but we’ll make it up later”

* THIS IS ONLY EXAMPLE

Parking lot

“THE VALUE OF AN IDEA LIES IN THE USING OF IT”

Thomas Edison

THE EXPERT SOLUTION

Reading List 1. Clean Code

2. Scrum Guide

3. Delivering happiness

4. Peopleware

*RECOURSE