ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

アジャイルプロジェクトを成功させる19の鍵

みなさんこんにちは。@ryuzeeです。

Jesse Fewell氏のThe 19 Keys to Successfull Agile Projectsより。 アジャイルなプロジェクトを成功させるために考えるべきことが19個紹介されているので、抜粋・意訳にてご紹介します。

  • 正しい理由でアジャイルを採用すること
    • ハリーポッターのように、悪の魔法使いがすごい魔法を使うと彼ら自身が滅びてしまう
  • アジャイルをやってみたいと思うチームと始めること
    • 抵抗する人に対してパイロットとして努力することを強制してはいけない。チーム自身でアジャイルを採用させるようにしなければならない。それから、彼らの期待する内容を決めなければならない。「本当にやりたいって?本当に危険な取り組みなんだよ。やっても良いけど1スプリントだけだよ!」
  • スクラムに対して現実的な期待をすること(非現実的な期待をしないこと)
    • 「スクラムは悲惨なプロジェクトを救ってくれる」なんて言ってはいけない。そういうプロジェクトだったら、単にプロジェクトをリスタートさせて、空気のきれいな部屋で3〜5スプリント与えてみよう
  • できる限りの間、アジャイルへの取り組みはパイロット的な取り組みであると言っておくこと
    • パイロットは大変だとみんな思うだろうし、パイロットプロジェクトであれば参加者の長い目でみたキャリアには何の脅威ももたらさないだろうから
  • 変化は多くの人にとって脅威であることを理解すること
    • 望まない状況下においては、人々は自身を安定した予測可能な状態になるように自分を守ろうとする。変化を紳士的に伝えよう。「スクラムは我々にとって正しい方法でないかもしれない。でもやってみなきゃ分からないじゃないか。だから1スプリントだけ正しくやってみないか?もし我々にとって何かメリットがあれば、もう1スプリントやってみようそれもやり方の1つだよ。これが唯一のやり方じゃないけどでもちょっとは我々の助けになるかもしれないよ」
  • 我慢することは美徳である
    • 1チームから始めて、そこから徐々に増やしていこう。把握している問題に対して20チームが同時にもがくようなことをしてはいけない。かわりに1つのチームが先駆者となって問題を解決してほかのチームがその問題に直面しないようにしてあげた方がよい
  • スクラムの中庸を見つけよう
    • ある意味、私の仕事は劇的な変化を純粋に提唱し、言いにくい事実を言い、それから彼らの状況下において、彼らにあったプラクティスを作り上げるように励ますことだ。しかし、多くの組織は変化を希薄にすることで、変化の痛みに対応しようとすることに気をつけよう
  • スクラムは難しい
    • スクラムはあなたたちのたくさんの嫌な問題を表面化させる。もしスクラムが明らかにする問題に対して対処する準備ができていないなら、スクラムを続けるのは難しいだろう
  • 経験者の力を借りる
    • コンサルタントは首になることを恐れていないし、もちろん部門の行動計画が用意されていないことも恐れていない
  • 十分なトレーニングを受ける
    • アジャイル適用の失敗は週末に本を読んだだけの人が行ったような初期のトレーニングと関係していることが多い。誰か1人を本当に良いトレーニングに行かせる方が、20人を悪いトレーニングにいかせるよりよほど良い
  • あなたの敵はあなたの仲間だ
    • スクラムが好きな人に対しては多くの時間を使うことはない。あなたの主たる抵抗者をスクラムのステアリングコミッティーに据えなさい。もし彼らが参加しないと、彼らはスクラムがどのように作用するか知る機会を逃してしまうし、置き去りにされた気になってしまう。もちろん、彼ら抵抗勢力は、アジャイルの適用の成功に対する主な妨害要素についてあなたが理解するのを助けることにもなる
  • ゲリラ的な戦略を用意する
    • 管理職があなたの問題を解決してくれない場合でも、時には自分たちで問題を解決しよう
  • 守り神を見つけよう
    • 「やってみろ」といってくれる上級管理職が必要だ。会社のルールを曲げなければならなかったり、特別な予算が必要になったときが守り神の出番だ。実際のところ、多くの経営者たちは多くのプロジェクトで失敗してきた経験から、アジャイルなアプローチを試すことを切望しているのだ
  • 良い情報への容易にたどり着けるようにしよう
    • メール、ランチミーティング、スタッフミーティングなどを使って良い情報のしっかりした流れを確立しよう
  • 早い段階から頻繁に結果を測定しよう
    • 良い結果も悪い結果もみんなに見せよう。ビジネスと技術の両方の観点で測定することが必要だ。顧客満足度やチーム満足度をはかるための調査も必要だ
  • 自分たち用にいじくりまわしたいという衝動は大きい(だろうがよく考える必要がある)
    • 自分たち用に仕立てることと、中途半端にやることの違いをはっきり示そう ピートはCricketButというゲームについてこう述べている。「我々はクリケットをやっているけれど、競技場でではなく、我が家のリビングルームでやっている。三柱門(クリケットの投球場所)の代わりに、我が家の犬を塚ている。そしてボールの代わりにおもちゃの積み木を使っている。バットの代わりに頭を使っている。ちょっとプレイしたらたぶん流血事件になるだろう。仕事に置き換えてみても、同じことだ。」
  • ツールは慎重に選ぼう
    • 「どのツールを使うべきですか?」なんて聞かないこと。そうではなくて「我々にツールが必要だと思わせるどんな問題を解決するべきですか?」と聞くこと
  • スクラムチームだけでスクラムを止めるのはやめよう
    • スクラムは組織的なフレームワークだ。一部の場所ではチームは成功を収めることが多いかもしれないが、組織には悪い習慣が積み重なっており、成功は本当の意味では実現されていないのだ。あなたはチームとしては結果を出すことはできるが、最終的な顧客に対して価値を届けられていないとしたら誰がそれをケアするのか?
  • スクラムはいつも面倒だ
    • アジャイルの活動は人と人の行動の土台になっている。人は完璧じゃないし、我々のプロジェクトも同じように完璧ではない。あなたはいつも矛盾や誤りをおかしながら挑戦していくのだ。「先月よりはうまく行ってるかな?」と自問してみよう
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 完成の定義のサンプル(2)
次の記事 プロダクトバックログアイテムの優先順位の付け方

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World