Rusfinance Bankの事例：SCRUMをオンラインでどのように翻訳したかとその結果

Rusfinance Bankは、国際的なグループSociétéGénéraleの一部であるロシアの自動車ローンのリーダーです（Frank RGによる）。さまざまな国の経験を見て、フランスだけでなく世界中の同僚が使用しているツールを適用することができます。一方、私たちにとって、新しいIT製品、サービス、さらには機能の開発と立ち上げは常にあります。さまざまなレベルのプロジェクト承認に関連するものを含む、課題。



かつて、市場投入までの時間を短縮するために、さまざまなアジャイルプラクティスを実装しようと試みました。予想通り、それらの中で最も実行可能なものはSCRUMでした。



2020年の初めに、SCRUMのスケーリングを開始し、LeSSフレームワークを研究し、オフラインの対話プロセスを構築しましたが、パンデミックは独自の調整を行いました。3月に、リモート作業形式に移行しました。私は緊急にすべてを再構築しなければなりませんでした。



カットの下で、私たちが解決しなければならなかったタスク、SCRUMおよびLeSSツールがこれにどのように役立ったか、そして何が起こったのかについて説明します。

オフライン販売の減少

もちろん、パンデミックは業績に影響を及ぼしました。お客さまがクレジットで車を買いに来てくださった販売店が閉店し、売上が減少しました。



しかし、心配する時間はありませんでした。ビジネスを構築し、パートナーを支援するために、クライアントとのやり取りをオンラインで転送しました。

1日でオンラインになりますか？

当初（今回は「パンデミックの前」と呼びましょう）、チーム全体が一緒に座り、タスクを備えた物理的なボードが壁に掛けられ、計画と回顧が「密室」のオフィスで行われました。 AGILEマニフェストとSCRUMガイドに従おうとしました。



しかし、時間が経つにつれて、チームは成長し始めました。私たちのモスクワ開発チームには、サマラの人たちが加わりました。これにより、確立された世界にいくつかの調整が加えられ、回避策の発明が推進されました。そのため、ビデオ会議とSkype for Businessをより頻繁に使用するようになり、毎日、物理的なボードの近くにWebサイトを配置しました。しかし、チームがモスクワとサマラの間に分散しているという事実にもかかわらず、実際にはオフラインのままでした。



私たちは、目に見えて仕事に役立つ相互作用のルール（たとえば、計画、毎日、グルーミング、レトロのルール）を切る機会がありました。誰もがそれらに注意を払うことができました。



これはオンラインでは当てはまらず、ベストプラクティス/ツールを使用するための他のアプローチを探す必要がありました。

ITはまったくFlexではありません

これはそれほど簡単なプロセスではないことが判明しました。銀行はフレックスオフィスへの移行に積極的かつ長い間取り組んできました。これにより、大多数が苦痛なくオンラインに接続できるようになりました。しかし、ITは別の世界です。13インチの薄いウルトラブックを持ってカフェで仕事をするのは難しいので、強力で生産性の高いコンピューター、大型の斜めモニター、できれば少なくとも2台が必要です。



サーバーにリモート接続する機能について何が言えますか？どの銀行の情報セキュリティも非常に重要ですが、これには追加の承認、設定、暗号化の使用などが必要です。



そしてもちろん、人的要因は省略できません。はい、ITプロフェッショナルは黙って座るのが大好きです。彼らのほとんどは、快適な環境に座って自宅で仕事ができることを喜んでいましたが、個人的なコミュニケーションは非常に不足しています。以前はSkypeを介した通信の形式で同僚といくつかの単語を交換することで簡単に解決できた質問でしたが、Slackは解決がより困難になりました。



たとえば、送信して発言権を取得する方法、非常に多くの参加者との会話をモデレートする方法などです。オフラインでは、これは有機的に起こりました。誰もがお互いを見たので、オンラインでは、私たちは即座にすべての非言語を失いました。



モデレートの問題を解決するために、次のことを提案しました。各従業員が交代で（2日間）デイリースクラムのリーダーになりました。したがって、誰もが「反対側から」のコミュニケーションの複雑さを感じ、すべての参加者が快適に感じるようにオンラインディスカッションでどのように行動するのが最善かを理解することができます。



さらに、「沈黙」の問題を解決しました。チーム全体に向けられた質問に誰が答えるべきかが明確でない場合（チームは、そのような状況で間違いなく不快感に直面した新入社員の50％以上で構成されていました）。この場合、モデレーターは参加者の1人に名前で呼びかけ、意見を求めました。このように、「老人」は決断を下す際に自分たちを覆い隠すことはなく、新入社員は快適に話すことができました。



逆もまた同様です。私たちは、長引くトピック外の議論を止める「ストップワード」を提案しました。誰かが「ファラフェル」と言ったら、全員が黙って、さらに個別の議論が必要な問題を保留し、会議のトピックに戻る必要があります。

 

「フルオンライン」へのスムーズな移行

「フルオンライン」への移行は非常にスムーズに始まりました。最初は、オンラインで対面したままのすべての会議（計画、毎日、グルーミング、スプリントレビュー、回顧）を行いました。すべての通信はSkypefor Businessを介して行われました（幸い、それはずっと前に銀行で導入されました）。







次の質問は、物理的なボードをどうするかでした。私たちはすぐに、JIRAを使用すると、同様の視覚化を備えたオンラインホワイトボードを簡単に作成できると判断しました。製品バックログとスプリントバックログを維持するために長い間JIRAを使用してきたため、この決定は表面的なものでした。一般的な便宜のために、プレゼンターはWIPからDONEへのステッカーの転送を引き継ぎました。DONEはSkype forBusinessでボードをブロードキャストします。

振り返り

最も難しいのは、おそらく、オンラインの回顧録に翻訳されることが判明した。パンデミック前の世界では、回顧展を開催することは完全な儀式でした-準備された演習、描かれたフリップ、購入したドーナツ/ピザ/お菓子-想像の余地がたくさんありました。チームの健康と友好を保つために、あらゆることを使用しようとしました。したがって、オンラインに切り替えると、そのようなSCRUMイベント用のツールはそれほど多くないことがわかりました。 IdeaBoardz、Miro、Mural、FunRetroなどの多くのツールを試しました。







その結果、TeamRetroに落ち着きました。これは、レトロな結果をメールまたはSlackの目的のチャネルに送信したり、他のチップや「グッズ」と一緒に送信したりできる便利なプラットフォームです。機能は他の多くのプラットフォームと非常に似ていますが、ポイントは、投票の実行、カードの準備、自動グループ化のメカニズムなど、作業を大幅に簡素化するニュアンスにあります。一般的に、私たちはそれが好きでした。

パートナーとのコミュニケーション

ちなみに、Slackについて：「フルオンライン」への移行に伴い、このコミュニケーションチャネルは私たちにとってセカンドライフを見つけました。パートナーを接続して問題について話し合い、迅速に解決したり、LeSS内の1つの製品で協力している他のチームと連携したり、ビジネスの問題と開発の問題や環境が混ざらないようにチャネル構造を修正しました。



また、パートナーとの対話ツールを探す必要がありました。Trello（パートナー側のバグと改善を分析するため）、Slack（運用上の対話と24時間年中無休の質問への回答）、ZOOM、Skype（会議用）。



パートナー/請負業者側のすべての改善とバグは、ステータスを監視するためにTrelloに追加されます。 「新規」、「進行中」、「完了」、「テスト」、「製品を待機中」、「製品」、「完了（削除する必要はありません）」、「保留」の8つの列があります。これらのステータスを使用すると、タスクが現在どこにあるかを追跡したり、新しいインシデントを迅速に通知したりできます。私たちとパートナーの両方がTrelloにアクセスできます。ステータスが変更された場合は、通知がメールに送信されます。



オンラインへの移行に伴い、ビジネスアナリストが情報を収集することがより困難になっています。 Skypeの会議を手配するのは必ずしも簡単ではなく、郵送による連絡には時間がかかりすぎました。その結果、データを取得するプロセスの効率が低下し、オフラインよりも時間がかかり始めました。



エンドユーザー、お客様（この場合は自動車ディーラー）との定期的なZoomおよびSkype会議を紹介する必要がありました。彼らは私たちのコンピューター画面をいじくり回し、彼らの問題が何であるかを明確に説明しました。受け取った説明に基づいて、ビジネスアナリストは結論を導き出し、ビジネスプロセスを構築しました。

オンライン開発とチームへの分割

オンラインにするときは、製品バックログとスプリントバックログのストーリーを明確に分ける必要がありました。そのため、歴史のある作品を「発見」「納品」「生産中」のフェーズに分けることにしました。







これは、スプリントで実行される検出フェーズの例です。この段階の結果に基づいて、「配信」に進むか、アイデアを実現しないままにするかが決定されます。

スケーラブルSCRUM（LeSS）には、1つの製品、つまり自動車ローンサービスに関する複数のチームの調整された作業が必要です。仮説をテストし、非常に多くの機能を開発および最適化することは、1つのチームの努力では不可能です。パンデミック中に4つのスクラムチームが実際にオンラインで結成されましたが、それもまた別の話です。



すべてのチームがカーローン製品に取り組んでいます。オンラインアプリケーションはその機能の1つです。チームは、アプリケーションの受信とクレジットトランザクションの処理のためのソフトウェア/ CRMパートナーとの統合のためのAPIの開発、クライアント向けの新しいサービスとサービスの開発と実装（たとえば、「CASCOオンラインの延長」、「オンライン貸付の割引率」）、外部システムとの統合に取り組んでいます。たとえば、ESIAサービスを使用して、クライアントがデータを入力するプロセスを最適化するため。すべてのタスクは、アプリケーションファネルを増やし、アプリケーションをローンに変換することを目的としています。チームには共通の商用KPIがあるため、誰もが結果をもたらすことを行うことに関心があります。







チームは、新機能とプロセスの改善に取り組んでいるだけでなく、「販売」と「テスト」の両方のバグを修正して、すでに実装されている改善に絶えず変更を加えています。

 

3か月以上のオンライン結果

テスト

テストチームでは、オンラインサービスの開発ペースが速まったため、優先順位がタスクに移りました。この点で、パンデミックの開始時に、小さなラッシュが発生しましたが、その後、負荷は横ばいになりました。



一般的に、パンデミックの間、タスクの数は大幅に変化しませんでしたが、1日を通して負荷を分散することが可能になりました。たとえば、休憩時間を長くして作業日を延長します。

開発

パフォーマンスを評価することは非常に困難でした。当初、開発チームには5人しかいませんでした。より正確には、1人の参加者が管理上の問題で部分的にロードされていたので、4年半でさえ。



3か月で、さらに5人を採用しました。したがって、チームメンバーの数の増加と、トレーニング、適応、新しい条件への没頭に費やした時間の両方を考慮して、「前」と「後」の結果の比較を行う必要があります。



しかし、スプリントの目標を達成するという優れた指標があります。以前（6月より前のいつか）、計画された3つの目標のうち1つだけにうまく対処し、7月には90％に達しました。



もう1つの重要な指標は、技術的負債のカバーに関連する問題の解決です。リファクタリング、次善の実装の修正などです。チームが過負荷の場合、これを割り当てる時間はなく、すべてがバックバーナーに置かれます。



過去1か月半から2か月の間に、私たちはそのような多くの問題を解決することができました。多くの場所でレガシーを放棄し、新しいテクノロジー（Reactなど）を使用して何かを完全に書き直すことさえできました。







パンデミックの前の5か月で、146のストーリー/タスク/バグを作成しました。3か月間、198のストーリー/タスク/バグが個別に作成されました。オンラインへの移行により、チームは効率を失うだけでなく、逆に、さらに集中して生産的になりました。