Scrum Fest Sapporo Day 2 参加レポート「It dependsから脱却するスクラム」

Scrum Fest Sapporo Day 2 「It dependsから脱却するスクラム」

2020/11/07に開催されたScrum Fest Sapporoの発表です。
https://confengine.com/scrum-fest-sapporo-2020/proposal/14100/it-depends

チーム参加してきました

aslead Agile のチーム「オキザリス」にて参加してきました。
チーム7人中、6人で参加して、その場で実況しつつ、記事も作っています。

スクラムが難しいと感じるのはどんなところですか？

• わかるようでわからない
• 具体的なのか抽象的なのかわからない
• どこからはじめればいいかわからない
• どうやって自分たちの状況に当てはめればいいかわからない

スクラムガイドから

• 軽量
• 理解が容易
• 習得は困難

有識者に質問するとよくIt depends（状況によるね）と言われる。

それっぽい言葉

• It depends
• マインドセット
• 心理的安全性

そりゃ大体 it dependsだし、どんなときもマインドセット・心理的安全性は大事

仕事を取り巻く状況

ここからは実際の現場で自分がどうしているか
わからないことだらけ。
わかる／わからないとか２つに分けたくなるけど、それ以外にも未知のわからないこともたくさんある。

わからないなんて普通だ！

わからないことをどうやって解消するか
→わからないこととどうやって付き合っていくか
を考える

プロジェクト

プロジェクトという単位で仕事することが多い。
プロジェクトには始まりと終わりが。
プロジェクトは、終わらせるために行う。プロジェクトは続いていくなにかのための活動。
内政開発でも受託開発でも同じ。

プロジェクト序盤

• 一番情報を持っていない
• 最初からすべてを計画することを諦める

どうすれば最速でスタートできるか

スクラムにはインセプションデッキがある。
チーム全員で話し合って合意したものをアウトプットしていく

そのときに必要なものをオリジナルで足し引きする
- チーム名・ロゴを決める

好きなインセプションデッキの進め方

• 個人ワークでそれぞれ書く
• お互いに共有し合う
• チームで１つにまとめていく

インセプションデッキのポイント

作ったものより、一緒に作ることに勝ちがあると考えている。
受け身の人は、自分たちの考えを発信していいことを知らないことが多い。
インセプションデッキを通して、自分たちを表現する。

特にエレベーターピッチが面白い。
いざエレベーターピッチを書いてみると、ターゲットの設定がバラバラだったりする。
ズレが生じるのは自然。ズレがあるまま開発を進めていくのではなく、違いを認識して話し合えるのが大事。

エンジニアは特殊な職業。
仲が悪くても、最終的に１つの成果物をリリースする必要がある。
ある意味これになれてるはず。
インセプションデッキを作るのはある意味１つのプロダクト開発だと考えている。

共通の言葉がチームのコンパスになる。
プロダクト開発中に共通の言葉が飛び交う。

仕事のリズムを設計する

タイムボックスはコンテキストに合わせて階層構造を持っていてもいいと思う。
チームの構造は
開発チームは自然と密にコミュニケーションする。
開発チームの周囲に、SM,PO,ステークホルダーが多い。
チームは階層構造であることが多い。
理想は目指しつつ現実を受け入れる。兼務・雇用形態などなど

スムーズに仕事が流れるように設計する。

誰をプロダクトオーナーにするのか

開発チーム、顧客、発注者、事業部などなどがいる中で。
こういうことを考えてみること自体がit dependsからの脱却につながる。

例えば、顧客にPOになってほしいが、やりづらさを感じて、自社の開発チーム外にPOをおいたり。

• 役割と責任を人に当てはめてもうまくいかないことが多い
• 早く走れる人たちが走り回ればいい
• プロダクトオーナーやスクラムに限った話ではない
• 誰かに依存していることは明確にして、それ以外は全体として役割を包含できればよい

たとえば、
-　判断するために必要な情報を集めたり、優先順位をおすすめしたり、こまめにプロダクトを見せて確認してもらう。
- 仮プロダクトオーナーをおいてコミュニケーションを階層構造にしない。

余白を作る

• 最初に決めて終わりではなく、決めすぎずに余白をもたせておく
• POやSMチームで育てていくと考えてみる 未完成だからこそかわいいとか応援したくなる。

プロジェクト中盤

どうやって変わらないようにするかではなくどうやって変えていくかを考える

次の価値観で考えてみる。
計画　＜　起こった事象
プロダクトバックログ　＜　動いているプロダクト

プロダクトバックログは
下の方にあるものは捨てることが多い。
必要以上に先まで計画しない。

活き活きしたプロダクトバクログ
- やることのリストアップではなく仮説のリストアップ
- 最初は解像度が低いがどんどん育っていく
- プロダクトバックログへのCRUD処理が多い

見積もり

優先順位をつけるときの判断喜寿としてのボリュームやビジネス判断をする際に見通しを知りたいことはある。

障害リスト

リスクだと思っていることを溜めておく箱を作る
定期的にチェックするタイミングを作る

決定を遅延する

適切なタイミングで決定ができるようにする
今決めなくていいことは先送りにする
今やるべきことにフォーカス

フィードバック

どうやって適切にもらうか
POに見せるだけのレビューになりがち。認識合わせは必要だが、本当にほしいのはリリースするためにフィードバック
仮説検証のためのフィードバック

肩越しの視線

実ユーザーがプロダクトを使っているところを見せてもらう
想定通りに問題解決までたどり着けるか
問題解決までがスムーズだったか

書いたコードを捨てる

捨てることをいとわない。
捨てる＝無駄になったのではなく、より洗練されたと考える
Be Simple

モブプログラミング

チーム全員で同じ時間に同じ画面を見ながら
常に画面同期してコーディング

私達のモブプログラミング→Gitのブランチ
チームとしてマスターブランチに

一緒に作業をする

• 会議に向けてそれぞれ準備や作業をして集まったときに報告・議論・判断をするのが効率がいいのか
• 集まったときに一緒に作業を進めたほうがスムーズに進むことは自分たちが考えている以上に多い
• 作業の結果だけでなく過程もチームの合意となる

ボトルネックは移動する

• ボトルネックは移動していく
• ボトルネックを停滞させない
• ボトルネックを素早く発見して移動させる

螺旋を登っていくイメージ

プロジェクト終盤

終わらせるのではなく次に繋げる

最後に頑張るのをやめる

次への準備に時間を割く

• PBLを精査する
• 障害リストを精査する
• 勉強する

まとめ

必要なことを必要なときに必要な文だけ実施する
変わらないようにするのではなく積極的に変えていく
失敗しても受け身で魅せる
終わらせるのではなく、次に繋げる

わからないことをどうやって解消するか（計画駆動）
→わからないこととどうやって付き合っていくか（経験主義）

「それはスクラムではない」と言われることあるよね。
→あっそ、フィードバックありがとうございます。
※建設的なフィードバックはきちんと受け止める

it dependsの正体

他社の事例を抽象化して自分たちに合わせる
- 実装力が問われている
- システムを実装するときに、他人のコードをそのままコピペして動かそうとはしていないはず
- 実装に必要な情報を一番多く持っているのは自分自身
- It dependsを脱却して先に行くのは自分自身

自問自答してみよう

• 行動せずに難しいかどうかを批評してしまっていないか
• 答えクレクレ君、事例クレクレ君になっていないか

実装力

どうやって実装力を上げるうか
- 知識をインプットする
- 人に聞きやすい部分
- 経験を積み重ねる

どうやって経験を積み重ねるか

現場で実験をする
思考実験をする

思考実験

• 現場の制約に関係なく、実験し放題である
• 一人ではなく誰かとやるとよい
• 相手や自分の具体的な事象について話
• 自分の頭で考えてフィードバックをもらう
• OSTやオンラインの場を使う

自分のことが話せるオンラインの場

• 分散アジャイルチーうについて考えるかい
• 製造業アジャイル勉強会
• アジャイル・ディスカッション
• Scrum Masters Night!
• スクラム道関西

ラジオ感覚で聞くなり、悩みを相談してみたりするとよい
思考実験を繰り替えｒして練度を高める

自分の頭で考える

• なるほど！
• 勉強になりました
• 刺激を受けました でとまらず

↓

• なぜそうしたんだろう
• 自分だったらこうする

と考えてみる

論理と感覚

どっちも大切。
片手落ちにならず、この２つをつかってどう現場に生かしていくか（実装力）

スクラムは難しいのか

• スクラムが難しいかどうかを気にしたことがない
• なぜならプロダクト開発が難しいことを知っているから
• わからないことだらけだって知っている
• わからないことの解消ではなくどうやって付き合っていくかを考える

スクラムの習得もスクラムと同じ経験主義

どうやって答えにたどり着く力を身に着けていくかを考えて取り組むのが大切だと改めて思った。

It dependsから実装の世界へ！

感想

• 実装力を培うと、状況に応じて最も効果的（であろう）選択肢を取れる確度が高まっていくという意味で、It dependsを乗り越えられるということなのだろうか。
• わからないことなんて普通だ！わからないこととどう向き合おう！という気持ちで取り組めると少しは気持ちが楽になりそうです。
• うちのチームでもモブワークが基本なので、「モブで作業すると過程もチームの合意となる。」というのはとても共感しました。
• 肩越しの視線は一度やってみたいと思いました。