スクラムマスターを雇う時に聞いてみるとよい38個の質問
はじめに
楽しそうなので回答してみました。
自分の回答
アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
型を守らせることで、「いつ」対話して「何を」得るのかをチーム・メンバに習得させるためと考える。 なので初めてスクラムに取り組むチームは最初からカスタマイズしようとせず、教科書通り全てのプラクティスを取り入れるべきだと考えている。標準とどうしても合わないものは後から見直しても十分間に合う。
自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
プロダクト開発・プロジェクトがステークホルダーの予想通り(予定通りではない)進捗していること。 スクラムマスターが扱う課題が技術・メンバなど内のものから、チーム・組織・プロダクトなど外に向かって変わってきていること。
追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
アジャイル開発・スクラム開発を取り入れて改善したかった事項をメトリクスにすれば良い。プロダクト・組織によって異なるので正解はない。 メトリクスはプロダクト・チームの状況を把握するきっかけとして使うべきで、値そのものを目標化しない方がよい。例えば生産性を上げるためベロシティを評価の指標としたらチームは見積もりの数字を大きくするだろうし、デプロイ回数に注目したら必要とされている顧客価値を提供できているかが後回しになるのではないかt。
あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
考えられる理由
- スケジュールが固定化しており、プロダクトオーナー・ステークホルダーがチームにバックログアイテムを与えすぎている。
- チームがスプリント期間中に全てのアイテムを完了できなくても良いと考えている。
- アイテムを完了させるための事前準備(アイテムのリファインメント、適切な分割)ができていない。
- 必要なスキルセットがチームに揃っていない。
対策
- スクラムマスターはデイリースタンドアップでアイテムが終わらない可能性を懸念として表明する。
- チームのふりかえりで議論の俎上にあげてもらう。
- 次のスプリントでは扱うアイテムを少なくし、完了させる状態が定常であることを認識させる。
- 準備・スキルの問題だと感じるときはリファインメントのやり方を見直す・技術習得の研修を計画するなどチームをサポートする対応を取る。
製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
もちろん参加してよい。 リファインメントに顧客・スクラムチームを招き、直接議論させる。
設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
バックログがメンテナンスされている状態を保てるようにサポートする。 上位にあるアイテムが適切に分割・見積もりされ、チームが着手できる状態になっているか、細かく詳細に入りすぎずプロダクトオーナーのマイクロマネジメントになっていないか、アイテムがステークホルダー・開発チームから上がっているフィードバックを考慮した上で妥当な優先順位で並んでいるかを確認する。
どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
スプリントを進めるにあたりステークホルダーへのアクセスが必要であればプロダクトオーナー・スクラムマスターに事前の断りを入れることなく直接コンタクトをとって進めてほしい。プロダクトオーナー・スクラムマスター・何らかの組織で決まった定例会議をボトルネックとしたくない。ただし、両者の話し合いで決まったことがあるのであればプロダクトオーナー・スクラムマスター・打ち合わせに参加していない人に対していつでも見えるようにして欲しい。
どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
まずはうまくいく1 チームを作る、広げるのはそれから。 ITじゃないメンバを巻き込む場合はカンバンの導入から入る、その次は定期的な振り返りかな。
上級管理職にどのようにスクラムを紹介するか
「今回のプロジェクトは自社にとって初めてのことが多いので、事前に詳細な計画を立てるのではなく、少しずつ検証しながら方針修正していきます。XX週間(1〜4)ごとに動くものを用意するので、ステークホルダーのあなたにはぜひアドバイスをいただきたいです。このご時世、メンバーの生産性も上げていかないとやっていけないので、こまめに振り返りを行い改善点を直していくようにします・・・」みたいな。
あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？
- 抵抗する人と話し合いの機会を持つ
- まずは1〜2週間やってみて、それから再度話しましょう
それでも改善が見られなく、他のメンバは順応し、チームの阻害要因になっていたらチームから外すことを検討する。
プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？
その流れで良い。バックログアイテムの分割に悩むようであればスクラムマスターと一緒にチームが取り組みやすい単位になるよう分割を行う。
チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
顧客・ステークホルダーの生の声を伝えて欲しい、できればそのまま。
誰がユーザーストーリーを書くとよいか？
プロダクトに関わる誰が書いても良い。チームメンバ・スクラムマスター・プロダクトオーナー・ステークホルダーなど。
よいユーザーストーリーとはどんなものか？どんな構造か？
「何をやるか」だけが書いてある。「どうやるか」についての記載がない。 さらにやることによって、「誰にとって」、「どんな価値があるか」、さらに「どうすれば価値を提供できているかを確認できるか」が書いてあると良い。
「Readyの定義」には何が含まれているべきか？
「何をやるか」について、チームが作業工数を見積もられる情報が揃っていること。
ユーザーストーリーを時間で見積もらないのはなぜか？
見積もりは正確にできない。担当するチーム・メンバーによっても必要な時間が変わる。 時間で見積もるとその時間内に完了させることが外に対してのコミットメントになりやすい。
プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
チケットが何個あろうがチームがスプリントに取り組めるのは上位の数個に限定される。 200個のチケットで重要なものが上位にきており、リファインメントがされていて、開発スピードとそこから予測できる開発計画に対してプロダクトオーナー・ステークホルダーと合意がとれていれば問題はない。
チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
プロダクトオーナーが上位に並べたアイテムについて、背景を質問する。
ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
開発工数に対して提供できる価値が大きいものを選ぶ。 開発できそうな目処が付いているのであれば提供できる価値の大きさだけに基づいて並べることもある。 売り上げやユーザ数だけに着目すると技術負債の解消に着手しづらくなるため、チーム・プロダクトオーナー・ステークホルダーで数スプリント単位の大まかな方針を握っておきたい。
上位に持ってきたいアイテムがあれば、リファインメントの際などにプロダクトオーナーにコメントを伝える。最終的にどう並べるかはプロダクトオーナーに任せる。
どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
ステークホルダー・プロダクトオーナー・メンバーと合意が取れていれば割合を気にすることなく費やして良いと考える。 とはいえ0にすると将来技術負債・スキル不足で苦しむことになるので毎スプリント10%ぐらいの時間は使うべきと考える。
チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？
スクラムマスターを通すように意見する。 バックログリファインメントなどプロダクトオーナーの責務に集中するよう何かプロダクト全体の課題になっていることの解決を依頼し、チーム内のやりくりは任せてもらうよう話をつける。
チームメンバーによるタスクのつまみ食いをどのように扱うか？
バックログアイテムの「上から」順に「1つずつ」担当するよう伝える。
ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
無理くり入れ込もうとしているならば、次のスプリントに回せないか話をする。もう少し時間が取れたらまた考えが変わるかもしれない。
どうしても今のスプリントに入れ込みたい場合、計画時に担当するアイテムを少なくして入れ込む余地を残しておく。ユーザーストーリーが確定し着手することになった場合も、担当する全アイテムがスプリントで完了するかをチームで判断し、終わらない場合はどれかを諦めてもらうようプロダクトオーナーと相談する。
スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
なぜ時間の無駄だと考えるのかをチームメンバでスプリントの振り返りに話してもらう。 もし結論が「時間の無駄」だとなってしまった場合、その時のチームの課題を議題として放り込み、それでもスクラムのセレモニーが時間の無駄かを再度考えてもらう。
チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？
勧める。 毎日、同じ時間に、短時間でチームの状況認識を揃えることに価値がある。
なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？
期待しない。困っているときはすぐにアラートを上げて欲しい。
スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？
司会は持ち回りにする。
メンバーからの報告はチーム目線の内容で話してもらう。
- チームのために昨日何をしたのか。
- チームのために今日何をするのか。
- チームにとって障害になりそうな事項は何か。
スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？
- 叱る
- チームのメンバから外れてもらう。
スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？
デイリースクラムはチームのためのセレモニーなのでステークホルダーがいなくても特に問題はない。
分散チーム間のスタンドアップをどのように進めるか？
分散チームの定義が1つのチームが複数拠点に離れていることを指しているのであれば…
- 拠点をまたいだチーム構成にならないよう分割を検討する。
- 拠点をまたいだチーム編成が避けられないのであればZoomなどのツールを使い、メンバの顔が遠隔地にあっても見える状態を作って実施する。
スクラムチーム用の物理カンバンボードをいま書いてください
| Plan | Do | Check | Done |
|---|---|---|---|
| □□□□ | ■ | ■■ | ■ |
| □□□□□ | ■■ | ■ | |
| □□□ |
- Plan : 未着手
- Do : 実施中
- Check : レビュー待ち
- Done : 完了
各タスクは数時間で終わる粒度まで分割する。 タスクは先に着手するものを右側に置く。
だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？
誰が参加しても良い。プロダクトオーナーも参加して良い。 ただしマネージャーは参加するとメンバーが意見を萎縮してしまうかもしれないので、あとでスクラムマスターからふりかえりの概要報告を受けることで出たがったとしても納得してもらう。
チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？
問題がきちんと吐き出されているか、なんとなく問題が先送りや見て見ぬ振りされていないかを確認する。
過去に使ったふりかえりのフォーマットはどんなものか？
KPT！
どうやってマンネリを防いでいるか？
- 自分たちが取り組んできた改善をまとめ、チーム外に紹介する。そこでのフィードバックをチームで検討する。
- リスクは高いが、大きい学びを期待できる「スプリント中の実験」を何か定める。
チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？
改善項目であげる数を絞る。 毎日のデイリースクラムでリマインドする。 改善項目をバックログアイテムの一つとして取り扱う。
どうやってアクションアイテムのフォローアップを薦めるか？
毎日のデイリースクラムでリマインドする。 着手状況をチームに確認する。
他の方の回答
LeSS Study LeSS本読書会 第3回
LeSS Study LeSS本読書会 第3回
第2回に引き続き、恵比寿 Redhatさんでの開催でした。 第2章の残りが対象でしたが、今回も途中の議論が盛り上がり完走できませんでした。
Q: 設計ワークショップはいつやるのか?
A: 必要なときにやる、いつやってもよい。
設計ワークショップは第2章の実際のLeSS開発事例で紹介されていた取り組みで、複数チームが関係する開発・修正がスプリントで生じた場合、事前に設計スプリントや設計ストーリーをやることなく、スプリント計画前後で関係するメンバーが集まり短期間で設計を済ませるという取り組みです。本の例ではスプリントプランニング2の後になっていましたが、設計ワークショップによって依存ストーリーやタスクの見落としなど気がつくこともあるので前にやっても良いよという話をしました。
Q: LeSSをどうやり始めたら良いのか? 導入手順は明確に規定されているのか?
A: 特に規定されていない。やりながら学ぶ。
SAFeの開発経験がある方からの質問でした。SAFeは導入手順が細かく規定されており、その通りに従っていけば悩むことがないそうです。とはいえ手順が多くて導入コーチ無しには始められない気もするのですが…
LeSSでは導入規定は特に規定されていません。ただおすすめの導入タイミングはチームメンバが増えてしまったことで2チームに分割する必要が生じた時です。他のスケーリングフレームワークよりもオーバーヘッドになる役割やセレモニーが少なく、スクラムを自然とスケールさせられます。
いきなり大規模に始めるのではなく、まずはうまくスクラムが回せる1チームを作ってからスケールさせるのが定石と何人かの方がおっしゃっていました。
Q : LeSSはうまく行くのか?
A: うまく行くよ！
「LeSSが使えると思って勉強会をやっているのか、使えるかわからないから勉強会をやっているのかどっちか」という質問でした。 実際にLeSS経験があるのは私一人だったようですが、「うまく行くよと」お答えしました。
Q: プロダクトオーナーにいつ成果物を見せるのか? スプリントレビューまで待つ?
A: いつでも、できたらなるべく早く見せる。
スクラムでやりがちな間違いとして、チームが完了させたストーリー・アイテムをスプリントレビューまでプロダクトオーナーに見せないというものがあります。できたものは早く見せた方がフィードバックがもらえるのでどんどん見せましょう。
アンチパターンとしてスプリントレビューで初めて見せると、スプリントレビューが細かな進捗確認の場や、成果物の出来栄えチェックの場になりがちです。
Q: チームは「コードでコミュニケーションをとる」と短くかかれれているが、込められている意味が大きい。
質問ではなく感想ですが、LeSSでは全チームが全コンポーネントを触り、頻繁に統合することで互いの開発が関連することを早期に検知します。コードがコンフリクトしたり、テストが通らなくなったり、設計に食い違いが生じたりなど。問題が生じたら相手の席まで歩いていき、話し合いを行います。
頻繁に統合を行うにはブランチを切らず、マスターで開発をする癖をつける必要があります。ワントランク開発 - tuneの日記で紹介した内容ですが、多くの開発では「最高のプルリクエスト」を追い求めがちです。
Q: コンフリクトしないの?
A: 特に問題になることはない。
作業に支障をきたすほどコンフリクトするのであれば実装や設計がまずい。 テストを回し終えないと次のコミットができないルールがあるのならば、テスト時間が長いなど別の問題を抱えている可能性もある。
コンフリクトしないように事前の設計やタスク分割を頑張るのではなく、細かくマスターに修正を入れ込んでいくやり方を習得したり、テストの実行時間を短くしたりして、根本的な解決を目指す。
Q: オーバーオールレトロスペクティブとは?
A: プロダクト開発全体の課題を考える場である。
チームごとの振り返りの後に行われる、複数チーム横断でプロダクト開発全体の問題を議論する場である。
私が勘違いしていたのは
- チームの振り返りの共有会では無い。
- チームの問題のエスカレーションの場では無い。
の2点です。
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
- 作者: 榎本明仁,木村卓央,高江洲睦,荒瀬中人,水野正隆,守田憲司
- 出版社/メーカー: 丸善出版
- 発売日: 2019/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Peterさんとアジャイルリーダーシップについて語ろう に行ってきました
GROOVE Xさんで開催されたスクラム実験室開催のイベント、「Peterさんとアジャイルリーダーシップについて語ろう」に行ってきました。資料は後日公開されるそうですが、記憶が確かなうちに内容をまとめておきます。
講演者のPeter BeckさんはドイツのアジャイルコーチでDas SCRUMTEAMという会社の創業者とのことです。
はじめに
顧客調整・プロジェクト運営の難しさをよく表した「顧客が本当に欲しかったもの」の絵ですが、出典は1973年に遡るそうです。アジャイルな開発に取り組む理由は顧客が本当に欲しいものを作るため。プロダクト開発では何を作るかとどう作るかについて不確かなものがいくつもありますが、アジャイル開発は両者が不確かな状態で効果がある開発手法です。
「リーダーシップ」とは何か、さらに「アジャイル」なリーダーシップとは?
リーダーシップに関するPeterさんによる定義は下記でした。
Leadership is the way to lead others to decision.
よくマネジメントや他人を導く意味で使われる言葉ですが、影響力を行使し、他の人に決断を促すことがリーダーシップだということです。この定義だとスーパーのお菓子売り場で目をウルウルさせながら親にお菓子をねだる子供もリーダーシップを発揮しているということになります。確かにストレートにお願いするのも、駄々をこねるのも、かわいさにうったえかけるのも、子供にとっては取れる選択肢の1つではあります。
アジャイルリーダーシップはAgileに言葉をくっつけて新しいものに見せかけるバズワード(Modern Agileとか、AgileHRとかかな)の一つ・・・ではありますが、Peterさんは下記のように定義していました。
Agile Leadership is the way to lead others to decision in fast changing environment.
スクラムフレームワークが提供する3つの役割とバランス
Peterさんは冒頭で
と言っていたのですが、その説明になります。
Scrumはプロダクトオーナー(PO)、開発チーム(Team)、スクラムマスター(SM)の3つの役割がありますが、これより多くても少なくてもスクラムは広まらなかっただろうと考察しています。それはバランスが影響しており、2つだとバランスの偏りが生じてしまい、4つ以上に増えると固定的になりアジャイルさ(俊敏さ)が失われるだろうと言っていました。
- POの役割：注力領域を明確化する
- Teamの役割：顧客価値を作る
- SMの役割：アジャイルな組織への変革を促す、POが意思決定できる環境を整える。
各役割が行使できるリーダーシップと影響力
PO/Team/SMはお互いが行使できるリーダーシップを持って相互に影響を与えあい、バランスを保ちつつプロダクトを大きくしていきます。PO/Team/SMごとに行使できる行動と、影響力の大小をマッピングして話し合うワークショップを行った結果が上の写真です。普段何気なく行なっている行動が実は他者の行動や決断を促していたり、強い影響力を持つ行動が必ずしも組織の後ろ盾を必要としていなかったり、ビジョン策定や予算・リソースの配分など普段会社の業務として当たり前にやっていたことが実はこれも影響力の行使だなと気が付いたりしました。
おわりに
PO/Team/SMいずれも重要な役割ですが、SMが組織変革の担い手で「全体最適を考えなければならない」立場だということは日頃の業務改善でついつい忘れがちだと思います。
その他
Peterさんの会社で作ったLeSSポスターの出来がよかったので写真に撮らせてもらいました。英語版でも十分欲しい気持ちになりましたが、日本語訳を作って壁に貼っておきたいわかりやすさです。
LeSS Study LeSS本読書会 第1回 & 第2回に行ってきました
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法が1月末に発売され、LeSSの勉強会「LeSS Study」が読書会として再スタートすることになったので行ってきました。アジャイル・スクラム・LeSSに関して突っ込んだ議論ができるとても楽しい会なのですが、ピザ&ビールを食べながらで翌日には記憶が曖昧になってしまうのが難点です。
LeSS Study LeSS本読書会 第1回
秋葉原のクラスメソッドさんでの開催でした。 内容は「読書会の説明」、「LeSS本の説明」、「LeSS でもっと多く: 2ページ」まで予定通り進みました。
以下質疑応答でかろうじて覚えているメモです。
Q: LeSSはスクラムなのか
A: スクラムである。原則にも「Large-Scale Scrumはスクラムである」と明確にかかれている。
LeSSはスクラムをベースに新しい役割やイベント、ルールを当てはめたものではなく、1つのスクラムを複数チームでやろうとした際に考慮した方がよいアドバイス集のようなイメージです。
Q : LeSSを構成する原理・原則が多いのではないか?
A: 確かにそうかも。
「透明性」や「顧客中心」などスクラムと重複しているものもある。 「LeSSはスクラムである」ならば、スクラムの原理原則をベースとして、LeSS固有の追加事項だけに記述を留めたほうが良いのかもしれない。
Q: システム思考ってどんなもの? 勉強にいい本ある?
A: 相互に作用する要素・関係性を整理し、どこを起点に改善を図っているかを考えるやり方。
例えばプロジェクトが遅延すると追加要員が送られる。開発メンバが増えるとコミュニケーションコストが増えさらにプロジェクトは遅延する。プロジェクトが遅延すると追加要員が送られ…といったよくある事象を関係で整理し、改善点を検討する。
LeSS Study LeSS本読書会 第2回
恵比寿 Redhatさんでの開催でした。 第2章が対象でしたが、途中の議論が盛り上がりスプリントプランニングぐらいしか話していません。
Q: スプリントプランニング1に代表者しか来ないとあるけど、残りの人は何しているの?
A: 対して長くないから気にしなくても大丈夫。
1チームスクラムのプランニングと異なり、LeSSのスプリントプランニング1はどのチームが何のストーリを担当するかを「ざっくりと」決めるものなので短いです。プロダクトオーナーがバックログを付箋に書いて持ってきて、チーム代表者の前にがさっと置き、代表者が好き好きに好きなものを持っていくぐらいのイメージです。事前にプロダクトバックログリファインメントでどんなストーリーが来るのか確認しているのでここで長い議論になることはないのだと思います。
Q: スプリントプランニング1でバックログの優先順位を考慮しなくて良いのか?
A: チームにストーリーの分配が終わった後で優先順位が高いものが残った場合、プロダクトオーナーがチームと交渉すれば良い。「このストーリーと交換できないか」とか。
Q: 書籍では「預託チーム」「取引チーム」「非デリバティブチーム」となっているが、チーム分けはどうするのか?
A: 顧客視点の機能で分けるフィーチャーチームが基本。コンポーネントチームではない。
とはいえ書籍のチーム名はコンポーネントチームに見えなくもない。「預託コンポーネント」とかありそう。 実際の現場では機能と関係がないチーム名をつけ、「預託に強いチーム」「取引に強いチーム」といった認識を裏で持っておくぐらいで良いが、書籍での説明のしやすさのため今の形に落ち着いているのかもしれない。
スクラムマスターは保育園の先生に似ているという話もあるので、「うさぎさんチーム」「くまさんチーム」といった名前でも良いかもしれない。
Q: 単一チームでプロダクトバックログリファインメント(PBR)したストーリーを別チームに割り振ってもいいの?
A: ダメじゃないけど、どのチームが担当しても良いストーリーは複数チームでPBRした方が良い。
「複数チームPBR」は、A・B・Cの3チームがあった時、3チームで順繰りに見積もりを行なって結果をまとめるということではない。A・B・Cのメンバをごちゃ混ぜにし、3グループに分け、3グループに見積もり対象のストーリーを1/3ずつ分け、それで見積もりを行う方式である。したがって見積もりに要する時間は単一チームに見積もらせる時と変わらない。
複数チームPBRを行う利点として、チーム横断で議論できることで観点の見落としが減り、ストーリーポイントなどの見積もりも自然と揃ってくることがある。また実際にチームがストーリーに着手した際も誰かしらストーリーの詳細を把握している人がチームにいることが期待できる。
Q: スプリントプランニング1でチームに自由に取らせると偏りが出て、得意なものばかりやるのでは?
A: あるチームが優先順位の高いストーリーばかりを担当するなど、スプリントを始めるにあたって課題がある場合、プロダクトオーナー・他チームとストーリーの交換など調整をすることになる。この時に「得意じゃないけど、担当できる」ストーリーが割り当てられることになるので、スプリントを長く続けていると偏りは出にくくなる。
Q: スプリントプランニング2は共有スペースで行うの?
A: その通り。複数チームで行う時は広い場所で行う。大きい会議室、食堂など。
計画時に他チームと調整が必要になった時にすぐに話せるようにするため。 リモートサイトのチームがあるときはスプリントプランニング2の時はテレビ会議を繋ぎっぱなしにし、部屋のある一角に移動したらすぐに話し始められるようにする。
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
- 作者: 榎本明仁,木村卓央,高江洲睦,荒瀬中人,水野正隆,守田憲司
- 出版社/メーカー: 丸善出版
- 発売日: 2019/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
awesome-agile-workshopを作っています
変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】
変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】
- 作者: Gary Gruver,Tommy Mouser,吉羽龍太郎,原田騎郎
- 出版社/メーカー: 技術評論社
- 発売日: 2017/01/25
- メディア: 単行本
- この商品を含むブログ (1件) を見る
だいぶ前に読んでいた本ですが、まとめてみました。
この本はどんな本か？
HPのプリンタでのファームウェア開発における事例をもとに、巨大な組織でハードウェアが絡む製品開発をアジャイルに進めるやり方を紹介した本です。
他のアジャイル本と比較して上位の経営幹部向けだと感じました。DeoOpsなど実践に関する説明は少ないです。
大組織におけるソフトウェア開発の変革
既存の大組織の多くがソフトウェア開発・デリバリーに苦しんでいる。 その結果、市場で競争したり、ソフトウェアでイノベーションを起こすことが困難になってきている。
大企業でソフトウェア開発を変革するには、チーム同士が協力し価値を生み出す仕組みづくりをまず考える。 それぞれのチームの働き方はその次である。
経営幹部が主導する
単にアジャイルに取り組むことを目的にしない。
エンタープライズレベルの継続的改善プロセスは経営幹部が作る必要がる。 なぜならば組織内のリソースを割り当てられる唯一の存在であり、バリューチェーンの端から橋までを見ることができるからである。
経営幹部はエンタープライズレベルで計画を推進し、進捗を把握できる戦略的な目標を設定する。
- 通常4〜7個の上位目標
- 測定可能な小項目
経営幹部は組織全体と共同して目標を設定し、この目標が重要であり達成可能だと全員が感じられるようにする。
アジャイルに取り組むための「正しい方法」を決めてしまうと、次にその正しい方法を全員に教えなければと思い始めてしまう。 リーダーとして、可能な限り目標ととともにフレームワークを提供し、仕事の進め方に関しては最大限の裁量をチームに与えることが重要である。 これによってチームは仕事により興味を覚え、結果に対するオーナーシップを高めることになる。
ビジネス目標を設定し、継続的改善プロセスを実施し続けることで、経営幹部やマネージャーを巻き込み、彼らに変革をリードさせる。 組織全体にわたる計画プロセスやデリバリープロセスの改善に注力する。
頻繁に結合する文化を作る
ブランチを切らず、全員がメインブランチで開発を進める。これにより頻繁な統合を促すことができる。 メインブランチで開発するにはテクニックが必要である。
- 既存のコードを壊す変更を実装しない。
- 既存の機能を壊すことなく、コードの大規模なリファクタリングを可能にする。
- フィーチャーフラグなどを導入し、新しいコードをコミットしつつ、システムの他の部分からは使わせない。
- 既存の機能を壊さずにデータベースのスキーマを変更する。
自動テストなどを拡充し、メインブランチは常に安定する状態を保たなければならない。
- コードをコミットする際、自動化された受入テストに合格するまでその場を離れてはいけない
- 壊れたビルドに続けてコードをコミットしてはならない。
アジャイルに開発された戦闘機 SAAB社グリペンについて
はじめに
アジャイル開発、スクラム開発の研修資料で「戦闘機だってアジャイルに作れる」という事例紹介で、よく引用されている気がするのですが、なかなかまとまった情報が見つからないのでここにまとめておきます。
SAAB社・グリペンについて
グリペンの特徴
- 戦闘機が帰還したのち、システムをシャットダウンしてから再始動、再び滑走路へ出ていくまでの時間「ターンアラウンドタイム」が10分。
- 機体は可能な限りシンプルに、かつ必要な機器が最低限となるよう、設計時から配慮されている。
- 1名の監督者と5名の整備員でターンアラウンド中の整備ができる。
- 設備の整った航空基地だけでなく、高速道路を流用した臨時飛行場でも上記対応が可能。
- 製造単価から燃料、廃棄に至るまでに必要な経費「ライフサイクルコスト」が1機あたり約100億円と安い。
SAAB社におけるアジャイル開発
モジュールごとにチーム開発
ソフトウェア開発におけるオブジェクト思考的な考えを取り入れ、コクピット・機体・エンジンなどの単位でチームを組織している。
スクラムの適用
スプリントは3週間区切り、全チームがタイミングを揃えている。
デイリースクラムは4096人が開発に従事し、毎日Scrum of Scrumsで1時間内に情報共有を終える。
- 7:30 Daily Scrum
- 7:45 Scrum of Scrums
- 8:00 Scrum of Scrum of Scrums
- 8:15 Scrum of Scrum of Scrum of Scrums
- 8:30 Executive Action Team
その他
会社の誰もがいつでも現在の3Dモデル、ソフトウェアにアクセスすることができる。またこれらを元にしたフライトシミュレータを使うことができる。
