私たちは、個人とチーム、そして組織や顧客のニーズを満たすためにアジャイル開発をしています。
しかし現実には、口には出さなくとも、各自のニーズが衝突することは少なくありません。

• 同僚のコードが酷い!
• QAエンジニアの指摘が細かすぎる!
• 部長はアジャイル開発を何も分かっていない!
• なんて不勉強なプロダクトオーナーだ!
• 顧客のスケジュールが厳しすぎる!
  
  

『エクストリームプログラミング』の参考文献に、NVCという、相互を尊重し、お互いのニーズを満たすためのコミュニケーション技法があります。

今回は、NVCの説明や簡単なワークを通して、個人、チーム、組織、顧客との対立を解消し、より良い関係を結ぶために私たちができることを一緒に考えたいと思います。

このセッションでは、スクラムの導入から、スクラムチームをスケーリングして複数のフィーチャーチームに拡大するまでの取り組みについて、取り組み内容とその気づきをお話しします。

私たちは約2年前にスクラムチームを立ち上げ、当時は10名程度だったスクラムチームも、現在では5チームになり約40名を数えるまでに拡大しました。

最初は、アプリ(iOS/Android)チームにスクラムを導入しました。当時はバックログはサーバーチームと別々に存在し、POはそれぞれのチームに仕様を説明していました。また、仕様はPOが作成し、開発チームは決まった仕様を作る・・・そんな状態でした。

現在は、アプリとサーバーが同じチームになり、フィーチャーチームとして最優先のバックログに取り組むことができるようになりました。

ここに至るまでに様々取り組んだことや、苦労した(している)ことなどを是非シェアできればと思います。

約一年前、他社向けアジャイルコーチとして転職し、10チーム以上でのスクラム導入を支援してきました。

スクラムマスターの仕事の一つにコーチングがあります。
(スクラムガイドには「自己組織化・機能横断的な開発チームをコーチする」などと書かれている)
また、アジャイルコーチは職業名にそのものずばり「コーチ」が入っています。

あらためて、コーチングとはなんでしょうか？

問いを立てればよいのか、どう立てればよいのか。暖かくすればよいのか、冷たくすればよいのか。
ティーチングやコンサルティングとのちがいはなにか。
実際のところ、「コーチング」は役に立つのか？

また、スクラムマスターやアジャイルコーチにとって、技術だけではなく「人」の問題と向き合うことが不可欠です。

自説を曲げることができない頑固な方、
すっかり自信を失って、自分はダメだと思い込んでいる方、
このような方々を、コーチングで良い方向に導くことはできるのでしょうか。
それとも良い方向に導くということ自体が傲慢なことでしょうか。

スクラムマスターやアジャイルコーチはアジャイルだけを淡々と伝える仕事でしょうか。

悩みはつきません。

書籍による学習や、さまざまな有識者へのインタビューなどを通して学んだ、
現場で実際に試した、明日から使えるコーチングテクニックなどを、
夏休みの自由研究スタイルでお送りします!

参考文献

• Rachel Davies, Liz Sedley (2017). 『アジャイルコーチング』 オーム社
• マンフレッド・ケッツ・ド・ブリース, コンスタンティン・コロトフ, エリザベス・フローレント・トレーシー (2008). 『エグゼクティブコーチング』 ファーストプレス
• ジョセフ オコナー (2012). 『コーチングのすべて――その成り立ち・流派・理論から実践の指針まで』 英治出版
• 山崎 啓支 (2016). 『NLPで最高の能力が目覚める コーチングハンドブック 知識と経験を最大化するセンスの磨き方』 日本能率協会マネジメントセンター
• ...その他