海と山が好き

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

『別にスクラムは目的ではないので』との向き合い方。

「別にスクラムは目的ではないので」

親の顔よりよく見かけるフレーズ(当社比)

スクラムの規定しているロールやイベントをやらない際に使われる。Scrumbut みたいな。

f:id:Bashiko:20200623171313j:image

もちろんスクラム自体は目的ではないし、してはいけない(と、個人的には思っている)が、スクラムがなぜ機能するのか、を理解せずに、上の言葉を持ち出してねじ曲げる場面を見ると、少し危ないと思っている。

(もっとも、スクラムだけじゃなくて、PMBOKCMMI でもよく聞いたし同様だ)

 

続きを読む

スクラムを個人戦にしてしまう方法

スクラムではチームの成果にフォーカスする。

そのためには、個人で仕事をする形から、チームで仕事をする考え方にシフトしないとけない。

いわゆる Swarming という考え方で、チームが寄ってたかって一つの開発アイテムを進めることを意味している。

逆に、チームでバラバラと仕事を進めるわけではない。

イメージしにくい人は、アメフトの試合で、ボールがフィールド上にいくつあるのか(1つに決まっている)、チームはどのボールに向かっているのか(1つに決まっている)を想像してみるといいと思う。あっちもこっちもボールが転がってたら大変だ。面白そうだけど。


なぜチームで仕事をするのか

続きを読む

なんでもアジャイルなのだ

空前のアジャイルブーム到来(主観)

ここ2、3年? アジャイルブームが来ている、気がする。

 

一方で、アジャイルっていう必要あるんかそれ?っていうモノも見かけるようになってきた。

 

アジャイルアジャイル、みたいな接尾辞がつくのは特にそんな感じのものが多い気がする。

 

 

アジャイルを名乗るな!とかいうわけではなくて、本質を見失うと空回りしかないからよくないんじゃないかなーと思う

 

第一、”それ” を広め ら れ る 側の立場からすると、謎の横文字と出羽守スタイルで殴りかかってくる敵と戦う構図になるので拒否反応しか出ないのではないかなあ。

 

アジャイルってなんだったっけ

ところで、そもそもアジャイルってなんだったっけ、に戻ってくる。

アジャイル開発ではなくてアジャイル

 

みんな大好きアジャイルマニフェストのとおり、価値宣言と原則があって、っていう。

 

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

アジャイル宣言の背後にある原則

 

表現がシンプルすぎて誤解を生みまくる、というか都合の良い解釈をされやすいこれら。

よくわかんないからって調べても、まあまあ怪しい解釈サイトがいっぱい出てきて中々腹落ちしづらいこともあるし、そこでみんないろんな解釈をしてすれ違いが生まれるんだろうなあ(他人事)

 

背景や過程を知らないで文言だけ追っても本来の意図とは違うものを解釈するのは当然起こる。

tree-swing-s-hogh

ので、背景や過程を知っておくのも、アジャイルとは?ってのを理解する上では重要だと思う。

(ユーザーストーリーにおける、so that ~~~ の部分。)

一応、Agile Manifesto のページにはちょっとだけ History ページもあるけどなんでこれ翻訳されておらんのやろ。

agilemanifesto.org

 

読もうね。

 

計画駆動(≒現実軽視)やプロセス重視(≒人間軽視) からの脱却であって、見える化とかチームとか速くデリバリするとかはそのための手段ちゃうんかな

 

アジャイルで部署の枠を超えて新商品発売の開発期間をxx%削減!とか言われても、会社が小さかった頃はアジャイルなんて言わずにそうだったんじゃないの?アジャイルっていう必要あるの?とか思ってしまう(性格悪い)

 

営業部は昔から組織目標の売り上げの達成グラフみたいなのを出すことはずっとやってる。でもアジャイルとは言わないだろう。

営業の現場でも昔から使われている見える化という取り組み(パターン)をアジャイルでも使われている、ってだけで。

土木の現場では毎朝朝会をやっている。でもそれをアジャイルとは言わないだろう。

毎朝現実の進捗に基づいてその日の計画を立てる、予測を立てる、っていうのをアジャイル開発も同じようにやっているだけで。

 

逆にアジャイルは朝会をやります、というのを、脳死でマネしても多分意味はないしそれでアジャイルとか言われてもツライだけだと思う。現場が。

 

とはいえ、

アジャイルとかいうのがなんらかの改善を伴う活動だっていうのは間違いないが、

 

「レビューで手戻りが起きた!」

→ 『よし、改善だ!』

→ 『事前に仕様に間違いがないことを合意して押印してもらうぞ!これで改善できるぞ!アジャイルだ!』

 

ぐらいのことはきっと起きるし起きてる。ツライ。

 

(例えは極端だけど、予実がズレたから1ポイントを1人日にしましょう!みたいなチームは稀によく見る。スクラムマスタークビにしろ)

 

じゃあどうすんのさ

どういう観点で改善進めるのかが肝心な気はしている。

 

ディスカバリーサイクルとデリバリーサイクルの流れをよく見るのが一番効果が高くなる気はしている。

バリューチェーンのどこがボトルネックだったり、サイクルタイムを長くしているのかを調査する。

(やることや観点はパフォーマンスのチューニングと一緒だったりする)

 

視野を狭めると効果がないので注意が必要だったりするし、難しい。

 

開発チームの中でスクラムを回して楽しく開発してても作ったものが本番にデリバリーされてないならそこに目を向けないでスクラムスクラム言ってるのはなんの意味もない。というか浅い。

よっしゃ DevOps や!とか言いながら改善スコープを広げていくしかない。

実は開発サイクルじゃなくて PO が顧客と話してまたは調査して課題発見するまでがボトルネックだったり長くなってるならそっちに手をかけないと意味がない。

一生懸命アプリケーションのチューニングばっかりしてるけど DB のレスポンス遅いのは DBA の仕事だから僕知らない、みたいな。良くないしそっちがパフォーマンスにおいて支配的なら自分のスコープに拘る意味がない。

 

f:id:Bashiko:20200317211947p:image

 

 ------2020/3/17 追記-----------

この辺で雑に書いてたことは全部綺麗に Ryuzee さんのブログに書いてあったから各意味なかったのと思ってるしそっちを参考にした方が1億倍健全ですのでそっちを見てください。

不確実な環境の中で 変化にどう対応すべきか | Ryuzee.com

 ------追記終わり-----

 

アジャイルを広める

とかいう難儀な仕事に就くなら、社内の改善サイクル、改善軸の手助けから始めるのがよさそう。

脳死で大規模プロセスとか導入するのはラクだし成果も見せられるだろうけど結果には繋がらんので。

(さいきょうのサーバーを1台置いたんで、ここでみんなかいはつしてでぷろいしてさーびすしてください!なんて悲劇しか起こらんでしょ)

スケールさせるのはプロセスじゃなくて文化。間違えると人間軽視に走って自己否定になるし。(もちろんプロセスも大事だけど。)

 

----

 

結局『アジャイル』とかいう実体の伴わないラベルは忘れた方が良いのかもしれない。

(AI やりましょう!くらい胡散臭いと思っていい)

 

自分らが顧客に何を提供するかの観点で、じゃあ何の問題を解決しましょうか、の繰り返しの結果、多分アジャイルみたいな何かになっている、はず。たぶん。知らんけど。

一方で、アジャイルっていうのが、どんな課題にどんな解決策で上手いことやってるか、というのは、知っておくと効率が良いし車輪の再発明しなくて済む。かな、って程度で。

研修やカンファレンスへ自費で行くかどうか

研修やカンファレンスに自費で行くかどうかっていう話

 

id:kobase16 さんの記事を見て思ったこと。

個人的には、ここ 1, 2 年は自費で行く場合が増えた。

理由として考えてみると

  1. 会社にとってまだアジャイルはそんなに必要じゃない。5年後には必要だけど。
  2. 社内の手続き&社内システムが面倒。金払ってでも回避したいレベル。
  3. 給料増えた(少しくらいはね)
  4. 仕事観が変わった

って当たりなのかなと。ハイパーものぐさなのはさておき 4.が一番大きい気がする。

 

どっかで見たんですが、「会社に仕える」っていう働き方と、「ジョブに仕える」働き方のパターンがあると。

  • 前者 (会社に仕える) は、会社のミッションに合わせてアサインされた仕事をこなす。何をやるのかよりも、どこに所属するか、が重要
  • 後者(ジョブに仕える)は、自分のジョブ(エンジニアとか)を発揮できる(金を払ってくれる)会社で仕事をこなす。何の仕事をするのか、が重要

で、個人的にはある程度アジャイル周りの経験を積んできて、後者に意識が移行してきたんだと思っています。

というか、会社に依存すると、会社が倒産したときにリスクしかないので、外でもやっていけるスキルを身に着ける=外のジョブ(欧米だとギルドみたいなもの作りがち)に交流することが増えるので、結果として私の中で必然的に会社への依存が相対的に低下したんだと思います。(まあ会社の本流じゃないことばっかりやってるし)

なので、自分がやりたい仕事をするうえで、自分の成長への投資っていう意味で、カンファレンスなどへの費用は自費で言ってます。当然 RSGT は休暇を取りました。

2020.scrumgatheringtokyo.org

(えっ、お茶の水なの‥?)

 

まあ結果として投資した分以上の給料のフィードバックが返ってきているので、そこら辺の株に投資するよりはリターンが大きいかなと思っています。

30代までは金融資本よりも人的資本に投資した方が効果が高そうなのでそうしています。

Agile Talks に行ってきたメモと感想

Agile Talks #1 に言ってきた話と感想

Agile Talks is 何

  • Agile Talks vol.1 - connpass
  • RSGT で落選したネタを聞いてみたいよの会
  • freee さん開催。そういうの男前でいいと思う。

1. 「アジャイルコーチから見たScaled Agile Method.. ~SAFe and LeSSから学ぶ勘所~」

SAFe の話(オージス原田さん)

  • 企業アジャイル標準とかの支援でやっている
  • 大事なこと: Train everyone, Launch Train
    • 乗せなくていい方法を考えたいわ
  • 徹底的にアジャイルをやっていこうよ!というのが SAFe
  • 予算の振り分けをポートフォリオでやる。(Epic に振り分ける)
  • Agile Release Train が大事。
  • Train にみんなを載せて価値を届けていく
    • 乗らないと価値を届けられないのはなぜ?
  • PI 計画を立てて、Iteration で Scrum をやっていく。
    • PI 計画のサイクルは、十分 Agile なの?
  • SAFe の価値は Innovation がある。
    • SAFe やりながら Innovation を生み出した例ってあるのかな?
  • やってみると問題が出てくる。ので、経営陣が課題を解決することになる。
  • ART(Agile Release Train)という横断的な組織で価値を届ける。
  • Train の中にチームがいっぱいある。
  • PI 計画は SAFe の基礎であり、これをやっていないなら SAFe をやっていないと言える。
  • PI 計画はとても熱気がある。アジャイルっぽい感じがするらしい。
  • PI 期間はどれくらい? → 10週間くらい
  • PI 計画の想定が違っていたらどうする? → PO Sync とかで PdMgmt と Sync する
  • 裏で PO 同士が握ってる感はたまによく見る(?)
  • システムを変えられるのはマネジメントです、という観点が SAFe の考え方。
    • 自己組織化どこいった
  • 組織全員でジャーニーする
  • リーダー研修やってるし来てね

LeSS の話(kanataku 木村さん)

  • 原理・原則を中心にフレームワークを持っている。ガイドがその外側にあり、実験が最外郭
  • LeSS は Scrum である。Scrum から変わっていない。
  • ”少なくすることでもっと多く”
    • でもチームはスケールさせるのは肯定するのかな…そこに矛盾を感じてしまわんでもないのが Scale なんちゃら
    • おなじ LeSS にしない、っていう判断基準はある?同じ Product でなければ、同じ LeSS にしない、ということでよいのかな?
  • 小さいところから始める。(SAFe とは逆だね)
    • これらの Scaled フレームワークが現場から出てくるケースはある?それは自己組織化していると言える?百歩譲ってトップダウンだとして、その後チームは自己組織化できるのかな?
  • Feature チームでチームを作るのが大事
  • Product Backlog は一つ。
    • いっぱいあるとマネージャーがゴニョゴニョ...
  • 依存や問題点を解決するために、複数チームで協調してイベント(計画とか)をやる
    • 依存をなくす方法は話されるのかなあ
  • レビューはみんなでやろうね。マネージャーも(?)
  • SAFe みたいに偉い人を捕まえて導入するわけじゃない。やっといた方がいい。
  • 小さく始めるのが大事。
    • 小さく始めて回ってるなら LeSS に参加する必要なくね?
  • ラーマンの組織の話、飛ばされる。
  • LeSS 勉強会やってるから来てね

所感

  • 知りたいのはアジャイルをどうスケールして組織に広めるか、であって、アジャイル開発(プロセス/フレームワーク)をどう広めるかじゃないんだよなあと再確認
  • "上" から出された方針の元で変えられたプロセスで、チームが自己組織化していけるのか?ってのがやっぱり1番の疑問(解決してない)
  • SAFe とか上しか見てないから顧客とか絶対見ないしなあんなもん

2. 「レトロ・オブ・ザ・デッド ~ゾンビレトロしてたチームを2年間観察していたら、良い振り返りをするようになったので、その活動報告~」

  • 講演者: Yamaneko 田中さん
    • Coaching Agile Teams の翻訳会やってる会社かな
  • RSGT でボツになった。タイトルのインパクト重視で長いタイトルにしたのに落ちた
  • 2年間同じチームを見続けている
  • お通夜みたいなレトロをやっていた。Problem の前でひたすらフリーズしてしまっていた。
  • Random retros - Get new ideas for your next retrospective をやるようにしてみた
  • チームがこのまま続いて楽しみ続けていくだろうということに疑いが無いレベルに育った
  • そもそも良いレトロってなんやろ
  • アンチレトロ:自傷的なレトロ、Problem だけに注目している、技術的課題しか見ない、そもそも振り返ってない。
  • 帆船のレトロとかやってみている
  • 行きたい先・なりたい姿に向かった少しでも前に進んでいることが見えないとあかん
  • 某コーチの助言「チームは問題解決をしてはいけない」
    • コンテキストがわからんけど正解(=解決策)がないからかな。暫定解。実験。
  • 自己肯定的であることが大事。From 子供を伸ばす共育コーチ
  • 良いレトロとは:実行可能かつ計測可能。長期的なゴールに対する投資。自己肯定的。
  • 高揚感と自己肯定感は別。

    どう変わってきたのか

  • レトロのパターンを変えてみた。帆船やってお絵描きをして空気が良くなった。
  • チームの雰囲気が良くなったものの、飽きてきた。ので、いろいろ試すようになった。
  • Check-In/Check-Out は効果あるので常にやるようにする。
  • 文化に対するアプローチをしたときに最も躍進する。変える気付きを得たとき。
  • 拡散と収束が大事
  • 何かをする、のが大事ではない。何を変えるのか、が大事。
  • 楽しくやる!
    • スクラムガイドにもちゃんと書いてあるのにね。現場で尊重されてない単語の一つだよね。
  • レトロのやり方も検査する。
  • 決めたことはやり切れ

所感

  • レトロ難しいよね
  • コーチとしてもういいかなこのチームは、って、どういうところを見てるのかなあ。

以上