Scrum & Kanban

  • 8,181 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
8,181
On Slideshare
0
From Embeds
0
Number of Embeds
6

Actions

Shares
Downloads
457
Comments
0
Likes
26

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 4. プレゼンテーションの目的 Scrum と Kanban を比較して、両者をよりよく理解する あなたが、自分のコンテキストで、 Scrum や Kanban をどう活用できるか自分で考えられるように Henrik Kniberg 4
  • 5. Your knowledge? Veteran Use Tried Scrum Kanban Seen Read 5 Henrik Kniberg
  • 6. 知識レベル? ベテラン 使った 試した Scrum Kanban 見た 読んだ 6 Henrik Kniberg
  • 7. Scrum in a nutshell Henrik Kniberg 7
  • 8. Scrum 超入門 Henrik Kniberg 8
  • 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 超入門 製品を分割 大きなグループが長い時間をかけて、巨大なものを作る 小さなグループが短い時間に、小さなものを作る ただし、しょっちゅう統合して、全体を見る プロセスを最適化 ビジネス価値を最適化 $$$ 時間を分割 1月 4月 $ 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)
  • 12. 最低限のチェック コア・スクラム the unofficial (非公認) この項目ができていたら、残りのチェックリス ト項目は無視していい。あなたのプロセスはう まくいっている。 定期的(4週間以内)に動作する、テスト済 スクラムの主要要素。これらを抜きにして、 スクラムと呼ぶことはできないだろう スプリントごとにふりかえりを Scrum Checklist みのソフトウェアを提供している 行えている スクラムチェックリスト Henrik Kniberg 結果として具体的な改善提 ビジネスニーズに基づいたものを最優先し て提供している 案を行っている 実際に、実現できた提案が 推奨項目(いつも必要というわけではない) ある ほとんどの項目は必要になる事が多い、すべて常に必要というわけではない。試してみて! プロセスを継続的に改善している チームとプロダクトオーナ チームは、バックログ項目を完了させ プロダクトバックログは、1スプリン ーの全員が参加している るために必要なスキルを全て持つ ト以内のタスクに分割されている はっきりと定義されたプロダクトオー プロダクトオーナーはプロダクトバッ チームメンバは特定の役割に固 スプリントタスクの見積りが行 ナー(PO) クログ(PBL)を持っている われている 定されていない プロダクトオーナーは、優先度 上位項目はビジネス価値に基づ 失敗が避けられないイテレーションを 実行中のタスクの見積りは 付けをする権限をもつ いて優先度付けされている 早めに強制終了している 毎日更新されている プロダクトオーナーは、優先度 上位項目は見積り済み 付けをする知識をもつ である POは プロダクトバックログと連動す るプロダクトビジョンをもつ ベロシティが計測されている プロダクトオーナーは、直接 チ 見積りはチームが ームと話している 行っている プロダクトバックログとプロダクトビ スプリント計画で、対象の ジョンを見える化している 項目が見積りを持っている プロダクトオーナーは、直接 ス 上位項目は1つのスプリントに テークホルダと話している 収まる規模になっている チームの全員が見積もりに参加 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)
  • 13. Kanban in a nutshell Henrik Kniberg 13
  • 14. Kanban 超入門 Henrik Kniberg 14
  • 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
  • 17. Kanban @ Imperial Palace Gardens Henrik Kniberg 17
  • 18. Kanban @ Imperial Palace Gardens Henrik Kniberg 18
  • 19. Kanban 看板 ”Visual Card” Signaling system Visual Limited in supply Henrik Kniberg 19
  • 20. Kanban 看板 ”Visual Card” 通知システム 見える 量の制限 Henrik Kniberg 20
  • 21. Kanban in your wallet Darn. Forgot to limit. Henrik Kniberg 21
  • 22. 財布の中のKanban あ、量の制限を 忘れてる! Henrik Kniberg 22
  • 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
  • 24. トヨタのかんばん Buyer バイヤー Supplier サプライヤ Consume Detach Receive Ship Allocate Manufacture 使用 外れ 受領 出荷 引当 製造 「トヨタ生産方式」を運用するの につかわれるツールは、かんばん である 大野耐一 原田騎郎氏のスライドより引用 トヨタ生産方式の父 Henrik Kniberg 24
  • 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
  • 27. Kanban example Board shared by 2 teams (16 people in total) Henrik Kniberg 27
  • 28. Kanban の例 ボードは2チームで共有されている (合計16人) Henrik Kniberg 28
  • 29. Compare for understanding, not judgement Henrik Kniberg 29
  • 30. 理解をすすめるため に比較する。 判断するためではな い。 Henrik Kniberg 30
  • 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
  • 38. どんなツールの間違った使い方ができる 昔のツールが よかった ツールを責めない! 38 Henrik Kniberg 38
  • 39. Why limit WIP? (work in progress) Henrik Kniberg 39
  • 40. なぜWIPを制 限するか? (WIP: 仕掛品) Henrik Kniberg 40
  • 41. Multitasking name game 準備 4 – 6人の顧客 1 開発者 Dave Lisa Bob Eric Maria Henrik Kniberg 41
  • 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 かかった時間を計算
  • 50. Multitasking name game Typical results Henrik Kniberg 50
  • 51. Multitasking name game よくある結果 Henrik Kniberg 51
  • 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
  • 53. 不必要なマルチタスクの原因 開始することに集中して、終了を意識し ない WIPを制限しない 人を忙しくしておくことに集中する(ゆとり 時間を恐れる) 症状を直すことと“理由”を受け入れて、 問題を気にしない。 水をかき出す 浸水 穴を直す ボートに穴 Henrik Kniberg 53
  • 54. Kanban & Scrum Real-life example Henrik Kniberg 54
  • 55. Kanban & Scrum 実例 Henrik Kniberg 55
  • 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
  • 57. ケーススタディ デザイン完了ゲーム 製造可能 ゲーム ゲームバックログ 15 12 8 グラ コンセ Lisa がリ サウン フィッ 統合 & 配 Sam プト作 ソース割 ドデザ 開発 クデザ 布 成 り当て イン 2d 1m 6m 1w イン 6m 6m 2h 4h 1d 1m 3w 3m 3w (1m+2m) 付加価値作業 3分 プロセス = 12% サイクル サイクルタイム 25分 効率 57
  • 58. Limit work to capacity Input: 3 customers / hour Output capacity: 2 customers / hour Henrik Kniberg 58
  • 59. 仕事の量を能力容量に合わせる 入力: 3 顧客 / 時 出力容量: 2 顧客 / 時 Henrik Kniberg 59
  • 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
  • 64. One day in Kanban land Henrik Kniberg 66
  • 65. Kanban チーム の一日 Henrik Kniberg 67
  • 66. ”One day in Kanban land” http://blog.crisp.se/henrikkniberg/tags/kanban/ Henrik Kniberg 68
  • 67. シナリオ 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
  • 68. シナリオ 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
  • 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 71
  • 70. 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
  • 71. シナリオ 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
  • 72. シナリオ 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
  • 73. シナリオ 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
  • 74. シナリオ 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
  • 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 77
  • 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 78
  • 77. シナリオ 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
  • 78. 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
  • 79. シナリオ 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
  • 80. シナリオ 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
  • 81. Evolve your process Henrik Kniberg 83
  • 82. プロセスを 進化させる Henrik Kniberg 84
  • 83. 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
  • 84. Kanban & Scrum は経験的手法である 容量 リードタイム 品質 予測可能性 (aka ベロシティ) (aka サイクルタイム) (バグ率, etc) (SLA 満足率, etc) Kanban is more configurable すばらしい! まいるなぁ 多数の小チーム 少数の大チーム 選択肢が広い! そんな沢山決めることが! WIP 制限小 WIP 制限大 ワークフロー状態少 ワークフロー状態多 イテレーション無 長いイテレーション 最小限の計画 綿密な計画 .... etc ... .... etc ... Henrik Kniberg 86
  • 85. 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
  • 86. 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) = 現在作業中の 現在作業中の • もっとも古いもの 担当者 担当者
  • 87. Kanban evolution example April 7 April 23 Henrik Kniberg 89
  • 88. Kanban ボードの進化の例 4月7日 4月23日 Henrik Kniberg 90
  • 89. 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
  • 90. 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
  • 91. Evolve your own unique board! Some of these photos courtesy of David Anderson, Mattias Skarin, and various other people Henrik Kniberg 93
  • 92. 自分のKanbanボードに進化 写真は、David Anderson、 Mattias Skarin、ほか多くの人から提供 いただきました。 Henrik Kniberg 94
  • 93. Kanban compared to Scrum Henrik Kniberg 95
  • 94. Kanban Scrum と比べ てみる Henrik Kniberg 96
  • 95. Product Team Scrum owner Master Scrum prescribes roles, Kanban doesn’t PO SM Henrik Kniberg 97
  • 96. プロダクト チーム スクラム オーナ マスタ Scrum は役割を指定する, Kanban はしない PO SM Henrik Kniberg 98
  • 97. 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
  • 98. 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
  • 99. 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
  • 100. Scrum のバックログ項目は、1スプリントに収まる必要 がある。 Scrum Sprint 1 Sprint 2 Sprint 3 Sprint 4 Kanban 長いタスク WIP 制限 = 3 長いタスク Henrik Kniberg 102
  • 101. 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
  • 102. 両方とも 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
  • 103. 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
  • 104. 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
  • 105. Scrum board is reset between each iteration Scrum First day of sprint Mid-sprint Last day of sprint Kanban Any day Henrik Kniberg 107
  • 106. Scrum ボードは、イテレーションごとにリセット Scrum スプリント初日 中盤 スプリント最終日 Kanban いつでも Henrik Kniberg 108
  • 107. 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
  • 108. 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
  • 109. 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
  • 110. 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
  • 111. 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
  • 112. 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
  • 113. 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
  • 114. 複数の製品を同時に扱うのは、どちらもで可能 (どうしても必要ならね…) Scrum 例 1 Kanban 例 1 色分けタスク Green 製品 Yellow 製品 Green チーム Yellow チーム Scrum 例 2 Scrum 例 3 Kanban 例 2 全製品 全製品 色分けレーン 製品横断チーム 製品横断チーム Henrik Kniberg 116
  • 115. Minor differences Henrik Kniberg 117
  • 116. 小さな違い Henrik Kniberg 118
  • 117. Minor difference: Scrum prescribes daily meetings ... but many Kanban teams do that anyway. Henrik Kniberg 119
  • 118. 小さな違い: Scrum は、毎日のミーティングを指定している ... まあ、Kanban チームも多くはやってます Henrik Kniberg 120
  • 119. 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
  • 120. 小さな違い: Scrum は、優先度付けされたプロダクトバックログを指定してます Scrum: Kanban: プロダクトバックログが必須 プロダクトバックログは任意 プロダクトバックログに対する変更は プロダクトバックログに対する変 、次のスプリントで反映される (今 更は、能力が空いた時点で反映さ のスプリントではない) れる プロダクトバックログは、「ビジネス価 優先度付けの方法は任意。例えば 値」順に並べる必要がある : 好きなものを選んでよい 一番上を常に選ぶ 一番古いものを常に選ぶ 20% は保守項目を、80% 新規フィ ーチャー開発を選ぶ 能力量を製品Aと製品Bで等分する 赤いものを常に選ぶ ポリシー Henrik Kniberg 122
  • 121. 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
  • 122. 小さな違い: 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 リードタイム 6日 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
  • 123. Final points Henrik Kniberg 125
  • 124. まとめ Henrik Kniberg 126
  • 125. 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
  • 126. http://www.infoq.com/minibooks/kanban-scrum-minibook Kanban & Scrum 比較のまとめ 類似点 相違点 Scrum Kanban リーンで、アジャイル タイムボックスを固定したイテレー タイムボックス固定イテレーション プルによるスケジューリングに基づく ションを指定 の選択は任意 WIP を制限する イテレーションの中での作業量を、 コミットメントは任意 プロセス改善を促進するために、透明性を活用 チームがコミットする する 計画やプロセス改善に使う基本の指 計画やプロセス改善に使う基本の指 早期かつ頻繁な使えるソフトウェアの提供に重 標は、ベロシティ 標は、リードタイム 点をおく 機能横断チームが指定 機能横断チームは任意 自己組織化したチームに基づく 専門家チームも可能 1スプリント内で完了するように、項 項目のサイズに制限はない ワークを部分に分割する 目は分割される リリース計画は、経験データにもとづき絶えず改 バーンダウンチャートが指定 特に指定のダイアグラムはない 善され続ける(ベロシティ/リードタイム) 間接的にWIPを制限 (スプリントあ 直接的にWIPを制限 (ワークフロー たり) の状態ごとに) 見積もりは必須 見積もりは任意 実施中にイテレーションに項目は足 容量があるならいつでも項目を足せ せない る スプリントバックログは、特定の1 Kanban ボードは、複数のチームや個 チームが保有 人で共有することもできる 役割を3つ指定 (PO/SM/Team) 役割を指定していない Scrum ボードは、スプリントごとに Kanban ボードはずっと使われる リセットされる Henrik Kniberg 優先度付きのプロダクトバックログ 優先度付けは任意 128 を指定
  • 127. Free download http://www.infoq.com/minibooks/kanban-scrum-minibook Henrik Kniberg 129
  • 128. フリーダウンロード http://www.infoq.com/minibooks/kanban-scrum-minibook Henrik Kniberg 130
  • 129. 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
  • 130. 教条主義に陥らない 立ち去れ。話しかけるな。 スプリント中だ。 三週間後に 汝、WIP 来たまえ 制限を守り給え Henrik Kniberg 132
  • 131. 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
  • 132. 必須なスキル プロセスによらず システムを利用可能な単位 ソフトウェア 振り返り に分割する 職人芸 As a buyer I want to save my shopping cart so that I can continue shopping later Henrik Kniberg 134
  • 133. 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
  • 134. お持ち帰り用のポイント 1. ゴールを知ること ヒント: Agile/Lean/Kanban/Scrumはゴールではない。 2. ツールを非難しないこと ツールが成功したり、失敗したりはしない。するのは、人。 ツールに良い悪いもない。ツールを使う時、場所、方法、目的、選び方などに 、よい判断と悪い判断があるだけだ。 3. 一つのツールにこだわるな 自分自身を広げること 判断のためでなく、理解のために比較する 4. 実験して、ライドを楽しもう はじめから正しくやろうと心配しすぎない。どうせできない。 大事なのはプロセスではない。大事なのは、プロセスを改善しようとするプロセス である。 Henrik Kniberg 136
  • 135. Perfection is a direction, not a place Henrik Kniberg 137
  • 136. 完璧とは方向のことであって、場所ではない。 Henrik Kniberg 138