この記事は 「ひとりでアジャイルo0h② Advent Calendar 2021」のday-10です。
adventar.org
day-2は「Scrumban: And Other Essays on Kanban Systems for Lean Software Development」です。
12/3から始まった「リーン/カンバン祭り」が、本日で最終日です。
どんな本
「スクラムに、よりリーンな実践を取り入れる」という事を志向したスクラムバン(Scrumban = Scrum + Kanban)という考え方があります。
本書はそんなスクラムバンについて書かれた本です。
「スクラムの欠点を補完する」というよりかは、「アジャイルを超えてリーンに進む」ために「スクラムをカンバン色にしていく」ようなものであるように感じました。
ただし、ここでいう「欠点」というのは、スクラムが「絶妙なバランスを取って保護していた」部分のガードレールを取っ払うような印象も受けます。
スクラムとカンバンの、あるいはアジャイルとリーンの「どっちがいいか」は課題やチームによるし、「二者択一的な意思決定を迫られる」ものではなくて「適切な塩梅を見つけること」がリーダーないしマスターに求められることだと思います。
※ 本書中では「アジャイルとリーン」は別物であるように扱われているので、この記事中でも別物として扱います。*1なお、著者の主張のウエイトは「(可能であれば)アジャイルを超えてリーンに進め」であるかのように感じています。
スクラムバンについての情報をいくつか貼っておきます。
↓本書の著者による記事
www.agilealliance.org
↓ スクラム、カンバン、スクラムバンの比較
blog.gurock.com
↓スクラムバンに対する批判
www.infoq.com
↓ スクラムバンではなく、「スクラムにカンバンを融合した」考え方
medium.com
自分自身が本書を読んだきっかけは、新しいプロジェクトに取り組む際に「スクラムをしっかりやるには能力やリソースが足りない、明らかにScrum-butになるが何かプラクティスで補完する事は可能なのだろうか?」と探求して「スクラムバン」という概念に出会ったからでした。
うまく扱えるレベルまで紹介している情報がWeb上で見つけられなかったので、原典っぽい本を買ってみよう〜と思った次第です。
全体的に、「リーンについてもカンバンについてもスクラムについても理解している」というレベル感にある読者を想定しているような感じです。
実際、著者の表現を紹介すると
"I’ve been getting into a lot of detail about how to apply Lean ideas to software development. Perhaps I sometimes take it for granted that we understand why we should apply them."
Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press. Kindle 版.
と書かれています。(しかも70%強ほど読み進んだところでw)
お気に入りポイントかいつまみ
プロジェクトマネジメントにおける「バッファ」の考え方
「リソース効率(最適)」「フロー効率(最適)」については、「This is Lean」で詳しく扱われていてわかりやすかったです。
スクラムは・・というか本書の立場にたてば「アジャイルでは」ということになりますが、仕事量をタイムボックスで管理しています。
「一定期間に行える仕事量を(経験的に)算出して、そこに見合うプロダクトバックログをスプリントに組み込め」です。
プロジェクトマネジメントにおけるバッファとは、「計画を実行するために/進捗をブロックさせないために、理想的なI/Oに対してInputを増やすかOutputを減らして(妥協させて)、余裕をもたせるもの」です。
例えば、タイムボックスを用いてイテレーションを行っている場合は、時間辺りの創出価値が生産性なので、「仕事量を減らす」ことで時間にバッファをもたせます。
リソース効率ベースの場合は、作業リソースの使用率が生産性なので、「投入する機材や人員を増やす」ことでリソースにバッファをもたせます。
リーン思考の場合は、スループットが生産性なので、「仕事の無駄を減らす、フローを最適化する(止まっている仕事をなくす)」ことが是であり、例えば「在庫を減らす」という取り組みが行われますから、バッファをもたせるというのは「在庫を持つ(止まっている仕事を増やす)」ことになります。
本書を読んでいて「なるほど!」と思ったのは、カンバンにおけるバッファを持つとは、すなわち「作業フローに流せる(="ready"な)タスクを増やす」ことである、という点です。
極端に言えば、「よく見積もられて、詳細な仕様定義をもって完全にタスク分割が済まされたバックログがある」のは「無駄」という訳です。
この無駄を極限まで抑えて、かつ「ストップ」が発生しないようにする・・というのがカンバンの目指す理想状態*2です。
そのためには「在庫ゼロ」「WIP=1」が最も良い状態です。
ある意味、「ただし摩擦係数はゼロとする」とか「自宅から学校までの2kmを時速5kmで全く立ち止まること無く歩くタカシ君」みたいなものでしょうか。
"However, controlling the size of the buffers is still very important. The ideal buffer size is 0, because all buffers are waste, but if a buffer is necessary for synchronization, then the ideal size is 1. If the buffer size grows much bigger than one, then you might consider adjusting downward the WIP limit of the upstream state instead. Remember that the only goal of the kanban buffer is to create the appearance of instant availability downstream."
Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press. Kindle 版.
「1個流し」についての言及はこちら
"In pull scheduling, One Piece Flow is the ideal result. A Value Stream identifies all of the processing steps that are applied to component materials in order to make the desired product. "
Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press. Kindle 版.
ここから「スクラムの欠点」が説明されており、「10日後に必要になるバックログを、なぜ今の時点で用意しなければならないのか?それは在庫を抱えるのに等しい」という事になります。
在庫を抱えた時点で過剰在庫・破棄リスクが発生します。タイムボックス駆動での活動は、「明日の要求変更に応えられない」可能性があるのです*3。極限までリーンを実践しようとすれば「正しくない」のです。
刺激的な観点ではあるな・・・・と感じました。
XP・スクラムと同様にデイリーミーティングは実施可能なのですが、その中身がスクラムのデイリースクラムとは異なるようです。
- デイリースクラム: メンバーが、スプリントゴールの達成の阻害要因になっていることをチームに共有する
- カンバンのデイリースタンドアップ: ブロックされているものがある人がチームに共有する
大きく違うのは「期間が固定されたイテレーションがない」ことで「短期的なゴール」がないから、協働の仕方が変わるという面があると思います。
また、明確に「スクラムマスター」や「プロダクトオーナー」も置かない(決まりになっていない)ので、各々が自主的に自分の課題を取り扱うことを求められます(スクラムだと、スクラムマスターが補助したりします)。
また、カンバンにおいては全てがオンデマンドで行われるため、「止まっている・止めているものがあれば当事者同士で解決すればいい」「動かせるものがあればどのタイミングでも任意に動かしていい」という前提から「定期的な打ち合わせが、よりミニマム(無駄を削ぎ落とした)ものになる」ようになります。
・・・といっても、スクラムであろうと「自分たちでタスクを持っていい」し「手が空いたら翌朝を待たずに次に行っていい」だと思うので、やろうと思えば逸脱しない範囲内でも十分ににたやり方は出来る気もしますが。目的が「ゴールに行ける確からしさを高める」ではなくなるので、その点は明確に違いそうですね。
スクラムバンとは何か / スクラムチームがどう取り入れるか
コレが本書で得たいと思って期待していた部分。
スクラムバンは「徐々にリーンに移行していく」ことを目指して考えられているような雰囲気です。
その段階を「スクラムと互換性を持ちながらやるフェーズ」「スクラムから離れるフェーズ」に区分けしています。
前提として、本書が想定しているスクラムが
- スプリントプランニング時に、タスクをメンバーにアサインしている
- タスクの管理(進捗のビジュアライズ)は、インデックスカードをホワイトボード上に貼って(=カンバンボード)管理している
- to do / in progress / done
- デイリースクラムは全員が喋るようにしている(”3つの質問”みたいなものを想定していそう)
他方で、カンバン/リーンなプロジェクトの肝は
あたり。
スクラムは「集中」と「学習効果を向上する・経験主義」のために固定されたタイムボックスを武器としますが、もはや「1ヵ月や1週間であっても、その間は在庫を持たなければいけない」というところを気にしているような雰囲気です。
"Once you’ve broken up the timebox, you can start to get leaner about the construction of the backlog. Agility implies an ability to respond to demand. The backlog should reflect the current understanding of business circumstances as often as possible. In other words, the backlog should be event-driven. Timeboxed backlog planning is just that, where the event is a timer, and once we see it that way, we can imagine other sorts of events that allow us to respond more quickly to emerging priorities. Since our system already demonstrates pull and flow, that increased responsiveness should come at no cost to our current efficiency."
Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press. Kindle 版.
まずは最初のフェーズに進む
A problem with the basic index-card task board is that there is nothing to prevent you from accumulating a big pile of work in process. Time-boxing, by its nature, sets a bound on how much WIP that can be, but it can still allow much more than would be desirable. If a kanban is a token that represents a work request, and our task board can still get out of control, then what is the problem here? The problem is that a kanban is more than just a work request on a card, and putting sticky notes on a whiteboard is not enough to implement a pull system.
Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press. Kindle 版.
とのことなので、この辺の「気になる所」を直していきます。
The simple approach is to start with Scrum-like iterations and iteration planning process, and begin to add pull features to the team’s internal process.
Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development . Modus Cooperandi Press. Kindle 版.
これならすぐに出来るよね、ということで紹介しているテクニックが
- WIPの制限を設ける
- これは「ブロックされている人」がWIPにあるものを助けに行く、というのを促す
- これによってスループットを挙げる
- ペアプロを含めたスウォーミングの実践や、タスクの更なる細分化ができるかな?
- ※「WIPの制限」で「ユーザーストーリー(=顧客に提供できる価値の実装)」を制限して、その構成要素である「タスク」は同時に扱って良いんじゃない?って考え方は「カンバン仕事術」に
- タスクのアサインを遅延させる
- (デイリースクラム等で)作業者が着手可能になった時点で、to doの最上部にあるタスクにサインアップする
ここまでで「プルシステム」を完成させ、更に「継続的改善を促すための強化」を提案しています
- レーンの分割: WIPを→分析/設計/実装に
- WIP制限をかけている以上、「どこでブロックが発生するのか(ボトルネックの探索)」は不可欠になる
- 「着手済み」だけだと、見える化の仕組みであるカンバンが提供してくれる情報が少ない
- 工程を細分化することで、チームのウィークポイントや協働の促進を実装する
- 障害点が自動的に顕在化してくる、という意味での「自働化」の要素とも言える
- 更に、分割された各レーンにそれぞれ別個の制限数を設けることが可能
- 肩書の少ないクロスファンクショナルチームが前提であるが、比較優位が働くようにアサイン・タスクの交換が進む方が全体効率が実現するので
こうして、「スクラムにリーンのワークフローを取り入れる」ことが可能になりました。
次のフェーズ: スクラムバン
いよいよスクラムのルールを逸脱します。
・・・といっても、チーム構成等は変わらない(変わらなくてもカンバンが実践できる)ので、可変要素は「アーティファクト」「イベント」のみです。
大きく言うと「スプリント」の概念が外れます。その結果、「スプリントプランニング」の中身が変わり、「スプリントレビュー」が無くなります。
ざっくりとまとめると、以下のようになるのでしょうか
- 「スプリント」をやめて、いつでも「ユーザーが欲しい物に取り組める」ようにしろ
- 「計画」「見積もり」のコストが高すぎる、やめろ
- 「次にやるべきもの」にだけ集中していればいいから、計画はいらない
- 「一定期間に入る量」を考えなくて良いのだから「1つ1つの大きさ」を考えるコストをなくして、その分は「価値生産」に振リ分ける
- 定期的なプランニングミーティングは行ってもいいが、「これからの計画を作る」ものではなく「在庫が不足しているものを補う」ためのものになる
- 「バーンダウン」や「ベロシティ」はやめろ
- 「バーンダウン」や「リードタイム」は結果であり、チームのヘルスを測るなら「サイクルタイム」の方に意味を感じるようになるはず
- サイクルタイムを用いれば、WIPの制限数や必要なバッファ、バックログをレディにすべきタイミングの最適化に利用できる
まとめ
「アジャイルと言えばスクラムになってしまった」というのは「Clean Agile」でも指摘されており、また、なんとなく「最終的にはXPに向かう」「スクラムは入門に最適で、守破離を経てbe agileを進化させていくもの」なんて言説も見かけたりします。
そうした意味で、「アジャイルのその先」「スクラムを超える」という地平はどこかにはあるんだろうな、と感じます。
スクラムは「軽量」なフレームワークでありつつ守るべきものからしっかりと守ってくれているような価値がしっかりあります。どういったコンテキストにおいてどういう課題を解決しているのか?は、スクラムガイドよりも寧ろ「組織パターン」等を読むことで感じられる部分もあるかも知れません。
それゆえ、易きに流れる・・という判断は避けたいものですが、確かに「カンバン」ないし「スクラムバン」も面白そうなものを感じるのは確かです。
チームや隣接するステークホルダーのObserveから始めて、対話をしながら「何が必要か」と「次のステップ」を見極めながら組織を導ける人になってみたいものです。
という訳で、リーン/カンバン祭りはここまで!