アジャイルへの旅：Brazeがソフトウェアプロジェクト管理プロセスをどのように再考したか

計画を立てる

少し考えた後、エンジニアリングチーム向けの実証済みの方法論に移行することを決定しました。つまり、よりアジャイルになりたいと考えました。

この新しい課題に取り組むために、製品およびエンジニアリング組織全体の知識を代表して活用するグループを編成したかったので、製品管理、設計、およびエンジニアリングを代表する8人のメンバーで構成される委員会を作成しました。 マネージャーと個人の貢献者の両方、およびさまざまなレベルのアジャイルのバックグラウンド、年功序列、および経験を持つ人々を含めました。

このアジャイル委員会は、私たちが吹き替えたように、いくつかの重要な原則をしっかりと念頭に置いて状況に取り組みました。

• 方法論とソフトウェアの両方で、可能な限り実績のあるソリューションを使用したいと考えました。 ユニークになるには多くの努力が必要であり、私たちは必要かつ戦略的な分野でのみユニークになりたかったのです。 また、人々が自分の仕事の管理に関するGoogleのベストプラクティスを利用できるようにしたかったのです。あるいは、もっと良いことに、人々にすでにほとんどの方法を知っているBrazeに参加してもらいたいと思いました。
• 同じ言語を話すことができることは価値があるため、Braze全体の製品エンジニアリングチームの運用方法にほぼ一貫性を持たせたいと考えました。
• 私たちは独断的に、またはそれを考え抜かずに何もしたくありませんでした。 方法を選んで本を読むだけでは十分ではありませんでした。 常識と思慮深い反復がその日を支配することは私たちにとって重要でした。

これらのガイドラインを武器に、多くの組織で効果的であることが証明されているアジャイルフレームワークであるスクラムを使用することにしました。 これは広く知られており、スケーラブルであり、アジャイルプロセスの実装を検討している場合は安全でデフォルトの選択肢です。

次に、2つの主要な決定に直面しました。（1）新しいプロセスをサポートするために使用するツールと、（2）プロセスへの変更をどのように展開するかです。 私たちはいくつかのソフトウェアについて話し合い、評価し、デモを行いました。最終的には、AtlassianのJiraが私たちにとって正しい選択であることがわかりました。 これは十分に実証されたソリューションであり、私たちのチームの何人かの人々はすでにそれを使用した経験があり、Braze内の他のチームはすでにそれを使用しており、私たち全員が1つのシステム内で作業するため、チーム間のコラボレーションを改善する機会が開かれます。

アジャイルの展開計画を選択する際には、いくつかの重要な決定を行う必要がありました。 まず、チームをどのようにトレーニング/有効化しますか？ アジャイルコーチを雇ったり、チームでの経験を持つ人々に他の人を訓練する仕事をさせたり、コンサルタントに手伝ってもらったりすることができます。 次に、アジャイルの経験があるエンジニアリング内のチームに、トレーニングを待ってから実装する必要がありますか？

最終的に、JiraとScrumに精通しているチームが可能な範囲で開始できるようにすることを決定し、組織全体の移行を支援するコンサルタントを雇いました。 私たちは、チームのメンバーや独立したプレーヤーが、移行を通じてチームメンバーを指導する主な責任を負うことに興味がありませんでした。理由は次のとおりです。

• アジャイルのやり方を個々のチームに持たせたくなかったので、サードパーティからの提案であれば、トレーニングの受け方が良くなり、提案がより包括的になると感じました。
• コンサルティングビジネスは、個々のアジャイルコーチよりも安定していて信頼できると考えました
• 私たちは、エンジニアリング組織全体の基本的なトレーニングを行い、組織の個々のメンバーがアジャイルの周りに持っている知識について何も仮定せずに開始したいと考えていました。
• 最後に、組織内の全員が今後のプロセスを維持する責任があることを明確にするために、コーチを特定の時点で退去させたいと考えました。

計画の実行

数か月の計画の後、私たちがやろうとしていることすべてを詳述した大きな文書があり、それを組織全体と共有してフィードバックを求めました。 次に、いくつかのベンダーを評価した後、アジャイルへの旅で私たちとパートナーを組むためにエリアセンを選択しました。 その旅は、エリアセンによる2日間のアジャイルトレーニングから始まり、エリアセンが私たちとつながった専門家による3か月のアジャイルコーチングが続きました。

最初から、JiraとScrumへの移行にはかなり慎重でした。 インターネットと私たちのチームの個人的な経験はどちらも、過度に独断的なアプローチの危険性、Jiraが「アンチパターン」として機能するようになる方法、およびスクラムが組織でうまくいかない可能性があるすべての方法についての注意話でいっぱいでした。 私たちが相談した人々からは、これらの変更には時間がかかる可能性があり、アジャイルから実際のメリットが得られる前に痛みが増す可能性があることを強く警告されていました。

ありがたいことに、私たちは新しいプロセスにすぐに価値を見出しました。 この移行の良い点の1つは、スクラムの特定の側面を盲目的に追跡するというプレッシャーを感じたことは一度もないことです。 物事をより良く機能させるために、私たちは物事が数週間ごとにどのように進んでいたかを振り返り、次に修正が必要なものを修正します。 そして、3か月のコーチングを通じて、エンジニアリング組織全体に抜本的な変更を実装しました。

• 誰もがユーザーストーリーの書き方、手入れ、指摘、分解、ピックアップの方法を学びました
• 手元の仕事を終えることになると、スタンドアップは新たな焦点を見つけました
• 製品、設計、エンジニアリングはすべて同じ言語を話すことを学び、インターフェースはますますうまく設計されました

結果

この約6か月の取り組みの反対側にいる今、変化は明らかであり、劇的です。 この取り組みにつながった問題が大幅に減少しました。 アジャイルを使用すると、サインオフ、コラボレーション、バックログの作成、およびグルーミングのための明確で理解しやすいメカニズムが得られ、何を改善するかについて定期的に回顧展を実施します。

また、設計アーティファクトの場所が大幅に一貫しているだけでなく、特定のプロジェクトで実際に「完了」したことについての期待も一致しています。 他のチームが取り組んでいることを確認するのは簡単になり、人々が一緒にうまく作業する方法を理解するのはこれまでになく簡単になりました。

この移行の最後に気付いたのは、私たちがより多くのことを行い、チームの規模を拡大しているにもかかわらず、組織内のオープンプルリクエストの総数が常に減少していることです。 少しずつ作業を進め、仕上げに集中することで、飛行中のアイテムの数が大幅に減少しました。

私たちの組織での成功は、他の人々にも刺激を与えました。 Brazeの他の部門のチームが独自のアジャイル変換を開始するのを目にし始めているので、すぐに多くの人々が同じ言語を話し、コラボレーションを定義および改善するために必要なツールを手に入れるようになります。

要点

私たちの努力の2つの主要な要素は、その成功を確実にしました。

第一に、それが代表委員会によって推進されたという事実は、エンジニアリング組織の周りから、そしてさまざまな異なる視点からインプットを得るのに不可欠でした。 全社的に、人々は日常業務に影響を与える問題について耳を傾け、代表していると感じました。 その後、チームと共有できるアジャイル移行の動機と計画をまとめた完全なドキュメントを作成することも非常に役立ちました。 意思決定がどのように行われるかを示し、フィードバックの明確なパスを導入することを信じています。これは、コンテキストを提供し、フィードバックを提供するための成果物を確立するためです。

第二に、私たちのチームを指導するために第三者を雇うという決定は不可欠でした。 客観的で経験豊富なパートナーがいることで、プロセスに多くの改善をすばやく行うことができました。 私たちのコーチは、良いものがどのように見えるかを知っていて、偏見なく推奨を行うことができました。何度も、「チームは通常、Xをどのように行うのでしょうか」と尋ねることができました。 すぐに実行可能な解決策を手に入れましょう。 一方、内部リソースを使用した場合、受け取ったフィードバックが偏った当事者からのものであり、既存の責任とのリソース競合が増加するリスクがあります。

他に何か？

当社の製品とその製造にかかる作業についての当社の考え方について詳しく知りたい場合は、BuildingBrazeをご覧ください。 私たちのチームに参加することに興味がありますか？ 現在の求人広告をご覧ください。