TL;DR

4月より開発手法にアジャイル開発を取り入れることになりました
アジャイル札幌より講師をお招きして、Scrumのワークショップを開催していただきました
半日間でしたが、非常に実りの多いワークショップとなりました

背景

弊社も開発部員が3名となり、いよいよチーム開発の体制が取れるようになりました。
4月より少し規模の大きな開発案件があり、その際にお客様にアジャイル開発のお話をしたところ、幸いなことに非常に乗り気になっていただいたため、その案件にアジャイル開発の手法を取り入れることとなりました。
実は創業当初よりアジャイル開発をいつか取り入れたいと考えて情報収集をしてきたのですが、未経験な手法なので、実際にどうすればよいのかの検討がつきませんでした。
参加させていただいているエンジニアリング組織論への招待読書会の席上にて、アジャイル札幌の根本さんに相談させていただいたところ、ワークショップについてご紹介いただき、今回実際に開発を行うチームにて開催する運びとなりました。

ワークショップ

参加させていただいたチームは4月から実際に業務を行う開発メンバ、および、要件定義に入ってもらうお客様、そしておまけに弊社の社長です。
講師として、アジャイル札幌より、根本さんとしょーださんにお越しいただきました。
エンジニアのみのチームではなかったため、ワークショップの内容を工夫していただけました。
ワークショップの流れは下記のようなものでした。

オープニング：ボール回しゲーム
座学：スクラムの歴史
座学：スクラムイベントの必要性について
スクラム体験：ワークショップの説明とユーザストーリーの洗い出し
スクラム体験：実際に4イテレーション回してみる
まとめとふりかえり

オープニング：ボール回しゲーム

ボールを特定の順序で受け渡す、というシンプルな作業を行います。
回を重ねるごとに受け渡し速度は速くなっていったのですが、途中アクシデント（？）ともいえるイベントが発生し、作業がぐちゃぐちゃになります。
メンバの忙しさと、仕事が回っている速度は、必ずしも比例しない、という事を、短い時間で実際に体験できるとても良いワークでした。

座学：スクラムの歴史

ご用意頂いたスライドを使用して、ざっとスクラムの歴史をご説明いただきました。
お客様には事前に「エンジニアリング組織論への招待」をお渡ししてある程度読み込んでいただいていましたが、良い補足となったと思います。

座学：スクラムイベントの必要性について

Scrum Fest Osaka 2019で永瀬さんの発表の資料を使用して、スクラムの各イベントの役割をご説明いただきました。
スクラムについては基本的に全員基礎知識のない状態だったので、良い学びとなりました。

スクラム体験：ワークショップの説明とユーザストーリーの洗い出し

いよいよ、紙ワークショップです。
今回は、紙粘土で動物園を作成します。
開発側はプロダクトオーナ、スクラムマスタ、開発チームに分かれます。
しょーださんが顧客役となっていただき、事前に与えられた動物園のビジョンに沿って、必要なユーザストーリの作成、受入基準の決定、および、プランニングポーカーを使用した見積もりを実行します。

気づいた点は、下記のような部分です。

顧客にインタビューしてない（たたき台を持って顧客確認しようとした）
見積に時間かけすぎ
最初にすべてのユーザストーリーの見積をしようとしてしまった

いわゆるウォーターフォール開発での、要件定義フェイズの様相を呈しています。
アジャイル開発について事前知識があっても、やはり普段実施している考え方が根強く場を支配してしまうのだな、と感じました。

スクラム体験：実際に4イテレーション回してみる

20分1イテレーションで、実際にユーザストーリーを消化していきます。
イテレーションを回すたびに、チーム内のコミュニケーションが活発になり、それに伴ってプロダクトオーナ、スクラムマスタ、開発チームの動きが良くなっていくのが実感できました。

実際に作成された動物たちは、下記です。

1イテレーション目

ポニー

ポニー

大きさがだいぶ違っており、顧客からツッコミをうけました。

ペンギン

ペンギン

エンジニアが一人で黙々と作りました。
なかなかのクオリティ

2イテレーション目

シロクマ

シロクマ

最初一人で作成していたのですが、「時間に間に合わないかも！」というコミュニケーションがとれ、顔と身体を二人で作成。
迫力のあるクマーが完成しました。

クジャク

写真を撮るのを失念してしまいましたが、クジャクを作成しました。
顧客レビューにて羽の色が地味、という指摘を受けて、次のイテレーションで色を塗りなおすことに。

このあたりからプロダクトオーナが、次のイテレーションの受け入れ基準について事前に顧客と打合せをしてくれるようになり、徐々にチームの分担が確立されてきます。
ただし、開発チーム内では気づいていませんでしたが、手を動かしているのが特定のメンバだけになっていました。

3イテレーション目

予期せぬアクシデントが発生！
開発チームの生産性が落ちます。
写真を撮り忘れてしまいましたが、2頭の象を作成しましたが、色のことをすっかり忘れており・・・
白いままの象を２頭作成してしまいました。
結局この時作成した象は、顧客レビューで受入拒否され、次のイテレーションで作り直すことに・・・
また、実は顧客の要望としては象は１頭いればよかったことも判明します。

クジャク

クジャク

前回のイテレーションでリジェクトされたクジャクに、色を足しました。

このイテレーションから各人が自分のロールを回せるようになってきます。
プロダクトオーナは顧客とコミュニケーションをとり、次のイテレーションの内容を策定。
モルモットの大きさが不明な事がわかったため、開発チームからモックアップとして１匹作ってみる、という事になります。
冒頭のアクシデントでかなり現場は混乱したのですが、スクラムマスタも適宜声掛けを行い、状況を制御可能な状態に戻していきます。