Shape Up: Stop Running in Circles and Ship Work that Matters

Ryan Singer bekerja hampir dua dekade di Basecamp, salah satu perusahaan software yang dikenal luas karena keteguhannya menjaga tim tetap kecil, meski produknya dipakai jutaan orang.

Selama itu, dia menyaksikan satu pola yang menurutnya jadi akar penyakit di hampir semua tim software yang menerapkan Scrum atau Agile versi standar: proyek yang terus-menerus molor, backlog yang membengkak tanpa henti, dan tim yang merasa terus berlari tapi tidak pernah benar-benar sampai ke mana pun.

Basecamp memutuskan berhenti mengikuti resep standar itu. Mereka membangun metode sendiri dari nol, disesuaikan dengan cara kerja tim kecil yang tetap ingin bergerak cepat tanpa kehilangan kendali.

Singer menuliskan metode itu jadi buku yang awalnya dibagikan gratis secara online, sebelum akhirnya diterbitkan secara resmi karena permintaan yang terus mengalir dari berbagai tim di luar Basecamp yang ingin mencobanya sendiri.

Perbedaan paling mendasar dari metode ini, alih-alih bertanya "berapa lama waktu yang dibutuhkan untuk mengerjakan ide ini", tim Basecamp bertanya sesuatu yang jauh lebih tajam, "berapa banyak waktu yang mau kita korbankan untuk ide ini, dan seberapa berharga ide ini dibanding waktu sebesar itu".

Pertanyaan itu mengubah total cara mereka merencanakan, membangun, dan mengirim produk.

Bagian 1: Shaping, Menyiapkan Ide Sebelum Diserahkan ke Tim

Di kebanyakan tim, ide mentah langsung dilempar ke developer sebagai tiket backlog, lalu developer diminta memberi estimasi waktu pengerjaannya.

Singer bilang, urutan ini terbalik, dan jadi sumber banyak masalah.

Level Abstraksi yang Tepat, Tidak Terlalu Kasar, Tidak Terlalu Detail

Shaping adalah proses menyiapkan ide mentah menjadi proyek yang siap dikerjakan, dilakukan oleh kelompok kecil senior yang bekerja paralel dengan tim yang sedang menjalankan cycle. Mereka mendefinisikan elemen-elemen kunci solusi sebelum sebuah proyek dianggap siap untuk "dipertaruhkan" ke satu cycle penuh.

Proyek yang sudah di-shape harus cukup konkret sehingga tim tahu apa yang harus dikerjakan, tapi tetap cukup abstrak sehingga tim masih punya ruang untuk menyelesaikan detail-detail menarik sendiri, mirip wireframe tingkat tinggi, bukan spesifikasi teknis yang sudah dikunci sepenuhnya.

Shaping pada dasarnya adalah kerja desain, meski Anda tidak harus jadi programmer untuk melakukannya, Anda tetap harus cukup melek teknis untuk menilai mana yang mudah dan mana yang sulit diimplementasikan.

Bagian 2: Appetite, Kenapa "Berapa Lama Ini Akan Selesai" Adalah Pertanyaan yang Salah

Estimasi tradisional bertanya, "berapa lama waktu yang dibutuhkan untuk menyelesaikan ini". Singer mengubah total arah pertanyaan ini.

Menetapkan Nilai Sebelum Menentukan Ruang Lingkup

Alih-alih bertanya berapa lama sesuatu akan memakan waktu, Basecamp bertanya, berapa banyak waktu yang mau mereka investasikan untuk ide ini, dan seberapa berharga ide itu dibanding waktu sebesar itu. Ini yang mereka sebut appetite, batasan waktu yang ditetapkan lebih dulu, bukan hasil kalkulasi mundur dari scope yang sudah dirancang detail.

Appetite yang sudah ditetapkan ini kemudian membentuk seberapa besar dan seberapa detail solusi yang dirancang saat shaping, bukan sebaliknya. Kalau appetite-nya cuma enam minggu untuk tim kecil, solusi yang dirancang harus disesuaikan supaya realistis diselesaikan dalam waktu itu, bukan dipaksakan lewat lembur atau penambahan orang di tengah jalan.

Pendekatan ini membalik logika perencanaan tradisional, waktu jadi konstanta yang tetap, sementara scope jadi variabel yang fleksibel menyesuaikan waktu itu, bukan sebaliknya.

Bagian 3: Betting Table, Kenapa Tidak Ada Backlog di Basecamp

Kebanyakan tim menumpuk semua ide di backlog yang terus membengkak, berharap suatu hari nanti sempat dikerjakan.

Basecamp menolak model ini sepenuhnya.

Memilih untuk Bertaruh, Bukan Menjejalkan Semua ke Antrean

Sebelum setiap cycle enam minggu dimulai, para stakeholder senior duduk bersama di apa yang disebut betting table, untuk memutuskan proyek mana yang akan dikerjakan di cycle berikutnya, dari kumpulan pitch yang sudah di-shape di cycle sebelumnya.

Kalau sebuah pitch tidak dipilih, itu bukan berarti masuk antrean untuk cycle berikutnya secara otomatis. Ide itu dibiarkan begitu saja, tidak perlu dilacak atau dipertahankan. Kalau ide itu masih relevan nanti, seseorang bisa dengan sengaja menghidupkannya lagi dan mengajukannya ulang di betting table berikutnya.

Filosofi di balik ini, backlog yang terus menumpuk justru menciptakan beban psikologis dan false hope bagi tim, seolah semua ide itu suatu hari pasti akan dikerjakan, padahal kenyataannya sebagian besar ide lama sudah tidak relevan lagi begitu waktunya tiba.

Bagian 4: Cycle Enam Minggu dengan Circuit Breaker yang Tidak Bisa Ditawar

Kenapa enam minggu, bukan dua minggu seperti sprint pada umumnya, atau tiga bulan seperti kuartal biasa?

Singer menjelaskan, enam minggu adalah titik keseimbangan, cukup panjang untuk membangun sesuatu yang bermakna dari awal sampai akhir, tapi cukup pendek sehingga semua orang bisa merasakan tenggat waktu itu mendekat sejak awal cycle dimulai.

Circuit Breaker, Batas yang Tidak Bisa Dilanggar

Setiap cycle diikuti dua minggu masa cooldown, waktu tanpa proyek terjadwal untuk membersihkan bug, bereksperimen bebas, atau sekadar istirahat sebelum cycle berikutnya dimulai.

Bagian paling tegas dari sistem ini adalah "circuit breaker", tim harus mengirim pekerjaan dalam batas waktu yang sudah disepakati di awal. Kalau tidak selesai, proyek itu secara default tidak mendapat perpanjangan waktu otomatis. Ini menghilangkan risiko proyek yang terus molor tanpa batas, karena appetite sudah ditetapkan jelas sejak awal, dan akan terasa bodoh menghabiskan waktu dua, tiga, bahkan sepuluh kali lipat dari nilai yang sepadan dengan ide itu.

Kalau proyek benar-benar butuh lebih banyak waktu, tim harus secara sadar memakai jalur shaping baru di cycle berikutnya untuk mencari solusi yang lebih baik, bukan otomatis memperpanjang cycle yang sedang berjalan.

Bagian 5: Tim Kecil yang Terintegrasi, Tanpa Rapat Harian dan Tanpa Micromanaging

Selama cycle berjalan, Basecamp secara sengaja menghindari praktik-praktik yang umum di banyak tim agile lainnya.

Melepaskan Kontrol Mikro, Mempercayakan Tim Sepenuhnya

Keputusan-keputusan tim Basecamp didasarkan pada memajukan produk dalam enam minggu ke depan, bukan mengatur waktu secara mikro. Mereka tidak menghitung jam kerja atau mempertanyakan bagaimana hari-hari individu dihabiskan. Tidak ada rapat harian wajib. Tidak ada evaluasi ulang roadmap setiap dua minggu.

Sekali sebuah proyek dipertaruhkan di betting table, tim yang mengerjakannya dibiarkan bekerja secara mandiri selama enam minggu, dipercaya penuh untuk menyelesaikan pekerjaan tanpa pengawasan berlebihan dari manajemen di atasnya.

Untuk memantau progres tanpa micromanaging, Basecamp memakai alat visual sederhana yang mereka sebut hill chart, merepresentasikan proyek sebagai bukit dengan dua sisi, sisi menanjak untuk fase menemukan solusi yang masih penuh ketidakpastian, dan sisi menurun untuk fase eksekusi yang sudah jelas jalannya. Ini memberi gambaran progres yang lebih jujur dibanding sekadar persentase penyelesaian tugas.

Pelajaran untuk Hari Ini

1. Tentukan Appetite Sebelum Merancang Solusi Detail Alih-alih bertanya berapa lama sesuatu akan selesai, tanyakan dulu berapa banyak waktu yang layak diinvestasikan untuk ide itu, lalu sesuaikan solusinya dengan batasan waktu tersebut.

2. Berhenti Menumpuk Semua Ide di Backlog Abadi Pertimbangkan membiarkan ide yang tidak dipilih untuk sementara waktu memudar, alih-alih terus dilacak dan menciptakan beban psikologis yang tidak perlu bagi tim.

3. Tetapkan Circuit Breaker yang Tegas untuk Setiap Proyek Jangan biarkan proyek terus diperpanjang tanpa batas. Kalau waktu yang disepakati habis, evaluasi ulang secara sadar, bukan otomatis menambah waktu tanpa pertimbangan.

4. Percayakan Tim untuk Bekerja Mandiri Selama Periode yang Disepakati Kurangi rapat harian dan pengawasan mikro. Gunakan alat visual sederhana untuk memantau progres tanpa harus mengintervensi keputusan kerja sehari-hari tim.

Penutup

Shape Up lahir bukan dari teori akademis, melainkan dari pengalaman nyata bertahun-tahun Basecamp mencoba berbagai pendekatan, gagal di beberapa titik, dan akhirnya menemukan sistem yang benar-benar cocok dengan cara kerja tim kecil yang ingin tetap gesit tanpa kehilangan kendali atas waktu dan scope proyeknya.

Yang membuat buku ini menarik bagi banyak pembaca, Singer secara terbuka memposisikan metode ini sebagai kontras terhadap Scrum dan Agile konvensional, meski sebagian pengamat mencatat beberapa elemen di dalamnya, seperti shaping, sebenarnya punya kemiripan dengan refinement atau grooming pada praktik agile yang sudah ada, hanya dengan istilah dan penekanan yang berbeda.

Di tengah semakin banyaknya tim yang merasa lelah dengan siklus sprint tanpa akhir dan backlog yang terus membengkak, pendekatan appetite-driven dan circuit breaker yang ditawarkan Shape Up jadi alternatif yang menarik dipertimbangkan, terutama bagi tim kecil yang ingin bergerak cepat tanpa kehilangan fokus pada apa yang benar-benar penting untuk dikirim.

Pertanyaan untuk Anda, dari semua proyek yang sedang berjalan di tim Anda sekarang, adakah yang sebenarnya sudah melebihi jauh dari nilai yang sepadan dengan waktu yang sudah dihabiskan untuknya?

Tentang Buku Asli