scrum & kanban

Board of directors

Henrik KnibergAgile/Lean coach

www.crisp.se

Kanban and ScrumMaking the most of both

Agile 2010, OrlandoAugust 12, 2010

[email protected]+46 70 4925284

Copyright notice

These slides are licensed under Creative Commons. Feel free to use these slides & pictures as you wish, as long as you leave my name and the Crisp logo somewhere.

For licensing details see: http://creativecommons.org/licenses/by/3.0/

All slides available at:http://www.crisp.se/henrik.kniberg/

mailto:[email protected]

http://creativecommons.org/licenses/by/3.0/


Board of directors

Henrik KnibergAgile/Lean coach

www.crisp.se

Kanban と Scrum両者を最大限に活用する

Agile 2010, OrlandoAugust 12, 2010

[email protected]+46 70 4925284

Copyright notice

These slides are licensed under Creative Commons. Feel free to use these slides & pictures as you wish, as long as you leave my name and the Crisp logo somewhere.

For licensing details see: http://creativecommons.org/licenses/by/3.0/

All slides available at:http://www.crisp.se/henrik.kniberg/

翻訳ドラフト版2010/8/30

K. [email protected]

mailto:[email protected]



3

Purpose of this presentation

To clarify Kanban and Scrum by comparing them

...so you can figure outhow these may come to usein your context.

Henrik Kniberg 3

4

プレゼンテーションの目的

Scrum と Kanban を比較して、両者をよりよく理解する

あなたが、自分のコンテキストで、

Scrum や Kanban をどう活用できるか自分で考えられるように

Henrik Kniberg 4

5

Kanban

Henrik Kniberg5

Scrum

Veteran

Read

Seen

Tried

Use

Your knowledge?

6

Kanban

Henrik Kniberg6

Scrum

ベテラン

読んだ

見た

試した

使った

知識レベル?

7

Scrum in a nutshell

Henrik Kniberg 7

8

Scrum超入門

Henrik Kniberg 8

9

Scrum in a nutshell

Henrik Kniberg 9

January April

Split your organization

Split your product

Split time

Optimize business valueOptimize process

$

$$$

Burndown

Unplanned items

Not

checked out Done! :o)

Write failing test

DAO

DB design

Integr test

Migrat ion

tool

Write failing test

GUI spec

Tapestry spikeImpl.

migration

2d

Code

cleanup

Deposit

2d1d 0.5d1d

2d

8d

1d2d

2d

Backoffice

Login

BackofficeUser admin

Write failing test

3d

2d

1d2d

Impl GUI

1dIntegr. with

JBoss2d

Write failing test

3d

Impl GUI

6d

Clarify require-ments

2d

GUI design (CSS)

1d

Fix memory leak(JIRA 125)2d

Sales support

3d Write whitepaper

4d

SPRINT GOAL: Beta-ready release!

Next

WithdrawPerf testWithdraw

checked out

Write failing test

Large group spending a long time building a huge thingSmall team spending a little time building a small thing

... but integrating regularly to see the whole

10

Scrum 超入門

Henrik Kniberg 10

１月４月

組織を分割

製品を分割

時間を分割

ビジネス価値を最適化プロセスを最適化

$

$$$

Burndown

Unplanned items

Not

checked out Done! :o)

Write failing test

DAO

DB design

Integr test

Migrat ion

tool

Write failing test

GUI spec

Tapestry spikeImpl.

migration

2d

Code

cleanup

Deposit

2d1d 0.5d1d

2d

8d

1d2d

2d

Backoffice

Login

BackofficeUser admin

Write failing test

3d

2d

1d2d

Impl GUI

1dIntegr. with

JBoss2d

Write failing test

3d

Impl GUI

6d

Clarify require-ments

2d

GUI design (CSS)

1d

Fix memory leak(JIRA 125)2d

Sales support

3d Write whitepaper

4d

SPRINT GOAL: Beta-ready release!

Next

WithdrawPerf testWithdraw

checked out

Write failing test

大きなグループが長い時間をかけて、巨大なものを作る小さなグループが短い時間に、小さなものを作るただし、しょっちゅう統合して、全体を見る

11

Process is

continuously improving

Have Definition of Done (DoD)

DoD achievable within

each iteration

Team respects DoD

The bottom line

Delivering working, tested

software every 4 weeks or less

Delivering what the

business needs most

Demo happens after every

sprint

Shows working, tested

software

Feedback received from

stakeholders & PO

Retrospective happens after

every sprint

Results in concrete

improvement proposals

Some proposals actually get

implemented

Whole team + PO

participates

Team has a sprint backlog

Highly visible

Updated daily

Owned exclusively by the

team

Have sprint planning meetings

PO participates

Whole team participates

Results in a sprint plan

Whole team believes plan is

achievable

PO satisfied with

priorities

PO brings up-to-date PBL

Iteration length 4 weeks or

less

Always end on time

Team not disrupted or

controlled by outsiders

Timeboxed iterations

PO has a product backlog

(PBL)

Top items are prioritized by

business value

Top items are estimated

PO understands purpose of

all backlog items

Top items in PBL small

enough to fit in a sprint

Estimates written by the

team

Clearly defined product owner

(PO)

PO is empowered to

prioritize

PO has knowledge to

prioritize

PO has direct contact with

team

PO has direct contact with

stakeholders

PO speaks with one voice

(in case PO is a team)

Team members sit together

If you achieve these you can ignore the

rest of the checklist. Your process is fine.

These are central to Scrum. Without these

you probably shouldn’t call it Scrum.

Core Scrum

PO has product vision that is in

sync with PBL

PBL and product vision is highly

visible

Everyone on the team

participates in estimating

PO available when team is

estimating

Team members not locked into

specific roles

Team has all skills needed to

bring backlog items to Done

Team has a Scrum Master (SM)

Whole team knows top 1-3

impediments

SM has strategy for how to

fix top impediment

SM focusing on removing

impediments

Escalated to management

when team can’t solve

Velocity is measured

Velocity only includes

items that are Done

PO uses velocity for

release planning

Team has a sprint burndown

chart

PBL items are broken into tasks

within a sprint

Estimates for ongoing tasks

are updated daily

Highly visible

Updated daily

PO participates at least a

few times per week

All items in sprint plan have

an estimate

SM sits with the team

Daily Scrum is every day, same

time & place

Sprint tasks are estimated

Estimate relative size (story

points) rather than time

Max 15 minutes

Each team member knows

what the others are doing

Most of these will usually be needed, but not always all of them. Experiment!

Recommended but not always necessary

Daily Scrum happens

Whole team participates

Problems & impediments

are surfaced

You have a Chief Product

Owner (if many POs)

Dependent teams do Scrum of

Scrums

Dependent teams integrate

within each sprint

Scaling

Having fun! High energy level.

Overtime work is rare and

happens voluntarily

Discussing, criticizing, and

experimenting with the process

Positive indicators

Scrum Checklist

http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17)

the unofficial

Henrik Kniberg

PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done

Team usually delivers what

they committed to

Leading indicators of a

good Scrum implementation.These are pretty fundamental to any

Scrum scaling effort.

Max 9 people per team

Iterations that are doomed to

fail are terminated early

12

プロセスを継続的に改善している

完了の定義(DoD)を持っている

DoDはイテレーションごとに達成可能なものになっている

チームはDoDを尊重している

最低限のチェック

定期的(4週間以内)に動作する、テスト済みのソフトウェアを提供している

ビジネスニーズに基づいたものを最優先して提供している

毎スプリント終了後にデモを行っている

動作する、テスト済みのソフトウェアを見せている

ステークホルダとプロダクトオーナからフィードバックを得ている

スプリントごとにふりかえりを行えている

結果として具体的な改善提案を行っている

実際に、実現できた提案がある

チームとプロダクトオーナーの全員が参加している

チームはスプリントバックログを持っている

見える化している

毎日更新されている

完全にチームの持ち物である

スプリント計画ミーティングを行っている

プロダクトオーナーが参加している

チーム全員が参加している

結果がスプリント計画に盛り込まれている

チーム全員が計画は達成可能だと考えている

プロダクトオーナーは、優先度を含め満足している

プロダクトオーナーが最新のプロダクトバックログを提示

イテレーションの長さは4週間以内

いつも期限どおりに終了する

チームは部外者に妨害や指図を受けていない

イテレーションをタイムボックス化している

プロダクトオーナーはプロダクトバックログ(PBL)を持っている

上位項目はビジネス価値に基づいて優先度付けされている

上位項目は見積り済みである

プロダクトオーナーがすべての項目の目的を理解している

上位項目は１つのスプリントに収まる規模になっている

見積りはチームが行っている

はっきりと定義されたプロダクトオーナー(PO)

プロダクトオーナーは、優先度付けをする権限をもつ

プロダクトオーナーは、優先度付けをする知識をもつ

プロダクトオーナーは、直接チームと話している

プロダクトオーナーは、直接ステークホルダと話している

プロダクトオーナーは、同じことをいう(複数人いる場合)

チームメンバは同じ場所に机がある

この項目ができていたら、残りのチェックリスト項目は無視していい。あなたのプロセスはうまくいっている。

スクラムの主要要素。これらを抜きにして、スクラムと呼ぶことはできないだろう

コア・スクラム

POはプロダクトバックログと連動するプロダクトビジョンをもつ

プロダクトバックログとプロダクトビジョンを見える化している

チームの全員が見積もりに参加している

チームが見積っている間、プロダクトオーナも待機している

チームメンバは特定の役割に固定されていない

チームは、バックログ項目を完了させるために必要なスキルを全て持つ

チームにスクラムマスター(SM)

がいる

チーム全員が上位3つの障害について認識している

最上位の障害解決について、SMが戦略をもっている

スクラムマスターは、障害を取り除くことに集中している

チームが解決できないときは管理層に報告されている

ベロシティが計測されている

ベロシティは完了した項目だけをカウントしている

POはベロシティを用いてリリース計画を作成している

チームはスプリントバーンダウンチャートを持っている

プロダクトバックログは、1スプリント以内のタスクに分割されている

実行中のタスクの見積りは毎日更新されている

見える化されている

毎日更新されている

最低でも週の何日かはプロダクトオーナが参加している

スプリント計画で、対象の項目が見積りを持っている

スクラムマスターは、チームと同じ場所に机がある

デイリースクラムは、毎日・同じ時間・同じ場所で行っている

スプリントタスクの見積りが行われている

時間ではなく、相対規模(ストーリーポイント) で見積っている

長くても15分まで

各チームメンバは他のメンバが何をしているか知っている

ほとんどの項目は必要になる事が多い、すべて常に必要というわけではない。試してみて!

推奨項目(いつも必要というわけではない)

デイリースクラムを行っている

チームの全員が参加している

問題と障害を表面化できている

チーフプロダクトオーナーがいる (たくさんのPOがいるとき)

所属するチームを集めてスクラムのスクラムを行っている

所属するチームはスプリント内でインテグレーションを行っている

スケーリング

楽しんで! みんな活発に

残業は稀。残業を強制されない

プロセスについて議論、批評、実験を行っている

よい兆候

Scrum Checklist

http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17) 日本語訳 rev.1 (2009-09-01)

the unofficial (非公認)

Henrik Kniberg

PO = プロダクトオーナー SM = スクラムマスター PBL = プロダクトバックログ DoD = 完了の定義

チームは通常、何にコミットするかを明言している

よいスクラムを実施している事を示す先行指標

スクラムの規模を拡大する取り組みのうち、ごく基本的なもの

ひとつのチームは最大でも9

人まで

失敗が避けられないイテレーションを早めに強制終了している

スクラムチェックリスト

13

Kanban in a nutshell

Henrik Kniberg 13

14

Kanban超入門

Henrik Kniberg 14

15

Which team needsmost improvement?

Henrik Kniberg 15

Team 1 Team 2

Todo Doing Donethis week

orem ipsum dolor sit amet, co nse ctetur



orem ipsum dolor sit amet, co nse

ctetur



Avg lead time: days 3






Avg lead time: days

20











Russel Ackoff

Managers who don’t know how tomeasure what they want

settle forwanting what they can measure

16

どっちのチームが改善が必要？

Henrik Kniberg 16

チーム 1 チーム 2






ctetur



平均リードタイム: 日3






平均リードタイム: 日20











Russel Ackoff

欲しいものを、どうやって計測するかを知らないマネージャは、結局計測できるものを欲するように

なる。

17

Kanban @ Imperial Palace Gardens

Henrik Kniberg 17

18

Kanban @ Imperial Palace Gardens

Henrik Kniberg 18

19

Kanban

Signaling system

Visual

Limited in supply

Henrik Kniberg 19

看板”Visual Card”

20

Kanban

通知システム

見える

量の制限

Henrik Kniberg 20

看板”Visual Card”

21

Kanban in your wallet

Henrik Kniberg 21

Darn. Forgot to limit.

22

財布の中のKanban

Henrik Kniberg 22

あ、量の制限を忘れてる！

23

SupplierBuyer

Kanban @ Toyota

Henrik Kniberg 23

ReceiveConsume Detach Ship Allocate Manufacture

Taiichi OhnoFather of theToyota Production System

The tool used to operate the [Toyota Production] system is kanban.

Adapted from Kiro Harada’s slide

24

SupplierBuyer

トヨタのかんばん

Henrik Kniberg 24

ReceiveConsume Detach Ship Allocate Manufacture

大野耐一トヨタ生産方式の父

「トヨタ生産方式」を運用するのにつかわれるツールは、かんばんである

原田騎郎氏のスライドより引用

バイヤーサプライヤ

使用外れ受領出荷引当製造

25

Kanban in SW development

Henrik Kniberg

Backlog Dev Done





ctetur


ctetur

UAT Deploy5 3 2 3

FLOW Avg lead time: days 12




Visualize the workflow

Limit WIP (work in progress)

Measure & optimize flow

Explicit policies (definition of Done, WIP limits, etc)

Pioneered byDavid Andersonin 2004

26

ソフトウェア開発における Kanban

Henrik Kniberg

Backlog Dev Done





ctetur


ctetur

UAT Deploy5 3 2 3

フロー平均リードタイム日12




ワークフローの見える化

仕掛品(WIP: work in progress)の制限

流れの計測と最適化

明示的なポリシー (完了の定義, WIPの制限,他)

David Andersonが2004年に開始

訳注:Kanban は、もちろん「看板・かんばん」に由来しますが、TPS

における「かんばん」と相違が多いため、誤解をさけるため Kanban としています。

27

Kanban exampleBoard shared by 2 teams(16 people in total)

Henrik Kniberg 27

28

Kanban の例ボードは２チームで共有されている(合計１６人)

Henrik Kniberg 28

29

Compare for understanding, not judgement

Henrik Kniberg 29

30

理解をすすめるために比較する。判断するためではない。

Henrik Kniberg 30

31Henrik Kniberg 31

Pair programming

Product Owner role

Physical tools

Process toolsa.k.a. ”organizational patterns”

Thinking toolsa.k.a. ”mindsets” or ”philosophies”

Lean Agile Toolkitsa.k.a. ”frameworks”

Scrum XP

Visualize the workflow

To do Dev Release

H C

2Test

35Done!

3

D

G

K

A

B

FLOW

Kanban

Systems Thinking

Theory of ConstraintsRUP

Tool”anything used as a means of accomplishing a task or purpose.”- dictionary.com

32Henrik Kniberg 32

ペアプロ

プロダクトオーナという役割

物理的なツール

プロセスツールa.k.a. ”組織パターン”

思考ツールa.k.a. ”マインドセット” 、”哲学”

リーンアジャイルツールキットa.k.a. ”フレームワーク”

Scrum XP

見える化

To do Dev Release

H C

2Test

35Done!

3

D

G

K

A

B

FLOW

Kanban

システム思考

制約理論RUP

ツールタスクや目的を達成するために使われる手段であれば何でも- dictionary.com

33

More prescriptive More adaptive

Compare for understanding, not judgement

Henrik Kniberg 33

XP(13)

Scrum(9)

Kanban(3)

Do Whatever(0)

RUP(120+)

• Architecture Reviewer• Business Designer• Business-Model Reviewer• Business-Process Analyst• Capsule Designer• Change Control Manager• Code Reviewer• Configuration Manager• Course Developer• Database Designer• Deployment Manager

• Design Reviewer• Designer• Graphic Artist• Implementer• Integrator• Process Engineer• Project Manager• Project Reviewer• Requirements Reviewer• Requirements Specifier• Software Architect• Stakeholder• System Administrator• System Analyst• Technical Writer• Test Analyst• Test Designer• Test Manager• Tester• Tool Specialist• User-Interface Designer• Architectural analysis

• Assess Viability of architectural proof-of-concept

• Capsule design• Class design• Construct architectural proof-of-

concept• Database design• Describe distribution• Describe the run-time architecture• Design test packages and classes• Develop design guidelines• Develop programming guidelines• Identify design elements• Identify design mechanisms• Incorporate design elements• Prioritize use cases• Review the architecture• Review the design• Structure the implementation

model• Subsystem design• Use-case analysis

• Use-case design• Analysis model• Architectural proof-of-concept• Bill of materials• Business architecture document• Business case• Business glossary• Business modeling guidelines• Business object model• Business rules• Business use case

• Whole team

• Coding standard• TDD• Collective ownership• Customer tests• Pair programming• Refactoring• Planning game• Continuous integration• Simple design• Sustainable pace• Metaphor• Small releases

• Scrum Master

• Product Owner• Team• Sprint planning meeting• Daily Scrum• Sprint review• Product backlogt• Sprint backlog• BUrndown chart

• Visualize the workflow

• Limit WIP• Measure and optimize lead time

Miyamoto Musashi17th century samurai

Do not develop an attachmentto any one weaponor any one school of fighting

• Business use case realization• Business use-case model• Business vision• Change request• Configuration audit findings• Configuration management plan• Data model• Deployment model• Deployment plan• Design guidelines• Design model

• Development case• Development-organization

assessment• End-user support mateirla• Glossary• Implementation model• Installation artifacts• Integration build plan• Issues list• Iteration assessment• Iteration plan• Manual styleguide• Programming guidelines• Quality assurance plan• Reference architecture• Release notes• Requirements attributes• Requirements

management plan• Review record• Risk list• Risk management plan

• Software architecturedocument

• Software developmentplan

• Software requirements specification

• Stakeholder requests• Status assessment• Supplementary business

specification• Supplementary specification• Target organization assessment• Test automation architecture• Test cases• Test environment configuration• Test evaluation summary• Test guidelines• Test ideas list• Test interface specification• Test plan• Test suite• Tool guidelines

• Training materials• Use case model• Use case package• Use-case modeling guidelines• Use-case realization• Use-case storyboard• User-interface guidelines• User-interface prototype• Vision• Work order• Workload analysis model

34

より記述的より適応的

判断のためでなく、理解のための比較

Henrik Kniberg 34

XP(13)

Scrum(9)

Kanban(3)

なんでもいい(0)

RUP(120+)

• Architecture Reviewer• Business Designer• Business-Model Reviewer• Business-Process Analyst• Capsule Designer• Change Control Manager• Code Reviewer• Configuration Manager• Course Developer• Database Designer• Deployment Manager

• Design Reviewer• Designer• Graphic Artist• Implementer• Integrator• Process Engineer• Project Manager• Project Reviewer• Requirements Reviewer• Requirements Specifier• Software Architect• Stakeholder• System Administrator• System Analyst• Technical Writer• Test Analyst• Test Designer• Test Manager• Tester• Tool Specialist• User-Interface Designer• Architectural analysis

• Assess Viability of architectural proof-of-concept

• Capsule design• Class design• Construct architectural proof-of-

concept• Database design• Describe distribution• Describe the run-time architecture• Design test packages and classes• Develop design guidelines• Develop programming guidelines• Identify design elements• Identify design mechanisms• Incorporate design elements• Prioritize use cases• Review the architecture• Review the design• Structure the implementation

model• Subsystem design• Use-case analysis

• Use-case design• Analysis model• Architectural proof-of-concept• Bill of materials• Business architecture document• Business case• Business glossary• Business modeling guidelines• Business object model• Business rules• Business use case

• Whole team

• Coding standard• TDD• Collective ownership• Customer tests• Pair programming• Refactoring• Planning game• Continuous integration• Simple design• Sustainable pace• Metaphor• Small releases

• Scrum Master

• Product Owner• Team• Sprint planning meeting• Daily Scrum• Sprint review• Product backlogt• Sprint backlog• BUrndown chart

• Visualize the workflow

• Limit WIP• Measure and optimize lead time

宮本武蔵17th century samurai

武器や流儀にこだわらない

• Business use case realization• Business use-case model• Business vision• Change request• Configuration audit findings• Configuration management plan• Data model• Deployment model• Deployment plan• Design guidelines• Design model

• Development case• Development-organization

assessment• End-user support mateirla• Glossary• Implementation model• Installation artifacts• Integration build plan• Issues list• Iteration assessment• Iteration plan• Manual styleguide• Programming guidelines• Quality assurance plan• Reference architecture• Release notes• Requirements attributes• Requirements

management plan• Review record• Risk list• Risk management plan

• Software architecturedocument

• Software developmentplan

• Software requirements specification

• Stakeholder requests• Status assessment• Supplementary business

specification• Supplementary specification• Target organization assessment• Test automation architecture• Test cases• Test environment configuration• Test evaluation summary• Test guidelines• Test ideas list• Test interface specification• Test plan• Test suite• Tool guidelines

• Training materials• Use case model• Use case package• Use-case modeling guidelines• Use-case realization• Use-case storyboard• User-interface guidelines• User-interface prototype• Vision• Work order• Workload analysis model

35

Lean & Agile process toolkits

Henrik Kniberg 35

Kanban

Scrum

XP

Values & PrinciplesLean, Agile, Theory of Constraints, Systems Thinking, etc

Other lean tools(Value Stream Mapping, Root Cause Analysis, etc)

36

リーンとアジャイルのプロセスツールキット

Henrik Kniberg 36

Kanban

Scrum

XP

価値と原則リーン、アジャイル、制約理論、システム思考、他

他のリーンツール(バリューストリームマッピング, 原因分析, 他)

37Henrik Kniberg

37

Any tool can be misused

The old toolwas better!

Don’t blamethe tool!

38Henrik Kniberg

38

どんなツールの間違った使い方ができる

昔のツールがよかった

ツールを責めない!

39

Why limit WIP? (work in progress)Henrik Kniberg 39

40

なぜWIPを制限するか? (WIP: 仕掛品)

Henrik Kniberg 40

41

準備

Henrik Kniberg 41

Dave

Lisa

Bob

Eric

Maria

1 開発者

4 – 6人の顧客

Multitasking name game

42

Round 1: Ordering process

Henrik Kniberg 42

JEFF

JEFF28

1

2

3


Developer Customer Jeff

Log delivery time

Deliver

Order

43

ラウンド 1: 注文プロセス

Henrik Kniberg 43

JEFF

JEFF28

1

2

3


開発者顧客 Jeff

納入時間を計測

納品

注文

44

Round 1: Development process

Henrik Kniberg 44

D A V E

L IS

B O B

E R I

M A R

Never keep acustomer waiting

Start early= Finish early

Policy Dave

Lisa

Bob

Eric

Maria


28

45

ラウンド 1: 開発プロセス

Henrik Kniberg 45

D A V E

L IS

B O B

E R I

M A R

顧客を待たせない

早く始める= 早く終わる

ポリシー Dave

Lisa

Bob

Eric

Maria


28

46

Round 2 – Development process

Henrik Kniberg 46

D A V E

L ISLimit WIP(work in process)

Current limit =1 customerat a time

Policy Dave

Lisa

Bob

Eric

Maria

A


47

ラウンド 2 – 開発プロセス

Henrik Kniberg 47

D A V E

L ISWIPを制限(WIP: 仕掛品)

現在のリミット=顧客対応は、一人づつ

Policy Dave

Lisa

Bob

Eric

Maria

A


48

Round 2: Ordering process

Henrik Kniberg 48

1

2

3


Developer Customer Jeff

Log delivery timeCalc project length

Deliver product

Log start timeSubmit order

5

5JEFF

5JEFF

15

10

0

Request order

49

ラウンド 2: 注文プロセス

Henrik Kniberg 49

1

2

3


開発者顧客 Jeff

納入時刻を記録かかった時間を計算

製品の納品

開始時刻を記録発注

5

5JEFF

5JEFF

15

10

0

発注

50

Typical results

Henrik Kniberg 50


51

よくある結果

Henrik Kniberg 51


52Henrik Kniberg 52

Focusing on starting stuff rather than finishing

Not limiting WIP

Focusing on keep people busy (fear of slack)

Accepting the “reason” & solving the symptom instead of the problem

Bail water

Water in boat

Hole in boat

Fix hole

Causes of unnecessary multitasking

53Henrik Kniberg 53

開始することに集中して、終了を意識しない

WIPを制限しない

人を忙しくしておくことに集中する(ゆとり時間を恐れる)

症状を直すことと“理由”を受け入れて、問題を気にしない。

水をかき出す

浸水

ボートに穴

穴を直す

不必要なマルチタスクの原因

54

Kanban & ScrumReal-life exampleHenrik Kniberg 54

55

Kanban & Scrum実例

Henrik Kniberg 55

56

Case study

SamConcept

pres.

Lisa assigns

resources

Graphics design

Sound design

DevIntegr. & deploy

2d 1m4h

6m

8

Game backlog

1w 6m 6m

15

Design-ready games

12

Production-ready games

1m 3w 3m(1m+2m)

3w2h 1d

3 m value added time

25 m cycle time= 12%

Process cycle efficiency

57

ケーススタディ

Samコンセプト作

成

Lisa がリソース割り当て

グラフィックデザイン

サウンドデザイン

開発統合 & 配

布

2d 1m4h

6m

8

ゲームバックログ

1w 6m 6m

15

デザイン完了ゲーム

12

製造可能ゲーム

1m 3w 3m(1m+2m)

3w2h 1d

付加価値作業 3分

サイクルタイム 25分= 12%

プロセスサイクル効率

58

Limit work to capacity

Henrik Kniberg 58

Input: 3 customers / hour Output capacity: 2 customers / hour

59

仕事の量を能力容量に合わせる

Henrik Kniberg 59

入力: 3 顧客 / 時出力容量: 2 顧客 / 時

60

Case study

Henrik Kniberg 60

SamConcept

pres.

Lisa assigns

resources

Graphics design

Sound design

DevIntegr. & deploy

2d 1m4h

6m

8

Game backlog

1w 6m 6m

15

Design-ready games

12

Production-ready games

1m 3w 3m(1m+2m)

3w2h 1d

Cross-functional game team

3-4 m cycle time = 6-8x faster

Game team(graphics, sound, dev, integrate)

3-4 months




61

Case study

Henrik Kniberg 61

2d 1m4h

6m

8

1w 6m 6m

15 12

1m 3w 3m(1m+2m)

3w2h 1d

機能横断ゲームチームCross-functional game team

サイクルタイム3～4分= 6～8倍速い

ゲームチーム(グラフィック, サウンド, 開発, 統合)

3～4 か月

Samコンセプト作

成

Lisa がリソース割り当て

グラフィックデザイン

サウンドデザイン

開発統合 & 配

布

ゲームバックログデザイン完了ゲーム製造可能ゲーム




64

Operations / support team

Typical evolution to Scrum/Kanban combo

Henrik Kniberg 64

Featureteam 1

Featureteam 2

Featureteam 2

Featureteam 1

Featureteam 2

Featureteam 2

Scrum Scrum Scrum Scrum Scrum Scrum

Scrum

Operations / support team

Featureteam 1

Featureteam 2

Featureteam 2

Scrum Scrum Scrum

Kanban

Scrum step 1 Scrum step 2 Scrum + Kanban

65

運用サポートチーム

Scrum/Kanban 組み合わせのよくある改善例

Henrik Kniberg 65

Featureteam 1

Featureteam 2

Featureteam 2

Featureteam 1

Featureteam 2

Featureteam 2

Scrum Scrum Scrum Scrum Scrum Scrum

Scrum

運用サポートチーム

Featureteam 1

Featureteam 2

Featureteam 2

Scrum Scrum Scrum

Kanban

Scrum ステップ 1 Scrum ステップ 2 Scrum + Kanban

66

One day in Kanban land

Henrik Kniberg 66

67

Kanban チームの一日

Henrik Kniberg 67

68

”One day in Kanban land”

Henrik Kniberg 68

http://blog.crisp.se/henrikkniberg/tags/kanban/

http://blog.crisp.se/henrikkniberg/tags/kanban/

69

NextDev

Done

Backlog 32

In production :o)

Ongoing

シナリオ 1 – 一個流し

Henrik Kniberg 69

B

C

A

D

E

F

G

H I

J L

KM

70

NextDev

Done

Backlog 32

In production :o)

Ongoing


Henrik Kniberg 70

BC

A

D

E

F

G

H I

J L

KM

71

NextDev

Done

Backlog 32

In production :o)

Ongoing


Henrik Kniberg 71

BC

A

D

E

F

G

H I

J L

KM

72

NextDev

Done

Backlog 32

In production :o)

Ongoing

Scenario 1 – one piece flow

Henrik Kniberg 72

B

C A

D

E

F

G

H I

J L

KM

73

NextDev

Done

Backlog 32

In production :o)

Ongoing


Henrik Kniberg 73

B

C A

D

E

F

G

H I

J L

KM

74

NextDev

Done

Backlog 32

In production :o)

Ongoing

シナリオ 2 – 開発での問題

Henrik Kniberg 74

B

C

A

D

E

F

G

H I

J L

KM

PO

75

NextDev

Done

Backlog 32

In production :o)

Ongoing


Henrik Kniberg 75

BC

A

D

E

F

G

H I

J L

KM

PO

76

NextDev

Done

Backlog 32

In production :o)

Ongoing


Henrik Kniberg 76

B

C A

D

E

F

G

H I

J L

KM

PO

77

NextDev

Done

Backlog 32

In production :o)

Ongoing


Henrik Kniberg 77

B

C A

D

E

F

G

H I

J L

KM

PO

78

NextDev

Done

Backlog 32

In production :o)

Ongoing


Henrik Kniberg 78

B

C A

D

F

G

H I

J L

KM

!?

E

PO

79

NexetDev

Done

Backlog 32

In production :o)

Ongoing


Henrik Kniberg 79

B

C

A

D

EF

G

H I

J L

KM

!?

PO

80

NextDev

Done

Backlog 32

In production :o)

Ongoing

Scenario 2 – Deployment problem

Henrik Kniberg 80

B

C

A

D

EF

G

H I

J L

KM

PO

81

NextDev

Done

Backlog 32

In production :o)

Ongoing


Henrik Kniberg 81

B

A

D

EF

G

H I

J L

KM

C

PO

82

NextDev

Done

Backlog 32

In production :o)

Ongoing


Henrik Kniberg 82

B

AD

EF

G

H I

J L

KM

C

PO

83

Evolve your process

Henrik Kniberg 83

84

プロセスを進化させる

Henrik Kniberg 84

85

Kanban & Scrum are empirical

Henrik Kniberg 85

Many small teams Few large teams

Low WIP limits High WIP limits

Few workflow states Many workflow states

No iterations Long iterations

Little planning Lots of planning

Capacity(aka velocity)

Lead time(aka cycle time)

.... etc ... .... etc ...

Quality(defect rate, etc)

Predictability(SLA fulfillment, etc)

Kanban is more configurable

Great! More options! Oh no, more decisions!

86

Kanban & Scrum は経験的手法である

Henrik Kniberg 86

多数の小チーム少数の大チーム

WIP 制限小 WIP 制限大

ワークフロー状態少ワークフロー状態多

イテレーション無長いイテレーション

最小限の計画綿密な計画

容量(aka ベロシティ)

リードタイム(aka サイクルタイム)

.... etc ... .... etc ...

品質(バグ率, etc)

予測可能性(SLA 満足率, etc)

Kanban is more configurable

すばらしい!選択肢が広い!

まいるなぁそんな沢山決めることが!

2009-08-29

orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl

2009-09-01

orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl

Analysis Development Acceptance ProdNext

Definition of Done:• Customer accepted• Ready for production

Ongoing Done

Definition of Done:• Code clean & checked in on trunk• Integrated & regression tested• Running on UAT environment

Ongoing DoneOngoing Done

Definition of Done:• Goal is clear• First tasks defined• Story split (if necessary)

2 3 3 2

Feature / story

= completed

= blocked

= who is doing this right now

2009-08-20 2009-09-30

(description)

• Panicfeatures(should be swarmed and kept moving. Interrupt other work and break WIP limits as necessary)

• Priority features• Hard deadline features

(only if deadline is at risk)

• Oldest features

2009-09-02


2009-08-27

orem ipsum dolor sit amet, adi pis cing elit nisl

2009-08-20

orem olor sit amet, co nse ctetur adi pis cing elit nisl

2009-08-30

orem ipsum dolor sit amet, co adi pis cing elit nisl

2009-09-08

2009-08-25

orem ipsum dolor sit ctetur adi pis cing elit nisl

Task / defectHard deadline(if applicable)Date when added

to board









(description)

(description)

(description)Why

(description)

Who is analyzing / testing right now

= priority

= panic

What to pull first

xxxx kjd dj d xxx

Kanban kick-start exampleHenrik Kniberg www.crisp.se/kanban/example

version 1.22009-11-16

(description)


=task =defect

2009-08-29

orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl

2009-09-01

orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl

分析開発受入本番次

完了の定義:•顧客の受入合意•本番移行可能

実施中完了

完了の定義:•きれいなコードをtrunkにチェックイン•統合テスト、回帰テストに合格•受入テスト環境で動作

実施中完了実施中完了

完了の定義:•ゴールが明確•初期タスクが定義済み•ストーリー分割(必要なら)

2 3 3 2

フィーチャー / ストーリー

= 完了

= 開始できない

= 現在作業中の担当者

2009-08-20 2009-09-30

(description)

• パニック(みんなで集まって、とにかく片づける。必要とあらば他のタスクを止めたり、WIP制限を破ってもよい)

• 優先• 最終納期があるもの

(納期内完了にリスクがある場合)

• もっとも古いもの

2009-09-02


2009-08-27

orem ipsum dolor sit amet, adi pis cing elit nisl

2009-08-20

orem olor sit amet, co nse ctetur adi pis cing elit nisl

2009-08-30

orem ipsum dolor sit amet, co adi pis cing elit nisl

2009-09-08

2009-08-25

orem ipsum dolor sit ctetur adi pis cing elit nisl

タスク / 障害

最終納期(オプション)

ボードに張られた日









(description)

(description)

(description)Why

(description)

現在作業中の担当者

= 優先

= パニック

どれから手をつけるか

xxxx kjd dj d xxx

Kanban kick-start exampleHenrik Kniberg www.crisp.se/kanban/example

version 1.22009-11-16

(description)


=タスク =障害

89

Kanban evolution example

89

April 7

April 23

Henrik Kniberg

90

Kanban ボードの進化の例

90

４月７日

４月２３日

Henrik Kniberg

91

Optimizing the WIP limit

Henrik Kniberg 9191

To do Doing Done

orem ipsum dolor

sit amet, co nse ctetur

1

Too low WIP limit

To do Doing Done


2

Just Right WIP limit

To do Doing Done


5

Too high WIP limit


Zzzzzzzzz

orem ipsum dolor



orem ipsum dolor


orem ipsum dolor


orem ipsum dolor sit amet, co nse cteturPeople

often idle

Slow flow (end-to-end)

People sometimes idle

(slack)

Fast flowTasks

rarely idle

Slow flow

Tasks often idleLack of wall

space...

People never idle

92

WIP 制限の最適化

Henrik Kniberg 9292

To do Doing Done

orem ipsum dolor


1

WIP 制限が低すぎる

To do Doing Done


2

WIP 制限がちょうど良い

To do Doing Done


5

WIP 制限が高すぎる


Zzzzzzzzz

orem ipsum dolor



orem ipsum dolor


orem ipsum dolor


orem ipsum dolor sit amet, co nse ctetur手待ちの

人が沢山

流れが遅い(全体で)

人はときどき手待ちになる

(ゆとり)

速い流れ待ちタスクは少ない

遅い流れ

待ちタスクが沢山壁のスペース

が足りない...

人は手待ちにならない

93

Evolve your own unique board!

Henrik Kniberg 93

Some of these photos courtesy ofDavid Anderson, Mattias Skarin,and various other people

94

自分のKanbanボードに進化

Henrik Kniberg 94

写真は、David Anderson、 Mattias Skarin、ほか多くの人から提供いただきました。

95

Kanban compared to Scrum

Henrik Kniberg 95

96

KanbanScrum と比べてみる

Henrik Kniberg 96

97

Scrum prescribes roles, Kanban doesn’t

Henrik Kniberg 97

PO

SM

Product owner

Team Scrum Master

98

Scrum は役割を指定する, Kanban はしない

Henrik Kniberg 98

PO

SM

プロダクトオーナ

チームスクラムマスタ

99

Scrum prescribes timeboxed iterationsScrum team

Henrik Kniberg

week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

Sprint 1

Plan & commit Review(release?)

Kanban team 1

Kanban team 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

Planning cadence (2w)

Sprint 2

Retrospective

Release cadence (1w)

Retrospectives (4w)

Kanban team 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

Planning (on demand)

Release (on demand)

Retrospectives (4w)

100

Scrum は、タイムボックス固定のイテレーションを指定Scrum チーム

Henrik Kniberg

week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

スプリント 1

計画 & コミットレビュー(リリース?)

Kanban チーム 1

Kanban チーム 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

計画ケイデンス(2w)

スプリント 2

振り返り

リリースケイデンス(1w)

振り返り(4w)

Kanban チーム 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

計画(オンデマンド)

リリース (オンデマンド

振り返り(4w)

101

Scrum backlog items must fit in a sprint

Henrik Kniberg 101

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Long running task

Long running task

Scrum

Kanban

WIP limit = 3

102

Scrum のバックログ項目は、１スプリントに収まる必要がある。

Henrik Kniberg 102

Sprint 1 Sprint 2 Sprint 3 Sprint 4

長いタスク

長いタスク

Scrum

Kanban

WIP 制限 = 3

103

Both limit WIP, but in different ways

Henrik Kniberg 103

To do Ongoing Done :o)

B

C

A

D

FLOW


B

C

A

D

FLOW

2

Scrum board Kanban board

WIP limited per unit of time

(iteration)

WIP limited per workflow state

104

両方とも WIPを制限する。方法は異なる。

Henrik Kniberg 104


B

C

A

D

フロー


B

C

A

D

フロー

2

Scrum ボード Kanban ボード

単位時間(イテレーション)の間のWIP 制限

ワークフロー状態ごとのWIP制限

105

Scrum discourages changein mid-iteration

Henrik Kniberg 105


B

C A

D

FLOW


B

C A

D

FLOW

2

Scrum Kanban

2

PO

I’d like to have E!

Wait until next sprint!

Wait until a To Do slot becomes available!Or swap out C or D!

Policies

106

Scrum は、イテレーション途中の変更を避ける

Henrik Kniberg 106


B

C A

D

フロー


B

C A

D

フロー

2

Scrum Kanban

2

PO

I’d like to have E!

次のイテレーションを待って

ToDo が空くまで待って。それとも C か D

をやめる？

ポリシー

107

Scrum board is reset between each iteration

Henrik Kniberg 107

ScrumFirst day of sprint Mid-sprint Last day of sprint

KanbanAny day

108

Scrum ボードは、イテレーションごとにリセット

Henrik Kniberg 108

Scrumスプリント初日中盤スプリント最終日

Kanbanいつでも

109

Scrum prescribes cross-functional teamsKanban supports both specialists & generalists

Henrik Kniberg 109

Backlog Design


Fold Tape






Trim Draw

3 2 2 1 4 3



Scrum team

Cross-functionalteam

Kanban team 1

Kanban team 2

110

Scrum は、機能横断チームを指定Kanban は、専門家チームも、総務チームもサポート

Henrik Kniberg 110

Backlog Design


Fold Tape






Trim Draw

3 2 2 1 4 3



Scrum チーム

機能横断チーム

Kanban チーム 1

Kanban チーム 2

111

Scrum prescribes estimation and velocity

Henrik Kniberg 111

Sprint 1 Sprint 2 Sprint 3

Likely velocity: 8 per sprint(sustainable pace?)

2

2 3

1 2

31 1 2 2 1

1 1 2

V= 8 V= 7 V= 9

112

Scrum は、見積りとベロシティの利用を指定

Henrik Kniberg 112

スプリント1 スプリント2 スプリント3

想定ベロシティ: 8 / スプリント(持続可能なペース?)

2

2 3

1 2

31 1 2 2 1

1 1 2

V= 8 V= 7 V= 9

113

Estimation is flexible in both Kanban & Scrum

TasksFeatures

Henrik Kniberg 113

1. Don’t estimate features. Just count them.

2. Estimate features in t-shirt size

1. Skip tasks

2. Don’t estimate tasks. Just count them.

3. Estimate tasks in days

1d2d0.5d

4. Estimate tasks in hours

12h8h4h

S M LHours?

Days?

Weeks?

S M

L

3. Estimate features in story points

1sp 2sp5sp

4. Estimate features in ideal man-days

1d 3d6d

”Typical”Kanban

”Typical”Scrum

114

Scrum でも Kanban でも、見積は柔軟なもの

タスクフィーチャー

Henrik Kniberg 114

1. フィーチャーを見積もらない。数える。

2. フィーチャーをTシャツのサイズで見積もる

1. タスクをスキップする。

2. タスクを見積もらない。数える。

3. タスクを日数で見積もる

1d2d0.5d

4. タスクを時間で見積もる

12h8h4h

S M LHours?

Days?

Weeks?

S M

L

3. フィーチャーをストーリーポイントで見積もる

1sp 2sp5sp

4. フィーチャーを理想人日で見積もる

1d 3d6d

”普通の”Kanban

”普通の”Scrum

115

Both allow working on multiple products simultaneously (if you must…)

Henrik Kniberg 115

Green ProductGreen team

Yellow ProductYellow team

All products Cross-product team Cross-product team

Scrum example 1

Scrum example 2 Scrum example 3

All products

Kanban example 1

Kanban example 2

Color-coded tasks

Color-coded swimlanes

116

複数の製品を同時に扱うのは、どちらもで可能(どうしても必要ならね…)

Henrik Kniberg 116

Green 製品Green チーム

Yellow 製品Yellow チーム

全製品製品横断チーム製品横断チーム

Scrum 例 1

Scrum 例 2 Scrum 例 3

全製品

Kanban 例 1

Kanban 例 2

色分けタスク

色分けレーン

117

Minor differences

Henrik Kniberg 117

118

小さな違い

Henrik Kniberg 118

119

Minor difference:Scrum prescribes daily meetings

Henrik Kniberg 119

... but many Kanban teams do that anyway.

120

小さな違い:Scrum は、毎日のミーティングを指定している

Henrik Kniberg 120

... まあ、Kanban チームも多くはやってます

121

Minor difference:Scrum prescribes a prioritized product backlog

Scrum:

Product backlog must exist

Changes to product backlog take effect next sprint (not current sprint)

Product backlog must be sorted by “business value”

Henrik Kniberg 121

Kanban:

Product backlog is optional

Changes to product backlog take effect as soon as capacity becomes available

Any prioritization scheme can be used. For example:

Take any item

Always take the top item

Always take the oldest item

20% on maintainance items,80% on new features

Split capacity evenly between product A and product B

Always take red items first

Policies

122

小さな違い:Scrum は、優先度付けされたプロダクトバックログを指定してます

Scrum:

プロダクトバックログが必須

プロダクトバックログに対する変更は、次のスプリントで反映される (今のスプリントではない)

プロダクトバックログは、「ビジネス価値」順に並べる必要がある

Henrik Kniberg 122

Kanban:

プロダクトバックログは任意

プロダクトバックログに対する変更は、能力が空いた時点で反映される

優先度付けの方法は任意。例えば:

好きなものを選んでよい

一番上を常に選ぶ

一番古いものを常に選ぶ

20% は保守項目を、80% 新規フィーチャー開発を選ぶ

能力量を製品Aと製品Bで等分する

赤いものを常に選ぶ

ポリシー

123Henrik Kniberg 123

Backlog Dev Test

orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor





Day 4

Prod

Burndown

10

20

30

40506070

1 2 3 4 5 8 9 10 11 12 15 16 17 18 19August

Est imated work

remaining

Date

Common alternative in Kanban:

Cumulative flow diagram

Minor difference:In Scrum, burndown charts are prescribed

124Henrik Kniberg 124

Backlog Dev Test

orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor





Day 4

Prod

Burndown

10

20

30

40506070

1 2 3 4 5 8 9 10 11 12 15 16 17 18 19August

Est imated work

remaining

Date

Kanban で利用される代替:

累計流動数グラフ

小さな違い:Scrumでは、バーンダウンチャートの使用が指定

リードタイム６日

WIP9項目

125

Final points

Henrik Kniberg 125

126

まとめ

Henrik Kniberg 126

127

Kanban & ScrumComparison summary

Both are Lean and Agile

Both based on pull scheduling

Both limit WIP

Both use transparency to drive process improvement

Both focus on delivering releasable software early and often

Both are based on self-organizing teams

Both require breaking the work into pieces

In both cases the release plan is continuously optimized based on empirical data (velocity / lead time)

Henrik Kniberg 127

Scrum Kanban

Timeboxed iterations prescribed. Timeboxed iterations optional.

Team commits to a specific amount

of work for this iteration.

Commitment optional.

Uses Velocity as default metric for

planning and process improvement.

Uses Lead time as default metric for

planning and process improvement.

Cross-functional teams

prescribed.

Cross-functional teams optional.

Specialist teams allowed.

Items broken down so they can be

completed within 1 sprint.

No particular item size is prescribed.

Burndown chart prescribed No particular type of diagram is

prescribed

WIP limited indirectly (per sprint) WIP limited directly (per workflow

state)

Estimation prescribed Estimation optional

Cannot add items to ongoing

iteration.

Can add new items whenever

capacity is available

A sprint backlog is owned by one

specific team

A kanban board may be shared

by multiple teams or individuals

Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles

A Scrum board is reset between

each sprint

A kanban board is persistent

Prescribes a prioritized product

backlog

Prioritization is optional.

Differences

http://www.infoq.com/minibooks/kanban-scrum-minibook

Similarities

128

Kanban & Scrum比較のまとめ

リーンで、アジャイル

プルによるスケジューリングに基づく

WIP を制限する

プロセス改善を促進するために、透明性を活用する

早期かつ頻繁な使えるソフトウェアの提供に重点をおく

自己組織化したチームに基づく

ワークを部分に分割する

リリース計画は、経験データにもとづき絶えず改善され続ける(ベロシティ/リードタイム)

Henrik Kniberg 128

Scrum Kanban

タイムボックスを固定したイテレー

ションを指定

タイムボックス固定イテレーション

の選択は任意

イテレーションの中での作業量を、

チームがコミットする

コミットメントは任意

計画やプロセス改善に使う基本の指

標は、ベロシティ

計画やプロセス改善に使う基本の指

標は、リードタイム

機能横断チームが指定機能横断チームは任意

専門家チームも可能

1スプリント内で完了するように、項

目は分割される

項目のサイズに制限はない

バーンダウンチャートが指定特に指定のダイアグラムはない

間接的にWIPを制限 (スプリントあ

たり)

直接的にWIPを制限 (ワークフロー

の状態ごとに)

見積もりは必須見積もりは任意

実施中にイテレーションに項目は足

せない

容量があるならいつでも項目を足せ

る

スプリントバックログは、特定の１

チームが保有

Kanban ボードは、複数のチームや個

人で共有することもできる

役割を３つ指定 (PO/SM/Team) 役割を指定していない

Scrum ボードは、スプリントごとに

リセットされる

Kanban ボードはずっと使われる

優先度付きのプロダクトバックログ

を指定

優先度付けは任意

相違点

http://www.infoq.com/minibooks/kanban-scrum-minibook

類似点

129

Free downloadhttp://www.infoq.com/minibooks/kanban-scrum-minibook

Henrik Kniberg 129

130

フリーダウンロードhttp://www.infoq.com/minibooks/kanban-scrum-minibook

Henrik Kniberg 130

131

Don’t be dogmatic

Henrik Kniberg 131

Go away! Don’t talk to us!We’re in a Sprint.

Come backin 3 weeks.

Though ShaltLimit WIP

132

教条主義に陥らない

Henrik Kniberg 132

立ち去れ。話しかけるな。スプリント中だ。

三週間後に来たまえ

汝、WIP制限を守り給え

133

Essential skills neededregardless of process

Henrik Kniberg 133

Software craftsmanship

Splitting the system into useful pieces

Retrospectives

As a buyerI want to save my shopping cartso that I can continue shopping later

134

必須なスキルプロセスによらず

Henrik Kniberg 134

ソフトウェア職人芸

システムを利用可能な単位に分割する

振り返り

As a buyerI want to save my shopping cartso that I can continue shopping later

135

Take-away points

Henrik Kniberg 135

1. Know your goal

Hint: Agile/Lean/Kanban/Scrum isn’t it.

2. Never blame the tool

Tools don’t fail or succeed. People do.

There is no such thing as a good or bad tool. Only good or bad decisions about when, where, how, and why to use which tool.

3. Don’t limit yourself to one tool

Broaden yourself

Compare for understanding, not judgement.

4. Experiment & enjoy the ride

Don’t worry about getting it right from start – you won’t

The important thing is not your process.The important thing is your process for improving your process

136

お持ち帰り用のポイント

Henrik Kniberg 136

1. ゴールを知ること

ヒント: Agile/Lean/Kanban/Scrumはゴールではない。

2. ツールを非難しないこと

ツールが成功したり、失敗したりはしない。するのは、人。

ツールに良い悪いもない。ツールを使う時、場所、方法、目的、選び方などに、よい判断と悪い判断があるだけだ。

3. 一つのツールにこだわるな

自分自身を広げること

判断のためでなく、理解のために比較する

4. 実験して、ライドを楽しもう

はじめから正しくやろうと心配しすぎない。どうせできない。

大事なのはプロセスではない。大事なのは、プロセスを改善しようとするプロセスである。

137

Perfection is a direction, not a place

Henrik Kniberg

138

完璧とは方向のことであって、場所ではない。

Henrik Kniberg

scrum & kanban

Technology

d failingtest125

d migration

d test1d

d tolo tapes

ntoch cke oe d ut d

se ch cke o e d ut d

scrum henrik kniberg

henrik kniberg agilelean