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ではないです。

最後に

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

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

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

フリカエリ

[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。

今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカエリを行い、そこではKPT(Keep/Problem/Try)のフレームワークを使っています。

やり方はほぼプロジェクトファシリテーション実践編 ふりかえりガイド(※リンク先はPDF)の通りです。
以下は、今のチームでやっている工夫や気づいたことです。

W(分かったこと)を書き出す

KPTに似たようなフレームワークで「YWT」というものがあります。
Y(やったこと)・W(わかったこと)・T(次にやること)というもので、弊社ではひょっとするとKPTよりこっちに慣れている方が多いような気も・・・。

Keep・Problemといった事象やアクションから「感じた」何かがあると思います。
それを「W(分かったこと)」として書き出します。
分かっこと自体がTryなどの直接のアクションになることは少なくても、それをさらに深く考えることで別のTryに結びつくこともあります。

日常的に書き出す仕組み

youRoomをコミュニケーションツールとして使っています。
そこにイテレーション開始時に”あらかじめ”フリカエリ用のスレッドを立てておきます。そして、日常の開発などで「あっ!これはPかも」「次はこんなこと(T)したいなぁ」と思えば、すぐに書き込むようにしています。

イテレーション終了時のフリカエリより先にPの内容によってはすぐに対応できます。
早く対応した分だけ、チームのパフォーマンスが上がります。
なかなかチーム全員が開発に集中しているとPへの対応は後回しになりがちですが、そこはスクラムマスターがうまく動くことである程度はカバーできると思います。

Problemの深掘り

これは最近やり始めたことです。

Pに対してTを書き出しますが、中には「本当にそれでPは解決する?もう少し深く話した方がいいのでは?」というものもあります。
例えばPの原因が実は根深かったり、TがPの対処療法にしかなっていない等です。

このような場合、(KPTが一通り終わった後)新しいホワイトボードにPを中心としたマインドマップを使って深掘りします。
こうすることで「隠れていた本当のP」や「(Pに対する)より効果的なT」が見えてくることもあります。
(時間の関係で)全てのPを深堀りすることはできないことも多いので、チームが「これでできるのかな?」と半信半疑な雰囲気になっているPを取捨選択する必要があります。

ProblemのTry以外にも、チャレンジしたいTryを書く

(Pとは関係なくても)「こんなことにチャレンジしたい!」という意味のTも書き出すようにしています。
そしてそれがPJの方向性と合うのであれば、実際にその手を上げたメンバーを中心にして、次のイテレーションなどでやるようにします。

(サインアップのように)「自分がやりたい!」と手を挙げることで、その質やコミット感が強くなるのが良い点です。
Pに対するTは(改善ではあるものの)、(内容によっては)「できていないこと」にフォーカスが当たりがちです。
ですので、前向きにやる…とのが難しいこともあります。

それとバランスを取るように「チャレンジしたいT」を使ってみると良いと思います。

同じProblemが上がっていないかを見る

同じチームで何度かフリカエリをやっていると「あれ、これって前も同じようなPが上がっていなかったっけ?」というシーンが出てくることもあります。
同じPが出ていると、ひどい場合には、チームの中に「どうせ変わらないし…」という負の感情やマンネリ感が出てしまい、あまり良い状態ではなくなります。

そこで毎回フリカエリのKPTを(写真などで)残しておき、次のフリカエリでそれを眺めて、同じようなPが上がってないか?を見るようにしています。
そのようなPがあるなら、その根本原因やTを工夫しないと、また同じ結果になってしまうのでチームで対応を考える…例えば、上に書いた「深堀り」の対象にするなど…必要があります。

気づき:暗黙知となったKは減っていく

同じチームでフリカエリを行なっていると(PやTはそれなりに出ているのですが)Kは少なくなっていきました。
チームの状態が悪くなったわけではなく、そのKがチームにとって当たり前になり「暗黙知」になったのです。
そして「あえて書き出すまでもない当たり前のこと」になり、Kとして出ることがなくなったわけです。
新しいメンバーが入って、そういう暗黙知を「K」として書き出すことで改めて、チームがその良さに気づくということがありました。

このように、いくつか工夫はしていますが、最初に上げた「プロジェクトファシリテーション実践編 ふりかえりガイド」に書かれているほぼその通りです。

大事なのは(リーダーなどを含めた)チーム全員が、そこに書かれている心持ちや姿勢を取ることができるか?ということです。
その点では、(日常の)朝会に比べると少し難しいかもしれませんが、フリカエリをきっかけにチームが大きく変わることもあるのでチャンレジする価値はあります。

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

Photo by Acarlos1000 on Visualhunt.com / CC BY

朝会

朝会と夕会

[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」について考えることがあって、その後もチームで話すことがあったのでちょっと書いてみます。

今のチームでも、もちろん朝会をやっています。
そのやり方はほぼプロジェクトファシリテーション実践編 朝会ガイド(※リンク先はPDF)の通りです。

以下は、(別のチームも含む)過去の朝会でやった工夫です。

司会者持ち回り

最初はリズムを作るためにリーダーがやっていたのですが、リズムができてからは司会者をメンバー持ち回りでするようにしました。

背景として、若手メンバーにチームの朝会ではありますが、場を作って進めることを学んで欲しかったというのがありました。

自分が実際にその役割(ここでは朝会の司会)を実際にやってみないと、考察や気づきには至らないこともあります。
また実際にやってみることで新しい適性に気づいたりして、レベルアップにもなりますので「いまいち、若手が積極的でない…」という場合にはやってみても良いかもしれません。

プチふりかえり

当時はなかなか頻繁な「ふりかえり」がなかなかできませんでした。
社風的なこともあるのかもしれませんが「プロジェクトが終わった後に一気にやる」というアンチパターンな形が多かったように思います
#それでも「無し」よりはマシですが。

当時のチームは新人もいたので「頻繁なふりかえりとそこからのフィードバック」はきっと効果があると考えていました。
そこで、「朝会の延長戦」的な感じで、毎週金曜日の朝会の後に「プチふりかえり」と称して少し話し合うようにしました。

朝会と同じ場所ですので、チームの目の前には「今週にやったタスク」「次週にやるタスク」がタスクボード上に付箋としてあります。
#その会社の標準的なタスクボードでは(カンバンとは違い)時系列で作られていることが多いのです。

そのタスクボードをインプットにして、KPTをサッと話しあうようにしました。対象期間は1週間ですので、15分程度ですぐに終わります。

「ふりかえり」単独の場合「今回はちょっと忙しいからスキップしようか」となることもありますが、朝会はスキップされることが少ないので、このプチふりかえりを安定して行うことができました。

改善する点としてはKPTを書き出していなかった(話すだけ)ので、ここは書いておいた方が見えるようになるので、その点はこれからの改善点です。

退社時間の表明

「今日は19時に帰ります!」と宣言します。

こうすることで「今日やること」とのバランスが分かります。
「今日やること」が残業そうな量なのに「定時で帰ります」と宣言していると、タスクが漏れていたり、勘違いしているのでは?と気づいたりします。

また表明することでその表明した人にも良い意味のプレッシャーがかかり(いつも以上に)集中できます。
#「あれ?○○さん、19時過ぎたよ、帰らないの?」なんて声がかかって来ることもありました

さらに他のメンバーとのスケジュール調整ができるようになります。

「19時に帰る」と表明したメンバーに仕様の相談、レビューなどをお願いする場合、18時半ではなく、15時とかにお願いする必要があることに気づき、そうであれば、タスクの順序を変えるなどというようなことができます。

定時の予定を(プロジェクト状況次第ではありますが)ちょっと気をつければ防げた的な予期せぬ割り込みタスクで影響を受けるのが好きでないので、このルールは助かりました。

夕会

同僚が(朝会と)夕会をやっていたチームにいたこともあって、それについても考えてみました。

予定通り行っていないことやハマっていることなどの心配事を夕会で言う(はき出す)ことができるので、退社後から朝会までの間ではありますが、あれこれ気にかけることが少なくなります。特に週末などは効果が高そうです。

ちょっとやればクリアできそうであれば、夕会後、ペアプロなどで対応すれば、スッキリしてその日のタスクを終えることができます。

また「本当に今日それが必要なのか?」「(残業が必要でも)他の人とペアでやったりすることで早くできないか?」などを考える場にもなり結果的に不要な残業も少なくできます。

ここで大事なのは、2交代制(でも人が変わらない)のプロジェクトのように「後半戦(長時間残業)開始の合図」にしてはダメということです。

特別な準備もないのでまずは朝会をやってみる

朝会はお金がかからないですし、特別な準備もそれほどは不要です。

もちろんより効果を出そうとすれば、見える化された情報は必要になります。
が、まずは集まって「リズムを作って」「隣の人が何やっているか知る」ようにしてみてはどうでしょうか?
そうすると「もっとこういう情報が見えた方が朝会が効果的になるよね?」と改善していくと思います。

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

※アイキャッチ画像:http://www.flickr.com/photos/practicalparticipation/4055214381/

Share

インセプションデッキを書いてみた

社内で「アジャイルサムライ~達人開発者への道~」の読書会をやっています

この読書会。色々な所(道場)があります。詳しくはGitHubにまとめられているWikiをご覧ください。

読書会で作ってみた

その読書会で、(この本の特徴の1つでもある)「インセプションデッキ」を作って発表しました。

最初に読んだ時は「あぁプロジェクト憲章とか計画書かな?」と思っていました。

いざ書き始めてみると、答えに窮する部分が見つかったり、分かっていたつもりでも文章にするとボンヤリとしていてフワッとしていることが明らかになってきました。

チームでもやってみた

(この読書会とは別の日に)チームの何人かと「エレベータピッチ」「トレードオフスライダー」を「みんなはどう思います?」と議論しました。

すると、(幸いにして根本的にはそれ程違いはなかったのですが)それぞれの想いや細かな優先順位の違いがありました。このチームで携わっているプロジェクトはすでに1年半ほど経つのに、それでもこれだけ違うというのは面白い発見でした。

インセプションデッキは、プロジェクトの初期段階に、できればメンバー全員で、最低でも核となるメンバーを含めてやった方が良いと感じました。

マネジメントが主な業務となるプロジェクトマネージャや最後までいない上流工程のコンサルタント的な方が「プロジェクト計画書」なるものを作ったりしますが、それがメンバーに浸透するかというと、まずほとんどしていません。
だから開発の山場で「そもそもこれは何のためなんだ?」となったり、設計方針がぶれたりすることもあります。

「プロジェクト計画書」でも浸透できるようなプロセスが組み込まれていると良いのですが、実際は前述のような人が書いて、メンバーには「読んでおいて」(そしてメンバーは多忙なので読む余裕はない)で終わっていると思います。

その点、インセプションデッキは気軽に始めることができ、チームのみんなで作っていくように組み込まれています。
#その質問の内容自体は本気で考えると手軽ではなく、むしろタフクエスチョンなのですが。

常に意識する、継続的に見直すことができれば、判断に迷った時に「インセプションデッキに照らし合わせるとこうだ!」と言え、それが正解か間違えているかは別としても、少なくとも迷走して疲れ果てることは少なくなると思いました。

セキュリティ的に問題なければ10枚程度のスライドなので壁に貼りだしても常に見えるようにしても良いくらいです。

こんなイベントもあります

2011/09/18(日)には東京で他流試合という名のイベントもあります。社内の読書会メンバーが参加してLTもするので、どんな内容だったか感想を楽しみにしています。

もう1つ、2011/10/08(土)にある「AgileTourOsaka2011」では、監訳者の1人西村直人(@nawoto)さんがインセプションデッキのワークショップをするのでそちらも参加したいです。
日々のタスクに追われていて、「そもそも自分はなぜそれを作っているのは?どうなるのが目的??」というのを意識できないかもしれませんが、まずはできるところだけでもやってみてはいかがでしょう?

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像:http://www.flickr.com/photos/acain/5418547739/

アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス[読書感想]

アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)

2011年最初に読んだ本です。
300ページほどの大型本で、この手のは一気に読まない/読めないのですが、これはとても興味深い内容で(また翻訳に違和感もなく)グイグイと読むことができ、一気に最後まで読んでいました。

◆目次
第1部 ソフトウェアアジリティの概要
第1章 アジャイルメソッドの概要
第2章 なぜウォーターフォールモデルは正常に機能しないのか?
第3章 XPの本質
第4章 スクラムの本質
第5章 RUPの本質
第6章 リーンソフトウェア、DSDM、FDD
第7章 アジャイルの本質
第8章 アジャイルスケールアップへの挑戦

第2部 スケールアップ可能な7つのプラクティス
第9章 定義/ビルド/テストコンポーネントチーム
第10章 2レベル計画作りと追跡
第11章 反復型開発の習得
第12章 頻繁な小規模リリース
第13章 コンカレントテスティング
第14章 継続的インテグレーション
第15章 継続的な考察と適応

第3部 アジャイルな企業を作る
第16章 意図的なアーキテクチャ
第17章 リーン要求開発のスケールアップ:ビジョン、ロードマップ、およびジャストインタイムの詳細化
第18章 システムオブシステムとアジャイルリリーストレイン
第19章 高度に分散した開発の管理
第20章 顧客とオペレーションへのインパクトの調整
第21章 組織を変化させる
第22章 ビジネスパフォーマンスを計測する

結論:アジリティはスケールアップ可能である
索引

「小規模開発環境で適用されている(日本では「されつつある」)アジャイル開発を(それなりの規模の)企業に適用するには、どのような課題があり、それらをどう解決していけば良いか?」という内容が3部構成で書かれています。

第1部はアジャイルの歴史やXP、スクラムなどの主要なアジャイルメソッド、RUPなどそれぞれの特徴、開発メソッドの解説を簡単に説明しています。
第2部ではアジャイルのプラクティスの中からスケールアップできる…大規模に拡張可能な…7つのプラクティスについて言及しています。
第3部ではスケールアップした際に企業が直面する課題に対するプラクティスとして新たに7つ言及しています。

特に印象に残ったのは、第3部で「アジャイル開発(やそのマインド)を現場・チーム以外にも企業全体に広めていくには?」を考察している点でした。

アジャイル開発がメインになった時に、マーケティングやセールスにとってどういう影響があり、それに対してどうすれば良いか?
またエグゼクティブは組織全体にアジャイル開発を根付かせる為にはどうすれば良いか?
企業体にはどのような阻害要因が発生しうるか…等々、アジャイル開発を開発現場の視点で書かれた内容とは違っており興味深かったです。

自分が所属しているSIerの組織全体ではアジャイル開発には程遠い…ということを認識しているか余計に思ったのかもしれません。
ちょうど今年のアクションにも関係する内容で(その為に大晦日に買った)、良書だと思いました。

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