「強いチームの作り方」という記事を WEB+DB PRESS Vol 83 に書きました

が、ブログのURLが含まれていることに気がつきまして、最新エントリがさすがに去年のままだとまずかろうと。

WEB+DB Press Vol.83は先週の金曜日発売でした。

内容についての紹介は、共著のryuzeeがもう書いてくれたので、割愛して、こちらでは、ちょっとその背景みたいなものを書いてみようと思います。

仕事がら、コンサルタント、コーチまたはトレーナーなどとして、いろいろなチームに伺うことが多いのですが、こういう立場で呼ばれるということは、いろいろと問題があることが多いのですね。

ご依頼の内容の通りの問題があるときももちろんあるのですが、よく見受けられるのは、問題そのものを議論の対象にすること自体を怖れているという状況です。問題があることはわかっているが、それに触れてしまうと、もっと大きな問題を引き起こしそうで、みんな触りたがらないという状態ですね。

そうなってしまうと、どう解きほぐしていくかは、状況に依ります。対策にあたるメンバーを変えるようなことが必要なこともあります。

でも、そういうことになるまえに、ちょっと練習をしておくだけで、そういう状況に陥ることが避けられるようになりますし、大きな問題に接したときも、怖れずに議論できるようになります。この特集では、そういうときに役立ちそうな考え方、プラクティス、ワークショップなどを入れてみたつもりです。どうだったでしょうか？ぜひ、お読みになったご感想をお知らせください。

WEB+DB PRESS Vol.83

WEB+DB PRESS Vol.83

あと、ご紹介したバルンガ、改善ゲーム、星取表などのワークショップは、どこかで体験できる機会を設けられるといいですね。ぜひご遠慮なく、ご相談ください。

Barnga: A Simulation Game on Cultural Clashes (25th Anniversary Edition)

Barnga: A Simulation Game on Cultural Clashes (25th Anniversary Edition)

2013のコミュニティ活動のまとめ

今年も暮れてきましたが、今年のコミュニティ活動についてまとめておく予定地。

発表スライドとか、イベントサイトとかへのリンクを足していきます。

こう眺めると、けっこういろいろやってますね。

また来年もいろいろやると思いますので、一緒に連れて行け、やってみたい、なにか手伝ってほしいなど、何かできることがあれば、ご遠慮なくお知らせください。

よろしくお願いします。

今年の活動履歴

日付 場所 イベント 活動
1/7-11 Kihei ScrumPLoP mini Writer
1/15-16 東京 Scrum Gathering Tokyo 2013 Talk / Organizer
2/22 横浜 Agile Samurai横浜道場番外編 Workshop
3/4-6 HCMC 3 Days of Lean and Kaizen Sponsor
3/19 名古屋 DevLOVE 名古屋 準備会 Agitator
4/23 東京 QCon Tokyo 2013 Talk "DDD-Scrum"
4/24 東京 DDD/Scrum Workshop Workshop
4/27 大阪 XP祭り関西 Talk
5/2-24 Tisvildeleje ScrumPLoP 2013 PLoP
5/28-29 Zurich Scrum in Manufacturing Trouble Maker
6/12 神戸 Lego Scrum Kobe Host
7/3-5 上海 Scrum Gathering 上海 Talk
7/13 仙台 レッツゴーデベロッパー変真 Workshop
7/20 大阪 TDD for embedded C Workshop
8/19 マラケシュ アフリカ上陸 Strayer
8/31 岡山 TDD BC 岡山 2.0 Participant / LT Talker
9/11-12 東京 ソフトウェア品質シンポジウム2013 / SQiP Tutorial
9/20 神戸 DevSumi 関西 Talk x 2
9/21 大阪 Scrum Boot Camp 大阪 Trainer
9/23-27 HCMC Agile Retreat 2013 Coach
10/5 大阪 Agile Tour Osaka 2013 Organizer/Interpreter
10/26 大阪 DDD/Scrum Workshop with SEA Workshop
11/1 仙台 DDD/Scrum Workshop mini Workshop
11/3 石巻 ツール・ド・東北 Rider
11/7 HCMC DDD/Scrum Workshop in Ho Chi Minh City Workshop
11/8-9 HCMC Agile Tour Ho Chi Minh City Talkx2/Workshop
11/10 Hanoi Agile Tour Hanoi Talk/Workshop
12/8 Honolulu Honolulu Marathon Runner
12/14 神戸 Global Day of Coderetreat in Kobe 2013 Facilitator

Mike Beedle 氏の認定スクラムマスタ研修を開催します。

 

来年の年始、1/14-15に開催されるRegional Scrum Gathering Tokyo 2014に、Mike Beedle氏がキーノートスピーカーとして来日します。

 

その来日に合わせて、1/9-10 と  1/16-17 に Mike氏による認定スクラムマスタ研修を開催します。詳細資料はこちら。

 

Mike Beedle 氏は、スクラムを作った Jeff Sutherland / Ken Schwaber 以外で、初めてスクラムを適用した人です。しかも、スクラムの説明にあるように小さなチームからのスタートではなく、トラブルに陥った２００名を超えるプロジェクトを立てなおすためにスクラムが使われました。

 

氏の研修は、Enterprise Scrum (企業のためのスクラム)となっています。

ソフトウェアに限らず、さまざまなビジネスがいかにアジャイル・リーンという方向性に向いてきたかを解き明かしながら、どうやってスクラムを活用したらよいかという面を中心とした内容となっています。その中で、どうやってアジャイルマニフェストが、”アジャイル”という言葉を選んだのかが解き明かされます。これまで、あまりアジャイル開発向きではないと思われていた業界、業務で、どのようにスクラムを活用するかというプラクティスは、今の日本のソフトウェア業界でも参考になることが多いと思われます。

 

また、最近ふたたび注目をあびつつあるパターンランゲージが、どうスクラムの成立と発展に寄与したかを知ることができるのも興味深いと思われます。最近、翻訳された「組織パターン」と、野中・竹内氏の論文、そしてリーンがどのよう組み合わさってスクラムが生まれ、さらにビジネスにおけるパターンを産み出してきたかが語られます。

 

今回、２回の認定スクラムマスタ研修を行いますが、１回目は同時通訳無しで行います(テキストは、日英対訳のものを用意します)。逐次の翻訳は行いませんが、必要に応じて私が通訳支援をしますので、ぜひ英語の練習も兼ねて参加していただけるとよろしいかと思います。

 

それでは、ご参加をお待ちしております。

 

開催概要

f:id:haradakiro:20131126130711g:plain

 

 

f:id:haradakiro:20131126130724g:plain

 

スクラムチームの最悪の敵に対処する

寒くなってきましたね。

この前の記事が暑い話だったのは、いつの話ですかね。

 

で、今回は、スクラムチームの最悪の敵の話です。

まあ、プロダクト開発をぐるぐる続けられているなら、魑魅魍魎ステークホルダーともうまくつきあえるようになっているでしょう。

 

でも、怖い敵はいるのです。

 

 

 

 

インフルエンザ

 

寒くなってくると、そろそろと流行りはじめます。

 

チームメンバーの誰かが、敵の手に落ちます。敵もさることながら、いきなりは攻撃してきません。ちょっとだるいなとか、頭が重いなくらいの感覚です。

 

でもプロジェクトは進めないといけませんから、がんばって出社します。最近の風邪薬は強力ですから、多少の熱、咳くらいはコントロールできます。熱が下がったのでデイリースクラムに参加します。プランニングポーカーでエキサイトすることもあるでしょう。

 

はい、これでチームは敵の手に落ちてしまいました。しばらくすると、みんな感染します。フロア全体に蔓延したりします。あれれ、今回のスプリントどこまでやるんだったっけ？多少のベロシティ変化がぶっとぶくらいのダメージです。

 

改善しましょう。 

  • チームで予防接種を受けましょう。
  •  ちょっとでも体調がすぐれなかったら、出社せずに様子をみましょう（あなたは敵の手に落ちた生物テロ兵器になってるかもしれません）
  • リモートワークの練習をしましょう。

それでは、みなさまお大事に。

次回のふりかえりのときに、ぜひ話し合ってみてくださいな。

 

追記(2013/11/14 16:40):

具合の悪そうなのがデイリースクラムにいるのを見つけた時は、そいつをつまみ出して、適切な治療を受けさせるのはスクラムマスターの仕事です。咳こみながらデイリースクラムにでるんじゃありませんよ。

 

 

P.S.

筆者は神戸在住なので、数年前の新型インフルエンザのときは、しばらくクライアント先に行かず閉じこもってました。なかなか手強いです。 

 

がんばるあなたがプロジェクトを殺す

あまりに暑いのでちょっと怪談を。

 

今のような仕事のやり方をする前、いわゆるシステムインテグレータに所属していた。まあ、呼び方はいろいろあるのだろうけれど、一番長いこと仕事にしていたのは、いわゆる「火消し」。問題プロジェクトにがあると、プロジェクトに投入されるという役どころだ。まあ投げ込まれるのは大変だけれど、いろいろなものを見ることができた。

 

投入されたプロジェクトは多種多様だけれど、たいていの場合、すぐに問題があるようには見えない。みんな忙しそうに働いているし、大きな開発プロセスの問題もない。粛々と作業がすすんでいるように見える。でも、クライアントと管理職は怒っている。怒っているから、いろいろな作業が追加されて、メンバーはどんどん忙しくなる。

 

しばらく見ていると、プロジェクトには必ずある種類の人がいることに気がつく。みんなに頼りにされていて、なにかあると彼(彼女の場合もあるよ、もちろん)のところに相談がいく。

 

彼は、たいてい最後まで残業している。メンバーがみんな帰っても、「あとちょっと」と言いながら、最後まで残っている。メンバーは、「彼があんなにがんばっているんだから、私もあれくらいは、、、」と思っている。

 

本人に聞くと、「私ががんばらないと、このプロジェクトはまずいので、」と必ず返ってくる。彼は、時々朝まで仕事をしていることがある。プロジェクトレビューがあったりするときとか、部内の進捗会議がある日とかね。ドキュメントをチェックして、誤字を直したり、テスト環境のデータベースパスワードが間違っているのを修正したり、進捗資料の画面ハードコピーを取り直したり、、、

 

そう彼はとても真面目でプロジェクトのために身を粉にして働いている。プロジェクトの問題を修正し続けている。みんな彼を頼りにしている。

 

で、壊れる。プロジェクトまたは彼自身が。「または」はプログラマの OR だからね。どっちも壊れることもある。

 

で、どちらかが壊れたとき、プロジェクトを安全に元に戻すことはできない。プロジェクトが抱える多くの問題は、彼しか直せないからだ。彼が直せなくなったとき、プロジェクトはどうしようもなくなる。

 

これが怪談なのは、誰も悪意を持っていないところだ。彼はプロジェクトを助けるために働き、皆もそれに感謝した。結果、プロジェクトが破綻に近づいた。

 

この状況に問題があるとすると一点だけ。彼がプロジェクトメンバーが学習する機会を奪ったという点だけだ。自分が作ったドキュメント、コード、デモ、プレゼンテーションのどこに不具合があるかを知ることができなければ、次によくすることもできない。

 

少しは、涼しくなっただろうか。怖くなったらみんなでビールを飲みに行くのがいいんじゃないかな。

 

よい夏休みを。

 

 

 

 

 

 

 

 

 

ぐるぐる DDD/Scrum というワークショップをやってきました

東北デベロッパーズコミュニティにお招きいただき、DDD/Scrumのワークショップをやってきました。

 

ワークショップは、DDD のモデリングのうずまきに、スクラムのワークショップでよく使うタイムボックス縛りを組み合わせて、Agile でいうところの Swarming という状態になれないかな、という目標で設計しました。

 

正直、１時間の枠組みで、シナリオ書いて、モデル描いて、コードも実装するのは、だいぶ大変だったと思います。ご参加いただき、ありがとうございました。

 

ただ、１時間を二回廻すだけでも、チーム内で駐車場を語る語彙、モデル、設計実装案は、だいぶ共有できたのではないでしょうか。そのまま、プロジェクトに突入できる訳ではありませんが、わからないことがわかっているというのは、プロジェクトを始めるときには非常に役に立つでしょう。

 

参加された方は、各チームの発表したモデルの中心(コアドメイン)が、どれも一致していないことに気づかれたかと思います。どんなビジネスをやりたいかによって、同じドメインでも、どこをコア、サポート、一般サブドメインにするかは異なります。駐車場みたいに、比較的簡単なドメインでさえそうです。

 

ぜひ、みなさんのプロジェクトでも、プロジェクトを始めるときに、あるいは途中でも、そしてできればプロジェクトの間中ずっと DDD/Scrum のぐるぐるをやってもらえればと思います。

 

ご質問などありましたら、ご遠慮なくご連絡ください。 

 

 

 
で、こんなワークショップが成立したのは、何より強力な講師陣がいたからですね。増田さん(@masuda220)、和智さん(@digitalsoul0124)、井上さん(@i_takehiro)、ありがとうございました。
 
また、イベントを企画した運営された東北デベロッパーズコミュニティの皆様、ありがとうございました。
 

P.S. いやー、仙台、涼しくて、食べ物おいしくて、参加者が元気で、すばらしいです。また、おじゃましたいと思います。

 

「プロジェクトが成功するためならなんでもする」と考えておけば十分か

まあ、大人げないと思いつつ。いろいろ考えるのですよ。

というわけでアジャイルに不慣れな受託のマネージャー向けに。

 

「プロジェクトが成功するためならなんでもする」

まあ聞いたことがあるよねこの言葉。SIer にいたころに協力会社の営業から。できれば頼みたくない会社だったりするんだが、そういうところに限って見積が安かったりするんだな。

で、トラブルになっても何もしない。唯一やってくれるのは、「人が足りないんですか？職務経歴書お送りしますよ。」だ。

あうち。

ソフトウェアにアーキテクチャがあるように、プロセスにもアーキテクチャがある。変わりにくいものと変わりやすいことを読むのが本質だ。

ソフトウェア開発において、みんなどこでも「なんでもやりますよ」をやるとどうなるかはみんな知っているだろう。大きな泥だんご(Big Ball of Mud)っていうやつだ。結局何もできなくなるまで、無駄を生み続ける。

プロセスも一緒で、どこのプロセスでも「なんでもやりますよ」をやると、小学生のサッカーみたいになる。見たことあるでしょ、流行のバズワードのプラクティスは全部やってるように見えて、実際には何も役に立っていないような現場を(テストカバレッジが100%だけど、アサーションが一行もないとか)。

私は、

  • 無駄とわかっていることを、さらに続けることを無駄という
  • 改善とは、成果の量と品質と保ちつつ、やることを減らすことである

という立場だ。

でも、どうやって無駄を認識して、取り除いていくか？また、より良いプロセスを試行するか。それを変えにくい(依存しやすい)プロセスとして入れておく必要があるだろう。

プロセスが生み出した結果(プロダクト)とプロセスを定期的にふりかえり、やめること、次に試すことを決めることだ。スクラムだと、スプリントレビューとレトロスペクティブを必ず固定のタイムボックスにいれるというところだな。「なんでもやる」という姿勢を続けるための安定した基盤としては、今のところ有効なメタプロセスであると自身では思っている。

ただ、そこで止まっているわけではないよ。最近名前を聞くようになってきた、Kanban というプロセスでは(ところで日本語訳はまだ出ないのかなぁ？)、タイムボックスが改善の妨げになると主張している。バッチを小さくするのに飽き足らずフローでの開発に取り組むという野心的な取り組みだ。うまくいく例、いかない例が報告され、だんだん知見が蓄積されていくのではないかな。楽しみだ。

 

P.S.

うーん、でも職業アジャイラーって何だろう？