弊社はアジャイル、スクラムの知見を持っていたり、学習・活用している人が多くいますが、自分のチームではこれまで「なんちゃってアジャイル」、「なんちゃってカンバン」、「なんちゃってスクラム（スプリント）」でやってきていました。
基本をこなしたうえでの、応用の「なんちゃって」ならいいのですが、開発リーダーである私が根本から「なんちゃって」でやってきていたので、遅ればせながら社内でも評判の高いワイクル 角さんのレゴスクラム入門に参加してきました。
一応事前にスクラムガイドはざっと読んで参加。公式スクラムガイドの日本語訳は、以下のページから PDF が無料でダウンロードできます。
また弊社の過去の参加者の真面目なレポートは以下をご参考ください。
雑感
おもにいま自分が仕事で実践しているやり方との差を感じた部分、それについての思いなどを。
プロダクトバックログとスプリントバックログ
普段それぞれを「バックログ」、「ToDo」として管理している。
スプリントで回しているし、なんとなく正式な呼び方のほうが認識が合いそうと思った（呼び方はチーム内の合意が得られていればなんでもいいとは思うが）。
プロダクトバックログの書き方を工夫したい。いまは「＊＊機能」「＊＊対応」とだけ書いていて、「誰が」必要とするのか「なぜ」必要とするのかが明確でない。そのへんは一度話していたとしても、実際に対応する段になると忘れていたりして、自己組織化を阻害しているように感じた。
あと WIP 制限は導入したほうが良いかもしれない。レビュばかりで開発に着手できないということが度々起きているが、これは（レビュを含む）仕掛り中の付せんの数が制限できてないせいな気がする。
スプリントレビューとスプリントレトロスペクティブ
スプリントレビューについては、最近はレビュの場でプロダクトオーナーから「これはOK」「これはOKだけど、さらに＊＊してほしい」といったようなフィードバックを受けるようになったので、だいぶスクラムガイドのやり方に沿ってきたなと思った。
座学でも言っていたけど、Simple OR Complicated なタスクをこなす分にはスクラムでなくても良くて、有用なのは Complex な領域であると。Complex な領域とは「何を作ればいいか」「どうやって作ればいいか」の双方に不足がある（すべてを想定しきれない）「複雑」な場合。
参考: Simple vs. Complicated vs. Complex vs. Chaotic - NOOP.NL
プロダクトの改善と、プロセスの改善は別物で、それぞれ必要なことである。というのは感覚として認識していたけど、あらためて言われるとなるほどと思った。
スプリントレトロスペクティブは主に KPT を行っているが、そこでこの２つを意識してみたいと思う。
スクラムマスター不在
いまの自分のチームで、これが良いのか悪いのかは、あまり判断がつかなかった。
「一度スクラムをきちんとやってみます！」となったら、慣れるまで数イテレーションはサポートしてもらうのがいいのかもしれない。
開発チームとプロダクトオーナーの役割
いま、プロダクトオーナーと開発チームの間に自分が立つような形に（若干）なっているが、これは全面的に止めたほうが良さそう。これもメンバーの自己組織化を阻害している気がする。
とはいえ、自分がいなければメンバーが動けない、ということは無いので気にし過ぎなだけかも。メンバーの意見も聞きたいな。
開発チームが継続的デリバリーを導入している場合、「顧客」あるいは「社内関係者」へスプリントレビューで機能そのものを説明するのは、プロダクトオーナーの役割という話があった。これは継続的デリバリーによって、日々ローンチされるものはプロダクトオーナーによる検査が通っているという前提があるため。
継続的デリバリーを取り入れている場合、プロダクトオーナーの検査は日々行われていないといけないのだな、と認識した。でないと結局「週一リリース」みたいなことになってしまう。
この点はデイリースクラムか、その後に時間を取るのがいいのだろうか。
全体的に
「なんちゃって」でやってきてはいたが、最近はむしろスクラムガイドに沿った方法に自然と寄ってきている気がする。
もたついている部分があるので、そこにきちんとしたスクラムのプラクティスを導入してみたらスッと動けるかもしれない。
タイムボックスやスプリントの区切りについては、ちょうどこれから変えてみようという話もしているところなので、参考にしたい。
すごくどうでもいい感想
これはスクラムに関する感想ではないですが
ワークショップは、現実世界でロールプレイが得意なひとがいると楽しいですね。自分は照れが出てしまってまだまだです(；´∀｀)
