ナナメガキ

本

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

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

#スクラム開発

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

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

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

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

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

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