Scrum & Kanban

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

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

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

プレゼンテーションの目的 Scrum と Kanban を比較して、両者をよりよく理解するあなたが、自分のコンテキストで、 Scrum や Kanban をどう活用できるか自分で考えられるように Henrik Kniberg 4

Your knowledge? Veteran Use Tried Scrum Kanban Seen Read 5 Henrik Kniberg

知識レベル? ベテラン使った試した Scrum Kanban 見た読んだ 6 Henrik Kniberg

Scrum in a nutshell Henrik Kniberg 7

Scrum 超入門 Henrik Kniberg 8

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

組織を分割 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

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)

最低限のチェックコア・スクラム the unofficial (非公認) この項目ができていたら、残りのチェックリスト項目は無視していい。あなたのプロセスはうまくいっている。定期的(4週間以内)に動作する、テスト済スクラムの主要要素。これらを抜きにして、スクラムと呼ぶことはできないだろうスプリントごとにふりかえりを Scrum Checklist みのソフトウェアを提供している行えているスクラムチェックリスト Henrik Kniberg 結果として具体的な改善提ビジネスニーズに基づいたものを最優先して提供している案を行っている実際に、実現できた提案が推奨項目(いつも必要というわけではない) あるほとんどの項目は必要になる事が多い、すべて常に必要というわけではない。試してみて! プロセスを継続的に改善しているチームとプロダクトオーナチームは、バックログ項目を完了させプロダクトバックログは、1スプリンーの全員が参加しているるために必要なスキルを全て持つト以内のタスクに分割されているはっきりと定義されたプロダクトオープロダクトオーナーはプロダクトバッチームメンバは特定の役割に固スプリントタスクの見積りが行ナー(PO) クログ(PBL)を持っているわれている定されていないプロダクトオーナーは、優先度上位項目はビジネス価値に基づ失敗が避けられないイテレーションを実行中のタスクの見積りは付けをする権限をもついて優先度付けされている早めに強制終了している毎日更新されているプロダクトオーナーは、優先度上位項目は見積り済み付けをする知識をもつである POはプロダクトバックログと連動するプロダクトビジョンをもつベロシティが計測されているプロダクトオーナーは、直接チ見積りはチームがームと話している行っているプロダクトバックログとプロダクトビスプリント計画で、対象のジョンを見える化している項目が見積りを持っているプロダクトオーナーは、直接ス上位項目は１つのスプリントにテークホルダと話している収まる規模になっているチームの全員が見積もりに参加 POはベロシティを用いてリリース計画を作成しているプロダクトオーナーがすべてのしているプロダクトオーナーは、同じことをいう(複数人いる場合) 項目の目的を理解しているチームが見積っている間、ベロシティは完了した項目だけプロダクトオーナも待機しているをカウントしているスプリント計画ミーティングをチームはスプリントバックログを持っ時間ではなく、相対規模(ストーリーポている行っているチームはスプリントバーンダウンチャイント) で見積っているートを持っているプロダクトオーナーが参加して見える化しているいるチーム全員が上位3つの障害見える化されているプロダクトオーナーが最新のプについて認識している毎日更新されているロダクトバックログを提示最上位の障害解決について、毎日更新されている SMが戦略をもっている完全にチームの持ち物であるチーム全員が参加しているスクラムマスターは、障害を取デイリースクラムは、毎日・同じ時間り除くことに集中している結果がスプリント計画に・同じ場所で行っている盛り込まれているチームが解決できないときは管デイリースクラムを行っている最低でも週の何日かはプロダク理層に報告されているトオーナが参加しているチーム全員が計画は達成可能だと考えているチームの全員が参加しているチームにスクラムマスター(SM) がいる長くても15分までプロダクトオーナーは、優先度を含め満足している問題と障害を表面化できているスクラムマスターは、チームと各チームメンバは他のメンバが同じ場所に机がある何をしているか知っているイテレーションをタイムボックス化している毎スプリント終了後にデモを行っているイテレーションの長さはスケーリングよい兆候 4週間以内動作する、テスト済みのソフトスクラムの規模を拡大する取り組みのよいスクラムを実施している事を示すウェアを見せているいつも期限どおりにうち、ごく基本的なもの先行指標終了するステークホルダとプロダクトオチーフプロダクトオーナーがいる (たーナからフィードバックを得てチームは部外者に妨害やくさんのPOがいるとき) 楽しんで! みんな活発にいる指図を受けていない所属するチームを集めてスクラムのスチームは通常、何にコミックラムを行っている残業は稀。残業を強制されない完了の定義(DoD)を持っているトするかを明言している所属するチームはスプリント内でプロセスについて議論、批評、 12 DoDはイテレーションごとに達チームメンバは同じ場所に机がインテグレーションを行っている実験を行っている成可能なものになっているあるひとつのチームは最大でも9 PO = プロダクトオーナー SM = スクラムマスター PBL = プロダクトバックログ DoD = 完了の定義チームはDoDを尊重している人まで http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17) 日本語訳 rev.1 (2009-09-01)

Kanban in a nutshell Henrik Kniberg 13

Kanban 超入門 Henrik Kniberg 14

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

欲しいものを、どうやって計測すどっちのチームがるかを知らないマネージャは、結局計測できるものを欲するように改善が必要？なる。 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

Kanban @ Imperial Palace Gardens Henrik Kniberg 17

Kanban @ Imperial Palace Gardens Henrik Kniberg 18

Kanban 看板 ”Visual Card” Signaling system Visual Limited in supply Henrik Kniberg 19

Kanban 看板 ”Visual Card” 通知システム見える量の制限 Henrik Kniberg 20

Kanban in your wallet Darn. Forgot to limit. Henrik Kniberg 21

財布の中のKanban あ、量の制限を忘れてる！ Henrik Kniberg 22

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

トヨタのかんばん Buyer バイヤー Supplier サプライヤ Consume Detach Receive Ship Allocate Manufacture 使用外れ受領出荷引当製造「トヨタ生産方式」を運用するのにつかわれるツールは、かんばんである大野耐一原田騎郎氏のスライドより引用トヨタ生産方式の父 Henrik Kniberg 24

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

ソフトウェア開発における 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

Kanban example Board shared by 2 teams (16 people in total) Henrik Kniberg 27

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

Compare for understanding, not judgement Henrik Kniberg 29

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

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

思考ツール 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

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

判断のためでなく、理解のための比較より記述的より適応的 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

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

リーンとアジャイルのプロセスツールキット価値と原則リーン、アジャイル、制約理論、システム思考、他 Kanban XP 他のリーンツール (バリューストリームマッピング, 原因分析, 他) Scrum Henrik Kniberg 36

Any tool can be misused The old tool was better! Don’t blame the tool! 37 Henrik Kniberg 37

どんなツールの間違った使い方ができる昔のツールがよかったツールを責めない! 38 Henrik Kniberg 38

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

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

Multitasking name game 準備 4 – 6人の顧客 1 開発者 Dave Lisa Bob Eric Maria Henrik Kniberg 41

Multitasking name game Round 1: Ordering process Developer Customer Jeff 1 Order 2 Deliver JEFF 28 JEFF 3 Log delivery time Henrik Kniberg 42

Multitasking name game ラウンド 1: 注文プロセス開発者顧客 Jeff 1 注文納品 2 JEFF 28 JEFF 納入時間を計測 3 Henrik Kniberg 43

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

Multitasking name game ラウンド 1: 開発プロセス 28 ポリシー DAV E Dave 顧客を待たせない L IS Lisa 早く始める BO B Bob = 早く終わる ERI Eric MAR Maria Henrik Kniberg 45

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

Multitasking name game ラウンド 2 – 開発プロセス Policy DAV E Dave WIPを制限 L IS A Lisa (WIP: 仕掛品) Bob 現在のリミット= 顧客対応は、一人づつ Eric Maria Henrik Kniberg 47

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

Multitasking name game ラウンド 2: 注文プロセス開発者顧客 Jeff 0 発注 5 1 開始時刻を記録発注 5 製品の納品 2 JEFF 5 15 JEFF 3 10 Henrik Kniberg 納入時刻を記録 49 かかった時間を計算

Multitasking name game Typical results Henrik Kniberg 50

Multitasking name game よくある結果 Henrik Kniberg 51

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

不必要なマルチタスクの原因開始することに集中して、終了を意識しない WIPを制限しない人を忙しくしておくことに集中する(ゆとり時間を恐れる) 症状を直すことと“理由”を受け入れて、問題を気にしない。水をかき出す浸水穴を直すボートに穴 Henrik Kniberg 53

Kanban & Scrum Real-life example Henrik Kniberg 54

Kanban & Scrum 実例 Henrik Kniberg 55

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

ケーススタディデザイン完了ゲーム製造可能ゲームゲームバックログ 15 12 8 グラコンセ Lisa がリサウンフィッ統合 & 配 Sam プト作ソース割ドデザ開発クデザ布成り当てイン 2d 1m 6m 1w イン 6m 6m 2h 4h 1d 1m 3w 3m 3w (1m+2m) 付加価値作業 3分プロセス = 12% サイクルサイクルタイム 25分効率 57

Limit work to capacity Input: 3 customers / hour Output capacity: 2 customers / hour Henrik Kniberg 58

仕事の量を能力容量に合わせる入力: 3 顧客 / 時出力容量: 2 顧客 / 時 Henrik Kniberg 59

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

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

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

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

One day in Kanban land Henrik Kniberg 66

Kanban チームの一日 Henrik Kniberg 67

”One day in Kanban land” http://blog.crisp.se/henrikkniberg/tags/kanban/ Henrik Kniberg 68

シナリオ 1 – 一個流し Dev Backlog Next 3 In production :o) 2 Ongoing Done A B G C F D H I J L E M K Henrik Kniberg 69

シナリオ 1 – 一個流し Dev Backlog Next 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 70

シナリオ 1 – 一個流し Dev Backlog Next 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 71

Scenario 1 – one piece flow Dev Backlog Next 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 72

シナリオ 1 – 一個流し Dev Backlog Next 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 73

シナリオ 2 – 開発での問題 Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A B G C F D H I J L E M K Henrik Kniberg 74

シナリオ 2 – 開発での問題 Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 75

シナリオ 2 – 開発での問題 Dev Backlog Next 3 In production :o) 2 PO Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 76

シナリオ 2 – 開発での問題 Dev Backlog Next 3 In production :o) 2 PO Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 77

シナリオ 2 – 開発での問題 Dev Backlog Next 3 In production :o) 2 PO Ongoing Done C A G D !? B F H I J L E M K Henrik Kniberg 78

シナリオ 2 – 開発での問題 Dev Backlog Nexet 3 In production :o) 2 PO Ongoing Done G !? A D B F E C H I J L M K Henrik Kniberg 79

Scenario 2 – Deployment problem Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A G D B F E C H I J L M K Henrik Kniberg 80

シナリオ 2 – 開発での問題 Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A G D B F E C H I J L M K Henrik Kniberg 81

シナリオ 2 – 開発での問題 Dev Backlog Next 3 In production :o) 2 PO Ongoing Done D A G B E F C H I J L M K Henrik Kniberg 82

Evolve your process Henrik Kniberg 83

プロセスを進化させる Henrik Kniberg 84

Kanban & Scrum are empirical Capacity Lead time Quality Predictability (aka velocity) (aka cycle time) (defect rate, etc) (SLA fulfillment, etc) Kanban is more configurable Many small teams Few large teams Great! More options! Oh no, more decisions! Low WIP limits High WIP limits Few workflow states Many workflow states No iterations Long iterations Little planning Lots of planning .... etc ... .... etc ... Henrik Kniberg 85

Kanban & Scrum は経験的手法である容量リードタイム品質予測可能性 (aka ベロシティ) (aka サイクルタイム) (バグ率, etc) (SLA 満足率, etc) Kanban is more configurable すばらしい! まいるなぁ多数の小チーム少数の大チーム選択肢が広い! そんな沢山決めることが! WIP 制限小 WIP 制限大ワークフロー状態少ワークフロー状態多イテレーション無長いイテレーション最小限の計画綿密な計画 .... etc ... .... etc ... Henrik Kniberg 86

Henrik Kniberg Kanban www.crisp.se/kanban/example example kick-start version 1.2 2009-11-16 Next Analysis Development Acceptance Prod 2 3 3 2 Ongoing Done Ongoing Done Ongoing Done 2009-08-20 2009-09-01 2009-08-30 2009-09-08 2009-08-27 orem olor sit amet, co nse orem ipsum ipsum dolor orem dolor orem ipsum dolor orem ipsum dolor orem ipsum dolor ctetur adi pis sit amet, amet,nsense sit co co sit amet, co adi sit amet, co nse sit amet, adi pis ctetur ctetur cing elit nisl ctetur adi pis pis cing elit nisl cing elit nisl cing elit nisl orem ipsum dolor sit amet, co nse xxxx ctetur orem ipsum dolor kjd dj sit amet,dco nse xxx orem ipsum dolor ctetur sit amet, co nse ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor ctetur sit amet, co nse ctetur 2009-08-29 2009-09-02 orem ipsum dolor orem ipsum sit amet, nse 2009-08-25 dolor sit amet, ctetur adi pis orem ipsum dolor orem ipsum dolor co nse cing elit nisl amet, co nse sit orem ipsum dolor sit ctetur adi pis ctetur sit amet, co nse ctetur cing elit nisl Definition of Done: Definition of Done: Definition of Done: • Goal is clear • Code clean & checked in on trunk • Customer accepted • First tasks defined • Integrated & regression tested • Ready for production • Story split (if • Running on UAT environment necessary) Feature / story Hard deadline Task / defect What to pull first =task =defect (description) • Panicfeatures (description) Date when added (if applicable) to board (should be swarmed and kept (description) = completed moving. Interrupt other work and 2009-08-20 2009-09-30 = priority break WIP limits as necessary) (description) Why = blocked • Priority features = panic • Hard deadline features (description) (only if deadline is at risk) (description) = who is doing Who is analyzing / • Oldest features this right now testing right now

Henrik Kniberg Kanban www.crisp.se/kanban/example example kick-start version 1.2 2009-11-16 次分析開発受入本番 2 3 3 2 実施中完了実施中完了実施中完了 2009-08-20 2009-09-01 2009-08-30 2009-09-08 2009-08-27 orem olor sit amet, co nse orem ipsum ipsum dolor orem dolor orem ipsum dolor orem ipsum dolor orem ipsum dolor ctetur adi pis sit amet, amet,nsense sit co co sit amet, co adi sit amet, co nse sit amet, adi pis ctetur ctetur cing elit nisl ctetur adi pis pis cing elit nisl cing elit nisl cing elit nisl orem ipsum dolor sit amet, co nse xxxx ctetur orem ipsum dolor kjd dj sit amet,dco nse xxx orem ipsum dolor ctetur sit amet, co nse ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor ctetur sit amet, co nse ctetur 2009-08-29 2009-09-02 orem ipsum dolor orem ipsum sit amet, nse 2009-08-25 dolor sit amet, ctetur adi pis orem ipsum dolor orem ipsum dolor co nse cing elit nisl amet, co nse sit orem ipsum dolor sit ctetur adi pis ctetur sit amet, co nse ctetur cing elit nisl 完了の定義: 完了の定義: 完了の定義: • ゴールが明確 • きれいなコードをtrunkにチェックイン • 顧客の受入合意 • 初期タスクが定義済み • 統合テスト、回帰テストに合格 • 本番移行可能 • ストーリー分割(必要なら) • 受入テスト環境で動作フィーチャー / ストーリータスク / 障害どれから手をつけるか =タスク =障害 (description) • パニック (description) ボードに張られた日最終納期 (オプション) (みんなで集まって、とにかく片づける。 (description) = 完了必要とあらば他のタスクを止めたり、 2009-08-20 2009-09-30 = 優先 WIP制限を破ってもよい) (description) Why = 開始できない • 優先 = パニック • 最終納期があるもの (description) (納期内完了にリスクがある場合) (description) = 現在作業中の現在作業中の • もっとも古いもの担当者担当者

Kanban evolution example April 7 April 23 Henrik Kniberg 89

Kanban ボードの進化の例４月７日４月２３日 Henrik Kniberg 90

Optimizing the WIP limit Too low WIP limit To do Doing Done 1 orem ipsum dolor sit amet, co nse orem ipsum dolor sit amet, co nse Just Right WIP limit ctetur ctetur To do Doing Done 2 orem ipsum dolor sit amet, co nse orem ipsum dolor sit amet, co nse orem ipsum dolor Too high WIP limit ctetur ctetur sit amet, co nse ctetur Slow flow To do Doing Done (end-to-end) orem ipsum dolor sit amet, co nse ctetur 5 Zzzzzzzzz orem ipsum dolor sit amet, co nse orem ipsum dolor People ctetur sit amet, co nse ctetur often idle Fast flow Tasks rarely idle Slow People flow sometimes idle orem ipsum dolor sit amet, co nse ctetur (slack) People never idle Tasks often Lack of wall idle space... Henrik Kniberg 91

WIP 制限の最適化 WIP 制限が低すぎる To do Doing Done 1 orem ipsum dolor sit amet, co nse orem ipsum dolor sit amet, co nse WIP 制限がちょうど良い ctetur ctetur To do Doing Done 2 orem ipsum dolor sit amet, co nse orem ipsum dolor sit amet, co nse orem ipsum dolor WIP 制限が高すぎる ctetur ctetur sit amet, co nse ctetur 流れが遅い To do Doing Done (全体で) orem ipsum dolor sit amet, co nse ctetur 5 Zzzzzzzzz orem ipsum dolor sit amet, co nse orem ipsum dolor 手待ちの ctetur sit amet, co nse ctetur 人が沢山速い流れ待ちタスクは少ない遅い人はときどき流れ orem ipsum dolor 手待ちになる sit amet, co nse ctetur (ゆとり) 人は手待ちにならない待ちタスク壁のスペースが沢山が足りない... Henrik Kniberg 92

Evolve your own unique board! Some of these photos courtesy of David Anderson, Mattias Skarin, and various other people Henrik Kniberg 93

自分のKanbanボードに進化写真は、David Anderson、 Mattias Skarin、ほか多くの人から提供いただきました。 Henrik Kniberg 94

Kanban compared to Scrum Henrik Kniberg 95

Kanban Scrum と比べてみる Henrik Kniberg 96

Product Team Scrum owner Master Scrum prescribes roles, Kanban doesn’t PO SM Henrik Kniberg 97

プロダクトチームスクラムオーナマスタ Scrum は役割を指定する, Kanban はしない PO SM Henrik Kniberg 98

Scrum prescribes timeboxed iterations Scrum team week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Kanban team 1 Sprint 1 Sprint 2 Plan & commit Review Retrospective (release?) Kanban team 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Retrospectives (4w) Planning cadence (2w) Release cadence (1w) Kanban team 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Retrospectives (4w) Planning (on demand) Release (on demand) Henrik Kniberg 99

Scrum は、タイムボックス固定のイテレーションを指定 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Scrum チーム Kanban チーム 1 スプリント 1 スプリント 2 計画 & コミットレビュー振り返り (リリース?) Kanban チーム 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 振り返り(4w) 計画ケイデンス(2w) リリースケイデンス(1w) Kanban チーム 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 振り返り(4w) 計画(オンデマンド) リリース (オンデマンド Henrik Kniberg 100

Scrum backlog items must fit in a sprint Scrum Sprint 1 Sprint 2 Sprint 3 Sprint 4 Kanban Long running task WIP limit = 3 Long running task Henrik Kniberg 101

Scrum のバックログ項目は、１スプリントに収まる必要がある。 Scrum Sprint 1 Sprint 2 Sprint 3 Sprint 4 Kanban 長いタスク WIP 制限 = 3 長いタスク Henrik Kniberg 102

Both limit WIP, but in different ways Scrum board Kanban board To do Ongoing Done :o) To do Ongoing Done :o) 2 A A B B C C D D FLOW FLOW WIP limited per unit of time WIP limited per workflow state (iteration) Henrik Kniberg 103

両方とも WIPを制限する。方法は異なる。 Scrum ボード Kanban ボード To do Ongoing Done :o) To do Ongoing Done :o) 2 A A B B C C D D フローフロー単位時間(イテレーション)の間ワークフロー状態ごとのWIP制限のWIP 制限 Henrik Kniberg 104

I’d like to have E! Scrum discourages change in mid-iteration PO Wait until a To Do slot becomes available! Wait until next sprint! Or swap out C or D! Scrum Kanban To do Ongoing Done :o) To do Ongoing Done :o) 2 2 C A C A D B D B FLOW FLOW Policies Henrik Kniberg 105

I’d like to have E! Scrum は、イテレーション途中の変更 PO を避ける ToDo が空くまで待っ次のイテレーションをて。それとも C か D 待ってをやめる？ Scrum Kanban To do Ongoing Done :o) To do Ongoing Done :o) 2 2 C A C A D B D B フローフローポリシー Henrik Kniberg 106

Scrum board is reset between each iteration Scrum First day of sprint Mid-sprint Last day of sprint Kanban Any day Henrik Kniberg 107

Scrum ボードは、イテレーションごとにリセット Scrum スプリント初日中盤スプリント最終日 Kanban いつでも Henrik Kniberg 108

Scrum prescribes cross-functional teams Kanban supports both specialists & generalists Scrum team Kanban team 1 Kanban team 2 Backlog Design Fold Tape Trim Draw 3 2 2 1 4 3 orem ipsum dolor 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 sit amet, co nse sit amet, co nse ctetur 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 Cross-functional team Henrik Kniberg 109

Scrum は、機能横断チームを指定 Kanban は、専門家チームも、総務チームもサポート Scrum チーム Kanban チーム 1 Kanban チーム 2 Backlog Design Fold Tape Trim Draw 3 2 2 1 4 3 orem ipsum dolor 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 sit amet, co nse sit amet, co nse ctetur 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 機能横断チーム Henrik Kniberg 110

Scrum prescribes estimation and velocity V= 8 V= 7 V= 9 1 2 2 1 1 2 Likely velocity: 8 per sprint 2 3 1 3 1 2 2 1 (sustainable pace?) Sprint 1 Sprint 2 Sprint 3 Henrik Kniberg 111

Scrum は、見積りとベロシティの利用を指定 V= 8 V= 7 V= 9 1 2 2 1 1 2 想定ベロシティ: 8 / スプリント 2 3 1 3 1 2 2 1 (持続可能なペース?) スプリント1 スプリント2 スプリント3 Henrik Kniberg 112

Estimation is flexible in both Kanban & Scrum ”Typical” Features Tasks Kanban 1. Don’t estimate features. Just count them. 1. Skip tasks 2. Estimate features in t-shirt size 2. Don’t estimate tasks. Just count them. S M L S M L Hours? Days? Weeks? 3. Estimate features in story points 3. Estimate tasks in days ”Typical” Scrum 1sp 2sp 0.5d 1d 2d 5sp 4. Estimate features in ideal man-days 4. Estimate tasks in hours 4h 12h 1d 3d 8h 6d Henrik Kniberg 113

Scrum でも Kanban でも、見積は柔軟なもの ”普通の” フィーチャータスク Kanban 1. フィーチャーを見積もらない。数える。 1. タスクをスキップする。 2. 2. フィーチャーをTシャツのサイズで見積もるタスクを見積もらない。数える。 S M L S M L Hours? Days? Weeks? 3. フィーチャーをストーリーポイントで見積もる 3. タスクを日数で見積もる ”普通の” Scrum 1sp 2sp 0.5d 1d 2d 5sp 4. フィーチャーを理想人日で見積もる 4. タスクを時間で見積もる 4h 12h 1d 3d 8h 6d Henrik Kniberg 114

Both allow working on multiple products simultaneously (if you must…) Scrum example 1 Kanban example 1 Color-coded tasks Green Product Yellow Product Green team Yellow team Scrum example 2 Scrum example 3 Kanban example 2 All products All products Color-coded swimlanes Cross-product team Cross-product team Henrik Kniberg 115

複数の製品を同時に扱うのは、どちらもで可能 (どうしても必要ならね…) Scrum 例 1 Kanban 例 1 色分けタスク Green 製品 Yellow 製品 Green チーム Yellow チーム Scrum 例 2 Scrum 例 3 Kanban 例 2 全製品全製品色分けレーン製品横断チーム製品横断チーム Henrik Kniberg 116

Minor differences Henrik Kniberg 117

小さな違い Henrik Kniberg 118

Minor difference: Scrum prescribes daily meetings ... but many Kanban teams do that anyway. Henrik Kniberg 119

小さな違い: Scrum は、毎日のミーティングを指定している ... まあ、Kanban チームも多くはやってます Henrik Kniberg 120

Minor difference: Scrum prescribes a prioritized product backlog Scrum: Kanban: Product backlog must Product backlog is optional exist Changes to product backlog Changes to product take effect as soon as backlog take effect next capacity becomes available sprint (not current sprint) Any prioritization scheme can Product backlog must be be used. For example: sorted by “business value” 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 Henrik Kniberg 121

小さな違い: Scrum は、優先度付けされたプロダクトバックログを指定してます Scrum: Kanban: プロダクトバックログが必須プロダクトバックログは任意プロダクトバックログに対する変更はプロダクトバックログに対する変、次のスプリントで反映される (今更は、能力が空いた時点で反映さのスプリントではない) れるプロダクトバックログは、「ビジネス価優先度付けの方法は任意。例えば値」順に並べる必要がある : 好きなものを選んでよい一番上を常に選ぶ一番古いものを常に選ぶ 20% は保守項目を、80% 新規フィーチャー開発を選ぶ能力量を製品Aと製品Bで等分する赤いものを常に選ぶポリシー Henrik Kniberg 122

Minor difference: In Scrum, burndown charts are prescribed Burndo n w 70 60 E imt e w rk 5 st a d o 0 mining 40 re a 30 20 Common alternative in Kanban: 10 Cumulative flow diagram August 1 2 3 4 5 8 9 1 1 1 1 1 1 1 1 0 1 2 5 6 7 8 9 Dt e a Day 4 Backlog Dev Test Prod orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse ctetur orem ipsum dolor ctetur sit amet, co nse ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor ctetur sit amet, co nse ctetur Henrik Kniberg 123

小さな違い: Scrumでは、バーンダウンチャートの使用が指定 Burndo n w 70 60 E imt e w rk 5 st a d o 0 mining 40 re a 30 20 Kanban で利用される代替: 10 累計流動数グラフ August 1 2 3 4 5 8 9 1 1 1 1 1 1 1 1 0 1 2 5 6 7 8 9 Dt e a リードタイム６日 WIP 9項目 Day 4 Backlog Dev Test Prod orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse ctetur orem ipsum dolor ctetur sit amet, co nse ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor ctetur sit amet, co nse ctetur Henrik Kniberg 124

Final points Henrik Kniberg 125

まとめ Henrik Kniberg 126

http://www.infoq.com/minibooks/kanban-scrum-minibook Kanban & Scrum Comparison summary Similarities Differences Scrum Kanban Both are Lean and Agile Timeboxed iterations prescribed. Timeboxed iterations optional. Both based on pull scheduling Both limit WIP Team commits to a specific amount Commitment optional. Both use transparency to drive process of work for this iteration. improvement Uses Velocity as default metric for Uses Lead time as default metric for Both focus on delivering releasable planning and process improvement. planning and process improvement. software early and often Cross-functional teams Cross-functional teams optional. Both are based on self-organizing teams prescribed. Specialist teams allowed. Items broken down so they can be No particular item size is prescribed. Both require breaking the work into completed within 1 sprint. pieces Burndown chart prescribed No particular type of diagram is In both cases the release plan is prescribed continuously optimized based on WIP limited indirectly (per sprint) WIP limited directly (per workflow empirical data (velocity / lead time) state) Estimation prescribed Estimation optional Cannot add items to ongoing Can add new items whenever iteration. capacity is available A sprint backlog is owned by one A kanban board may be shared specific team by multiple teams or individuals Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles A Scrum board is reset between A kanban board is persistent each sprint Henrik Kniberg Prescribes a prioritized product 127 Prioritization is optional. backlog

http://www.infoq.com/minibooks/kanban-scrum-minibook Kanban & Scrum 比較のまとめ類似点相違点 Scrum Kanban リーンで、アジャイルタイムボックスを固定したイテレータイムボックス固定イテレーションプルによるスケジューリングに基づくションを指定の選択は任意 WIP を制限するイテレーションの中での作業量を、コミットメントは任意プロセス改善を促進するために、透明性を活用チームがコミットするする計画やプロセス改善に使う基本の指計画やプロセス改善に使う基本の指早期かつ頻繁な使えるソフトウェアの提供に重標は、ベロシティ標は、リードタイム点をおく機能横断チームが指定機能横断チームは任意自己組織化したチームに基づく専門家チームも可能 1スプリント内で完了するように、項項目のサイズに制限はないワークを部分に分割する目は分割されるリリース計画は、経験データにもとづき絶えず改バーンダウンチャートが指定特に指定のダイアグラムはない善され続ける(ベロシティ/リードタイム) 間接的にWIPを制限 (スプリントあ直接的にWIPを制限 (ワークフローたり) の状態ごとに) 見積もりは必須見積もりは任意実施中にイテレーションに項目は足容量があるならいつでも項目を足せせないるスプリントバックログは、特定の１ Kanban ボードは、複数のチームや個チームが保有人で共有することもできる役割を３つ指定 (PO/SM/Team) 役割を指定していない Scrum ボードは、スプリントごとに Kanban ボードはずっと使われるリセットされる Henrik Kniberg 優先度付きのプロダクトバックログ優先度付けは任意 128 を指定

Free download http://www.infoq.com/minibooks/kanban-scrum-minibook Henrik Kniberg 129

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

Don’t be dogmatic Go away! Don’t talk to us! We’re in a Sprint. Come back Though Shalt in 3 weeks. Limit WIP Henrik Kniberg 131

教条主義に陥らない立ち去れ。話しかけるな。スプリント中だ。三週間後に汝、WIP 来たまえ制限を守り給え Henrik Kniberg 132

Essential skills needed regardless of process Splitting the system into Software Retrospectives useful pieces craftsmanship As a buyer I want to save my shopping cart so that I can continue shopping later Henrik Kniberg 133

必須なスキルプロセスによらずシステムを利用可能な単位ソフトウェア振り返りに分割する職人芸 As a buyer I want to save my shopping cart so that I can continue shopping later Henrik Kniberg 134

Take-away points 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 Henrik Kniberg 135

お持ち帰り用のポイント 1. ゴールを知ることヒント: Agile/Lean/Kanban/Scrumはゴールではない。 2. ツールを非難しないことツールが成功したり、失敗したりはしない。するのは、人。ツールに良い悪いもない。ツールを使う時、場所、方法、目的、選び方などに、よい判断と悪い判断があるだけだ。 3. 一つのツールにこだわるな自分自身を広げること判断のためでなく、理解のために比較する 4. 実験して、ライドを楽しもうはじめから正しくやろうと心配しすぎない。どうせできない。大事なのはプロセスではない。大事なのは、プロセスを改善しようとするプロセスである。 Henrik Kniberg 136

Perfection is a direction, not a place Henrik Kniberg 137

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

http://www.ryuzee.com	823
http://paper.li	13
url_unknown	3

Scrum & Kanban

by Kiro Harada on Aug 29, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 839

Statistics

Scrum & Kanban — Presentation Transcript