誰かがこの列車が脱線しないように勤めなければならない。

匿名者

リリース列車エンジニアの概要

アジャイルリリース列車は主として自己組織化で自己管理のプログラムである一方、自身を駆動したり、運転したりはしない。運転の責務はのち紹介するリリース列車エンジニア(RTE)の役割によって担当する。RTEは「スーパースクラムマスター」である。この役割はプログラムレベルのプロセスやプログラムの実行を促進し、障害をエスカレートし、リスクを管理し、プログラムレベルの継続的な改善を促進することをサポートする。一般的に、RTEはプログラム管理者やプロジェクト管理者や開発管理者の経験をもつ。彼らは大規模アジャイルを確実に理解し、また、大規模なソフトウェアプログラムと指導事業戦略の計画、促進と継続的なベクトル合わせに関するユニークな機会や課題を理解している。

詳細

役割説明の概要

リリース列車エンジニアはアジャイルリリース列車のプロセスやプログラムの実行を促進し、障害をエスカレートし、リスクを管理し、プログラムレベルでの継続的な改善をサポートする。RTEはリリース計画策定検査と適用、スクラム・オブ・スクラムズのようなプログラムのイベントの開催に責任を持つ。

責務

SAFeでは、通常、リリース列車エンジニア(アジャイルャイルプログラム管理者とよく呼ばれている)は以下の責務を遂行する:

  • スプリントとPIの年間カレンダーを確立する
  • リリース計画策定の準備を推進する:ビジョンやバックログ、設備
  • リリース計画策定のイベントを主催する
  • チーム目標をプログラムのPI目標に集約し、可視化と透明化を図るために公開する
  • プログラムの実行やPIフィーチャーの完成状況の追跡を支援する(マトリックスを参照)
  • スクラム・オブ・スクラムズの司会を行う
  • チームによるエピックの見積もりを促進することで経済的な意思決定を支援し、プログラムレベルの可視性を形成する
  • 障害をエスカレートする
  • システムアーキテクトとチームの協調を推奨する
  • プロダクト管理プロダクトオーナービジネス責任者と一緒に作業を行い、戦略と執行の歩調の統一を確保する
  • リスク管理に支援する
  • リリース管理チームに状況報告をする
  • 重大なボトルネックに対処するためにリソース調整のためのインプットを提供する
  • 検査と適用ワークショップや定期的な改善マインドのデモを介して、プログラムレベルの継続的な改善を推進する
  • SAFe、スクラム、そしてアジャイルプログラムを中心にするチームとプログラムレベルの品質プラクティスと実践コミュニティを推奨する
  • 企業のプログラム管理の改善活動と標準化活動に参加する

報告ルート

報告のルートは特に定義されていないが、この役割は、開発組織、あるいはアジャイルPMOへと報告することが見えてくる。SAFeでは、アジャイルPMOはプログラムポートフォリオ管理の一部と考えられる。既存のPMO組織を持つ企業の場合、この役割はしばしばプログラム管理者によって果たす。プログラム管理者は通常RTEの仕事を実施するための組織的なスキルを持っているが、伝統的な、従来のマインドセットから移行しなければならない。また、プログラムポートフォリオ管理に記載されている変革パターンを適用しなければならない。

リリース列車エンジニアは奉仕型のリーダーとして務める

新任のリリース列車エンジニアが管理者/プログラム管理者から奉仕型リーダーへの移行する時、多くの場合、マインドセットが変えなければならない。奉仕型のリーダーシップは一種のリーダーシップの哲学であり、その哲学に人々、仕事とコミュニティ精神に関する本質の包括的な視点を意味する[1]。リリース列車エンジニアの場合、自己組織化で自己管理するアジャイルリリース列車にある各チームに対し、必要なサポートを提供することに注力する。奉仕型リーダーの行動特徴は以下を含む:

  • 課題識別と意思決定に関して、チームの話を聞き、サポートを提供する
  • 相互影響する環境を創出する
  • 他者を理解し共感する
  • チームの発展はもちろん、個々の個人的な発展を奨励し、サポートする
  • 権限を利用することより説得することを重視する
  • 日々の行動を超えて考える
  • チームの確約をサポートする
  • オープンしており、他の人のオープン性を高く評価する

奉仕型リーダーシップの父Rober GreenLeafが言ったように「よいリーダーはまずよい奉仕人でなければならない」。プログラムポートフォリオ機能の移行パターンと同じ、伝統的な管理者から奉仕型のリーダーへの移行パターンが以下で示す。

  • チームの行動を調整し貢献すること から チームが協働することをコーチングする
  • 納期を死守すること から 目標達成すること
  • 具体的な成果向けて駆動すること から プログラム全体的なパフォーマンスに投資する
  • 答えを知ること から 答えをチームに求める
  • チームを指導すること から チームが自己組織化と本領の発揮にさせる
  • 問題解決すること から 他の人が問題解決することに手伝う

さらに知りたい場合

[1] See Servant Leadership at http://en.wikipedia.org/wiki/Servant_leadership

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[3] Trompenaars, Fons and Voerman, Ed. Servant-Leadership Across Cultures: Harnessing the Strengths of the World’s Most Powerful Management Philosophy. McGraw-Hill. 2009.

 Last update 22 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.