Agile2010 – Using Scrum to avoid bad CMMI implementations

感想おまちしてます!

P1000904CMMIとScrumを併用して成功した例。
AgileプロセスとCMMIのようなかっちりしたプロセスがマッチするということを明らかにした興味深いセッション。
どうも、去年ぐらいにどこかで発表したネタらしい。

  • CMMIではWhat(品質)を改善し
  • ScrumではHow(顧客満足)を改善した
  • AgileやCMMIだけでは改善できない部分がある。例えばマネジメントが欠如していたり、ミッションやゴールの不理解などがうまれたり

Scrumによって以下の効果を目指した。

  • 顧客の焦点を明確にした
  • 軽いプロセスを定義した
  • 明確なチームの役割を決めた
  • 開発者を支援できるようにした

明確なチームの役割」は、カンファレンス全体としてのキーワードに感じる。
開発者は、ミッションとゴールを理解しているので、マネジメント部分をあまり意識しない。進捗などもバーンダウンチャートやかんばんを利用するので、きっと、それらを評価したり、レポートにまとめて経営層に報告したりする人は別にいるようだ(たぶん、これがマネージャなのかもしれない)。

事例と効果に関しては以下。

  • Excellent Scrum ・・・ 400%成長 主な企業:Pegasystems/Patient Keeper
  • Good Scrum ・・・ 300%成長 主な企業:スカンジナビアのいくつかの企業
  • Pretty Scrum ・・・ 150%から200%成長 主な企業:Google/Systematic
  • Scrum But ・・・ 0%?35%成長 主な企業:Yahoo

失敗する場合によくあるケースが以下。

  • スクラムが何かわかっていない
  • スプリントの終わりにテストされていない
  • バックログの準備ができていない

CMMIによって残業を減らし、ScrumでFocus残業?を減らす。

中でも、スプリントの準備はとても重要。
準備が曖昧だと、Velocityなどが不安定になる。

開発の不安定な要素をなくすために、バックログの整理やスプリント計画はしっかりやらなければならない。

*

やっぱり、プロセスはそれぞれに良いところ、悪いところがあるので、これからは、それぞれを生かした形を作っていく必要が出てくるのだろう。「XPやってます!」「Scrumはじめました!」だけでは、改善も止まってしまい、ハイパフォーマンスなチーム作りは難しくなっていくのかもしれない。