Jeff Sutherlandが5年前にやってたAMAを訳しつつ今を考えた その2
前回の続きです！スクラムの生みの親、Jeff SutherlandさんのAsk Me Anything（なんでも聞いて～）を訳しつつ自分の考えをまとめていきます！
Jeff Sutherland AMA Part.2
Q: AMAありがとうJeff！ビジネスアナリストについてどう見てて、それがどうスクラムに絡む？そのロールのためのポジションがあるのか、それともスキルセットはチーム全体で持っておくべき？
A: ビジネスアナリストは要求の明確化に責任があるので、これは一部プロダクトオーナーの仕事であり一部チーム全体の仕事でもある。私は通常ビジネスアナリストをバックログが準備できるまでPOと一緒に仕事するようアサインし、その後はチームと一緒にそれが正しく実装されてるかを確認してもらってる。
研究によれば、仕様に対する作業見積もりはドキュメントのページ数に比例する。なのでプロダクトオーナーはできるだけ短い仕様がほしい。多くのビジネスアナリストは長い仕様書を好むがそれは遅延が伴うよ。
ビジネスアナリストはプロダクトオーナーチームの一員てのが一番しっくりきますかね。ドキュメントの話は興味深いです。たしかに1機能に対して長々と仕様が制定されてるほうが楽そうに思えて、実際は時間がかかるという経験はあります。
Q: もっと大きな絵を書くアーキテクトが居たほうがいい？もしそうならスクラムマスターがやるべきなのか、システムアーキテクトが別で居たほうがいい？
A: スケールするスクラムではアーキテクチャに対して注意が必要。シニアアーキテクトがいて、各チームから代表でアーキテクトが定期的に会話する場、アーキテクチャのスクラムみたいに進めることで全体の戦略が決められる。これについてはいくつかオンラインコースがあるよ。
プロダクトの規模によりますが、複数チーム必要でスクラム・オブ・スクラムするなら横断的なアーキテクチャチームは必須になるでしょう。たとえ、スモールスタートで途中からチームが追加された場合でも同じです。
Q: 私が見る限りスクラムからカンバンへ移行してる会社が多いよ。カンバンは次のアジャイルの大きな波になると思う？
A: 会社が継続的デプロイメント(CD)に移行してるって言いたいのかな。それがスクラムの未来なので。
トヨタがどうカンバンを見ているかを深く理解する必要があるよ。彼らはカンバンを取り除いて、1ピース単位のコンティニュアスフローに移行しようとしている。これはスウォーミングして次のピースに移る前に1つを完成させる必要がある。Jim Coplienのブログを読んでみてね。
1ピース単位というのは1ストーリーの粒度で取り組むってことですかね。どこかが詰まればスウォーミング（群がって）してみんなで解決する。確実にひとつずつの価値を優先度順で届けてくためのやり方ですね。私はCSMの研修でCope先生(Jim Coplien)とお話させていただいたことがあります。とっても智慧深く、礼儀正しく、楽しい方なので是非Cope先生の研修参加してみてください。
Q: 私は過去10年間でいくつかのITチームと作業し、アジャイルのカンファレンスにも出てきた。私が見るに（間違ってる可能性もあるけど）、アジャイルのチームが失敗するほとんどの理由はメンバーのソフトスキル（コミュニケーション、フィードバック、回復力）の不足。アジャイルカンファレンスでは、ほとんどの人は未だ「アジャイルを弊社でも試した、けど……」とか「アジャイルなこともやってるけど、全部がそうじゃないよ」って語ってる。大きな会社（Spotifyとか）か、啓発された少人数の数少ないチームがアジャイルが唯一アジャイルになっていると感じる。アジャイルは皆できると思う？すべての会社、すべてのチーム？それか何か事前条件が必要？
ソフトスキルは改善できるとは知っているけど、なかなか厳しいしコーチを雇うなどは小さな会社には高額すぎる（ROIが高くなるのを知りつつも、だ）。これについては何か意見ある？
A: ソフトスキルがあるスクラムマスターが居るととても助かるね。しかし、スクラムは開発者のためにデザインされたもの。たくさん喋らずに済むようにミーティングは短めではある。皆が発言を求められるけど、少しだけでいい。最高のスクラムマスターとは常にチームのためのバックログをベースに働き続けるスクラムマスターだね。これは大野 耐一がトヨタでやってきたことそのままで、変える必要はないと思ってるよ。
もしあなたがROIが高くなるのを理解しつつそれでも高額って言うなら、ビジネスでは成功しないと思うよ。高いROIはそこに投資しろってことなので。
ソフトスキルが低いとスクラムマスターはあまり向いていないので、人を見て任命する必要はあると思います。スクラムマスターはチーム内外の分断をなくしていくための役割なので、チーム内外かとたくさん話しをしなくてはなりません。
みんなが少しだけで良いけど必ず発言する必要があるスクラムの仕組みは個人的にとても気に入ってます。放っておくと一言も喋らない人もデイリースクラムやプランニングでは発言せざるをえません。そうするとそういう人でもコミュニケーションの重要性を少しずつ理解してくれるかもしれません。
ROIについては異議なし。払えないぐらいに高いならしかたないけど払えるならやればいい。
Q: もしアジャイルチームに200人の開発者が居るとして、4年後、111のコンパイルが1つもエラー無く終わることが完成に必要で、さらにそれをやってもソフトウェアが動かない（そもそも動いたことナシ）、こんな状況はプロから見て何が間違ってる？
A: 動くソフトウェアを提供できない、アジャイルマニフェスト第2の価値に違反する、こんな状態をFragile（脆い）と呼んでる。ダメ・アジャイルのカテゴリだね。私たちの本 Software in 30 Days で、Kenと私はStandishグループ（研究機関）に50000のプロジェクトをトラディショナルとアジャイルに分けてもらった。そのうち半分の「アジャイル」チームはプロジェクトを提供できていない。たくさんのダメ・アジャイルが動いてる。あなたのケースではまだ1スプリントも実現できていないね。
アジャイルの本質を理解しないでアジャイルをやろうとしちゃいけない例ですね。まず、Jeffさんレベルとまでは言わずともアジャイルコーチを味方につけて一緒に進めるべきです。この際、私だったら気をつけるのはそのコーチがどういう考え方を持っている人かです。情報発信をしてる人ならその人のブログを漁りましょう。してない人なら面接でスクラムマスターへの38の質問をしてみてください。気になるのは怖いのは質問者の話が空想なのか現実なのか……😩
Q: 私たちのオフィスではスクラムが破綻してる。チームは9～10人でストーリーは私たちが少しでも「ポイント」を得るためにほぼ毎回2個に分割される（e.g. ボタンを直す その1、ボタンを直す その2）。管理職はベロシティをチームの点数として見てる。デベロッパーとしてこの状況を改善できる方法はない？
A: 時にはクリエイティブな開発者がスクラムマスターのように動くことでこういう状況を打破できる。一人の開発者がYahooを変えたみたいにね。
それができなければ、「希望はあるか？」と問いてみて。もし無いなら、520,000のより良いスクラムの仕事があなたを待ってる。
より良い会社を求めるのには色々歩いてみるのが一番だよ。このことが初期のスクラムを広げることを助けた。優秀な開発者たちは、自身をアジャイルと言い張るウォーターフォールの会社で働くことを拒んだ。私がいるKendall Square周辺の最高の会社の管理職はアジャイルな環境のためには優秀な開発者たちを雇い確保し続けることと知ってる。彼らの最高の開発者たちはいつでもビル内のMicrosoft, Google, Yahoo, Amazon, Appleの研究ラボに行けるんだ。
優秀な開発者は働き方も優秀であることが多いです。何がチームにとってベストなのかもよく理解しています。彼らがいればアジャイルな環境はより自然により速いペースで近づくわけです。なぜならアジリティが求められるプログラムや環境について一番詳しいのは彼らであって、管理職ではないから。
Q: チームがスクラムを始めてやる時、メソドロジーのどの部分が適応しやすく、どの部分が適応が難しい？
A: スクラムをやること自体は難しくないよ。難しいのはスプリントの最後に動くソフトウェアを用意することだ。良くないユーザーストーリーがあったり、それをスプリントに大量に持ち込んだり、バグを見つけても即座に直さなかったり、ストーリー単位でスウォーミングしないのでテストができなかったり、割り込みに対する方針が決まっていなかったり、緊急事態に反応できず失敗したり……と色々。うまくいかなくなる理由はいくらでもあるけど、アジャイルになる唯一の道は毎スプリントバグ無しで動くソフトウェアが届けられることだよ。
スクラムは「理解が容易で習得が困難」です。なので、始めるのは簡単だと思います。だってスクラムガイドありますし。ただ本質を捉え、うまく回していくのは難しいので本質を理解する手助けができるコーチが必要なのです。
動くソフトウェアについては補足すると、毎スプリントでリリースする必要はないです。だけど毎スプリントでデプロイする必要はあると思います。
Q: 推奨するアジャイルフレームワークある？
アジャイルなツールでのオススメは？
A: アジャイルマニフェストはスクラムフレームワークとXPのエンジニアリング・プラクティスに基づいている。DSDMが発表されたけどスクラム＋いくつかの役割って感じでほとんど同じだった。なのでスクラムとその中でXPをやるのがソフトウェア開発では推奨する。
最高のツールは、あなたの速度を落とさないツールだ。今のところ全部遅くなるから付箋紙がベストだね。3Mが付箋紙アプリを作ってたから見てみて。それが向かうべき未来かな。一方、RallyやVersion Oneなどのマーケットリーダー、Jira、私たちも使う軽量なPivotal Trackerなども見てみると良い。一番軽量に感じて一番開発スピードを落とさないツールを使おう。
スクラムをやりながら中でXPのプラクティスであるTDDやペアプロモブプロをやるのが私もオススメです。XPのプラクティスがどういうものがあるかは知っておいたほうが良いです。
ツールについては、それぞれのメリット・デメリットを正しく理解した上で選択してください。なんとなくで選んではダメです。付箋＆ホワイトボードはスピードに置いては圧倒的です。例えば、チームの進捗を確認するという一瞬で終わりそうなタスクをするとします。Webツールなら開発ウィンドウからWebブラウザに移りタブを選んで、PC画面ではスプリントバックログ全体像は見えないのでスクロールしながら誰が何やってるかを眺めます。最初から理解するまでに7～8秒かかるとします。付箋＆ホワイトボードは1秒で済みますよね。一日に10回なんとなしにチームの進捗を確認するだけで10秒と1分の差がでます。見るだけでこれです。タスクの移動や追加やその他アクションが重なると？複雑な使い方はソフトウェアに分があるでしょう。しかし複雑な使い方が必要な時点でそれが本当に必要かを考えるべきです。
Q: チームが新技術を使ったりシステムの新たなパーツを触ったりする場合、勉強会を開いたほうがいいのか、必要になった時に1対1で教えたほうがいいのかどっちだと思う？
A: 新しい技術は企業にとって競争力を得るために重要。同時に、進行中の開発を邪魔しないことも重要。IDX（今はGEヘルスケア）ではアーキテクチャチームがいて、新技術を色々みつつ部門内のチームが使えるようローから図する作業をしてた。それがうまくいけば、スケールさせて部門全体に広げ、全社に広げる。チーム横断的なアーキテクチャチームは新しい技術を導入するのに良いし、顧客に迷惑がかからない限りチームが何を使うかを自由に決められることも大切だ。
新たなチームであれば技術調査のSprint 0を用意したり、進行中のチームであればスパイクをバックログに追加したりという方法も取れますね。スケールするなら横断的なアーキテクチャチームがあったほうが確実に良いです。
Q: #NoEstimatesのディスカッションはフォローしてた ？データに基づく予測 vs プランニングと見積もり については何か考えはある？
A: 見積もりに時間の単位を使うことは放棄することをオススメしてるよ。なぜなら時間がかかるし、間違いは起きるし、チームの動きが遅くなる。だからすべてポイントにすべき。
チームが速くなれば、ストーリーは小さくなりチームはストーリーのタスク化すら不要になり更に加速する。
もしすべてのストーリーが小さければ、余計な見積もりは要らない。ハイパフォーマンスなチームがこれで上手くいくのを見てきたし、経験不足なチームがこれで失敗する話も聞いてきた。新しいチームにはこれはオススメしないね。
タスク単位の見積もりすら葬り去るほどハイパフォーマンスなチームってどんな感じか見てみたいですね。あまりイメージが沸かない……絶対モブプロでやる、みたいなチームなら見積もりなくすってのも良いかもしれないですね。
Q: 複数ロケーションで作業するチームについてどう思う？異なる町で働くチームと一緒に作業した経験は？実際どうやった？
A: Scrum Incでは2つの共同作業場で働くチームと1つの完全に分散して働くチームがある。この記事で説明されているように分散していても生産性を高めることはできる。でも、スクラムの基本に集中するのにやはり苦労しているね。分散しているとスクラムをうまくやるのは難しい。
リモート問題は最近のウイルス騒ぎで急速に進んでいます。できればアジャイルマニフェストにもあるようにフェイス・トゥ・フェイスのコミュニケーションを実現させたいところですが、Jeffの例もあるようにすべてがそうはいかないケースもあります。そういう場合はGoogle Hangout, Zoom, Teamsなどのビデオチャットツールを使ってネットワーク越しにフェイス・トゥ・フェイスを実現できるようにしてみましょう。
***
前半後半で分けるつもりが量が半端なくその3まで続きます😂自分ならこの質問どう答えるかな～みたいなのを考えながらJeffの回答を見るのが楽しくなってきてます。
Have a nice and agile life!
いいなと思ったら応援しよう！
