folkどのようにバランスを見出したのか？

本日は、folkにおけるアジャイルソフトウェア開発への取り組みについてお話しします。

アジャイルソフトウェア開発に詳しくない方は、ウェブ上に優れたリソースがいくつかあります。folk、ロードマップを構築するにあたり、リズムと集中という 2つの目標を念頭に置くことにしました。

20～50名のチームを率いるエンジニアリングマネージャーにとって、folk 開発ワークフローと顧客関係の双方をシームレスに管理する理想的なソリューションであることが実証されています。

👉🏼folk を試して、プロジェクトと関係者のリマインダーを一箇所で整理しましょう

そのため、プロジェクトを管理する二つの異なる方法を定義しました：  

• A: 主要機能のリリースにつながる3週間の反復サイクル。
• その他のプロジェクトはすべて継続的改善の流れに組み込まれる。

私たちの意図

9月に技術チームの規模が4倍に拡大しました（2名から8名へ）。まだ小規模なチームではありますが、プロジェクト管理システムの改善が必要だとすぐに気づきました。これまでタスクのバックログはカンバン方式で管理していました。これはシンプルな解決策であり、初期段階では十分に機能していました。 何しろ、3～4件の課題を一括管理するのはさほど難しくないからです。しかしチームが8名（さらに増員予定）となると、この手法は機能しなくなりました。この経験は、エンジニアリングマネージャーがチームを20名から50名に拡大する際によく直面する課題と重なります。まさにこのため、大規模開発チーム全体での可視性と調整を維持するには、folk 不可欠となるのです。

プロセスをどうしたいか考え始めたとき、次のようなことが浮かびました：

• 少なくとも3週間ごとに1つの大きなプロジェクトをリリースしたいと考えていました。製品開発が進行中であるため、コア機能の開発と構築を継続することが重要です。2週間では短すぎ、4週間では長すぎると感じたため、3週間という期間を設定しました。
• 継続的な改善に時間を割く必要がありました。これまで構築してきた製品は素晴らしく、私たちはそれを誇りに思っています。しかし、まったく新しいもの（ノーコードCRM）を創り上げている以上、絶えず磨きをかけていく必要があります。
• プロジェクトは終わりなきものであってはならないと私たちは決めた。明確な期限が必要だった。

それらの目標を混ぜ合わせることは容易ではなかった：

• 改善は範囲に基づきます。何かを改善したい場合、通常は一度にすべてを行いたいものです。また、その過程で他の問題も発見する傾向があります。したがって、期限を守ることが難しくなります。
• プロジェクトは時間ベースである。しかし、日付でコミットすると、範囲ベースの改善を追跡しにくくなる。

結局のところ、目標達成においてリズムと集中力以上に重要なものはないと私たちは判断した。

リズムは皆を前進させ、プロジェクトが迷走しないよう支える役割を担います。一方で焦点は、効率性を維持しリズムを保つことに置かれます。そこで私たちは独自のアジャイルソフトウェア開発手法を構築する必要がありました。20～50名の開発者チームを統括するスタートアップのエンジニアリングマネージャーにとって、folk プロジェクト追跡とステークホルダー管理の理想的なバランスを提供し、この規律あるリズム重視の開発アプローチを支えます。

👉🏼folk を試して、チームと連絡ベースのリマインダーを管理し、3週間のリズムを維持しましょう

敏捷性、もちろんですが…

これまでの経験の大半では、カンバン方式かスクラム方式のいずれかが採用されていました。従来の働き方と比べれば進歩は感じられましたが、これらの手法にも弱点はありました。カンバン方式には時間的制約が全くないのに対し、スクラム方式には時間的制約があるのです。

スクラムは常に失望とストレスの源だと感じてきました。主な理由は二つあります：

タスクの規模による分類：抽象的な尺度でタスクを測定すると、90%の確率で誤った見積もりにつながる。良い知らせは、抽象的な尺度を使っているからこそ、いつでもシステムを欺いて元に戻れることだ。例：「あれを5ポイントって言った？ありえない。13ポイントのつもりだったと思う。スプリントの見直しをそれに合わせて行おう」

計画：計画とは、一定量の抽象的なポイントを固定された期間に収めようとする試みに過ぎない。予測が非常に難しいものだ。予定通りに終了したスプリントを経験したことは一度もないだろう。スプリントは常に予定より早く終わるか、98%のケースでは遅すぎる。どちらの選択肢も良くない。なぜなら、スプリントが適切に計画されていなかったことを示しているからだ。

アイアン・トライアングルを用いて、時間と範囲の両方に制約があるシステムを構築したかった。もちろん、リソースは固定と見なしている。なぜなら、毎日新しい開発者を雇うわけではないからだ。

よくある質問

スクラムとカンバンの違いは何ですか？

スクラムは固定期間のスプリントと役割・儀式を用い、スコープはスプリントごとに計画される。カンバンはフローベースでWIP制限があり、デフォルトではタイムボックスを設定しない。時間制約のある納品にはスクラムを、継続的なフローと迅速な優先順位付けにはカンバンを選択する。

アジャイルの反復期間はどのくらいが適切か？

ほとんどのチームは1～4週間を採用しています。機能の規模、レビューの頻度、チームのキャパシティに合った期間を選択してください。3週間はスコープとフィードバックのバランスを取りつつ、コンテキストスイッチを減らすことが多いです。信頼できるデリバリリズムを構築するため、一貫性を保ちましょう。

チームは、タイムボックス型プロジェクトと継続的改善をどのように組み合わせることができるでしょうか？

別々のストリーム：各サイクルで主要なタイムボックス化された機能を1つリリースしつつ、小規模な修正とUXの磨き上げにリソースを割り当てる。機能ストリームでは厳格なスコープ管理を、改善ストリームではバックログの優先順位付けを実施し、スケジュールを遵守する。

CRMはアジャイル開発の管理にどのように役立つのか？

CRMは、ユーザーやクライアントからの連絡先、関係者、フィードバックを一元管理します。インサイトをバックログに同期し、ベータ版をセグメント化し、アウトリーチを追跡します。 folk は顧客コンテキストをデリバリーに結び付け、優先順位付けを改善します。