1. Copyright notice
These slides are licensed under Creative
Kanban and Scrum
Commons. Feel free to use these slides &
pictures as you wish, as long as you leave
my name and the Crisp logo somewhere.
Making the most of both For licensing details see:
http://creativecommons.org/licenses/by/3.
0/
Agile 2010, Orlando All slides available at:
August 12, 2010 http://www.crisp.se/henrik.kniberg/
Henrik Kniberg
Agile/Lean coach
www.crisp.se
Board of
directors
henrik.kniberg@crisp.se
+46 70 4925284
2. Copyright notice
These slides are licensed under Creative
Kanban と Scrum
Commons. Feel free to use these slides &
pictures as you wish, as long as you leave
my name and the Crisp logo somewhere.
翻訳ドラフト版
2010/8/30
両者を最大限に活用する For licensing details see:
http://creativecommons.org/licenses/by/3.
0/
Agile 2010, Orlando All slides available at:
K. Harada
harada@isken.co.jp August 12, 2010 http://www.crisp.se/henrik.kniberg/
Henrik Kniberg
Agile/Lean coach
www.crisp.se
Board of
directors
henrik.kniberg@crisp.se
+46 70 4925284
3. Purpose of this presentation
To clarify Kanban and Scrum by comparing them
...so you can figure out
how these may come to use
in your context.
Henrik Kniberg 3
9. Split your organization
Scrum in a nutshell
Split your product
Large group spending a long time building a huge thing
Small team spending a little time building a small thing
... but integrating regularly to see the whole
Optimize process
Optimize business value
$$$
Split time
January April
$
Nt
o
ch cke o
e d ut D ne :o
o ! ) S R T G A B t a a re a !
P IN OL: e -re dy le se
ch cke o
e d ut
D p sit
Write
eo failing
test Burndown
2d
DAO
Code Integr
p DB
cleanu test
2d 0.5d design
1d 2d
1d
GUI Write
igra n
M t io spec
2d
failing
2d test
1d 3d
tol
o Tapes
try
spike
Impl. 1d
2d
migration
8d
a ffice
Bcko Write
failing
test
Login
Integr.
Impl
GUI
2d
U la d it e s
np nne m N xt
e
1d
with
JBoss
2d
P it ht e w
W dra
Fix memo
Write
Write
leak
(JIRA
ry
Sales support e st
W rfdra
it h w
Bcko
a ffice failing
test
3d
2d
failing
test
125)
3d Write
U r a in
se dm whitepaper
4d
GUI Clarify
design Impl
require-
(CSS) ments GUI
1d 2d 6d
Henrik Kniberg 9
10. 組織を分割
Scrum 超入門
製品を分割
大きなグループが長い時間をかけて、巨大なものを作る
小さなグループが短い時間に、小さなものを作る
ただし、しょっちゅう統合して、全体を見る
プロセスを最適化
ビジネス価値を最適化
$$$
時間を分割
１月 ４月
$
Nt
o
ch cke o
e d ut D ne :o
o ! ) S R T G A B t a a re a !
P IN OL: e -re dy le se
ch cke o
e d ut
D p sit
Write
eo failing
test Burndown
2d
DAO
Code Integr
p DB
cleanu test
2d 0.5d design
1d 2d
1d
GUI Write
igra n
M t io spec
2d
failing
2d test
1d 3d
tol
o Tapes
try
spike
Impl. 1d
2d
migration
8d
a ffice
Bcko Write
failing
test
Login
Integr.
Impl
GUI
2d
U la d it e s
np nne m N xt
e
1d
with
JBoss
2d
P it ht e w
W dra
Fix memo
Write
Write
leak
(JIRA
ry
Sales support e st
W rfdra
it h w
Bcko
a ffice failing
test
3d
2d
failing
test
125)
3d Write
U r a in
se dm whitepaper
4d
GUI Clarify
design Impl
require-
(CSS) ments GUI
1d 2d 6d
Henrik Kniberg 10
11. The bottom line Core Scrum the unofficial
If you achieve these you can ignore the
rest of the checklist. Your process is fine.
Delivering working, tested
These are central to Scrum. Without these
you probably shouldn’t call it Scrum.
Retrospective happens after
Scrum Checklist
software every 4 weeks or less every sprint
Results in concrete Henrik Kniberg
Delivering what the
improvement proposals
Recommended but not always necessary
business needs most
Some proposals actually get
Process is implemented Most of these will usually be needed, but not always all of them. Experiment!
continuously improving
Whole team + PO
Team has all skills needed to PBL items are broken into tasks
participates
bring backlog items to Done within a sprint
Clearly defined product owner PO has a product backlog Team members not locked into
(PO) (PBL) Sprint tasks are estimated
specific roles
PO is empowered to Top items are prioritized by Iterations that are doomed to Estimates for ongoing tasks
prioritize business value fail are terminated early are updated daily
PO has knowledge to Top items are estimated
prioritize PO has product vision that is in
Velocity is measured
sync with PBL
PO has direct contact with Estimates written by the
team team PBL and product vision is highly All items in sprint plan have
visible an estimate
PO has direct contact with Top items in PBL small
stakeholders enough to fit in a sprint Everyone on the team PO uses velocity for
participates in estimating release planning
PO speaks with one voice PO understands purpose of
(in case PO is a team) all backlog items PO available when team is Velocity only includes
estimating items that are Done
Team has a sprint backlog Have sprint planning meetings Estimate relative size (story Team has a sprint burndown
points) rather than time chart
Highly visible PO participates
Whole team knows top 1-3 Highly visible
impediments
Updated daily PO brings up-to-date PBL
SM has strategy for how to Updated daily
fix top impediment
Owned exclusively by the Whole team participates
team SM focusing on removing Daily Scrum is every day, same
impediments time & place
Results in a sprint plan
Escalated to management PO participates at least a
Daily Scrum happens
Whole team believes plan is when team can’t solve few times per week
achievable
Whole team participates Team has a Scrum Master (SM) Max 15 minutes
PO satisfied with
Problems & impediments priorities
Each team member knows
are surfaced SM sits with the team
what the others are doing
Timeboxed iterations
Demo happens after every
sprint
Iteration length 4 weeks or Scaling Positive indicators
less
Shows working, tested These are pretty fundamental to any Leading indicators of a
software Always end on time Scrum scaling effort. good Scrum implementation.
Feedback received from You have a Chief Product
Team not disrupted or Having fun! High energy level.
stakeholders & PO Owner (if many POs)
controlled by outsiders
Dependent teams do Scrum of Overtime work is rare and
Team usually delivers what
Scrums happens voluntarily
Have Definition of Done (DoD) they committed to
Dependent teams integrate Discussing, criticizing, and
11
DoD achievable within within each sprint experimenting with the process
Team members sit together
each iteration
PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done
Team respects DoD Max 9 people per team
http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17)
15. Which team needs Managers who don’t know how to
measure what they want
settle for
most improvement? wanting what they can measure
Russel Ackoff
Team 1 Team 2
Todo Doing Done Todo Doing Done
this week this week
orem ipsum dolor
sit amet, co nse orem ipsum dolor
ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor
sit amet, co nse ctetur sit amet, co nse
ctetur ctetur
orem ipsum dolor orem ipsum dolor orem ipsum dolor
orem ipsum dolor
sit amet, co nse sit amet, co nse sit amet, co nse
sit amet, co nse
ctetur orem ipsum dolor ctetur ctetur
ctetur
sit amet, co nse orem ipsum dolor orem ipsum dolor orem ipsum dolor
ctetur sit amet, co nse sit amet, co nse sit amet, co nse
ctetur ctetur orem ipsum dolor ctetur
orem ipsum dolor sit amet, co nse
sit amet, co nse ctetur
ctetur orem ipsum dolor
orem ipsum dolor
orem ipsum dolor sit amet, co nse
sit amet, co nse
sit amet, co nse orem ipsum dolor ctetur
ctetur
ctetur sit amet, co nse
orem ipsum dolor
ctetur
sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
Avg lead time:20 Avg lead time: 3
ctetur
days
days
Henrik Kniberg 15
16. 欲しいものを、どうやって計測す
どっちのチームが るかを知らないマネージャは、結
局計測できるものを欲するように
改善が必要？ なる。
Russel Ackoff
チーム 1 チーム 2
Todo Doing Done Todo Doing Done
this week this week
orem ipsum dolor
sit amet, co nse orem ipsum dolor
ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor
sit amet, co nse ctetur sit amet, co nse
ctetur ctetur
orem ipsum dolor orem ipsum dolor orem ipsum dolor
orem ipsum dolor
sit amet, co nse sit amet, co nse sit amet, co nse
sit amet, co nse
ctetur orem ipsum dolor ctetur ctetur
ctetur
sit amet, co nse orem ipsum dolor orem ipsum dolor orem ipsum dolor
ctetur sit amet, co nse sit amet, co nse sit amet, co nse
ctetur ctetur orem ipsum dolor ctetur
orem ipsum dolor sit amet, co nse
sit amet, co nse ctetur
ctetur orem ipsum dolor
orem ipsum dolor
orem ipsum dolor sit amet, co nse
sit amet, co nse
sit amet, co nse orem ipsum dolor ctetur
ctetur
ctetur sit amet, co nse
orem ipsum dolor
ctetur
sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
平均リードタイム: 20 日 3
ctetur
平均リードタイム: 日
Henrik Kniberg 16
23. Kanban @ Toyota
Buyer Supplier
Consume Detach Receive Ship Allocate Manufacture
The tool used to operate the
[Toyota Production] system is
kanban.
Taiichi Ohno
Adapted from Kiro Harada’s slide
Father of the
Toyota Production System
Henrik Kniberg 23
25. Kanban in SW development
Visualize the workflow Pioneered by
David Anderson
in 2004
Limit WIP (work in progress)
Measure & optimize flow
Explicit policies (definition of Done, WIP limits, etc)
Backlog Dev UAT Deploy Done
5 3 2 3
orem ipsum dolor
sit amet, co nse
ctetur
orem ipsum dolor orem ipsum dolor orem ipsum dolor
sit amet, co nse sit amet, co nse sit amet, co nse
ctetur ctetur orem ipsum dolor
ctetur
sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
orem ipsum dolor ctetur
sit amet, co nse
ctetur
FLOW 12
Avg lead time: days
Henrik Kniberg 25
26. ソフトウェア開発における Kanban
ワークフローの見える化 David Anderson
が2004年に開始
仕掛品(WIP: work in progress)の制限
流れの計測と最適化
明示的なポリシー (完了の定義, WIPの制限,他)
Backlog Dev UAT Deploy Done
5 3 2 3
orem ipsum dolor
sit amet, co nse
ctetur
orem ipsum dolor orem ipsum dolor orem ipsum dolor
sit amet, co nse sit amet, co nse sit amet, co nse
ctetur ctetur orem ipsum dolor
ctetur
sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
orem ipsum dolor
sit amet, co nse
ctetur
訳注:
ctetur
Kanban は、もちろん
「看板・かんばん」
に由来しますが、TPS
フロー 平均リードタイム 12 日 における「かんば
ん」と相違が多いた
め、誤解をさけるた
め Kanban としてい
ます。
Henrik Kniberg 26
31. Thinking tools
a.k.a. ”mindsets” or ”philosophies”
Tool Agile Systems Thinking Toolkits
”anything used as a means of Lean
a.k.a. ”frameworks”
accomplishing a task or purpose.” Theory of Constraints
- dictionary.com RUP XP
Scrum
Physical tools Kanban
Process tools
a.k.a. ”organizational patterns”
Product Owner role
Pair programming
Visualize the workflow
To do Dev Test Release Done!
5 3 2 3
H D C
A
G
B
K
FLOW
Henrik Kniberg 31
32. 思考ツール
a.k.a. ”マインドセット” 、”哲学”
ツール アジャイル システム思考 ツールキット
リーン
タスクや目的を達成するために使われ a.k.a. ”フレームワーク”
る手段であれば何でも 制約理論
- dictionary.com RUP XP
Scrum
物理的なツール Kanban
プロセスツール
a.k.a. ”組織パターン”
プロダクトオーナ
という役割
ペアプロ
見える化
To do Dev Test Release Done!
5 3 2 3
H D C
A
G
B
K
FLOW
Henrik Kniberg 32
33. Compare for understanding, not judgement
More prescriptive More adaptive
RUP XP Scrum Kanban Do Whatever
(120+) (13) (9) (3) (0)
• Architecture Reviewer • Business use case realization
• Business Designer • Business use-case model • Whole team • Scrum Master • Visualize the workflow
• Business-Model Reviewer • Business vision • Coding standard • Product Owner • Limit WIP
• Business-Process Analyst • Change request • TDD • Team • Measure and optimize lead time
• Capsule Designer • Configuration audit findings • Collective ownership • Sprint planning meeting
• Change Control Manager • Configuration management plan • Customer tests • Daily Scrum
• Code Reviewer • Data model • Pair programming • Sprint review
• Configuration Manager • Deployment model • Refactoring • Product backlogt
• Course Developer • Deployment plan • Planning game • Sprint backlog
• Database Designer • Design guidelines • Continuous integration • BUrndown chart
• Deployment Manager • Design model • Simple design
• Design Reviewer • Development case • Sustainable pace
• Designer • Development-organization • Metaphor
• Graphic Artist assessment • Small releases
• Implementer • End-user support mateirla
• Integrator • Glossary
• Process Engineer • Implementation model
• Project Manager • Installation artifacts
• Project Reviewer • Integration build plan
• Requirements Reviewer • Issues list
• Requirements Specifier • Iteration assessment
• Software Architect • Iteration plan
• Stakeholder • Manual styleguide
Do not develop an attachment
• System Administrator • Programming guidelines
• System Analyst • Quality assurance plan
• Technical Writer • Reference architecture
• Test Analyst • Release notes
to any one weapon
• Test Designer • Requirements attributes
• Test Manager • Requirements
• Tester management plan
• Tool Specialist • Review record
or any one school of fighting
• User-Interface Designer • Risk list
• Architectural analysis • Risk management plan
• Assess Viability of architectural • Software architecture
proof-of-concept document
• Capsule design • Software development
• Class design plan
• Construct architectural proof-of- • Software requirements
•
•
concept
Database design
Describe distribution
•
•
specification
Stakeholder requests
Status assessment
Miyamoto Musashi
•
•
Describe the run-time architecture
Design test packages and classes
• Supplementary business
specification 17th century samurai
• Develop design guidelines • Supplementary specification
• Develop programming guidelines • Target organization assessment
• Identify design elements • Test automation architecture
• Identify design mechanisms • Test cases
• Incorporate design elements • Test environment configuration
• Prioritize use cases • Test evaluation summary
• Review the architecture • Test guidelines
• Review the design • Test ideas list
• Structure the implementation • Test interface specification
model • Test plan
• Subsystem design • Test suite
• Use-case analysis • Tool guidelines
• Use-case design • Training materials
• Analysis model • Use case model
• Architectural proof-of-concept • Use case package
• Bill of materials • Use-case modeling guidelines
• Business architecture document • Use-case realization
• Business case • Use-case storyboard
• Business glossary • User-interface guidelines
Henrik Kniberg 33
• Business modeling guidelines • User-interface prototype
• Business object model • Vision
• Business rules • Work order
• Business use case • Workload analysis model
34. 判断のためでなく、理解のための比較
より記述的 より適応的
RUP XP Scrum Kanban なんでもいい
(120+) (13) (9) (3) (0)
• Architecture Reviewer • Business use case realization
• Business Designer • Business use-case model • Whole team • Scrum Master • Visualize the workflow
• Business-Model Reviewer • Business vision • Coding standard • Product Owner • Limit WIP
• Business-Process Analyst • Change request • TDD • Team • Measure and optimize lead time
• Capsule Designer • Configuration audit findings • Collective ownership • Sprint planning meeting
• Change Control Manager • Configuration management plan • Customer tests • Daily Scrum
• Code Reviewer • Data model • Pair programming • Sprint review
• Configuration Manager • Deployment model • Refactoring • Product backlogt
• Course Developer • Deployment plan • Planning game • Sprint backlog
• Database Designer • Design guidelines • Continuous integration • BUrndown chart
• Deployment Manager • Design model • Simple design
• Design Reviewer • Development case • Sustainable pace
• Designer • Development-organization • Metaphor
• Graphic Artist assessment • Small releases
• Implementer • End-user support mateirla
• Integrator • Glossary
• Process Engineer • Implementation model
• Project Manager • Installation artifacts
• Project Reviewer • Integration build plan
• Requirements Reviewer • Issues list
• Requirements Specifier • Iteration assessment
• Software Architect • Iteration plan
• Stakeholder • Manual styleguide
• System Administrator • Programming guidelines
• System Analyst • Quality assurance plan
• Technical Writer • Reference architecture
• Test Analyst • Release notes
Test Designer Requirements attributes
武器や流儀にこだわらない
• •
• Test Manager • Requirements
• Tester management plan
• Tool Specialist • Review record
• User-Interface Designer • Risk list
• Architectural analysis • Risk management plan
• Assess Viability of architectural • Software architecture
proof-of-concept document
• Capsule design • Software development
• Class design plan
• Construct architectural proof-of- • Software requirements
•
•
concept
Database design
Describe distribution
•
•
specification
Stakeholder requests
Status assessment
宮本武蔵
•
•
Describe the run-time architecture
Design test packages and classes
• Supplementary business
specification 17th century samurai
• Develop design guidelines • Supplementary specification
• Develop programming guidelines • Target organization assessment
• Identify design elements • Test automation architecture
• Identify design mechanisms • Test cases
• Incorporate design elements • Test environment configuration
• Prioritize use cases • Test evaluation summary
• Review the architecture • Test guidelines
• Review the design • Test ideas list
• Structure the implementation • Test interface specification
model • Test plan
• Subsystem design • Test suite
• Use-case analysis • Tool guidelines
• Use-case design • Training materials
• Analysis model • Use case model
• Architectural proof-of-concept • Use case package
• Bill of materials • Use-case modeling guidelines
• Business architecture document • Use-case realization
• Business case • Use-case storyboard
• Business glossary • User-interface guidelines
Henrik Kniberg 34
• Business modeling guidelines • User-interface prototype
• Business object model • Vision
• Business rules • Work order
• Business use case • Workload analysis model
35. Lean & Agile process toolkits
Values & Principles
Lean, Agile, Theory of Constraints, Systems Thinking, etc
Kanban
Other lean tools
XP (Value Stream Mapping,
Root Cause Analysis, etc)
Scrum
Henrik Kniberg 35
36. リーンとアジャイルのプロセスツールキット
価値と原則
リーン、アジャイル、制約理論、システム思考、他
Kanban
XP 他のリーンツール
(バリューストリーム
マッピング, 原因分析, 他)
Scrum
Henrik Kniberg 36
37. Any tool can be misused
The old
tool
was
better!
Don’t blame
the tool!
37
Henrik Kniberg 37
42. Multitasking name game
Round 1: Ordering process
Developer Customer Jeff
1
Order
2
Deliver
JEFF
28
JEFF 3
Log delivery time
Henrik Kniberg 42
43. Multitasking name game
ラウンド 1: 注文プロセス
開発者 顧客 Jeff
1
注文
納品
2
JEFF
28
JEFF 納入時間を計測
3
Henrik Kniberg 43
44. Multitasking name game
Round 1: Development process
28
Policy DAV E Dave
Never keep a L IS Lisa
customer waiting
BO B Bob
Start early
= Finish early ERI Eric
MAR Maria
Henrik Kniberg 44
45. Multitasking name game
ラウンド 1: 開発プロセス
28
ポリシー DAV E Dave
顧客を待たせない
L IS Lisa
早く始める
BO B Bob
= 早く終わる
ERI Eric
MAR Maria
Henrik Kniberg 45
46. Multitasking name game
Round 2 – Development process
Policy DAV E Dave
Limit WIP L IS A Lisa
(work in process)
Bob
Current limit =
1 customer
at a time Eric
Maria
Henrik Kniberg 46
47. Multitasking name game
ラウンド 2 – 開発プロセス
Policy DAV E Dave
WIPを制限 L IS A Lisa
(WIP: 仕掛品)
Bob
現在のリミット=
顧客対応は、
一人づつ Eric
Maria
Henrik Kniberg 47
48. Multitasking name game
Round 2: Ordering process
Developer Customer Jeff
0
Request order
5 1
Log start time
Submit order
5
2
Deliver product
JEFF
5 15
JEFF 3
10
Henrik Kniberg Log delivery 48
time
Calc project length
49. Multitasking name game
ラウンド 2: 注文プロセス
開発者 顧客 Jeff
0
発注
5 1
開始時刻を記録
発注
5
製品の納品
2 JEFF
5 15
JEFF 3
10
Henrik Kniberg 納入時刻を記録
49
かかった時間を計算
52. Causes of unnecessary multitasking
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 Fix hole
Hole in boat
Henrik Kniberg 52
56. Case study
Design-ready games Production-ready games
Game backlog
15 12
8
Lisa
Concept Graphics Sound Integr. &
Sam assigns Dev
pres. design design deploy
resources
2d 1m 6m 1w 6m 6m
2h 4h 1d 1m 3w 3m 3w
(1m+2m)
3 m value added time Process
= 12% cycle
25 m cycle time efficiency
56
60. Case study
Design-ready games Production-ready games
Game backlog
15 12
8
Lisa
Concept Graphics Sound Integr. &
Sam assigns Dev
pres. design design deploy
resources
2d 1m 6m 1w 6m 6m
2h 4h 1d 1m 3w 3m 3w
プロセス (1m+2m)
付加価値作業 3分
= 12% サイクル
サイクルタイム 25分 効率
Cross-functional game team Game team
(graphics, sound,
dev, integrate)
3-4 m cycle time = 6-8x faster
3-4 months
60
Henrik Kniberg 60
61. Case study
デザイン完了ゲーム 製造可能 ゲーム
ゲームバックログ
15 12
8
グラ
コンセ Lisa がリ サウン
フィッ 統合 & 配
Sam プト作 ソース割 ドデザ 開発
クデザ 布
成 り当て イン
2d 1m 6m 1w イン 6m 6m
2h 4h 1d 1m 3w 3m 3w
プロセス (1m+2m)
付加価値作業 3分
= 12% サイクル
サイクルタイム 25分 効率
機能横断ゲームチームCross-functional game team
ゲームチーム
(グラフィック, サウ
ンド, 開発, 統合)
サイクルタイム3～4分= 6～8倍速い
3～4 か月
61
Henrik Kniberg 61
62. Typical evolution to Scrum/Kanban combo
Scrum step 1 Scrum step 2 Scrum + Kanban
Feature Feature Feature Feature Feature Feature Feature Feature Feature
team 1 team 2 team 2 team 1 team 2 team 2 team 1 team 2 team 2
Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum
Operations / support team Operations / support team
Scrum Kanban
Henrik Kniberg 64
63. Scrum/Kanban 組み合わせのよくある改善例
Scrum ステップ 1 Scrum ステップ 2 Scrum + Kanban
Feature Feature Feature Feature Feature Feature Feature Feature Feature
team 1 team 2 team 2 team 1 team 2 team 2 team 1 team 2 team 2
Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum
運用サポートチーム 運用サポートチーム
Scrum Kanban
Henrik Kniberg 65
