海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

大規模にアジャイルをやるにはどうしたらいいか、に対する答え

大規模にアジャイルをやるにはどうしたらいいですか?

答え 大規模にしない

以上終わり。


先日大規模な組織レベルでのアジャイル導入をするという人と話す機会があったのだが、どうするのがいいですかね?って聞かれて出た感想が、「大規模にしない」だった。

ドメインも違う、プロダクトも違う、顧客も違う、作るチームも違う

そんなチームのプロセスを同期や依存させる意味あるのかと。

「DB にアクセスするときは必要ないけどこっちの DB へもコネクション確立してね!」

って言われたらどう考えても頭おかしい人でしょ。

依存がいらないところをわざわざ依存させない。

偉い人が同じ?組織上同じだから?

依存を増やしてどうやって変化に対応するのか?

変化に対応するコストを高めるだけの価値がその偉い人が気持ちよくなることにあるのか?

そんなことを感じないでもない。


アジャイル界隈で悪名高い?Scaled Agile Framework (SAFe) というものがある。

(現在バージョン 4.6) SAFe 5.0 Framework - SAFe Big Picture

エンタープライズレベルで統率されたアジャイル プロセス を適用するためのフレームワークになっている。

そもそもアジャイルを適用することが目的化している時点で怪しい臭いがプンプンしないでもない。

大抵アジャイルが目的化している組織では、アジャイルプロセスに変化したことが目的化していて、そもそもアジャイルを導入するモチベーションとなるべき、顧客への価値提供の最大化や、リスクの抑制、変化への対応といったことが考慮されず、ただただプロセスが適用されて終わる。

場合によっては、その配下の組織(トレインとかいってたりする)のドメインにおいては、PI (SAFe の計画スパン)がすでに変化に対応できないものになっていたりするがおかまいなしにプロセスが適用され、顧客やビジネスの満足度が下がる始末になるのは明白になる。だって見てないもん。

上位組織の承認がなければ自分たちの活動内容を進めることができない、上位組織の決めたプロセスに合わせることが現場の課題の解決の為のプロセス改善よりも優先される。

場合によっては現場がプロセスを ”適用された” 側となってしまい、なぜそのプロセスなのか、そのプロセスがどう機能していないといけないのかに疑問すら持てないまま、「順調に各トレインが運営されています」とか報告されるだろうと考えると頭が痛い。

まあそんな会社や組織はそのうち潰れるだろうからどうでもいいかもしれないので気にしてもしょうがないが。


SAFe でも LeSS でも NEXUS でも DAD でも Spotify モデルでもなんでもいいが、

「依存のあるチームをまとめて大規模に運営できる」 プロセスは、「チーム間の依存をどうやったら減らせるか」 という、当たり前の視点を奪ってしまいやすい。

依存が切れて独立運営できる方が効率が明らかに高いのだが、それに気づく機会を奪うのは中々罪だな、と思う。

Spotify モデルは組織の枠組みの話だし、明確に依存を減らすアクティビティを儲けると謳っているのはさすがだなとは思う)

同期を取らないと開発進めるの大変じゃん、ていう当たり前の事を知らないと、気にせずこの辺導入してしまいそう。(自戒)


(2020/10/19 追記)

Clean Agile ~Back to Basic~ という Uncle Bob の本を読んだら似たようなことが書いてあったので、参考までに追加。

大規模アジャイルはどうなのか?私はそんなものはないと思っている

大規模なチームの組織化は、小さなチームに分割する問題である。アジャイルは小さなソフトウェアチームの問題を解決する。

小さなチームを大きなチームにする問題はすでに解決されている。

したがって、大規模アジャイルの質問に対する私の答えは、「小規模なアジャイルチームを組織せよ」だ。

この本が先に出てればこんな拙稿捻らなくて良かったのでは、感ある。

スクラムマスターとしてチームの改善をどう助けるか?

スクラムマスターとしてどう改善をフォローするか?

そんな話題が出たのは、私がスクラムチームを支援するにあたり、改善ポイントを考えながらふりかえりでフォローしている、という話をしたときでした。

で、その場にいた別のスクラムマスターの方から、ある人から、ふりかえりでチームが考えた改善を進めてあげるのが大事で、事前に考えるのは違うのでは?とツッコミを受けた。

これ、スクラムマスターとして物凄いさじ加減が難しいとこだと思っている。

チームには自己組織化して問題を見つけ、改善できるようになって欲しい。

スクラムマスターとしては、スクラムマスターがいなくても(ある意味チームが勝手に)改善し続けてくれる状態に持っていくことが一旦の目標だと思う。

そのため、スクラムマスターは、チームに「どうしたいですか?」と考えることを促すことが大事。

一方で、それならスクラムマスター簡単やん!ってことで、チームが改善できる状態に持っていけないまま放置し続けるスクラムマスターも見かける。

"アジャイルコーチ" とは何か

そうですよね,話を聞くふりをして,時たま頷いてみせて,"分かりました。それであなたは今,何をすべきだと思いますか?" とでも尋ねることができれば,それだけで結構な収入になるのですから。

(認定ホニャララ資格が信用出来なくなってきたのと同じかもしれない。)

日々の仕事を思い返すと、スクラムマスターとして参画する場で、チームがスクラムについて成熟しているケースは、残念ながらあまりお目にかかれていない。

大体は2週間の目標を立ててふりかえりと朝会(≠ Daily Scrum)をやってる程度。

ストーリーはバッチリ個人にアサインするし朝会はリーダー(?)への進捗報告の場だ。

当然メンバーがスクラムに精通しているなら外部から呼ぶ必要も無いのでバイアスありありなのだが仕方ないが、そうしたケースで、「ふりかえりはチームに任せる」というのは、スクラムマスターとしてはただの責任放棄に過ぎないと思う。

なので、その状態のチームで、「自己組織化ですから(^-^)」とか言いながら放置するのはどうかと思う。

じゃあ改善点を指示してチームにやらせるのかというと、それもまた放置の次くらいにダメなやり方になる。

瞬間的には改善するがチームとしては「問題に気付く」「原因を考える」「解決策を導き出す」「やると決める」と言った一番大事な、「改善のやり方を学ぶ」機会を奪ってしまいよろしくない。

("ふりかえり" っていう、分かりやすいけど誤解を生みやすい言葉もどうかと思うんだけどね)

スクラムマスターはリーダーシップじゃない(サーバントリーダーシップ)ので、コーチングスキルをフル動員して、チームに気付かせる、考えさせる、encourage する、をしないといけないが、ふりかえりのファシリテーション?フォロー?は、メンバーのメンタルも気にしながらスイートスポットな働きかけが必要になるのでとてもセンシティブだと思う。難しい。

( ´-`)。oO(4歳児に歯磨きを教えるよりは、ラクかも)

スクラムマスターのアプローチにテンプレートが無いのは、育児にテンプレートが無いのと一緒だな、と最近よく思う。アンチパターンくらいしか決められない。

環境も直面する問題も違うのに同じアプローチなんてあるわきゃ無いのだ。

あ、一緒に気付いて考えて勇気付けてチャレンジさせて成長していった瞬間の達成感も育児と同じかな。これは個人の主観がとても入ってるけど。

日々無力感とか詐欺師症候群と闘わないといけないのも似てるな。楽しいからいいのだが。

そういえば、この辺の大事なことは書籍『アジャイルコーチング』によく載ってるから、とても参考になるので困ったら参考になるかもしれないし、ならないかもしれない。

2019/6/1 追記

Teaching と Coaching の違いなのかなと今更ながら思った。

キッズスクールのサッカーコーチと、W杯のサッカーコーチは話す内容が違うじゃん?っていうコラムを見て、まずは走る蹴るを一緒になってやらないといけないから、チームが一人でサッカーを出来るようになるまでは手放しで放置せずに手助けする方がいいという感じだろうか。

アジャイルコーチング

アジャイルコーチング

スクラムマスターを雇う時に聞いてみると良い38個の質問をやってみた

スクラムマスターを雇うときに聞いてみると良い 38 個の質問をやってみた

スクラムマスターを雇う時に聞いてみるとよい38個の質問」というものがあり、昔から知っていたのだが、改めて自分で考える機会ということで書いてみた。

スクラムマスターを雇う時に聞いてみるとよい38個の質問 | Ryuzee.com

※ あくまで自分の経験に基づく考えなので、使えるかどうか(≒採用に値するかどうか?)はわかりかねます。


スクラムマスターの役割について

Q. アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか?

  • ツールやプロセスが大事ではないとは言っていない。あくまで比較の話。

  • ツールやプロセスは、チームが価値を生むまでの一連の作業に、より集中できる為に必要とされる場合がある。

  • 「いつまでにスプリントが終わるんだっけ?」とか、「どうやってスプリントの進捗を見えるようにすればいいんだっけ?」といったトコロにいちいちクリエイティビティを発揮しなくていい。

  • (逆に、ツール・プロセス標準化、みたいな、ツール・プロセスありきは NG だと思う。誰も使わなくなる。)

Q. 自分の組織でアジャイルがうまくいっていることを示す兆候は何か?また自分の働きが成功している兆候は何か?

  • どうやるか、どこまでやるか/出来たか、といった議論ではなく、デリバリーしたものが期待通り使われているか、デリバリーしたことからの気付きは何か、を考えるようになっている
  • そのために、組織・チームとして、どうすれば(改善すれば)いいのかを考え続けられている

の、2点は、上手く回っている状況だと思う。

Q. 追跡しないといけないメトリクスはあるか?もしそうだとしたら何の目的でどのメトリクスを追跡するか?

  • チームが直面している問題や、リスクに応じて取るメトリクスは変えるので、必ずこれ!というのはない。

  • メトリクスをとると、観察者効果でよくない影響を与える可能性があるので注意が必要と感じている。

  • ストーリーのサイクルタイムは、チームの効率的な仕事ができているか、どこを改善すれば一番チームの作業効率に効くのか、を考える上で重要な指標になる。

  • ベロシティは、サイクルタイムが改善した結果、わかりやすく表れる指標なので、チームのモチベーションや気づきの意味でも取ることが多い。

  • あとはビジネス的な KPI とかも見ることで、チームが注力すべきことに集中しやすくなる。(売上、VOC、ストアレート etc)

Q. あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか?そして問題をどのように指摘するか?

  • コミットしたタイムボックスの長さが、既に計画駆動できないドメインに置かれているため、割り込みが多い
    • 割り込みが多いのに計画でコミットしてしまうのは問題ではないですか?と聞く。
    • (ある程度の)割り込みを前提とするか、タイムボックスを短くする。
    • そもそも PO が直近必要なものを予測/計画できていない場合もあり、PO のお仕事の仕方を一緒に考えることもある。
  • 技術的に、”やってみないと分からない” ものが多いアイテムを扱っている
    • 技術的 Spike と分割することは可能か?を考えてみる。
    • 可能であれば、Sprint を半分の長さにする。(Spike → Ready になった Story としても CT を悪化させないため)
  • チームがコミットメントしないといけないという意識がそもそもない
    • ふりかえりなどで、計画でコミットしたことが終わらなかったことは、私たち/ステークホルダー から見て問題だと思いますか?という問いを投げる。
  • コミット下はいいものの、内容を詳細に見積っておらず、楽観的に開始したまま達成できず、振り返りもできていない
  • 終わるかどうかをトラッキングしていない
    • デイリースクラムで、終わるかどうかをどう考えているかを観察する。
    • どうすれば今日この時点で Sprint が終わりそうだと判断できそうですか?と聞いてみる。
  • メンバーが別の作業と兼務していて、コミットしても状況に振り回されてしまう
    • 本人ではなく、アサインしている?上司?などに、意図を聞き、ムダやコミットできない問題の温床であることを伝える。

Q. 製品のディスカバリープロセスにスクラムチームは参加してよいか?その場合はどのようにするか?

  • 当然参加してよい。プロダクトの要求が、何を狙って決定されたものであるのかを理解することは、ストーリーのカードに詳細な Acceptance criteria を書き込むよりはるかに効率が良い。
  • また、実現方法においては、チームは Professional であるので、より良い解決法が提案できる場合は、アドバイスできるとよい。
  • ただし、チームや PO らは考え方や価値観が異なる場合が多いので、主観で話してしまって対立を生むようであれば、事実ベースで話すように心がけさせる必要がある。(スクラムの話に拠らないですね、これは)

Q. 設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか?

  • PO が注力すべきでないことに労力を割いているようであれば、それらを分離し、PO 以外の人間でできるように整理する。
  • 学習やディスカバリーに注力できるように、実現手法においてはチームがある程度の粒度の粗さで検討開始できるように、チームのドメインに対する理解や技術レベルを向上させることも長期的には必要になる。

Q. どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか?

  • 難しい質問。いま接しているステークホルダーが”しかるべき”ステークホルダーであるかどうかを検証する必要がある。
  • この人に聞いても裏の決定者がいるな、とか、デリバリーしたプロダクトに対する要求や不満を発見するのに効率が悪いな、と感じれば、しかるべき人探しをするのが良いと思う。
    • エンドユーザー向けサービスなら、エンドユーザーの振る舞いやインタビューから学ぶこと!
    • 社内にエンドユーザーはいないし、PO もその代わりにはなれない。
    • 幸せの青い鳥探しにならないように。

Q. どのように複数の異なる部門にまたがってアジャイルマインドセットを広げるか?ITじゃないステークホルダーをコーチするのにどんな戦略をとるか?

  • アジャイルを目的にする」と、迷走するし、上手くいかない。目的も共有できないのでうまくいかない。
  • 自分たちが置かれている環境と現状のやり方で、どういった課題があって、アジャイルのどんな考え方であれば、よりよくやれるのか、を説明する。 始めに課題ありき。
  • コーチの初期段階は、上記のように進めて、具体的にやっていく中で、こういった事象は、アジャイルだと当たり前のように捌けてるけど、計画駆動だったら無駄に苦労してたね、っていう点を一緒に気付けてあげられれば、彼らの気付きになる。あとは勝手に広めてくれる。

Q. 上級管理職にどのようにスクラムを紹介するか

  • 必要がないなら、しない。
  • どういう状況に対して、どういう考え方で臨むのか程度は伝えておく。
  • いわゆるスクラムってやつだとイチイチ言わなくてもいいと思う。
  • 上級管理職が 「それスクラムってやつか」と ”自分で” 気付けたら、その時点で敵にならない場合が多い。
  • 「なかま に なりたそう に、こちら を みている!」な上級管理職であれば、積極的に説明して巻き込むこともある。

Q. あなたはすでにステークホルダースクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか?またどんな経験があるか?

  • 上手くやるためにやっていることを共有する
  • そのうえで、スクラムをやる上で、何に懸念や不安があるのかを一緒に明らかにする。
  • トム・デマルコもいう通り、「怒りとは恐怖」なので、彼らの恐怖している内容を共有することが大事。
  • 分かりやすい拒絶に対して、不安を取り除くための活動をすること自体は、他のチームメンバーにとっても、不安を共有し、取り除くことの重要性が伝わるので、心理的安全性の向上に寄与できる場合が多い。
  • 逆に、簡単にその「人」を除外すると、他から見ているメンバーは…後はお察し。

プロダクトバックログのグルーミングと見積りについて

Q. プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか?

流れとしてはよいが、以下の点が気になる。

  • ステークホルダーの要求を分析する段階が無いと、PO が ROI を最大化するための情報が曖昧になる恐れがある。
  • チームのドメインへの理解度か高ければ、要求をチームが理解して PBI にする、といった形も取れる。 チームが受け取るのに Ready (Sprint Ready じゃなくて) であるかどうかは、チームの力量によるので一概には言えないが。
  • また、特にプロダクトの内部改善のための PBI はチームが作る場合もあるので、↑ の流れ以外にはない、というのは誤解を生みやすいので注意が必要。

Q. チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか?

  • プロダクトに関する VOC の KPI を知ることで、自分たちが優先順位付けする際の議論の情報ベースになる。
  • また、ビジネス目標や競合分析情報を知ることで、チームにいい効果が得られる場合もある。

Q. 誰がユーザーストーリーを書くとよいか?

  • 誰が書いてもよいが、コツがいるので、内容の確認のムダが多いようであれば、教育を要する。

Q. よいユーザーストーリーとはどんなものか?どんな構造か?

  • いわゆる INVEST と言われるものになる。
    • Independent: 他のストーリーと独立している
      • これがないと、優先順位等を考える際にとても無駄が増えるので大事。
    • Negotiable: 交渉可能である
      • どう実現するのか、どこまでやるのかに幅を持っておくことで、PO とチームがお互い効率よく進めるためのやり方を導く余地ができる。
    • Valuable: そのストーリーが単体で価値があること
      • ”**基本設計書を書く” みたいなストーリーの書き方をしても変化に対応できないし何も学習できないノデ、やらないようにしましょう。
    • Estimable: 見積もり可能である
      • 見積れないようなものはエピックと名前を付けて、細分化させた方が良い。
    • Sized small: 十分小さい
      • スプリントの期間内で終わるサイズでないと、レビューできないし、変化にも追従できなくなってしまう。
    • Testable: テスト可能である
      • テスト可能でない時点で、完了したかどうか判断できないので揉める。
      • テスト可能でない時点で、将来的にデグレードしているかを判断できないし、自動化もできない。

これらに加えて、よく、「状態で書くようにしましょう」 と言うことが多い。

実現手段はチーム次第。「~~を実施する」といった書き方だと、期待値を見たいしていなくても良いような書き方になってしまうし、チームも意識できない。

どういった背景で、何を実現したいのか(どういう状態になっていてほしいのか)をチームに伝え、実現手法と効率よくやる方法はチームが考える、でよいし、そこまで PO が踏み込むのはチームに対してリスペクトが無いし、チームとしても自律して考えることを放棄してしまっていてよくないと思う。

Q. 「Readyの定義」には何が含まれているべきか?

  • チームによる。
  • スクラムを円滑に運営する上で増やすこともあるし、チームの Capability が上がって減らすこともある。

Q. ユーザーストーリーを時間で見積もらないのはなぜか?

  • 時間はとても分かりやすい概念で、容易に誤用されやすいため。
    • 「なんで3日の仕事が3日で終わらないんだっけ?」→「それは理想日で、現状のチームの置かれている状況とタスク消化スタイルとしては・・・・・」みたいな不毛なやり取りをするくらいなら顧客を見てコードを書いて障害を取り除く時間に充てたい。
  • そもそも相対見積りするのに単位は必要ないため
  • 日付としての定量評価に使わない単位なら、当たり前だけど付ける理由すらない。

Q. プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか?スクラムチームは200個のチケットに取り組めるか?

  • バックログに突っ込んで、必要な時に必要なだけ考えましょう?とするだけ。
  • 先々のことまで気を回したい人はいるしそれは性格だからいいけど、「今やるべきこと」に注力して、「今見えていないこと」に早めに気付ける方がリスクが少ない。
  • 今時点で先々まで見通して他に抜け漏れがない!という自信があるなら、計画駆動のウォーターフォールでどうぞ。

スプリントプランニングについて

Q. チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか?

  • PO と協力して、バックログアイテムを優先度の高い順に並べる
  • ストーリーに背景や解決したい課題を明記して、チームがそのストーリーの価値を理解できるように助ける
  • チームが気付けない・伝わらないことを察知し、改善に向けた下ごしらえを考える。または、その場で簡単な問いかけを行い、気付きを深める手助けをする(初期に2,3回やると、自分たちで気付きやすくなる)
  • 価値の低いストーリーの話題になるようであれば、時間の無駄なので、その会話を今(スプリントのスコープを明確化するための会議で)やる理由があるのか、確認する。

Q. ユーザーストーリーの価値をどんなメトリクスに基いて判断するか?どんなメトリクスは受け入れがたいものか?

  • ビジネス KPI や VOC のコメント、ユーザーの利用ログを用いて、期待した振る舞いに改善されているかを測定する。
  • かけた工数や、コードの行数はどうでもいい。

Q. チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか?

  • PO とストーリーを優先順位順に並べ、チームの計画に対して、価値を最大化できるように取り組めているか?を問いかける。

Q. どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか?

  • チームやプロダクトの状況によるとしか…
  • 経験的に 10%は最低でも必要だと思うし、だいたい毎日1hくらいはみんなやってるんじゃないかなあ。

Q. チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか?

  • 自己組織化の阻害や、PO 自身がボトルネックになっていることを理解させる。
  • あなたがいなくてもチームが自分で同じ選択をできるようになったら、あなた(PO)はもっとプロダクトの価値発見に時間を割けるようになるし、そうすべきだ、という話をする。
  • 一方で、チームが良い判断をできるようには、どうしたら育つだろうか、という議論を一緒に考える、になる場合が多い。

Q. チームメンバーによるタスクのつまみ食いをどのように扱うか?

  • ムダを生んでいること、チームの生産性を阻害し、残業を生むということを理解させる。
  • サイクルタイムでも測定しておくとわかりやすい。
  • 一方で、なぜつまみ食いしたくなった?というのは尋ねておく。
  • 手が空いたので、、とかであれば、大事な取り組みはつまみ食いではなく、仕掛中のタスクを終わらせるスキルを身に付けたり、調査を進めてあげることだったりする。できることをつまみ食いすることより大事。

Q. ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか?

  • 終わらせることをコミットできないし、割り込むのであれば、チームのスプリントの達成に向けたコミットメントに対する挑戦行為であることは理解してもらう。
  • 一方で、なぜ1日遅れてしまうのかを共に考える。
    • ひょっとしたら、スプリント期間が長すぎるのかもしれない
    • ひょっとしたら、スプリント開始タイミングが悪いのかもしれない
    • 単純に PO のポカであれば、どうやればうまくできるかを考えた方が良いかもしれない

Q. スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか?

  • なぜ無駄だと考えるのかを質問する。
  • スプリントプランニングの目的が伝わっているか、確認する
  • 無駄だと感じられてしまうような、チームのスクラム状況の問題を見つけ、ともに改善する

スタンドアップやデイリースクラムについて

Q. チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか?

  • 推奨する。経験度合いは関係ない。
  • スタンドアップ形式による集中と、長引かせないための仕組みはどのチームでも機能しやすい。
  • タイムボックスを守れないとしたら、そのこと自体についても振り返りで考えられるように仕向ける

Q. なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか?

  • 期待しない。アンドンでも Slack でも StackOverflow でも Qiita の謎ポエムでもいいから最速で解決されることを望む。

Q. スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか?

  • デイリースクラムの目的を理解させる。
  • 自己組織化し、お互いのやっていることを共有し、お互いが今日何をやることがベストなのかを考える場であることを理解させる。

Q. スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか?

  • チームへの悪影響が出ているか、事実として把握する
  • 属人化したタスクの持ち主であったりする場合に見かけることがある気がする。
    • その場合は、属人化しないようなタスクの取り方になっていないことがリスクでないか、考え、属人化せずチームとして機能するようにタスクの選び方を考える場を設ける。
    • そもそもチームのメンバーである必要が無い場合、外すこともありうる。
  • チームになっていないようであれば、チーム構成として必要かを見直す。

Q. スクラムチームのスタンドアップステークホルダーは誰も参加していない。この状況をどのように変えるか?

  • ステークホルダースタンドアップに参加する必要ある?
  • 監視のために出席したいようであれば、チームの状況検査の場において、あなたがいるだけでネガティブな影響となるプレッシャーを持ちうる立場であるということは伝える。
  • それでもひつようなら、カンバンなりバーンダウンを見るように進める。
  • 見ながらも外野からピーチク言うタイプのステークホルダーであれば障壁なので排除する。

Q. 分散チーム間のスタンドアップをどのように進めるか?

  • そもそも分散になってしまう状況と戦いたい
  • 全員が状況に対して同じ認識を持てているか、無駄な時間を使っていないか、F2F なら伝わる機微に気付けないことで問題から目をそらしていないか?を観察する。
  • 可能な限り情報を短時間にリッチに伝える方法を考えると思う。

Q. スクラムチーム用の物理カンバンボードをいま書いてください

  • ストーリーカンバンとタスクカンバンはセットで必要かな。あとは各種チャートも必要なら。
  • チームのプロセスやフローによって変わるので正解はない。
  • 正解や標準があるという認識が不正解、ということだけはいえそう。

ふりかえりについて

Q. だれがふりかえりに参加してよいか?チームだけか?プロダクトオーナーも参加してよいか?

  • スクラムチームが楽しく効果的に働くための改善ミーティングであるので、PO も当然参加してよい。
  • たまに PO の存在によって問題の発掘や提示がしにくいチーム状況であれば、軽減するプランを考える。
  • Sensitive な状況だと、Team building のための下ごしらえが必要だったりもする。
  • たまに、そんな下ネゴや信頼関係の醸成に向けた仕事を、酒がすべて解決する場合もある。まあ、それならそれで。

Q. チームが健全な状態かをふりかえりの中で確認するか?それとも不要か?もし必要だとするとどうやって確認するか?

  • 「健全な状態」の定義が難しい気がする。
  • チームが自身で検査して、課題の発見ができているかどうか、それに向けてリーズナブルな解決策を選べているか、を「健全な状態」だと思っているのでそれを確認する。

Q. 過去に使ったふりかえりのフォーマットはどんなものか?

Q. どうやってマンネリを防いでいるか?

  • 持ちよりお菓子を変えたり、アイスブレイクで工夫したり、色々。
  • マンネリ化してきた際に、世の中のカッコイイチームはどんなやり方をしているのかな?といった、ソリューションから入って、自分たちにそれで解決できるポイントって、あるかな?といった気付きに使うチームはいた。

Q. チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか?

  • チケット切って次のスプリントバックログの一番上に置けって Jeff が言ってた。
  • そもそもそれで解決できると感じていないような場合は、改善策検討までの過程をサポートすることもある。

Q. どうやってアクションアイテムのフォローアップを薦めるか?

  • スプリントに突っ込んだものがやられたかどうか、チームで検査できる。

うん、長い!&タフな質問が多い!

これは確かに、Junior なスクラムマスターを炙り出しやすい気がした。

(炙り出されてるかもしれない)

炙り叉焼食べたくなってきた…

俺のアジャイルマニフェスト

アジャイルマニフェストを鵜呑みにしていいのか

って話でして。

中身の理解をしないで腹落ちもしないまま人に勧めるような場面を見かける。

中身をわかってて勧めてるのとわからないまま勧めてるのでは天と地の違いがある。

(主にそいつが信用できるか、と言う点で)

ってわけで、アジャイルマニフェストをどう理解しているか?を見直そうと思った。

マニフェストはわかるし、価値と原則もわかる。

が、いざ正確な言葉で表現するとなかなか難しいかもしれない。

自分の理解を見直すいい機会になりました。

Manifest

Item Because hoge
プロセスやツールよりも個人と対話を、価値とする なぜならば
包括的なドキュメントよりも動くソフトウェアを、価値とする なぜならば
契約交渉よりも顧客との協調を、価値とする なぜならば
計画に従うことよりも変化への対応を、価値とする なぜならば

Principal

Item Because hoge
顧客満足を最優先し、価値のある
ソフトウェアを早く継続的に提供します。
なぜならば
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
なぜならば
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
なぜならば
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
なぜならば
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
なぜならば
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
なぜならば
動くソフトウェアこそが進捗の最も重要な尺度です。 なぜならば
アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
なぜならば
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
なぜならば
シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 なぜならば
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
なぜならば
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
なぜならば

これの、‘なぜならば‘ に続く理由が言えるか、腹落ちしているか、は、スクラムマスターやアジャイルコーチをやる上で大事だな、って気がしました。

エンプラアジャイル勉強会(20190212)に参加してきた。

2月のエンタープライズアジャイル勉強会に参加してきた話

オージス総研さん主催のエンタープライズアジャイル勉強会に参加してきました。

エンタープライズアジャイル勉強会

たまによく行く(謎)のですが、レポッす。

品川インターシティ開催だったのが、大崎開催となり、職場から近くなったのでちょっとラッキー。

仕事の都合で少し遅れて参加しました。


セッション ① スクラムマスターの目で見たサイボウズの変化 -アジャイルの先にあるもの-

講師は天野祐介 ( ama-ch (@ama_ch) | Twitter ) さん。

speakerdeck.com

サイボウズアジャイルコーチをやられているとのこと。

(アジャイルコーチっていう職種が認められている会社って時点で若干羨ましい。)

アジャイルコーチチームは3名いるとのこと。

そのうちの一人は永田敦さんで、以前会社でアジャイル先駆者として活躍されていた方だったのでビックリ。

別の会社に行ったとは聞いていたけどいつの間にサイボウズに。

契約形態で優秀な人間を逃すな

興味深かったこととして、アジャイルコーチを採用する上で、副業上等な柔軟な契約形態が取れたことが理由の一つ、という話。

確かに、裏を返せば、契約形態を固定したいがために優秀な人を逃していいのか?という問題にぶち当たる。

そうまでして押し通したい契約形態ってなんだろう?

(往往にして管理する側がめんどいだけだと思うけど。)

マネージャが消えた話(誇張表現)

もう一つ面白かったのは、プロダクトに合わせてフラットな組織にしたら、部長の役割がなくなってしまったという話。

「組織運営チーム」のメンバーとしてマネジメントをしているらしい。

役割が給料に直結してしまい、下げられないような大きい会社とはフットワークが違うなと感じた。

古い大きい会社でそんなんやったらゼッタイ偉い人反対するでしょそんなん。

放浪するアジャイルコーチ

チームが育って空調調整おじさんと化した(理想だ)ある日、暑くも寒くもないと言われついにチームでやることがなくなってしまい、他のチームを見に行ったりしていたが、特に上司からは怒られなかったという話が面白かった。

権限が移譲されている(管理を不要としている)素敵な状態だ。


権限委譲ってどうやるんだろ

マネージャーからの権限の委譲って、そう簡単な話ではない。

大抵の場合、マネージャが結果責任を負う一方で、過程に介入できないというのはかなりリスクだ。

ってなると、「何やってるか逐次報告しろ!何をやるか俺の指示通りに動け!」ってなる。

権限委譲しようと思うと、マネージャーから見て、チームが向かっている方向性が適正で、働き方が適正で、正しい方向に是正する力学が働いている、というのが把握できていないと心配でしょうがない。

個人的な経験で言うと、マネージャのクソ度胸というか、器の大きさにも依存する気はする。



セッション ② あなたの会社にアジャイルを見つけよう

講師は LINE の横道 ( Minoru Yokomichi (@ykmc09) | Twitter ) さん

omoiyari.fm の Podcast をやってる人だ!

lean-agile.fm

資料は ↓

speakerdeck.com

LINE の社風と、アジャイルが合っているので、アジャイルが進む、と言う話をされていた。

自分たちの中で何がアジャイルで、何がアジャイルじゃないか?を見つけることから始めようと言う話だった。

アジャイルじゃないものを変えるための第一歩は何か?を見つけて、自分の手の甲に書くこと!というワークショップをやった。2日経ってもまだ消えねえよサインペン。

そしてワークショップをやると行っていないのにどこからか湧き出てくるポストイット。さすが。

何がアジャイルって考える基準か?

ちょうど自分の仕事でも、「アジャイルってなんだろう?」を考える会があった。みんな認識バラバラだし。

端的に言えば、アジャイルマニフェストで書かれている価値と原則だし、本質としては変化に対応して勝つための姿勢だと思っている。

アジャイルソフトウェア開発宣言

今回の LT でも、アジャイルマニフェストをベースに、会社のミッションに沿っている(=取り入れていくべき)価値観があるよね、と言う話だった。

個人的には、自社のアジャイルなところ/アジャイルじゃないところを考えた時に、真っ先に浮かんだのが、「非アジャイルマニフェスト」だった。

kawaguti.hateblo.jp

涙無しで読めるようになりたいぞ。


そのほか学んだこと

突如湧いて出たポストイット、川口さん (Yasunobu Kawaguchi (@kawaguti) | Twitter )の私物(?) だったわけだが、その時に面白かったのが、

ポストイットケース!

今までもポストイットとサインペンを持ち歩いてたが、書類ケース内でポストイットが散乱して鬱陶しかったので、困っていた。

どうやら100均の折り紙ケースが使えるらしい。まじか。

で、今日3件くらい回って程よいサイズのケース(ハガキケース)をゲット。

これでかさばらなくて済む!

モノがキッチキチに詰まってるのがなんか好き。どうでもいいけど。


ウッキウキで帰りにピープルウェアを買って今に至る。

ピープルウエア 第3版

ピープルウエア 第3版