アジャイル以外の厳密な方法を使用するチームにアジャイルを導入するにはどうすればよいですか？
一部の非アジャイル方法論について誇らしげに認定されている企業を考えてみましょう。アカウンタビリティを実証するための顧客へのセールスポイントとしてそれを使用しています。
システム全体を壊さずにカンバンまたはスクラムを徐々に導入し、どのように進めますか、それでも彼らにそれを確信させますまだ説明責任/監査可能である？
これは「 スクラムのようなアジャイル方法論をどのように導入しますか 」に関連している可能性があることを知っていますが、ここでは、会社が特定の管理方法を課しているという事実を回避/回避する方法について疑問に思っていますSDLCは、それが監査証跡を取得する唯一の方法であると偽装しています。
アジャイルプロジェクトチームがアプリケーションを文書化しないのは神話だと思います。これは、標準に従って最高の文書を持っていると認定されている企業であなたが得る最初の抵抗点です。
私はISO-9001認定企業で働いていますが、多数のプロジェクトでスクラムも行っています。私たちの場合、この変更はプロジェクトデリバリーヘッド（つまり、かなり上級の人々）からのものであり、プロジェクトマネージャーや開発者がこの変更をプッシュしようとするのではなく、それが採用される理由です。
私たちが従う1つの便利な方法は ドキュメントは十分ですが、継続的に です。これは明らかに、プロジェクトに規定されているすべてのテンプレートに従っていないことを意味しますが、どのセクション/ドキュメントが必要であるかに対して、意識的な理解と合意があります。それは無意味なオーバーヘッドです。
次に、この視点を社会化し、品質グループや標準部門、またはそれが何と呼ばれるものでも承認を得る必要があります。
アジャイルの原則は「十分」なドキュメントです。どれだけの量で十分かをチームに説明するために、顧客からそれを試してみてください。プロジェクトマネージャーは顧客と話し合い、彼らの期待と組織のニーズが何であるかを理解してから、決定を文書化し、それらの期待に応えることができます。彼ら（つまり、有料の顧客）にとってそれが十分であれば、それはあなたが従うものになる可能性があります。
彼らがアジャイルが大規模なプロジェクトにスケールアップしないと思うなら、分解と並列作業によって、それが可能であると彼らに納得させてください。
大規模な組織では、大規模なプログラムの制御と監視は、原価計算/経理/リソース管理などの従来の計画を実施するプロジェクト監視オフィス（PMO）を実行することによって達成されます。 （1つのSCRUMバーンダウンチャート）。継続的インテグレーションなどの手法が後からではなく、前にどのように役立つかを知る必要があるため、オーバーヘッドドキュメントを邪魔にならないように全員の生産性を高める方が良いでしょう。
アジャイルは、チームが習得できる一連のスキルであり、従来の技術的スキルとほぼ直交しています。しかし、これを既存のスキルに追加すると、もちろん、より効果的なチームになることができます。毎日のスタンドアップ（つまり、スクラムミーティング）は一晩で行うことはできませんが、現在、定期的なチームミーティング（たとえば隔週）があるでしょうか。まず、これらをスクラムの質問アジェンダ（こっそりではありません）に変換することから始めて、このアプローチが機能する理由を広くチームに伝え、ドキュメントが不十分であったり、標準が不十分であったり、その他の神話ではないことを伝えます。
私は最初にかんばんからスクラムを分離します。
かんばんの場合- そして、これを正しく行う方法についてのかなり良い情報源があります -原則は、開始時に終了プロセスを尊重することです。かんばんは、既存のプロセスを置き換えるものではなく、それに適用するものです。それを計画し、視覚化し、徐々に改善するための特定の条件を設定します。
スクラムは、既存のプロセスを置き換えるものであるという意味で、根本的に異なります。
12か月（またはそれ以上）のウォーターフォールSDLCサイクルに慣れているチームは、スクラムへの移行が非常に困難になります。サイクルの段階的短縮から6か月または3か月のリリーストレインへのスコープの縮小は、有用な中間ステップ。
組織に導入しようとする新しいことと同様に、強い反対に直面します。それが失敗した場合、あなたは批判され、theの責任を負う準備ができていますか？あなたは強い人でなければなりません。それはあなた自身を公開するときに支払う代償です。
- スクラムを使用する理由を自問してください。実際の問題を解決する必要がありますか？
- YOUがコミットされているであることを確認してください。だれもそれを行わないからです。あなたはモノの所有者になります。 少なくともそれが組織にプラスの効果をもたらすまで
- トレーニング。本とインターネットだけでは十分ではありません。最初にコースに参加しないと、スクラムを誤って実装する可能性が劇的に高まります。これはおそらくあなたのチームを以前よりも悪い結果に導くでしょう
- 最初にチームに売ります。あなたは彼らの完全なサポートが必要です
- 変更を提案しないでくださいテストを提案してください。そして、それをそのように考えてください。スクラムは組織（またはチーム）に適さない場合があります
- 経営陣のスポンサーを探す
これはほぼ正確に私たちの会社で起こったことです。私たちは厳格で非アジャイルな方法に従いました。 [〜＃〜] scrum [〜＃〜]の経験がある新しいリードテクニカルマネージャーが参加したとき、彼はそれを試してみるのが良いだろうと思いました。
私たちが行った方法は、開発者（およびアナリスト）の小さなグループをパイロットSCRUMチームに参加させることでした。約4か月間、厳密なSCRUM方法論を実行し、その後、会社は私たちが行ったこと、それをどのように行ったかを反映し、データを分析しました（BAが行う必要のあるすべてのことです）。
彼らが発見したのは、パイロットは大成功だったということです。それで彼らはかんばんに続く別のチームを作りました、そして彼らも大成功を収めました。他の開発者もSCRUM /かんばんチームを形成しているという話があると思います。
パイロットは極めて重要だったと思います。これは、ビジネス時間のstrict側を評価して、それが最初に機能することを確認します。
私はアジャイルコーチであり、イニシアチブを変えるための鍵の1つは、すべてのレベルでの賛同です！これには、幹部、開発チーム、マネージャーなどが含まれます。大規模または小規模な変更の取り組みを発表する前に、まずは個人を参加させることをお勧めします。第三者との会話を通じてこれを行うことは、個人が新しいアイデアに取り掛かるための最も簡単な方法です。第三者とは何ですか？ブログ、YouTubeビデオ、プレゼンテーションなど...このようにして、それらの人々は自分のアイデアを思い付き始めることができ、あなたの影響力が変化のイニシアチブに飛び込みます。
ここに私が使用した2つの巧妙なビデオがありますspark=フードチェーンのすべてのレベルでの興味。