アジャイル開発の始め方

Podcastのふりかえりam ep.11を聴いてふと感じたことを記録。

少しずつ始める、その第一歩めがふりかえり

スクラム開発を導入するときに最初はふりかえりしか入れなかった

たしかに自分も前職ではまずふりかえりから始めたのでとても共感したとともに、そういや今スクラム導入を進めてるけど、ふりかえりにまだあんまり力入れてないなーと思い、ちょっとまとめてみたくなった。

まだ今回のアプローチは結果が出ていないので何とも言えないところではあるが、前職ではアジャイル開発という言葉自体「何それ」というところからのスタートだったので、プロセスを整えるのは大掛かりすぎて最初からやるつもりはなかったように記憶している。
まず何かひとつプラクティスを入れてみよう、というときに、毎週ふりかえって課題をひとつずつ解決していけば、段々理想のプロセスに近づいていくんじゃないかなーと思いながらふりかえりを導入したのだと思う。

翻って今回は、ある程度アジャイル開発を意識したプロセスで開発が行われていて、その状況を実際に見て、自分の中の理想と現実のギャップを感じた結果、全体の流れをスムーズにするべきだなと考えて会議・役割・作成物の明確化から着手した。
ふりかえりも導入するが、まだ少し様子見の感はある。

こうしてまとめてみると、スクラムの3つの原則「透明性」「検査」「適応」のうち、前職の時のアプローチは「検査」に、今回は「透明性」に最もフォーカスしていたのかなと思う。

あとは、メンバーが受け入れやすそうなところから始めている、というのもあるかも。
現在のチームはふりかえりを以前やってみたけどあまり効果を感じられずにやめてしまった、という背景があり、そこに無理にふりかえりを導入するよりは、わかりやすいところに改善のアクションを加えることで、ふりかえりの効果を説明する材料を作る意図もあったりする。

ちなみに前職のチームでは、ふりかえりは僕が退職するまで3年弱くらい継続した。最後の1年はスクラムも導入して、ふりかえり導入前から比べると新しいことを試したり、効率を上げるために改善したり、ということを自分たちで考えてどんどん進めていけるチームになっていた。

結論、何から始めるかはチームの状況や状態による。
でも共通して言えるのは、いきなり大きな変化を強いるのは避け、少しずつ受け入れていってもらうこと。