Embracing Small Iterations
At the core of our work philosophy lies a commitment to small iterations. Instead of undertaking large-scale overhauls, focus on making incremental improvements one step at a time. Short iterations mean quicker feedback, faster delivery of value, and continuous improvement.
Minimum Viable Change (MVC)
Strive to implement the swiftest change possible that improves the outcome. Don’t wait for a polished solution; if your idea is an improvement, act on it. When proposing changes that aren’t essential for the first iteration, create a separate issue for them. Avoid drafting extensive plans; focus on outlining the initial step. You’ll know you’re on the right track if the first iteration feels slightly unpolished. More often than not, the simplest version proves to be the most effective.
An Iteration Ships. A Revision Doesn’t.
This is the most common misunderstanding. Changing something without putting it in front of anyone — refining a document, polishing a prototype, improving a plan — is a revision, not an iteration. You only learn when the work reaches someone who can react to it: an internal user, a stakeholder, a customer, a search engine. If nothing shipped, nothing was iterated. By the same logic, moving through internal stages — experiment to prototype to staging to demo — is one release, not several iterations. Milestones on a roadmap are not iterations either. The test is always the same: did someone outside the work see it and react?
Publish Early So Others Can Build on It
There’s a second reason to ship early that has nothing to do with feedback: a published artifact is what lets a team work in parallel. Once a first version exists — one real page, one working report, one live process — one person can improve how it’s produced, another how it looks, another the content itself, and everyone’s changes land on the same thing where we can see them fit together. When work stays split into private fragments, nobody discovers whether the fragments fit until the end. Publish the smallest real thing, then improve it together.
Low Level of Shame
Publishing early means publishing unpolished, and that takes practice. In many workplaces you take a risk showing work that isn’t finished, so people learn to hide work until it’s perfect — and by the time it appears, it’s too late to course-correct cheaply. Here, showing rough work early is a strength, not an embarrassment. If someone asks why something isn’t polished, the answer is simple: it’s an iteration, it took X hours, and the next version arrives on Y. When a teammate ships something rough and early, that’s the behavior to praise. (Adapted from GitLab’s handbook.)
Deliver one before starting another
Keep ongoing concurrent work to a minimum, ideally one, at most a handful. Working on too many things at a time erodes the focus, attention and depth that any of those items can humanly be dealt with. Starting new tasks before completing an ongoing one creates the illusion of moving fast, but it ultimately slows down both of them. Setting expectations and communicating early, clearly and openly reduces the anxiety around pending tasks.
Keep Early Decisions Easy to Walk Back
Don’t agonize over getting early decisions perfect; keep them easy to walk back instead. Shipping small does this naturally — the less that’s built on top of a choice, the cheaper it is to change your mind. (See Decision Making, §12.)
Set a Due Date; Cut Scope, Not the Date
If a first version can’t ship soon, the scope is too big. When a date is at risk, remove features — don’t move the date. Something real on a fixed date builds trust and starts the feedback clock; something complete on a sliding date does neither. (Adapted from GitLab’s handbook.)
Iteration Is Not an Excuse
To be clear about what iteration is, it helps to say what it isn’t. Iteration is not: reducing quality or lowering the goalposts; skipping documentation or compromising on security; shipping something of no value; revisions you never publish; an excuse to skip planning or impose unrealistic deadlines; or expecting others to fix your work. You should still know where you’re going — iteration is how you get there, not a substitute for having a destination. (Adapted from GitLab’s list of “things that are not iteration.”)
小さな反復を受け入れる
私たちの仕事の哲学の中心には、小さな反復へのコミットメントがあります。大規模なオーバーホールを行うのではなく、一歩ずつ漸進的な改善を目指します。短い反復は、迅速なフィードバック、価値の早期提供、継続的な改善を意味します。
最小限の実行可能な変更(MVC)
結果を改善するために、可能な限り迅速な変更を実施することを目指します。洗練された解決策を待たずに、アイデアが改善であるならば、それを実行してください。最初の反復に必須でない変更を提案する場合は、それらのために別の課題を作成してください。広範な計画を立てるのではなく、初めの一歩を概説することに集中してください。最初の反復が少し未完成に感じられるなら、正しい道を進んでいる証拠です。多くの場合、最もシンプルなバージョンが最も効果的であることが証明されます。
反復は出荷される。改訂はされない。
これは最も一般的な誤解です。誰にも見せずに何かを変更すること—文書を洗練する、プロトタイプを磨く、計画を改善する—は改訂であり、反復ではありません。作業が誰かに届き、反応を得ることで初めて学ぶことができます:内部ユーザー、ステークホルダー、顧客、検索エンジンなどです。何も出荷されなければ、何も反復されていません。同じ論理で、内部段階を通過すること—実験からプロトタイプ、ステージング、デモへ—は1つのリリースであり、複数の反復ではありません。ロードマップ上のマイルストーンも反復ではありません。テストは常に同じです:作業外の誰かがそれを見て反応したかどうかです。
早期に公開し、他の人がそれを基に構築できるようにする
早期に出荷する理由にはフィードバックとは関係のない第二の理由があります:公開された成果物がチームが並行して作業することを可能にします。最初のバージョンが存在する—1つの実際のページ、1つの動作するレポート、1つのライブプロセス—と、1人がその生産方法を改善し、別の人がその見た目を改善し、さらに別の人がその内容自体を改善し、全員の変更が同じものに着地し、それらがどのように組み合わさるかを見ることができます。作業がプライベートな断片に分かれたままだと、断片が合うかどうかは最後まで誰も発見できません。最小限の実際のものを公開し、それを一緒に改善してください。
恥のレベルを低く保つ
早期に公開することは未完成のものを公開することを意味し、それには練習が必要です。多くの職場では、未完成の作業を見せることはリスクを伴うため、人々は完璧になるまで作業を隠すことを学びます—そしてそれが現れる頃には、安価に軌道修正するには遅すぎます。ここでは、粗い作業を早期に見せることは強みであり、恥ではありません。誰かがなぜそれが洗練されていないのかを尋ねたら、答えは簡単です:それは反復であり、X時間かかり、次のバージョンはYに到着します。チームメイトが粗く早期に何かを出荷したとき、それは称賛すべき行動です。(GitLabのハンドブックから適応)
1つを完了してから次を始める
同時進行の作業を最小限に抑え、理想的には1つ、多くても数個にしてください。多くのことを同時に進めると、それらの項目に対して人間的に対処できる集中力、注意力、深さが損なわれます。進行中の作業を完了する前に新しいタスクを始めると、速く進んでいるという錯覚を生みますが、最終的には両方を遅らせます。期待を設定し、早期に、明確に、オープンにコミュニケーションを取ることで、未完了のタスクに対する不安を軽減します。
初期の決定を簡単に撤回できるようにする
初期の決定を完璧にすることに悩むのではなく、簡単に撤回できるようにしてください。小さく出荷することで自然にこれが実現します—選択の上に構築されるものが少ないほど、考えを変えるコストが安くなります。(意思決定、§12を参照)
締め切りを設定し、範囲を削る、日付を削らない
最初のバージョンがすぐに出荷できない場合、範囲が大きすぎます。日付が危険にさらされている場合、機能を削除してください—日付を動かさないでください。固定された日付に何か現実的なものがあると信頼が築かれ、フィードバックの時計が始まります;スライドする日付に完全なものがあるとどちらもありません。(GitLabのハンドブックから適応)
反復は言い訳ではない
反復が何であるかを明確にするためには、それが何でないかを言うことが役立ちます。反復は次のことではありません:品質を下げることや目標を下げること;文書化を省略することやセキュリティを妥協すること;価値のないものを出荷すること;公開しない改訂;計画を省略する言い訳や非現実的な締め切りを課すこと;他の人があなたの作業を修正することを期待すること。どこに向かっているのかを知っているべきです—反復はそこに到達する方法であり、目的地を持つことの代わりではありません。(GitLabの「反復ではないもの」のリストから適応)