ナナメガキ

本

まっすぐ向き合ってナナメに書き捨てる、エンジニアリングマネージャーの思いのたけ。ナナメ読みするくらいがちょうどいい。

運営しているクリエイター: あろえ

#スクラムマスター

スクラムマスターの壁 - 回復志向からの脱却

スクラムを始めたばかりのチームでのスクラムマスター業は"うまくいかない現状"との戦いだ。それもそのはず。チーム内外問わず関わる人達のスクラムに対する理解度もモチベーションもまちまちだし、スクラムであろうがなかろうが従来のやり方からの変化には戸惑うのが当たり前なのだ。そういった精神状態のチームメンバーやステークホルダーと共に、プロダクト開発を進行しつつ(成果を継続的に出しつつ)、スクラムを確立させていくためのあらゆる支援をするのがスクラムマスターなのだ。うまくいかない状態をど

初めてスクラムマスター業をしたときにだけ味わう苦悩

初めてスクラムマスター業をやったとき、何からしていいか本当に分からなかった。あれこれ試して失敗した時期があれば、チームメンバーを失敗で振り回すのが怖くて何も試せない時期もあった。本や有識者の記事を読み漁って、今の状況にちゃんと照らし合わせながら取捨選択して施策を打ったりもした。だけれど手応えがいまひとつで「なんだ机上の空論か」と愚痴ることもあった。例えばチームビルディング的なアクティビティをしてみたり、レトロスペクティブにてもやもやを言語化してみたりすると、その時は盛

受け入れやすい変化とそうでないもの

最近の悩みの一つは、「変化の許容量が違うチームメンバー同士で、どうやってチームを改善し続けるか」だ。悩みの内訳については先日書いた。この件について、頼れる同僚がディスカッションに付き合ってくれたので、そこで出たアイデアをまとめておく。＊＊＊変化に耐え得る総量があるのではないか変化を受け入れられる総量が各々にあって、そのリソースを他の部分に割いているときはチームの改善をしにくいと感じる可能性があるかもしれない。例えば「新しい技術の導入にチャレンジしている途中だか

"変化に対するキャパシティ"のズレと改善活動の難しさ

スクラムチームにせよ、エンジニアチームにせよ、僕が属するチームには自分たちの開発プロセスを自分たちで改善する裁量がある。ありがたい話だ。ただ、誰もが僕みたいに反省や改善が大好きなわけではないし、僕より遥かにハイペースで改善し続けようとする人だっている。期待する改善のペースは人それぞれで、だからチームで取り組む改善活動は難しい。＊＊＊ところで、改善とは変化の連続の上に成り立つものだ。何かしらを改善しようと思ったら、新しい方法を試行して、データを集めて、検証して…

スクラムに感じた歪さとスプリントの再考

今までいくつかのスクラムチームに携わってきた。開発者として、スクラムマスターとして、はたまたスクラムチームメンバーのエンジニアリングマネージャーとして。何度実践しても腑に落ち切らなかったことが1つある。スプリントの長さだ。どのチームでも、どのプロダクトでも、自分たちにとって(比較的)適したスプリントの長さはこれだと言い切れたことが一度もなかった。プロダクトバックログの分割しやすい粒度と、計画しやすい期間と、割り込みをロックしスプリントゴールへ邁進したい期間と、レトロス

失敗から学ぶために本当に必要な"失敗"とは何なのか

失敗から学ぶ、つまり「経験をもとに得た知識や教訓を自身に定着させる」ためには、失敗を経験することが必要だし、それをふりかえることが必要だろう。ふりかえりの具体的な方法論については本で学んだり実践したりして知見を溜めてきたけれど、どんな経験をふりかえれば良いのかについては考えたことがまだなかった。なので今日ここでチャレンジしてみる。ちなみにふりかえりの方法論はこの本にびっしりと載っている。チームのふりかえりをレベルアップさせるにはもってこいの一冊だと思う。＊＊＊