scrum

agile

私たちは、software 開發の實踐あるいは實踐を手助けをする活動を通じて、よりよい開發方法を見つけださうとしてゐる。この活動を通して、私たちは以下の價値に至った。

process や tool よりも個人と對話を、

process や tool に使はれるのではなく process や tool を使ふ

no-process は NG。no-process は自然の process に使はれる事。作爲せねばならない

包括的な document よりも動く software を、

契約交渉よりも顧客との協調を、

計劃に從ふことよりも變化への對應を、

價値とする。すなわち、左記のことがらに價値があることを認めながらも、私たちは右記のことがらにより價値をおく。

私たちは以下の原則に從ふ :

顧客滿足を最優先し、價値のある software を早く繼續的に提供します。

要求の變更はたとへ開發の後期であっても歡迎します。

變化を味方につけることによって、お客樣の競爭力を引き上げます。

動く software を、2-3 週閒から 2-3 ヶ月といふできるだけ短い時閒閒隔で release します。

business 側の人と開發者は、project を通して日々一緒に働かなければなりません。

意欲に滿ちた人々を集めて project を構成します。

環境と支援を與へ仕事が無事終はるまで彼らを信賴します。

情報を傳へるもっとも效率的で效果的な方法は fact-to-face で話をすることです。

No。半二重 communication (會話) の範圍を限り、更には減らせ

廢止したくはない

會話を汎ゆる communication の最上位に置くな

會話に使はれるのではなく會話を使ひませう

動く software こそが進捗の最も重要な尺度です。

agile process は持續可能な開發を促進します。

一定の pace を繼續的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に對する不斷の注意が機敏さを高めます。

simple さ (ムダなく作れる量を最大限にすること) が本質です。

最良の architecture・要求・設計は、自己組織的な team から生み出されます。

team がもっと效率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

dual track agile

好い物を (discovery) 好く作る (delivery)

向き直り (discovery) + 振り返り (delivery)

cf. multi 學習

XP (eXtreme Programming)

第 4 章 價値

4.1 communication

team による software 開發で最も重要なのは、communication である。開發中に問題が發生したときには、すでに誰かが解決策を知ってゐることが多い。だが、その情報は變更する權限のある人には傳はらない。情報があるのに傳はらないのは、自分の直感を無視するときの心の內面と同じだ。他人と communication する必要があるときには、その影響の度合いはさらに惡化する。

「情報があるのに傳はらないのは、自分の直感を無視するときの心の內面と同じだ。」

monadology (fractal)

4.2 simplicity

私は「最も simple で、うまくいきさうなものは何ですか?」と質問するやうにしてゐる。批判する人たちは、質問の後半部分を見逃してゐるやうだ。「我々には深刻な security や信賴性といった制約がありますので、system を simple にはできません」などと返ってくる。私は、simple すぎてうまくいかないものについて質問しているわけではない。ムダな複雜性を排除するために、何ができるかを考へてもらってゐるのだ。

communication によって、現狀の觀點からは必要がない、あるいは時閒的猶豫のある要件を削除すれば、それが simplicity の達成につながる。simplicity を達成すれば、必要な communication も少なくなる。

4.3 feedback

feedback は communication に缺かせない。「performance は問題になるかな?」「わからないね。performance 測定用の prototype を作って確認してみよう」。feedback は simplicity にも影響する。3 つの解決策のなかで、どれが最もsimple になるだらうか? そんなときは、3 つすべてを試して確認してみよう。同じものを 3 囘實裝するのはムダに思へるかもしれない。だが、simplicity が備はった納得できる解決策にたどり着くには、かうするのが最も效率的な方法だらう。それと同時に、system が simple になれば、その分だけ feedback を受け取ることも簡單になる。

4.4 勇氣 (courage)

勇氣のみでは危險だが、他の價値と合はせれば強力だ。勇氣を持って眞實を語れば (たとへそれが不愉快なことであっても)、communication や信賴が強化されていく。うまくいかない解決策を捨てて、勇氣を持って新しい解決策を見つければ、simplicity が促進される。勇氣を持って現實の具體的な答へを求めれば、そこから feedback が生まれる。

4.5 respect

software 開發に關係してゐる人は、人閒として等しく重要である。他の人よりも本質的に重要な人などゐるはずがない。software 開發において人閒性と生產性を同時に高めるには、team に對する個人の貢献を respect する必要がある。私も重要であり、あなたも重要だ。

第 5 章 原則

5.1 人閒性 (humanity)

5.2 經濟性 (economics)

5.3 相互利益 (mutual benefit)

5.4 自己相似性 (self-similarity)

fractal

5.5 改善 (improvement)

5.6 多樣性 (diversity)

5.7 ふりかへり (reflection)

5.8 流れ (flow)

5.9 機會 (opportunity)

5.10 冗長性 (redundancy)

5.11 失敗 (failure)

5.12 品質 (quality)

5.13 baby steps

5.14 責任の引き受け (accepted responsibility)

第 7 章 主要 practice

7.1 全員同席 (sit together)

7.2 team 全體 (whole team)

そのためには、以下のやうな「team」感が必要だ。

我々は、歸屬してゐる。

我々は、一緒の仲閒である。

我々は、お互ひに仕事、成長、學習を支へ合ってゐる。

7.3 情報滿載の workspace (informative workspace)

課題を解決できたり、chart の更新が滯ってゐたりすれば、すぐに外してしまおう。その space は重要な現在進行形の情報のために使ひたい。

かんばん board

7.4 いきいきとした仕事 (energized work)

7.5 pair programming

mob programming

7.6 stories

user story

user story mapping

event storming

7.7 週次 cycle (weekly cycle)

7.8 四半期 cycle (quarterly cycle)

四半期の計劃では、以下のことを行う。

bottleneck を特定する (特に team の外側で制御されてゐるもの)。

修正作業に着手する。

四半期の theme を計畫する。

「theme」を「story」と區別してゐるのは、team が全體像と今週の story の調和を考えずに、今やってゐることだけに集中する傾向があるからだ。theme は marketing の loadmap を描くやうな規模の大きな計劃にも適している。

dual track agile

theme に取り組むための四半期分の story を選擇する。

project を組織に適合させる全體像に集中する。

7.9 餘裕 (slack)

技術的 spike

survival mode から拔け出す

7.10 10 分 build (ten-minute build)

7.11 繼續的 integration (continuous integration; CI)

7.12 test-first programming

7.13 incremental な設計 (incremental design)

第 9 章 導出 practice

9.1 本物の顧客參加 (real customer involvement)

9.2 incremental な deploy (incremental deployment)

9.3 team の繼續 (team continuity)

9.4 team の縮小 (shrinking teams)

9.5 根本原因分析 (root-cause analysis)

9.6 code の共有 (shared code)

9.7 code と test (code and tests)

9.8 單一の code base (single code base)

9.9 daily deployment

9.10 交渉による scope 契約 (negotiated scope contract)

9.11 利用都度課金 (pay-per-use)

價値

確約 (commitment)

八割 (これは適當) の主觀的確率で完了出來る sprint goal

集中 (focus)

仕掛かり (WIP、やりかけ) を減らす

swarming

公開 (openness)

敬意、尊敬 (respect)

寛容さ

acceptance

勇氣 (courage)

役割

PO (product owner)

SM (scrum master)

開發者

成果物

product backlog

product goal を示す

PO が PBR (product backlog refinment) にて作る

PBI (product backlog item) が優先度順に竝ぶ

完了の定義が明白である

見積もりが成されてゐる

sprint backlog

sprint goal を示す

sprint goal を達成する主體は team である

開發者が sprint planning にて作る

product backlog の上位を元に作る

increment

sprint で製品に附け加へた價値

開發者が sprint にて作る

done の定義

遲延 : undone work に對處するためには追加の努力が必要です。これは柔軟性の缺如をもたらし、PO は市場の needs や變化に直接對應出來なくなります。undone work を完了するための努力は非常に變動的で豫測しにくいため、この遲延による痛みはより惡化します

risk : undone work は透明性の缺如を引き起こします。risk はそこに隱蔽されます。例へば、もし性能 test が undone の場合、性能問題の露呈を release の直前――最惡の timing――まで遲らせることになりかねません

Done is better than perfect

Type A

sequential

waterfall

Type B

隣接 step との overlap

多工程持ち

Type C

離れた多くの step との overlap

6 つの特徴

1. 不安定な狀態を保つ (built-in instability)

矛盾にもちこたへる

不安定性を變化させる

自然な不安定性に任せる

2. project team は自ら組織化する (self-organizing project teams)

自己組織化

autonomy (自律性)

A00 (命) + ワイガヤ

zero information から始める

unlerning

宿命 / 受命 / 使命

例

self-transcendence (自己超越)

cross-fertilization (相互交流)

cross functional な team

3. 開發 phase を重複させる (overlapping development phases)

shared division of labor (協同して分業する)

4. multi 學習 (multilearning)

multifunctional learning

隣接分野の學習

橫へ

multilevel learning

個人の學習、個人閒の學習、組織の學習、組織閒の學習、法人の學習

double loop 學習

上下へ

cf. dual track agile

5. 柔らかな management (subtle control)

self-control

control through peer pressure

control by love

7 つの術

1. Selecting the right people for the project team while monitoring shifts in group dynamics and adding or dropping members when necessary.

2. Creating an open work environment

3. go out into the field and listen to what customers and dealers have to say.

4. Establishing an evaluation and reward system based on group performance.

5. Managing the differences in rhythm throughout the development process.

6. Tolerating and anticipating mistakes.

The key lies in finding the mistakes early and taking steps to correct them immediately.

if we do make mistakes, we ought to make them creatively.

7. Encouraging suppliers to become self-organizing.

But the project team should refrain from telling suppliers what to do.

suppliers produce better results when they have the problem explained to them and are allowed to decide how to furnish the parts.

6. 學びを組織で共有する (organizational transfer of learning)

unlerning

SoS (Scrum of Scrum)

Scrum@Scale

dual track agile

https://gyazo.com/838e7ed7ee23a73148a237f82459460c

scrum master cycle (how)

roles

scrum of scrum master (SoSM)

events

scaled daily scrum (SDS)

outputs / outcome

continuous improvement (繼續的改善) and impediment removal (障礙の除去)

cross-team coordination

deployment

product woner cycle (what)

product owner team

各 SoS は PO team を持つ

各 scrum の PO の集まり

PO team は backlog を持つ

MasterScrum

PO team で行ふ backlog refinment

Chief Product Owner (CPO)

PO team の長

SM cycle の SoSM に當たる

outputs / outcome

strategic vision

backlog prioritization

backlog decomposition & refinement

release planning

SM cycle と PO cycle の接續

feedback

metrics & 透明性

productivity : e.g. change in amount of Working Product delivered per Sprint

value delivery : e.g. business value per unit of team effort

quality : e.g. defect rate or service downtime

sustainability : e.g. team happiness

fractal

Executive Action Team (EAT)

EAT backlog

scrum with PO→PO MasterScrum with CPO→CPO MasterScrum with CCPO→CCPO MasterScrum with CCCPO→…

Executive MasterScrum (EMS)

https://gyazo.com/83a91ef18d18f3ac70be8c603bc1567b

knowledge teams

infrastructure teams

fractal iteration

pomodoro technique 🍅

15 分轉職

fractal team

team は個人の集合と考へるのではなく、個人は既に 1/n 個人達の team だと考へる。team は、sub-team 達の SoS

LeSS (Large-Scale Scrum)

https://gyazo.com/26c9930aae04362a1de6bbbd04448a02

原則

https://gyazo.com/512162a03f45d84277fad0f1f6533d14

經驗 base の process 管理

透明性

少なくすること (LeSS) でもっと多く

product 全體思考

顧客中心

完璧を目指しての繼續的改善

system 思考

lean 思考 (トヨタ生產方式)

https://scrapbox.io/files/610888e6e41943001ca130f9.webp

柱

人の尊重

繼續的改善

原則

long-term

flow

pull

less variability & overburden

Stop & Fix

master norms

simple visual management

good technology

leader-teachers from within

leadership engine

develop exceptional people

help partners be lean

Go See

consensus

reflection & kaizen

待ち行列理論

WIP (仕掛り、在庫) を減らす

WIP は未だ無價値

WIP が價値を產むには投資が要る

WIP (undone work を含む) は在庫であるから資源を消費し續ける

cycle time を短くする

制約理論 (Theory of Constraints; TOC)

主要因

製品 (deploy 單位) を共有する

PO (product owner) は一人

product backlog は一つ

release を共有する

sprint 期閒を共有する

職種ではなく顧客の要求に沿って team を分割する

cross functional で自律した (team 內で機能を完備し increment を作成出來る) team

events

sprint planning

https://gyazo.com/9af7adab371eb162da1c373d63140550

sprint planning 1

參加者 : PO + 各 team の代表者 (SM ではない!)

各 team が sprint で何をやるか決める

sprint planning 2

參加者 : 各 team の 開發者。各 team 毎、或いは複數 team が協同する

sprint backlog が作られる

sprint backlog を如何に完了するか計畫する

design session を行ふ事も出來る

daily scrum

參加者 : 各 team の 開發者

team が sprint goal を達成する事が目的

質問

昨日は何をしたか

今日は何をするか

障壁に成りさうなモノが無いか

team 閒の協調

→fractal team

observer を送り込む

PBR (product backlog refinement)

https://gyazo.com/8e8e1eb7afe701f07e6c5b431697d8bf

全體 PBR

參加者 : PO + 各 team の代表者

product backlog を優先順位に竝べる

完了の定義を決める

team PBR で議論可能な樣に PBI を各 team 毎の PBI へ分割する

team PBR

參加者 : team 毎或いは複數 team

複數 team で行ふ事が推奬される

PBI を實行可能にし、見積もる

sprint review + retrospective

https://gyazo.com/185c2b6ee02a5808aee818941b018b0b

sprint review

檢査適應であり檢査受入ではない

team 振り返り (team retrospective)

全體振り返り (overall retrospective)

參加者 : PO + SM + 各 team 代表

質問

team はどの程度協力してゐますか?

實踐共同體 (CoP; Communities of Practice) は機能してゐますか?

實踐共同體は、懸念、一連の問題、または topic に關する情熱を共有し、繼續的に對話することによってこの分野の知識と專門知識を深める人々の group です

team が行った、共有すべきことはありますか?

team は一緒に學んでゐますか?

team は顧客の近くにありますか?

team の運營方法に問題を引き起こす體系的な組織上の問題はありますか?

product owner は順調ですか?

product owner は 5 つの關係を維持してゐますか?

KPT (Keep, Problem & Try)

FDL (Fun, Done & Learn)

4Ls (Liked, Learned, Lacked & Longed for)

LeSS Huge

https://gyazo.com/d46916aa5809f1e1078a3a595f86d521

8 team より多くに分割する場合

PO (product owner) > APO (area product owner) + LeSS teams

Nexus

https://gyazo.com/e490717eaf26aaea1cf88c5c00520f3f

team 同士の依存要因

要求

domain 知識

software や test の作成物

役割

Nexus 統合 team

統合 increment を完成させる責任を負ふ

Nexus 統合 team の product owner

product backlog は一つ

Nexus 統合 team の scrum master

Nexus の實行に責任を負ふ

各 team には scrum master がゐる

各 team の scrum master を兼ねても好い

Nexus 統合 team の member

各 team の member を兼ねる。各 team の代表者

各 scrum team の成果を統合する

各 team での作業よりも統合 team での作業を優先する

作成物

product backlog

Nexus sprint backlog

Nexus sprint goal

統合 increment

event

product backlog の refinement

Nexus sprint planning

參加者 : 各 team の代表者

各 team 毎の sprint planning をこの後に行ふ

開發作業

CI (繼續的統合)

Nexus daily scrum

參加者 : 各 team の代表者

各 team 毎の daily scrum をこの後に行ふ

Nexus sprint review

參加者 : 全員 + stake holder

Nexus sprint retrospective

參加者 : 各 team の代表者

全體の振り返り→各 team 毎の振り返り→各 team 毎の振り返り結果の共有

SAFe (Scaled Agile Framework)

https://gyazo.com/b9e2e91de93b2aada01278f28ad7a493

https://gyazo.com/225cb39bddd716d7f63f7a3d17d0a1e4

matrix 型組織

但し勞働法上の指揮命令系統では無い

Spotify の遣り方を非分斷的にしたもの

衆 (chapter)、棟梁

座 (squad)、頭

「タスクが空いたときは、棟梁に相談して別の座のお手傳いをしてもOK。」

The Agile Transformation Kata (ATK) is a scientific approach to practice agile transformations. It is a structured training routine to learn something new or unfamiliar, until the practice becomes a new habit. This Kata is very different compared to other approaches, as it uses an agile mindset during the transformation process itself. This truly shapes the agile culture in all aspects of an organization and will lead to business agility.

指標

https://gyazo.com/46d4bf7a6acbc220828bd2cdded989e0

1. deploy の頻度 (deployment frequency)

Four Keys の script で deploy の頻度が Daily (毎日) bucket に分類されるのは、1 週閒のうち正常な deploy が 1 囘以上行はれた日數の中央値が 3 日以上である場合です。わかりやすく言ひ換へると、「毎日 deploy する」といふ category に分類されるやうにするには、ほぼすべての營業日に deploy を實行する必要があります。

次に、本番環境への deploy の成功の條件を檢討する必要があります。traffic の 5% のみに適用される deploy を含めるべきでせうか? 80% の場合はだうでせうか? 最終的には、これは team の個々の business 要件に應じて異なります。

elite : on-demand。日に數囘

high : 日に一囘～週に一囘

2. 變更の lead time (lead time for changes)

lead 時閒の中央値

elite : 一日未滿

high : 一日～一週

3. service 復元時閒 (time to restore service)

MTTR (平均修復時閒、mean time to restore)

elite : 一時閒未滿

high : 一日未滿

4. 變更障礙率 (change failure rate)

elite : 0～15%

high : 0～15%

d/d/d (deploys / a day / a developer)

0.1 以上を目指す

24 KC (24 key capabilities)

繼續的 delivery の促進效果が高い capability

1. 本番環境のすべての成果物を version 管理 system (VMS) で管理

IaC (infrastructure as code)

3. 繼續的 integration (CI; continuous integration) の實裝

4. trunk base の開發手法の實踐

寿命の長い feature branch を使はない。feature branch は作って一日以內に main branch へ merge する

6. test data の管理

7. 情報 security の shift left

8. 繼續的 delivery (CD; continuous delivery) の實踐

architecture 關聯の capability

9. 疎結合の architecture

10. team への tool 選擇權限の付與

製品・process 關聯の capability

11. 顧客 feedback の蒐集と活用

12. 全業務 process の作業 flow の可視化

13. 作業の細分化

14. team による實驗の奬勵・實現

lean 思考に卽した管理・監視に關はる capability

15. 負擔の輕い變更承認 process

16. 業務上の意思決定における、application と infrastructure の監視結果の活用

17.system の健全性の proactive (豫防的) な check

18. WIP (Work in Progress、仕掛り) 制限による process 改善と作業管理

19. 作業の可視化による、品質の監視と team 內 communication の促進

組織文化に關はる capability

20. (Westrum 推奬の) 創造的な組織文化の育成

table:Westrum が提唱した 3 type の組織文化とその特徴

不健全な (權力志向の) 組織 官僚的な (rule 志向の) 組織 創造的な (performance 志向の) 組織

協力態勢が惡い ほどほどの協力態勢 協力態勢が確立

情報傳達を阻止 情報傳達を輕視 情報傳達に熟達

責任逃れ 責任範圍が狹い risk を共有

仲介を阻止 仲介を許容 仲介を奬勵

失敗は責任轉嫁へ 失敗は裁きへ 失敗は調査へ

新規性をつぶす 新規性を問題化 新規性を實裝

Likert 尺度 (まったく同意できない、同意できない、やや同意できない、どちらとも言へない、やや同意できる、同意できる、強く同意できる)

質問

情報を積極的に蒐集する

失敗など、よくない news を知らせても罰せられない

責任を共有できてゐる

職能の垣根を越えた協働が推奬、報奬されてゐる

失敗があると調査が行はれる

新しい idea が歡迎される

失敗がまづ system 改善の機會と受け取られる

21. 學びの奬勵と支援

multi 學習

22. team 閒の協働の支援と促進

23. 有意義な仕事を可能にする tool 等の資源の提供

24. 改善を推進する leadership の實現や支援