agile lean kanban training 1 hour

Post on 16-May-2015

6.407 Views

Category:

Technology

3 Downloads

Preview:

Click to see full reader

DESCRIPTION

Agile Lean Kanban Training 1 hour

TRANSCRIPT

0

Agile & Lean / Kanban

1

What is Lean?

2

Agile Development Methods (Dogma)

eXtreme Programming (XP)

Scrum

Lean Software Development

Behavior Driven Development (BDD)

Feature Driven Development (FDD)

Crystal Clear Methodology

DSDM

Others: Test Driven Development (TDD), Model

Driven Development (MDD), Rational Unified

Process (RUP).

3

Lean Has History Standard software development practice for the last

decade.

Agile is the combination of principals that have existed for over 60 years.

Lean Software Development exposes the pedigree of Agile.

Almost all Agile practices can be traced back to Deming’s System of Profound Knowledge and his 14 Points for Management.

Deming’s System of Profound Knowledge:

Deming advocated that all managers need to have what he

called a System of Profound Knowledge, consisting of four

parts:

Appreciation of a system: understanding the overall processes involving suppliers, producers, and customers (or recipients) of goods and services (explained below);

Knowledge of variation: the range and causes of variation in quality, and use of statistical sampling in measurements;

Theory of knowledge: the concepts explaining knowledge and the limits of what can be known.

Knowledge of psychology: concepts of human nature.

W. Edwards

Deming

Lean

Manufa

ctu

ring

Agile

Quality

Managem

ent

(Six

Sig

ma)Lean

Software

Dev.

4

Agile

PrincipalsCommunications

Simplicity

Feedback

Courage

Respect

Visibility

Honesty

Realism

Quality

Lean

PrincipalsOptimize the Whole

Eliminate Waste

Create Knowledge

Build Quality In

Defer Commitment

Deliver Fast

Respect People

5

Eliminate Waste

Everything not adding value to the customer is

considered to be waste (Muda). This includes:

Unnecessary code and functionality

Delay in the software development process

Unclear requirements

Bureaucracy

Slow internal communication

6

Create Knowledge / Amplify Learning

Customer Feedback

Short Cycle Times

Refactoring

Code Review

Automated Test instead of documented

defects.

7

Build Quality In

Unit Test / TDD

Automated Acceptance Tests

Refactoring

Pattern Based Development

Continuous Integration

8

Defer Commitment

Wait till the last “Responsible” moment to

make an irreversible decision.

Set Based Design

Pursue multiple solutions eventually choosing

the best one.

Agile Version: Prioritize backlog, but don’t

commit more then one iteration at a time.

9

Deliver Fast

Small Batch Sizes

Short Iterations

Feedback, Feedback, Feedback.

Close Customer Collaboration

Software Demos

10

Optimize the Whole

Manage the Value Stream

Look beyond the Development Team

Standardize the process

Efficiency vs. Effectiveness

11

Respect People

Trust in people that they know the best

way to do their jobs.

Recognize Teams and Individuals for their

effort and contribution

People are not “Resources”

Empower the team to make the right

decisions and improve the process.

12

How Does Agile Fit?

13

The Agile Manifesto – Agile Principals

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items

on the left more.

“We are uncovering better ways of developing software... Through this work we have come to value:”

14

Individuals & Interactions > Process and Tools

We value communication and teamwork over strict

processes and the tools to enforce them.

Most software problems can be traced back to

communication problems early on in a products

lifecycle.

Osmotic communication

means that information

flows into the background

hearing of members of the

team, so that they pick up

relevant information as

though by osmosis.

15

Working Software > Comprehensive Documentation

Working Software requires just as

much documentation as the

customer needs.

No More & No Less.

16

Customer Collaboration > Contract Negotiation

Remove barriers

between the developers

and the customers.

Understand that the

closer the relationship

between the customer

and the development

team the better the

product.

17

Responding to Change > Following a Plan

18

Agile PrincipalsSome of the principles behind the Agile Manifesto[6] are:

Our highest priority is to satisfy the customer through early and continuous deliveryof valuable software.

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

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

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

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

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

Working software is the primary measure of progress.

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

Continuous attention to technical excellence and good design enhances agility.

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

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

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

19

Typical Agile

Adoption

1. User Stories

2. Acceptance tests

3. Iterative Development

4. Burn Down Charts

5. Story Boards

6. Daily stand-ups

7. TDD / Unit Tests

8. Continuous integration

Simple Lean

Adoption

1. User Stories

2. Acceptance tests

3. Iterative Development

4. Burn Down Charts

5. Kanban Boards

6. Daily stand-ups

7. TDD / Unit Tests

8. Continuous integration

V.S.

20

Kanban

21

Kanban Signboard or Billboard

Kan means "visual," and ban, means "card" or "board”

Is a signaling system to trigger action

Uses cards to signal the need for work to be done

Another Toyota Lean lesson focusing on Just in Time

production

Example: 20 car doors, 5 left = “time to make more doors”

Doors are requirements, requirements are inventory

22

3 Rules

1. Strict Queue Limits

2. Pull Value Through

3. Make it Visible

Strict Queue Limits

Pull Value

Through

Make it Visible

Kanban

23

Example Development Boards

24

Example 2

25

Example 3

26

Work In Progress (WIP)

Create Columns for Each Step in your process

Pick Limits for “Active” Queues (team size divided by 2

or just be logical)

Set “Wait” Queues to 2 or 3, keep small, Eliminate

waste, get feedback

FIFO

If a slot is full, can’t start more work (A.K.A. PULL)

Team sets Queue sizes to be most efficient,

experiment

Designed to Limit WIP, More WIP means slower flow

27

WIP

Visible feature goals to minimize thrashing

MMF = minimal marketable feature

or MUF = minimal usable feature

Can Only reorder in “Wait” Queue to move MUF forward

Put Team Signals/Rules Above WIP

Queue & Cross Team Signals On Bottom

Could add a Queue for External Team

3 Rules: Strict Limit, Pull Value, Visible

28

What Goes On A Card

29

Cycle Time / Throughput

Goal is to get optimum flow

How many days does it take to flow through the team once it enters the WIP?

Keep a chart: Wait/Cycle Time for each card size

Good teams/systems: XS to Medium cards, Large = Bad

If 22 ~same size cards in WIP, track 22 as well

Sum up unit value on each board

Velocity is a trailing indicator

Throughput is a measure of demonstrated capacity

30

Backlog Board 3 Queues to show priorities

Set back log limit for each board to equal number of slots on WIP

Make assumption relative sizes will be close

Same number of items in WIP on each board (22 in this example)

Add up the “units” to ensure they are close, move wait line if they are considerably (not marginally) off

Can now forecast based on logical assumptions

Schedule regular backlog honing meetings with customer, rules at top

Trigger release planning meetings when necessary

Card is a TOKEN, physical means real, avoid temptation to live by a tool

31

What’s Changed:

Optimize/Continuous Flow No Iteration Planning Meetings

FIFO work order, don’t sign up

Cycle Time replaces velocity, always updated

Signal Event

Show & Tell

RPM

Scheduled Events

Retrospectives

Releases per MMF/MUF or Cadence

32

Agile & Lean

33

Scrum vs. Kanban

Why do we really care?

Agile Manifesto is about uncovering better ways of doing

software – not about one practice vs. another

Principles

Frequent Delivery does not mean you must do

iterations

Maintain a constant pace indefinitely (sustainable

pace AND consistent pace?)

34

Daily Scrum/Standup Used to Be

What did I do yesterday

What am I going to do today

Do I have any road blocks

Could Now Be

How are things flowing?

Team stands and reviews the WIP

Talk about blocks & constraints

Downstream work is most important

Take Turns with each person “reading” the flow

35

Agile & Lean Together

36

Agile & Lean Teams

1 Team Agile – 2 Week Interations

1 Team Lean – Kanban

Coordination: Release on the Cadence – 2 Weeks

Separate Stand-Ups / Scrum of Scrums

Rotating Testing & Verification

Product Owners provide work to both teams based on criteria.

Velocity, Lead Time & Cycle Time can all be coordinated.

37

Kaizen - Continuous Improvement

改善

Team retrospectives, Scrum of Scrums, Scrum Master

Retrospectives

Product Owner Retrospectives, Release Retrospectives

The entire process of development at an Agile Enterprise

should be regularly inspected and improved.

The outcome of the PDCA process must include the

Check and Act portions.

top related