Agile」カテゴリーアーカイブ

Regional Scrum Gathering Tokyo2023 に参加してきました #RSGT2023

Regional Scrum Gathering Tokyo2023(#RSGT2023)に参加してきました。

今回もハイブリッド開催でしたが、この形になってから一番多くの人が現地に集まっていたように感じました。
スポンサーブース前、ホワイエ、廊下など多くの場所でいろいろな会話の輪が出来ていて「あぁ、RSGTってやっぱりこれやなぁ」と改めて感じました。

まず、実行委員、ボランティアスタッフのみなさん、(毎回のことですが)こんなステキな場、ありがとうございました!

【発表】Outcomeにフォーカスするチームへのジャーニー


前回と同じ1日目の午後最初のセッションで、緊張していていたところ、いくおさん( @martin_lover_se )や新さん(@aratafuji)など見知った人と言葉を交わせたので少し気が楽になりました。
が、いざ始まってみると「全然うまく話せていないなぁ。スライドのつなぎもだし、リズムが整っていない…」と焦りながらのあっという間の20分でした。
けっこう駆け足で、いろいろ足りない箇所、わかりづらかった箇所があったと思うので、そのあたりはDiscordやSNSで声をかけてもらえたら嬉しいです。

それでも、いくつか質問もらったり、会場で「あの先を聞きたかった」と感想をもらってその場で意見交換をしたりできたのは良かったかと思いました(「あの先」についてはそのうちブログにでも書こうと思います)。

セッションの壁打ちしてくれたAkiさん(@spring_aki)、レビューしてくれたトミーさん(@Tommy1969)さん、ありがとうございました!

スポンサーブース

今回もレッドジャーニーとしてスポンサーをさせてもらいました。
市谷さんや新井さんの書籍の表紙を印刷したチロルチョコをアメニティとして配ったり、ブースに来てくれた人とお話したりできました。

スポンサーセッションでは市谷さん(@papanda)が『右手に「正しいものを正しくつくる」、左手に「組織を芯からアジャイルにする」』を話していました。

Coaches Clinic(コーチーズクリニック)

1日目、2日目とも午後は主にコーチーズクリニックでいろいろな人の相談を聞いていました。今回は例年以上にとても盛況で、ほとんどのアジャイルコーチが時間いっぱい埋まっていたようでした。

私も2日間で13人の方とお話しましたが、だいたい最後には「この場には仲間がいっぱいいるのでひとりで抱え込まないでくださいね〜」みたいなことを言っていた気がします。

クライアントが登壇したりしていた

その支援しているチームメンバーが出したプロポーザルが選ばれて自分たちの経験を話していました。

以前に「yohhatuが話すのもいいけど、クライアントをこういう場で話すように後押しするのも1つやで」と言われていたことが実現できて良かったです。

他にもいくつかの支援先からそれぞれ複数人で参加していたようです。こういう場に一人で来ると現場に戻った時に「なにをしようか」となりがちですが、複数で参加していれば相談できたりする仲間となるので良い形だなと思います。

その他

Day0に英語話者と話した

Day0に少し機会があり、英語で話をしました。
「なんとなく言っていることはわかるけど、こちらから話せない」だったのが、ちょっとだけ会話を続けることができたのが嬉しかったです(毎日DMM英会話続けている結果)。

「DevLOVE関西やろうよ」って話をした

Day2の夜、関西から来ていた人たちと「やっぱりオンサイトいいですね〜。2022年に久しぶりに1回だけやったDevLOVE関西を2023年はやっていきましょうか」みたいな話をしました。

こういう、なにか背中を後押ししてもらえるのもRSGTの良さの1つです。

Scrum Fest Fukuoka 2023にプロポーザルを出した

3月のスクラムフェス福岡がプロポーザル募集中だったので、今回のRSGT2023で採択されなかったプロポーザル「アジャイルコーチは何をもたらすのか?何を考えて、どんなことをしているのか?」を出しました。
ちょっとアジャイルコーチ文脈なのでどれくらい聞きたい人がいるかわかりませんが、興味あるな〜という人はLikeしてくれると嬉しいです。

最後に

「次のRSGTでも何かを伝えられるように1年をやっていこう!」と気持ちを新たにした場でした。

「自分がどんな変化をしたか?」を言葉にする

これはなに?

こちらはレッドジャーニーアドベントカレンダー25日目の記事です。
前日は市谷さん(@papanda)のそれでも、デイリースクラムをやらない理由とは?
でした。

レッドジャーニーのアドベントカレンダーを書いていて感じたこと

12月1日に始まったこのアドベントカレンダーも最終日になりました。

1日目のアドベントカレンダーで、森實さん(@samuraiRed)がアドベントカレンダーをやるということ でこのように書いていました。

我々のアドベントカレンダーの目的は自分たちの「発信力強化」。
つまり、自分たち自身のトレーニングとしてアドベントカレンダーをやっているのです。

25日書き続けたことがどのような変化を産むことになるかわかるにはもう少し時間が必要です。
それでも「レッドジャーニー全員で25日間なにかを発信し続けたこと」自体は事実ですし、少しでも発信力がレベルアップしたかなと思います。

なによりより物事を考えるきっかけにもなります。

みんなの書いたアドベントカレンダーを見てて、普段考えていることを出発点にしてこの機会により物事を考えたんだろうなぁというブログもあり「みんな、変わっていっているんだな」と感じました(手前味噌ですが)。

私自身もアジャイルコーチとして、日々いろいろな組織、チーム、人々と関わり、そこで起きていることに向き合い、また何かを起こそうと共に歩んでいます。そのような状況では”変化していくこと”は大事な要素の1つになります。

というわけで今回は”変化”について書いてみます。

どんな変化を自分がしたのか?

このブログを書いている25日の朝、市谷さんとのいつもの雑談で「自分はこの1年でどのような変化をしたのか?」という話をしました。

その中で「あまり自分は大きく変化していないのではないか?」と感じた場面がありました。

日々、組織、チーム、人々と関わらせてもらい、そこでの出来事に向き合う中で、新しい理論や考え方、プラクティスと出会ったり、その出会ったものやもともと手にあったものをより効果的にうまく使えるように手に馴染むようにする。このようなことはやっていたつもりです。
そして、ありがたいことにクライアントからも一定の評価はいただいているようです。

一方で、「こういう明確な変化があった」とハッキリと言えない自分の存在に気づきました。
うまく言えないのですが、ロールプレイングゲーム(RPG)でいうと、今使っている武器の熟練度は上がっている気はしているけど、これまで使っていなかった武器やあまり取り組んでいなかった魔法については手には入っていない感じです。

このこと自体がダメとかそういうわけではなく、この1年の変化に対し、自分がどのような感覚を持っているのかがわかったというところです。

変化を意識できているか?

変化することそのものや変化したことについてさらに話していくうちに、”意識せず起きた変化”と”意識して起きた変化”の大きく2つがあるよねという話になりました。

それぞれの名前の通りですが、”意識せず起きた変化”は、自分では意識していないふるまいや考えが知らず知らずのうちに変わっていったという現象です。

一方、”意識して起きた変化”は、自分である方向に変化することを意図し、その意思を持って活動した結果として起きた変化を指しています。

“意識して起きた変化”は継続的な内省などで気づくこともできます。一方、”意識せず起きた変化”は自分だけでは気づくことができないこともあります。
この日も市谷さんとの会話の中で、まさに”意識せず起きた変化”について伝えてもらい、それについてどんな意味が自分にはあるのか?などを深く考えるきっかけになりました。

このように”意識せず起きた変化”を発見するための仕組みや環境づくり(その1つが定期的な雑談です。雑談のススメ)は大切と感じてました。

変化はすぐには訪れない

変化はすぐに訪れるわけではありません。
なにか新しいスキルを身につけて使えるようになるにはそれなりの期間、時間が必要になります。新しい考え方や振る舞いというもう少し内面に関わるようなことであれば、その期間はもっと長くなることもあります。

そして、その変化は緩やかなものです。時には停滞することもあるでしょうし、時には後退することもあるかもしれません。
それにRPGでレベルアップした時のように派手なファンファーレで教えてくれるわけでもないですし、レベルアップした瞬間から突然何かがうまくできるようになるというハッキリとした変化が見えるわけでもありません。

それでも”1年”という期間で見てみると、そこで取り組んできたこと、意識してきたこと、積み重ねてきたことによる変化はあります。きっと、1年前の感覚、場所とは違う感覚、場所にいることがわかると思います。

なにが言いたかったかと言うと。
日々の変化は小さすぎて見えないかもしれないけど、その期間を長くすれば見えてくるものもある。なので、少しやってすぐに捨てたり諦めるのではなく、やり続けることで起きる変化もあるよ」ということです。
※似たようなことを市谷さんも 1年かけて「成果がない組織」なんてないんだ。で書いています。

ちなみに日々の変化は小さいからと言って、日々の検査がいらないというわけではありません。
例えば、デイリーミーティング(Scrumならデイリースクラム)や毎週のふりかえりなどがその検査にあたりますが、その期間で発見できる変化ももちろん多くあります。

おわりに

今回は”変化”について書いてみました。

2023年12月には「自分はこんな変化をしたよ」と明確に言えるように、また活動していきます。
みなさんにとっても「自分がどんな変化をしたか?」を言葉にするヒントになれば幸いです。

Photo by Brett Jordan on Unsplash

スクラムマスター自身で自分自身を検査する1つのアプローチ

これはなに?

こちらはレッドジャーニーアドベントカレンダー11日目の記事です。
前日は市谷さん(@papanda)の組織の「左手」は、自分たちの「右手」のことを知らないでした。

このエントリでは「スクラムマスター自身で自分自身を検査する1つのアプローチ」について書いてみます。
合わせて同僚の森實さん(@samuraiRed)が書いている100日後に死ぬスクラムマスターを読んでみると理解が広がるかもしれません。

「自分自身がスクラムマスターとしてうまくやれているかわからない」という声

スクラムマスターとして活動してしばらくした後のスクラムマスターがこのような悩みを持ったりすることは割とあるようです。
支援先のスクラムマスターたちとの会話でもよく耳にしますし、(もうずいぶん前ですが)自分自身がスクラムマスターとして活動し始めた頃にも持った悩みだったようにも思います。

この状況に対する1つのアプローチとして「スクラムマスター自身で自分自身を検査する」というのがあると考えています。
その検査するための物さし、基準にはどのようなものがあるでしょうか?
多くの先達が書き記した書籍やインターネット上にあるスライド、ブログなども参考の1つにできると思います(もちろんコンテキスト依存だったりするのでそのままの適応はできないかもしれませんが)。
こういう、困った時に”原点に戻る”ことは比較的、筋の良いアプローチです。というわけで、ScrumGuideにはどのように書いているか見てみましょう。

スクラムマスターは、さまざまな形でスクラムチームを支援する。

  • 自己管理型で機能横断型のチームメンバーをコーチする。
  • スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する。
  • スクラムチームの進捗を妨げる障害物を排除するように働きかける。
  • すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする。

スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。

  • 効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援する。
  • 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
  • 複雑な環境での経験的なプロダクト計画の策定を支援する。
  • 必要に応じてステークホルダーとのコラボレーションを促進する。

スクラムマスターは、さまざまな形で組織を支援する。

  • 組織へのスクラムの導入を指導・トレーニング・コーチする。
  • 組織においてスクラムの実施方法を計画・助言する。
  • 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。
  • ステークホルダーとスクラムチームの間の障壁を取り除く。

このように、支援の対象はスクラムチーム、プロダクトオーナー、組織の3つあり、それそれ4つの活動・行動があげられています。
この活動1つ1つを物さしとして、スクラムマスターとしての自身の活動を照らし合わせてみることで、検査が進むのではないかと思います。

もちろん、活動だけが大事ではなく、その活動の先にある周囲にもたらすもの(価値)も大事です。
ですが、まずスクラムマスターに取り組み始めてしばらくの間は活動の検査にフォーカスしてみるのもいいかもしれません。

スクラムマスターたちと実際にやってみて得られた3つのきっかけ

以下は、支援先のスクラムマスター(1〜3人)とアジャイルコーチとで実際に何度かやってみて、主に得られた3つのきっかけです。

具体的な活動を整理するきっかけになった

自己管理型で機能横断型のチームメンバーをコーチする。

「この活動に対して自分はどのようなことをやっているか?」という問いかけが起きました。
あるスクラムマスターは、メンバーとの1on1の中で、自己管理型が進んでいる状態を話し合ったり、その状態において自分たちは今、どこにいそうかといったことを話していました。
また別のスクラムマスターは、スキルマップを作り、その変化を検査することで、機能横断型のチームに近づいているかを意識していると話していました。

このように自分たちの具体的な活動がどんなものかを整理するきっかけになりました。

活動がもたらした変化や価値を考えるきっかけになった

必要に応じてステークホルダーとのコラボレーションを促進する。

「これに関する活動をやってみたことで、どんな変化が起きたんやろうね?」と話し合いました。
社内のステークホルダーと期待のすり合わせができて、協力を得やすくなったり、「あいつら大丈夫かな」となんとなく懐疑的に思われていた様子が変わっていったという話もありました。
社外のステークホルダーの1つである実際の利用者への理解の度合いが変わり、「これって刺さらさそうだから下にしよう」「ムダなものを作らないようにしよう」といったようにプロダクトバックログが変わることもありました。

Scrumを深く理解するきっかけになった

すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする。

「”開催し”ではなく、”開催され”になっている。この違いはなんだろうか?」という話題が出た場もありました。
ちなみに原文(英語)だと”Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.”とあります。

(1つの解釈ですが)スクラムイベントはスクラムマスターが開催するものでなく、スクラムチームが開催するものであり、スクラムマスターはその場がポジティブで生産的になるように関わることが期待されています。その点から「開催され」といいう表現になっているのではないかという解釈を自分たちで見つけたりしました。

この3つ目のきっかけは1人でなんとなくScrumGuideを読んでいるとなかなか行き着くことの難しいものだったようです。

補足1:チームでこのようなことを話してみる

今回は主にスクラムマスターとアジャイルコーチでこのような場を作り、会話をした話を書きました。ですが、このような会話をスクラムチームの中でやっている現場もあります。

例えば、スクラムチームへの4つの支援を、チームはどのように見えているのか?どれくらい気づいているのか?どんな風に感じているのか?などを話し合ってみることで、スクラムマスターが自分自身のふるまいを変える参考になります。また、チームも今はスクラムマスターがやっているこれらの活動をどのようにチームに取り込んでいくのか?というきっかけにもなります。

補足2:人事評価のためのチェックリストに使わない

注意点として、これらの物さしを人事評価のためのチェックリストに使わない方が良いです。冒頭に書きましたが、これはあくまでスクラムマスターが自分自身で、よりチームにとって効果的な活動をし、価値をもたらすことを検査することを目的としたものです。

おわりに

Scrumに取り組む現場が増えてきていますが、まだまだスクラムマスターの活動やその価値といったものを(スクラムマスター自身も含めて)理解し、効果的な活用ができている組織、現場はそこまで多くないと私の観測範囲では感じています。
そのような状況が少しでも前進する1つの参考になれば幸いです。

Photo by Hudson Hintze on Unsplash

Regional Scrum Gathering Tokyo2022 に参加してきました #RSGT2022

Regional Scrum Gathering Tokyo2022(#RSGT2022)に参加してきました。
前回と同じくハイブリッド開催でしたが、(特に1日目は)現地に多くの人が参加してて、ちゃんとマスクなどしつつ、ホワイエや廊下など様々な場所で面白そうな会話が繰り広げられたり、笑顔も見えたり、とても雰囲気がよくて「あぁ、RSGTってやっぱりこれやなぁ」と強く思いました。

まず、実行委員、ボランティアスタッフのみなさんありがとうございました。

発表:【「いい感じのチーム」へのジャーニー】

2017年から6年続けてお話させてもらっていますが、もしかしたら今回が一番緊張したかもしれません。投票してくれたみなさん、ありがとうございました。
1日目の午後に話したのですが、リアルの場であれほど多くの人の前で話すのは約2年ぶりということもあり、どういう身振り手振りをしたらいいのか、どこに目線を持っていけばいいのかとかとかかなりドキドキしました。

それでも終わった後のDiscordでの反応やいくつか質問や感想を直接もらったのを見ていると、なにか役に立ったようで嬉しかったです。

今回、事前に、@kawaguti@bash0C7@spring_akiの3人にレビューしてもらって、多くのフィードバックをもらいました。最初は正直、ザラザラでゴツゴツした感じでしたが、3人のフィードバックを取り込み、だいぶ良くなりました。3人ともありがとうございました。

Coaches Clinic

こちらもいろいろな人が来てくれました。中には「去年もお話聞いてもらったし、この1年間取り組んだことを話したいです!」という人もいたりしましたし、こういう場に初めて来たけど、少し勇気を出して申し込んでみた人もいたりしました(みなさま、ありがとうございました)。

2022年の印象としては、これから初めてScrumに取り組みますというよりも”自分のこれまでの領域から出る”ところで立ち止まっている、困っている感じの話が多かったように思いました。
それだけScrumなどアジャイルなやり方はチームレベルでは広まってきていることかなと思いました(少なくとも参加者の所属企業では)。

ホワイエやDiscordでの雑談

自分の中で、1日目は「久しぶりですね!」感がだいぶ先行していましたが、2日目にはだいぶ感覚も以前のようになり、ホワイエや廊下などでいろいろな対話や議論などができました。
「セッションは動画で後で見よう!」と決めて、この雑談に振り切っていた感もありますが、それくらいここでの雑談は自分にとって知的好奇心が刺激されて得難いものです。

また、RSGTとしてのハイブリッド開催は2年目ということもあり、夜遅くまでDiscord上の様々なチャンネルでいろいろやり取りがされていました。

スポンサーブース

所属しているレッドジャーニーでGold Sponsorとしてほぼフルメンバーでブースを出したり、市谷さん(@papanda)がセッションをしたりしました。
多くの人が興味を持って足を止めてくれたり、旧知の人が来てくれた様子です。

次回のRSGT2023でも、こんな風にステキな経験ができる場だと感じるために、自分もまた発表できるような学びや出来事を手に入れたいですし、自分の貢献できることをやっていこうと気持ちを新たにできたRSGT2022でした。

「あらゆるものは変わり続ける」ことに向き合うのがAgile

朝(というか3時半)に散歩しながら思ったことを雑に書く

Agileの考え方の特徴の1つに「あらゆるものは変わり続ける」というのがあると感じる。「”変わらないものはない”ということだけは変わらない」みたいな(もちろんその”変わる”頻度、度合い、間隔は様々)。

んで、人は本能的に、変わりたくない生き物っぽく、不安定を嫌い、安定していたい。
それに対して「あらゆるものは変わり続ける」ということを前提に置くのがAgileの特徴の1つ。

それって、大げさに言うと「人の本能に抗おう」としているようにも思える(そんな要素はないけど、そんな構図になってそう)。
だからこそ、もう1つの人の本能的なものである”楽しさ”や”自分事”みたいな個人のモチベーションに関係ある要素もAgileの特徴にあるんじゃないかなと思う。
不安(不快なレベルな時もあるだろう)に感じることが多い”変わり続ける”ことに向き合っていく時に、楽しく感じられないと続けられないことが多いんじゃないかなと。

もしかしたら自分自身も「楽しい」と思い込むことで、この変わり続けることに向き合えているのかもしれないなぁと感じた。

Regional Scrum Gathering Tokyo2021 に参加してきました #RSGT2021

もう4週間前になりますが、Regional Scrum Gathering Tokyo2021(#RSGT2021)に参加してきました
今回はハイブリッド開催でしたが、これまでとは違う楽しみ方を見つけることができました
この状況で、開催してくれた実行委員会のみなさん、スタッフのみなさんありがとうございました

こういう話をしてきました

組織がアジャイルになっていく道を歩んだ時、「少しだけうまくやれたこと」と「うまくやれなかったこと」“というお話させてもらいました
とてもとてもありがたいことに5年連続でRSGTでお話する機会をもらっています(投票してくれているみなさん、ありがとうございます)
今回は”組織”にフォーカスした自分の経験をお話しました

1つのチームにとどまらず、組織をよりいい感じにしようと活動する、している人にとって何か役立てば良いなと思っています

ハイブリッド開催だったRSGT2021での過ごし方

私は1,2日目は東京に行き現地で参加、3日目は朝一に大阪に帰り、自宅からオンラインという参加のスタイルにしました

現地では(それほど多くなかったものの)久しぶりな方々と話をすることができました
それにいろいろな人がアイデアを出して、実験をしていく中で、オンラインとオフラインが溶け合っていくような感じ(Discordに「廊下」というチャンネルができたり、会場の廊下の様子をオンラインに流したり)がしていました
また夜遅くまでDiscordのいろいろなチャンネルで会話が発生していて、これまでRSGTが終わった後にあった”中華”と似たような雰囲気を感じることもできました

RSGTが終わった後の過ごし方

ハイブリッドだったこともありセッションの録画を観ることができます
しかも、RSGTのチケットを持っている人と一緒であれば、他の人たちも見ることができます

関わっているある現場では、一緒にセッションを見て「自分たちの現場でどう活かせるか?」といった話をしています
また別の現場では「ウォッチパーティー」と呼び、ほぼ毎日のように視聴会が開かれています
このウォッチパーティーでは感想などを共同ドキュメントに書き込んでいくスタイルを取っているのですが、これがまた見終わった後の感想戦をとても豊かにすることに効果的なようです

クライアントの経営者が参加してくれたこと

前回のRSGTに参加したクライアントのチームから、今回さらに多くの人が参加しました
それと同時にその組織の経営者が現地で参加してくれたことがとても嬉しかったです

「よく紹介してくれる本や自分の会社で見るチームの様子とはまた違った角度のいろいろな現場の話や熱気、大切にしている価値観のようなものを感じることが出来てよかった」という感想をもらいました

次回のRSGT2022がどのような場になるかわからないですが、同じでも違っていてもここに集う人達とならいろいろ実験をして、学び、楽しむことができそうと思えるRSGT2021でした

Regional Scrum Gathering Tokyo2020 に参加してきました #RSGT2020

Regional Scrum Gathering Tokyo 2020(以下 RSGT2020)に参加してきました。
※スライドなどはRegional Scrum Gathering Tokyo 2020のスライドまとめ #RSGT2020 - スクラムマスダーの日記にまとまっています。

4年連続で参加していますが、毎回ものすごい熱量があり、新たな発見や学びを得られる場です。
そして次回のこの場に「自分のやったことや変わったことを持ってこれるようにする」ことが自分のモチベーションの源泉の1つでもあります。

実行委員会やボランティアスタッフのみなさん、ありがとうございました(もちろん話し手や参加者一人ひとりの貢献もあってこそですが)。

トピック

  • 発表した
  • Coach’s Clinic をやった
  • クライアントを呼んだ
  • その他いろいろ
  • RSGTのようなエキサイティングで熱い場が各地である

発表した

「みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか?」という内容で発表しました。

いくつかトピックは削ったのですが、それでも持ち時間20分に対し52枚(前夜は64枚ほど)ありました。
早口だったり、多少説明不足だったりした点もあったと思いますが、Twitterや会場でもらったフィードバックは概ね好評だったようです。
※いただいたフィードバックや質問は前述した削ったトピックだったりしたので、またどこかでお話したり、ブログに書いてみようと思います。

印象的だったのは「Outcomeは大事とわかっていたけどやり方がわからなかった。でもダイヤの事例が具体的で参考になったので、自分達の現場でも早速試してみようという話になった」という声でした。
※ダイヤがどう生み出されたのかはギルドワークスの事例(企画と現場の距離が近づき、OutputよりもOutcomeを優先する意識が根づいた)に詳しく書いています。

余談ですが、このチーム、現場はまだまだこれから変わっていくと思うので興味がある方は訪問したりコンタクトを取ってみると良いと思います。

Coach’s Clinicに参加した

Coach’s Clinic にコーチとして参加しました。
フィードバックを見ると何かのヒントになった方が多かったようでホッとしています。

相手の状況を聴いて対話していくという点では日々やっていることの一面と似ています。
が、相手のコンテキストの理解から深堀り、(必要があれば)何か伝えるという一連を15分〜30分の時間で行うのは集中力が必要でした(例年思うことですが)。

その他いろいろ

クライアントに参加してもらった

ギルドワークスのスポンサーチケットを興味を持っていたクライアントに渡したところ若手が参加していました。
これからいろいろ新しいことに取り組んでいこうとしている中で、これまでのやり方や価値観を持っている人達や流れの中でいろいろ試行錯誤している様子でしたが、ネットワーキングパーティなどで似たような場でも先に進んでいる仲間と出会えたようでした。

3日目のスポンサートークをやった

1,2日目のゴールドスポンサートークを聞いた方はわかると思いますが「あれはずるいなぁ」と思いながらやりました。
「関西人が全員おもろいわけじゃない」という話をしつつ、真面目な話として「こういう熱量が高い場に参加した翌日の現場との温度感の違い」の話をしました。
※この話も別のブログに書いてみようと思います。

(小さなことだけど)英語を少しだけ使った

前夜祭で Cope さんに少しだけ英語で挨拶とちょっとした会話ができたのは、小さい一歩だけど自分にとって嬉しい出来事でした。

RSGTのようなエキサイティングで熱い場が各地である

同じような場が札幌(Scrum Fest Sapporo)では4月に、大阪(Scrum Fest Osaka)では6月に開催される予定です。

そこに集まった人達によってRSGT2020に勝るとも劣らない場(勝ち負けじゃないですが)になるんじゃないかと思っています。
※宣伝:Scrum Fest Sapporo には「これまでと違うやり方に取り組む時にうまくいくかもしれない方法とその落とし穴」というプロポーザルを出したので、面白そうだなと思った方はLikeしてください。

3日間のRSGTが終わった後の楽しみ方

これは、Regional Scrum Gathering Tokyo Advent Calendar 2019の13日目の記事です。
これまでの記事はどれもRSGTにゆかりのある話だったり、ためになる話だったりで楽めてます。そして、きっとこの後も興味深い記事が続くと思います。

私は自分なりの3日間のRSGTが終わった後の楽しみ方を書いてみようと思います。
2018年のアドベントカレンダーでは自分なりのRSGTの楽しみ方を書いていたのですが、今回は終わった後の楽しみ方です。

要約

  • 3日間のRSGTが終わった後の楽しみ方の話
  • 同じ現場から参加した人達での感想戦、参加報告の場などで自分達のとのDiffを見つけるのも1つ
  • 参加していなくてもスライドや参加ブログをみんなで読んでみるのもDiffを見つけることができる

ギルドワークスで現場コーチとしていろいろな現場の変化、改善を支援しています。
私は1日目に「みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか?」というタイトルでお話します。
3日間とも会場をうろちょろしているので見かけたら気軽に声をかけてもらえると喜びます。

同僚と一緒に参加して感想戦をする

同じ組織やチームの人と一緒に参加して、セッションやホワイエ、懇親会などでいろいろ話したことなどを自分達の現場やチームでどう活かすことができるだろうか?と感想戦をします。

残念ながらこの記事を書いている時点では今回のチケットは売り切れているようですが、RSGT2020に限らずこのようなカンファレンスや勉強会では1人ではなく同じチームの同僚と参加することをオススメしています。
RSGTの特徴の1つに、講演を一方的に聴くだけでなく、参加者同士で話し合う機会があり、そういう場の雰囲気になっていることがあります。そういう場の雰囲気はその場にいるからこそ体験できることです。
そういう点で1人よりも2人以上で参加することで同じ体験をした人同士で感想を話し合うことが、インプットに対しいろいろな解釈をすることもできたりします。

スライドやブログを元に話し合う

これまでのRSGTでもセッションのスライドやブログが多く公開されていました。誰も参加できなかった場合でも、このようなスライドやブログをチームで読んでみて話し合うこともやってみてもいいと思います。

支援している現場ではハンガーフライト(※1)という名前で週に30分〜1時間程度、お互いの体験やチームに起きたこと、また人の意見を聴きたいようなことを話し合う場を持つことがあります。
※1コミュニティや職場で、ハンガーフライトしよう。 - The Dragon Scroll

このハンガーフライトの中で、RSGTのスライドなどをみんなで話し合ってみて、自分達の現場をより良くしていく活動のヒントを見つけることもできるかもしれません。
もちろんスライドだけではわからないことやその場における話と合わせてでないとわからないこともあるとは思います。
それでもスライドをチームで見て話し合うということを外部からの刺激として、自分達の現場のDiffを取ったり、自分達のことをふりかえるきっかけにできます。

番外編:再演をお願いする

どうしてもこのセッションの内容を現場やチームのみんなにも聞いて欲しい場合、社内勉強会で再演をお願いするのもいいかもしれません。
再演する話し手の状況やモチベーション次第ですが、快諾してもらえることもあります。

もし社内勉強会で再演することになった場合、再演して終わりではなく、より深い質問や議論ができるような時間を作ったり、話し手にとっても何か新しい知識や発見があるような場にできるとなお良いかなと思います。

3日間のRSGTではいろいろな話を聴いたり、人と話すことで得るものも多くあります。
そこで得たことを、自分の現場に持ち帰って、現場やチームで話すことで現場の前進に役立つこともあるでしょうし、それを聞いた誰かがアジャイルやScrumの理解を深め、興味を持ち、次回のRSGTに参加したり、アジャイルなコミュニティに参加するようになるかもしれません。

unsplash-logoAustin Distel

「アジャイルコーチが見てきた組織の壁とその越え方」という話をします

この記事はギルドワークスのアドベントカレンダーの3日目です。

要約

  • 変化していこうとするといろいろな壁と出会う
  • これまでコーチとしていろいろな壁に出会ってきた
  • July Tech Festa 2019で「アジャイルコーチが見てきた、組織の壁とその越え方」という新たな壁の話をする

アジャイルに立ち向かった時のいろいろな壁の話

これまで現場コーチとして、いろいろな組織、チームがアジャイルになっていくための活動を支援してきました。
具体的な活動としてはScrumチームの立ち上げを支援したり、これからのマネジメントのあり方を考えたり、ビジネス側と開発側にある”側”という言葉や考えを取り除きOneTeamになることを背中を押したりしてきました。

もちろん現場ごとに違いますが、そういう取り組みをした時によく出会う壁があることに気づきました。
このエントリでは、これまで出会ってきた壁について書いてみます。

アジャイルな現場になっていく時の越えなければいけない3つの壁

AgileJapan2015 でお話したのは導入の壁定着の壁拡大の壁組織の壁についてでした。
(「〜3つの壁」というタイトルでしたが、結局は4つになりました)

導入の壁は「アジャイルに取り組む時に当事者たちに理由がないとうまくいかない」というものです。
定着の壁は「正解をあるという前提でそれを見つけることの固執してしまう」というものです。
拡大の壁は「広げて行く時に活動やプラクティスの理由が伝わらず表面的になる」というものです。
最後の組織の壁は「アジャイルをなること自体が目的になってしまって、本来の目的が忘れ去られてしまい頓挫してしまう」というものです。

アジャイルカルチャーが組織に根付くまでの挑戦

Regional SCRUM GATHERING Tokyo 2017でお話したのは変化することへの壁やり方の壁役割の壁についてでした。
※参考:【資料公開】アジャイルカルチャーが組織に根付くまでの挑戦 – サウスポーなエンジニアの独り言

以下のブログに詳しく内容を書いていただいています。
[RSGT2017 レポート] アジャイルカルチャーが組織に根付くまでの挑戦 | Developers.IO

アジャイルコーチが見てきた、組織の壁とその越え方

そして今度の日曜日、July Tech Festa 2019でまた壁についてお話します。

セッション概要は

これまでの考え方ややり方を変えようとする時、最初は小さく上手に始められたとしても、しばらくすると文化に根ざす壁にぶつかることが多くあります。トップダウンでもボトムアップでも同じです。その壁にどう立ち向かうか?により組織の文化の方向がつけられます。
このセッションでは、現場コーチ(アジャイルコーチ)として様々な現場の変化を、組織の中からではなく一歩外から関わってきた経験からその壁の越え方をお話します。

今回はチームの中の壁チーム間の壁現場とマネージャー・経営の壁といった3つの壁について、どういう時にその壁が発生するのか、その壁はどういう問題を引き起こすのか、その壁を向き合って壊すためにはどうすればいいのかといったお話をするつもりです。

最大6トラックのセッションがあり、いろいろな人がお話するようですので、興味がある方はこちらからお申し込みください。

ギルドワークスに興味がある方はお気軽にお声がけください

ギルドワークスと一緒にプロダクトづくりをやってみたいと思った方、また、自社のプロダクトづくりや現場のチームのことで相談したい方はお問い合わせフォームやギルドワークスや各社員のSNSなどからお気軽にお声がけください。

Regional Scrum Gathering Tokyo2019の感想(1日目) #RSGT2019

Regional Scrum Gathering Tokyo

Regional Scrum Gathering Tokyo(以下 RSGT2019)に参加しています(このブログは3日間あるギャザリングの2日目の朝に書いています)。

参加はRSGT2017RSGT2018に続き、3回目です。

1日目の感想

セッション

Gabrielle Benefieldさんの基調講演「Outcome Delivery: delivering what matters」でのメビウスループの話は「やっぱりそうだよね」と強く思いました。
自分達ギルドワークスの「正しいものを正しくつくる」の実現するための1つの手段である仮説検証型アジャイル開発とも通じるものを感じました。

他にも支援しているエウレカさんのカンバンの話やDevLOVE関西などでもよく話してくれる椎葉さんの話など現場で実践した話をいろいろ聴けました。

Coaches’ Clinic やっていました。

セッションの合間にコーチに1on1で相談できるというコーナーがあり、そこに少しお手伝いしていました。
それぞれの現場の課題やいろいろ考えていることにふれる機会も貴重でした。

2日目は「ファシリテーションの難しさと楽しさ」というタイトルで話します。

先に公開しているスライドです。

2日目の最後のあたりの時間帯でアジャイルやスクラムの話はみんなお腹いっぱいになっていると思い、そのあたりの話はほぼなく”ファシリテーション”にフォーカスしています。

Scrum Festa Osakaやります

2019年2月22日(金)・23(土)にScrum Festa Osakaというイベントを開催します。
(あまり貢献はできていませんが、実行委員会に名を連ねさせてもらっています)

Scrum Fest Osakaはスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。この2日間を通じ、参加社同士でスクラムやアジャイルプラクティスについての知識やパッションをシェアするだけでなく、ここで出会ったエキスパートに困りごとを相談することもできます。

Scrum Festa Osaka が立ち上がるまで

思い返せばRegional Scrum Gathering Tokyo(RSGT)2018の前夜祭で「関西でもやろうよ」と声があがり、その場でSlackが作られたのがきっかけでした。
それからほぼ1年以上経ち、次のRSGT2019の開催より遅くなりましたが、開催することができそうです。

ここに至るまで本当に多くの方々の協力なしにはできなかったと思います(まだ終わっていませんが)。
実行委員会設立においてはスクラム道関西運営メンバー、またスクラムギャザリング東京実行委員会、中でも川口さんには何度もMTGにも参加いただいたり、これまでRSGTを運営してきた知見などを含め、貴重なアドバイスをいただきました(ありがとうございます)。

また素敵なロゴもJUNBOwさんに作っていただきました。

Scrum Festa Osakaの特徴

タイムテーブルにあるように2日間、2トラックの構成です。

これらのセッションは応募のあった78個ものプロポーザルからそしてみなさんの投票などで決まりました。
第1回目にもかかわらず、こんなにも多くのプロポーザル、ありがとうございました。
残念ならが採用できなかったプロポーザルも魅力的なものが多いので、ぜひ、社内外での勉強会などの場で発表できるといいなと思っています。

セッションは、平鍋さんなどアジャイルの黎明期から活動されてきた方から、今まさに現場でScrumを導入しようとしている方まで、まさに初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が話します。
おそらくどのセッションもその人が経験し、血肉となっていることを話してくれると思います。

1日目の終わりにはネットワーキングパーティーの場があります。
1日目のインプットを踏まえて、その夜に参加者同士で意見を交わし、2日目に新たなインプットをすることで、より深い理解や考えができるのでは?と考えています。

参加するにはどうしたらいいのか?

2月1日から発売予定のStandardチケットをこちらでお買い求めいただければと思います。
(なんとタイミングの悪い日に公開したエントリでしょう)

自分なりのRSGTの楽しみ方

これは、Regional Scrum Gathering Tokyo Advent Calendar 2018の19日目の記事です。
このエントリでは自分なりのRSGTの楽しみ方を書いていきます。

ギルドワークスで現場コーチとしていろいろな現場の変化、改善を支援している中村 洋です。
前日は鈴木啓太さんのAgile Development Center の取り組み 〜アジリティ高くサービスをデリバリするために〜というお話でした。

私は2日目に「ファシリテーションの難しさと楽しさ」というタイトルでお話します。
また3日とも会場をうろちょろしていると思いますので見かけたら気軽に声をかけてもらえると喜びます。

自分なりの楽しみ方

裏セッションの同士での再演セッション

2年前の牛尾さんとRochelle Koppさん、1年前の絹川さんと自分の裏セッションのいずれも「どうしても聞きたい!」と思うものでした。

そのどうしても聞きたい!という想いが高じて、声をかけてセッションをほぼ再演してもらうということをしました。
2年前のRochelle Koppさんには1日目のネットワーキングパーティの隅でお互いのセッションでどんなことを話すのか?それぞれどう思うのか?といったディスカッションをしました。
1年前の絹川さんもお互い話し終わった後にホールで同じ様なディスカッションになりました。
いずれも丁寧に話ができ、かつ、深い会話ができて有意義な時間でした。

Coaches’ Clinic での学び

(今回もあるとは思いますが)アジャイルコーチに相談できるCoaches’ Clinicというコーナーがあります。様々な経験を持ったアジャイルコーチが1on1形式で相談者の困り事の相談に乗り、時にはアドバイスをするという場です。
セッションでインプットをした後は、ぜひアウトプットの1つとしてCoaches’ Clinicを使って、現場の相談をしてみるのはいかがでしょう?

もちろんCoaches’ Clinic以外でも、セッションの合間や時にはセッション中にホールでは、休憩中の参加者やアジャイルコーチ達がいろいろ立ち話をしています。こういう立ち話に耳を傾けたり、輪の中に入り、自分の考えを話してみるというのもいい経験になります。

いろいろな人を引き合わせる面白さ

一緒に現場コーチの支援先のスクラムマスターなども参加しています。そんな彼ら彼女たちに他の現場で活動しているスクラムマスターやアジャイルコーチを紹介するのも、また違う化学反応のきっかけになることがあるので、面白さがあります。

そこでの出会いをきっかけに刺激を受け、自分の現場に何か持ち帰ってもらえるといいなと思っています。

まとめ

RSGTは、公式サイトにもあるように「学びの場」です。
もちろん様々なセッションも学びになりますが、それ以外にも場の至る場所に学びの機会は散りばめられています。
そんなRSGT2019を私も心待ちにしています。

明日はKenta Sasa さんのお話です。

unsplash-logoSimon Maage

Regional Scrum Gathering Tokyo2018に参加してきた #RSGT2018

2回目のRegional Scrum Gathering Tokyo

前回に引き続き、Regional Scrum Gathering Tokyoに参加して、【「ふりかえり」の始め方と続け方】というお話をしました。

前のセッションと休憩なしで連続、かつ、20分という短い時間だったのでHowのテクニック的な面の話が多くなりましたが、”ふりかえり”など、自分達のやり方をよくする余地はいろいろあります。

そういうことを考えるきっかけに少しでもなれば幸いです。

印象に残ったことなど

  • 1、2日目の基調講演、両方とも心に沁み込んできた。Richard Sheridanからは「(本にも書いているけど)実験することの大切さ」を、2日目の河野さんからは「自分で作ったものが世界を変えていく楽しさ」をそれぞれ受け取った
  • デブサミやらで色々お世話になっている岩切さんから「久しぶりに会ったけどすごく表情がよくなっているね」と言われたこと(3日目の岩切さんの話は残念ながら聞けなかったので、そのうちご飯でも食べながら聞かせて欲しい)
  • ネットワーキングで、現場支援先のスクラムマスター数人にちょっとネジが跳んでいる(※褒め言葉)人達を引き合わせることができた
  • 前回に続いて「Coach’s clinic」(コーチに相談する場)に相談される側で参加したこと。自分のやっていることが少しでも役に立ったのであれば幸い
  • 相変わらず運営がスムーズ、かつ、ホスピタリティ溢れるものだったこと。実行委員会、スタッフのみなさん、ありがとうございました

最後に

Regional Scrum Gathering Tokyo 2019もスピーカーで参加したいなと強く思いました。

どんなニーズがあるかわからないけど、東京だけでなく関西とかでもこういう場を作っていきたいなと思いました(DevLOVE関西はそういう場の1つだと思うけど少し違う感じで)。

RSGT2018のプロポーザルを出した #RSGT2018

Regional Scrum Gathering Tokyo 2018に2つのプロポーザルを出しました。

Regional Scrum Gathering Tokyoとは?

Regional Scrum Gathering Tokyoは、スクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。講演やワークショップ、そして参加者同士の交流を通じて、世界最前線の情報から日本の現場での工夫まで多くの知見を得られます。
(公式サイトより)

プロポーザルを読んで興味があれば、セッションに投票してもらえれば嬉しいです。
他にも興味深く、ワクワクするプロポーザルが並んでおり、それを眺めてみるだけでも、何かヒントを得られることもあるかもしれません。

前回RSGT2017に参加したのですが、色々な人の話を聴き、軽い感じから深い感じまで様々なディスカッションができるのがこのRSGTの良さの1つだと思っています。
しかも、これまで2日間でしたが、今回は3日間(3日目はOpen Space)ということもあり、前回以上に得られるものが多そうだと期待しています。

2人のアジャイルコーチが語る、とある現場支援の回想録

ヌーラボでアジャイルコーチをやっている@ikikkoと2人で話します。

このセッションでは、ある現場の社内アジャイルコーチと、その現場を外部から支援するアジャイルコーチ、2人のアジャイルコーチの視点でお話します。

社外のアジャイルコーチに支援してもらうとき、支援した方・された方、片方の視点からの事例を聞くことはありますが、案外双方の立場からの意見を聞くことは多くありません。ですが、ある一場面をとっても、お互い見えているものや感じていることは違うはずです。

本セッションでは、社外のコーチにチームの支援を最初に相談した時・改善の踊り場に来た時といった各場面で、双方のアジャイルコーチは何を見てどんな行動を起こし、どういう結果となっていったかをお話します。

「ふりかえり」の始め方と続け方

このセッションでは、アジャイルコーチとして様々な現場のふりかえりを観察、ファシリテートしてきた経験から得た“ふりかえり”の始め方と続け方をお話します。

”ふりかえり”の目的は大きくは以下の2つです。

自分達の仕事のやり方をもっとうまくできるようにすること
(うまくできるやり方を考えるために)仕事の手を止めて立ち止まること
この目的を実現するために様々なことにファシリテートするスクラムマスターは意識することがあります(できれば参加者全員が)。

どのようなデータを収集すればよいか?
どういう話し合いのやり方をすればよいか?
継続的にうまくできるように気をつけることは何か?
また以下のような”ふりかえり”あるあるに出会うこともあります。

ふりかえりといえばKPTとばかりに同じやり方をしてマンネリしてしまう
うまくできるようにするアイデアが実行されない
なんとなく続いているんだけど効果がわからない
このようなトピックをお話することで、みなさんのふりかえりをよくするヒントになればと思います。

以下の”ふりかえり”について話したような内容をUpdateしてお話できればと思います。

最後に:ギルドワークスはSilver Sponserです

仮説検証型アジャイル開発いきなり最強チームといったサービスで「正しいものを正しくつくる」を果たそうとするギルドワークスはRSGT2018のSilver Sponserとして協賛しています。

いろいろな現場の実践者の方々と出会え、話ができるのを今から待ち遠しく思っています。

Regional SCRUM GATHERING Tokyoに参加してきた #RSGT2017

初めてのRegional SCRUM GATHERING Tokyo

Regional SCRUM GATHERING Tokyoに初めて参加して、発表してきた。

余談。このスライドを作るために直近の3連休をほとんど使ったけど、そうさせてくれた家族に感謝。

印象に残ったことなど

  • 2日間(前日の準備なども入れると3日間)とも運営がスムーズ、かつ、ホスピタリティ溢れるものだったこと。実行委員会、スタッフのみなさん、ありがとうございました。

  • ロッシェル・カップと「明日、同じ時間に話すので、似たようなテーマで興味があるのにお話聞けないのは残念ですね」→「じゃ、先にお互いスライドを見せて意見交換しましょうよ」の流れで、1日目の夜に、お互いのスライドや話す内容の意見交換をして、フィードバックをもらったこと。だいぶ刺激になったし、、もっと話したいと思った。

  • このようなカンファレンスにほぼ初めての参加という、クライアントの若手(1人で来ていた)にスピーカーやスタッフなどを紹介したこと。

  • 「Coach’s clinic」(コーチに相談する場)に相談される側で参加したこと。自分のやっていることが少しでも役に立ったのであれば幸い。

  • 聴いたセッションはどれも面白かったけど、色々な人との議論が楽しかったし、考えの整理や新しいやり方、考えを得られた。

  • そしてこれ。

Regional SCRUM GATHERING Tokyo 2018もスピーカーで参加したい。

「アジャイルコーチの道具箱 – 見える化実例集」を読んだ

アジャイルコーチの道具箱 – 見える化実例集」を読みました。

ギルドワークスで現場コーチとして、様々な現場がアジャイルな開発をうまくやれるような支援、現場の改善や見える化をしている自分としてはとても興味をそそられるタイトルです。
また翻訳した方々も@haradakiro@ryuzeeなど期待せざるをえない人達ばかりで、すぐに読み始めました。

読んでいる途中「あの現場のあのチームはこれが良さそうかな」「あのチームが持っている課題はまずこれをやってみて、それからこっちをやってみてはどうだろう?」とアイデアが色々出てきてワクワクしてきました。

やるかどうかは現場のチームが決めればいいですが、「こういうアイデアがあるよ」「こういう感じで一度試してみてはどうかな?」とコーチとして色々なカードを見せたり、背中を押すことができそうです。

コーチだけでなく、チームが見える化を推進していくのも役立ちます。
「見える化する対象は分かったけど、どう見える化すればいいかわからない」という悩みはここにある様々な実例でほとんど解決できそうです。悩みにピッタリのそれがなくてもパラパラと見るだけで解決できそうなヒントは浮かんできます。
#もちろんどうやって運用するか?当たり前にするか?という次のステップはありますが、「やってみる」ことはできそうです。

以下は読みながら垂れ流したツイートです。

デブサミ2014でお話してきました!

もう2週間も前になるのですが、【Developers Summit 2014 (デブサミ2014)】に参加してお話してきました。

デブサミ2014、講演関連資料まとめとして資料などがまとめられています。

成功と失敗の狭間に横たわる2つのマネジメント

聴きに来てくださった皆様ありがとうございました!

登壇に至った理由は1つ前のエントリ(デブサミ2014で登壇します)に書いています。

1日前までスライドができあがらずけっこう悩んでいましたし、緊張もしていました。
壇上に上がる前は「整理した考えを”自分のため”に独り言のように話す」と開き直って言い聞かせたりもしました。

内容は目新しいことはなく、自分がこれまでやってきた中で「これは大事なんじゃないかな」と思うことについて、やってみてうまくいったり、失敗したこと経験談をお話しました。

他に参加したセッション

1日目は話す前に他の方のセッションを聴くと自分のスライドを手直ししたくなるので、コミュニティブースで色々な方とお話していました。

2日目は以下のセッションに参加しました。(リンク先はSlideShare)
【14-D-1】Team GeekによるFearless Change(角征典〔ワイクル〕)
【14-D-3】越境する開発~あの日開発していたサービスの名前を僕たちはまだ知らない~(市谷聡啓〔DevLOVE〕)
【14-B-5】ピンポンゲームでスクラム体験ワークショップ(川口恭伸〔楽天〕)

角さんのパターンの話は分かりやすかったですし、市谷さんの話をDevLOVE以外で聴くというのも新鮮でした。
ピンポンゲームも終わった後に川口さんと色々ディスカッションできたので「なるほど~」と思うことがありました。

デブサミは同窓会であり、良い刺激をもらう場

デブサミは自分にとって同窓会と改めて思いました。
DevLOVEのコミュニティブースで色々な「お久しぶり!」な人とお会いできたし、(一緒に仕事はしたことないけど)元同僚の@namikawaさんとランチしたり。

そしてそれぞれ場所は違えど色々挑戦していたりして、これも良い刺激になります。

写真

DevLOVEのコミュニティブース
DevLOVEのコミュニティブースです。
@teyamaguさんの設営力(?)に感謝です。

スピーカー控室への案内
スピーカー控室への案内板。

スピーカー控室
ここがスピーカー控室です。
リハーサルの関係で1番乗りだったので誰もいないのですが、日中はここでスピーカーの皆様があちこちで話をしていたり、スライドを手直ししていたりとワイワイガヤガヤと楽しい空間になっていました。

スピーカーパス
スピーカーパスです。これは次のデブサミでも身につけてみたいです。

会場
リハーサルの時に撮った会場です。実際は聞き手の席は暗くなっているので壇上からほとんどお顔は見えなかったのですが。

コーヒースポンサー
1万円でなれるコーヒースポンサーの頂き物です。
書籍も1冊いただけますし、セッションは並ばずに優先的に1番前の電源付きの席で聴くことができるしメリットが多いと思いました。

最後に

両日ともとても楽しく、あっという間の時間でした。

特に2日目は雪の中、時間短縮したり運営の難しい判断もあったと思いますが、それを感じさせることなく楽しませてくれた、翔泳社さんを初めとするスタッフの皆様のオペレーションに感謝です。ありがとうございました!

次のデブサミでも何かお話できるように頑張っていこうと改めて思いました。

「アジャイルの好きなところ」(Ultimate Agile Stories2)

そろそろUltimate Agile Storiesの季節です。
というわけで、Ultimate Agile Stories1に続き、Ultimate Agile Stories2で書いた内容をほぼ原文で公開します。

題名:アジャイルの好きなところ

2. はじめに
皆さんは「アジャイル」のどういうところが好きですか?

「そもそもアジャイルとは何か?」という議論も色々ありますが、ここでは「アジャイルソフトウェア開発宣言」を理解して実践しようとしていることとします。
私が「アジャイル」に感じた好きなところは以下のようなものです。
 
(a)顧客により価値の高いものを提供することができる
(b)自分達の成功体験を短いスパンで感じることができる
(c)携わったプロダクトやサービスに誇りを持つことができる
(d)またこのチームで仕事をしたいと思うことができる

以降、それぞれについて書いていきます。

3. 顧客により価値の高いものを提供することができる

アジャイルでは顧客に実際に動くものを見てもらい、フィードバックを得ます。
そのフィードバックを次のスプリントの開発に活かすことで、本当に顧客が欲しかったものを提供できる可能性が高くなります。

スクラムだと、各スプリントで行う「スプリントレビュー」でデモなどを行い顧客に確認してもらいます。
私が過去に経験していたやり方のいくつかでは、システムテストまで顧客が実物を見て触る機会がなかったこともありました。
実際に使うユーザにいたっては、リリースするまでその機会がなかったこともありました。

常にユーザに見てもらえる状態を維持するのは、それほど簡単なことではありませんが、それにチャレンジする価値はあります。

要件定義や基本設計の工程の成果物を変更したりできず、またより良い方法をマネージャなどに提案しても力ない笑みや苦笑と共に…「もう決まったことだから」「お客様はそれで良いと言ってるから」という返答を聞いたことありませんか?

社内定義のQCDは充足していたとしても、発注者だけでなく、実際に使うユーザも含んだ顧客の満足度をもっとトレースしたいと思っています。

プロジェクト終盤によく聞く「自分達が欲しかったのとは少し違うなぁ…」という声よりも、プロジェクトの途中に何度も「こういうことをしたかったんだよ。後、ここをこうすればもっと嬉しい」というユーザの声を聞きたくないですか?

4. 自分達の成功体験を短いスパンで感じることができる

「スプリント・レトロスペクティブ」(ふりかえり)が大事な理由の1つとして、チームの良い点をより強化して、改善し、顧客への価値の提供のスピード、質を上げるというのがあると思います。
そして、それと同じほど大事な理由に「自分達チームのことを知って、成功体験を得る」があると思います。

私が過去に経験していたやり方のいくつかでは、「ふりかえり」はプロジェクト終了時…それこそカットオーバー後…に行うことが多くありました。
いくつかは詳細設計などの工程の終わりで実施していたこともありました。
途中でプロジェクトから抜けたり、あまりに大きなプロジェクトの場合、ひょっとすると「ふりかえり」の場すら無いかもしれません。
いずれにせよ、そこで得た改善や成功体験を活かすまで、長いスパンが必要になります。
これでは何度もあるレベルアップのチャンスを逃しているようなものです。

特に経験が浅いエンジニアほど「自分達のチームがどの程度イケてるのか?」に敏感な傾向があり、「ふりかえり」によって成功体験を得ることで一段と伸びていきます。

またチームメンバー同士でフィードバックをし合うことで、個人の成功体験を得て、自信を持つことができ、レベルアップにつながります。
さらに相互理解も深まりチーム全体のレベルアップにもつながります。

「明日からこのふりかえりで出た〇〇をやってみます」とメンバーが宣言しているのを聞きたくありませんか?

5. 携わったプロダクトやサービスに誇りを持つことができる

ある尊敬できるエンジニアが「コードのAuthorに自分の名前を入れたくないようなコードを書くな」と言っていました。
これはプロダクトやサービスでも同じようなものだと思います。

自分達チームがリリースしたプロダクトやサービスを街中やインターネットで見かけた時に胸を張って「自分達が作ったもの」と言えますか?

前述した「顧客により価値の高いものを提供することができる」内容にも関係しますが、私が過去に経験していたやり方のいくつかでは、不本意なコード、ユーザインターフェース、機能群を持ったシステムを提供せざるを得ないことがありました。

アジャイルでは徐々に顧客と一緒にシステムを作り上げていくので、顧客はもちろん自分達チームにとっても「誇り」と思えるものになる可能性が高いと思います。

「このサービスは僕が作ったんだよ」と家族や友人に言いたくありませんか?

6. またこのチームで仕事をしたいと思うことができる

私自身はアジャイルで一番好きなのはこれです。
これは「アジャイルな開発をしたから思った」「アジャイルな開発でないから思わなかった」わけではありませんが、感覚としてアジャイルなチームで開発をすれば、ほぼ間違いなくこの感情を持ちました。

私が過去に経験していたやり方のいくつかは「二度と〇〇の顔を見たくない」ということも残念ながらありました。
でも顧客から「これが欲しかったんだ」という声をもらい、成功体験を積み重ねて、プロダクトに誇りを持っているチームだとそうはならないと思います。

「またこのチームで仕事したい」という言葉を聞きたくありませんか?

7. 最後に

私は「これまで書いたようなことをできる/したいからアジャイルをやろうとした」わけではありません。

当時は色々悩んでいました。もちろん今も悩んでいます。
「どうしたらお客様もハッピーになってチームも楽しく良い価値を提供できるんだろう?」を日々考えて、動いて、フィードバックを得て、改善してまた動いて…を繰返していく中でたどり着いた「こういう状態で働きたい」という形が自分なりのアジャイルなプラクティスや姿勢に近かったという感じだと思っています。

「アジャイルをやりたいんです」とたまにを聞きますが、その前に自分達とチームがしたいことが何なのか?を考えてみるってことも大事かと思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo by palooja on VisualHunt.com / CC BY

SCRUM BOOT CAMP THE BOOKを読みました

SCRUM BOOT CAMP THE BOOKはいい本です!マネージャーも開発者もみんな読んでみてください!」で終わらせようと思ったら・・・


・・・と言われたので、もう少し書いてみます。

さらに「なかなか書けないなぁ」とウダウダしているうちに長沢(@tomohn)さんにも先を越されてしまったりしました。

いや、でも本当にいい本なんですよ。
私の説明や感想なんかより「とりあえず(2時間もあれば読めるから)読んでみてよ!」です。

読書感想文ですが

Scrumを構成する事柄(原則やロール、イベント等々)について、「どういう背景で、なぜそれが必要なのか?そしてそれがなかったらどうなるのか?」とかなり深く書かれているように感じました。
正解がない中でボクくん達のチームが何を考え、決断して、振る舞えば、より良いゴールに辿り着けるのか(これもあくまで”可能性が高くなる”の話ですが)がテンポの良いマンガとして描かれています。

実際にScrumをやっていると、陥りやすかったり、悩みやすかったり、はまったりしやすい色々なポイントに対して「自分(著者達)ならこう考えて、こうするよ」と考えや豊富な経験を見事に文章に書かれている点も素晴らしいと思いました。
#章やコラムによっては3人それぞれの声が脳内再生されたりして、ニヤニヤしました。

マンガのように最初のScrumでこれほどうまく行くこと(それでも、ボクくん達チームはリリース間際は深夜残業な様子でしたが)は簡単ではないでしょうし、もしかするとプロダクトオーナー、チームメンバーが最初から前向きなのも、なかなか珍しいかもしれません。

繰り返しになりますが、そんなところも含めてScrumの嬉しいところも、難しい(そんな簡単に上手く行かないよ)ところが余すところなく書かれています。

Scrumを実践者はもちろん、「アジャイル、スクラムって聞いたことがあるんだけどなぁ」という方もぜひ読んで「こういう方法もあるんだ」と手持ちのカードを増やしてもらえたらと思いました。
#自分が読みながらつぶやいたまとめ

最後になりましたが、こんな素晴らしい本を届けてくださった著者のみなさん、ありがとうございました!

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

burn-down-chart

バーンダウンチャートの疑問を聞いてみた

先日社内勉強会で「バーンダウンチャート」について説明する機会がありました。

その際の資料として@ryuzeeさんの「[Agile]バーンダウンチャート虎の巻(資料公開)」を使わせてもらいました。
#@ryuzeeさん、ありがとうございました!

その資料で自分なりに疑問に思ったことを@ryuzeeさんとやり取りした内容を「誰かの役に立てば」と思いまとめておきます。

質問1:バーンダウンと自己組織化の関連

※スライド11枚目:「バーンダウンから分かること」
「チームが自己組織化されていて~」とは具体的にどのようなことでしょうか?バーンダウンの進み方と「自己組織化」の紐付けがイメージできませんでした。

質問1に対する@ryuzeeさんのお話

チームがスプリントを主体的に行なっているかどうかが分かります。
他人からの指示を欲してしまうチームは、一般的には問題が発生してもすぐ対応しないので、スコープ調整が行われず完了しないスプリントになったりスコープ調整が後半になったり、そもそも経験から学ばずに、毎回似たようなバーンダウンを描いたりします。

質問2:理想線の引き方について

スプリントの見積総時間とスプリント終了日を結んだ場合、チームの1日辺りの理想時間と乖離すること(※1)もあると思います。
この場合は「詰め込みすぎ」なので「スコープを見直す」アクションにつながると思っていますが、この理解にコメントあればお願いします。
(※1)3人チームで、1人の開発時間は6時間/日の場合、18時間/日のパワーです。一方、理想線の傾き(1日の時間)は24時間とした場合、毎日6時間のオーバータスクになってしまいます。

質問2に対する@ryuzeeさんのお話

その理解であってます。
ただし、チームにはキャパシティというのがあります。これはチームメンバーの稼働可能時間の合計値ですが、それは一般的には就業時間の6割程度です。

したがってスプリント計画第二部が終わって計画ができた時点で、まずチームの総キャパシティの中に合計タスク時間数が収まっているかは確認すべきポイントです。
既にこれを超えているようであればプロダクトオーナーと議論して順位の一番低いストーリーから順に外します。
またチームがタスク出しになれていない場合は、2割くらいの追加タスクが出るのが普通なので、これも見込んだほうがよいです。

結果として、理想線のスタート地点はキャパシティの下側になければいけません。

質問3:残時間の傾きが大きくなった場合の原因

※スライド21枚目:早期学習パターン
残時間が44→26のように(スコープの調整等がなく)ガクッと下がった場合、以下のことが考えられます。
A:チームがレベルアップして当初見積より早くそのタスクが終わった
B:チームが残業した

前者であれば良いのですが、後者であればそれは持続可能でないと思います。
そういう場合に「最終コミット時間」を別にプロットすることで「原因を明らかにする」のが良いと思っています。
この理解にコメントあればお願いします。

質問3に対する@ryuzeeさんのお話

本当は最終コミット時間プロットしなくたって振り返りで分かりますけどね。
本質的な原因を明らかにしなければいけないのはその通りです。
往々にして成果達成に対する強いプレッシャーがかかってたりします。

質問 4:複数スプリント間での比較

※スライド35枚目:複数スプリント間で分析する
スプリントで作る機能の難易度の違いを考慮する良いアイデアはあるでしょうか?
「ふりかえり」でチームでディスカッションして明らかにするのが1つの方法と思っています。

質問4に対する@ryuzeeさんのお話

難易度の違いはストーリーポイントと、ばらしたタスクに明確に現れるはずだと思います。
そのためにチームで見積るので。
それが着手してみて初めて難易度がわかるようであれば、そのバックログ項目はまだReadyではないです。

最後に

バーンダウンチャートを始めることは割と簡単にできます(おそらくガントチャートと並行してもできるはずです)。

実際にやってみるとガントチャートだけでは見えなかったチームやプロジェクトの色々なことが見えて来ます。
もし何も見えなかったらそれはそれで無茶苦茶素晴らしいチームか、何か隠しているかです。
それらの分かった情報をもとに改善のきっかけにしていくこともできると思うのでまずはやってみてはいかがでしょうか?

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。