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のハンドブックから適応)
初期の決定を簡単に撤回できるようにする
初期の決定を完璧にすることに悩むのではなく、簡単に撤回できるようにしておいてください。小さく出荷することで自然にこれが可能になります—選択の上に構築されるものが少ないほど、考えを変えるコストは安くなります。(意思決定、§12を参照)
締め切りを設定し、範囲を削る、日付を削らない
最初のバージョンがすぐに出荷できない場合、範囲が大きすぎます。日付が危険にさらされている場合、機能を削除してください—日付を動かさないでください。固定された日付に何か実際のものを出荷することで信頼が築かれ、フィードバックの時計が始まります;スライドする日付に完全なものを出荷してもどちらも達成されません。(GitLabのハンドブックから適応)
イテレーションは言い訳ではない
イテレーションが何であるかを明確にするために、それが何でないかを言うことが役立ちます。イテレーションは次のことではありません:品質を下げたり、目標を下げたりすること;ドキュメントを省略したり、セキュリティを妥協したりすること;価値のないものを出荷すること;公開しないリビジョン;計画を省略したり、非現実的な締め切りを課したりする言い訳;他の人があなたの作業を修正することを期待すること。どこに向かっているのかを知っているべきです—イテレーションはそこに到達する方法であり、目的地を持つことの代わりではありません。(GitLabの「イテレーションではないもの」のリストから適応)