Ritme Pengiriman Tanpa Tersandung di Perencanaan

Jumat pukul 16.30. Anda membuka kalender, menghitung blok rapat yang diarsir biru, dan menjumlahkannya. Sembilan jam minggu ini. Sprint planning Senin. Refinement pertengahan sprint Rabu. Retro yang berubah menjadi sesi perencanaan lagi Kamis. Tiga sesi estimasi yang Anda jadwalkan karena tiket belum "siap." Dan tim mengirimkan satu fitur.

Bahkan bukan fitur yang Anda rencanakan. Seorang IC senior di tim Anda memperhatikan sesuatu yang jelas rusak Rabu pagi, membuka PR sebelum makan siang, dan melakukan merge sebelum standup Kamis. Hal yang tidak dirumuskan siapapun, tidak diberi poin oleh siapapun, tidak dimasukkan ke papan oleh siapapun.

Anda berpikir: tim saya mengirimkan sesuatu meskipun ada perencanaan saya, bukan karena itu.

Jika gambaran itu terasa familiar, panduan ini untuk Anda. Saya telah membimbing EM melalui pola yang persis ini, dan solusinya bukan "perencanaan yang lebih baik." Solusinya adalah lebih sedikit perencanaan, disusun secara berbeda, dengan satu sinyal nyata yang benar-benar Anda pantau.

Mengapa Perencanaan Memakan Minggu Anda (dan Tidak Memperbaiki Apa pun)

Hitung matematinya. Enam engineer, perencanaan dua jam setiap dua minggu, ditambah refinement pertengahan sprint satu jam, ditambah retro satu jam. Itu 24 jam-engineer per sprint hanya untuk perencanaan formal. Tambahkan persiapan EM (biasanya 3-4 jam per sprint), persiapan tech lead (2 jam), dan grooming tiket async di Slack threads (tidak terhitung). Anda menghabiskan setara dengan seminggu penuh kerja seorang senior engineer, setiap dua minggu, untuk perencanaan.

Apa yang Anda dapatkan dari itu? Di sebagian besar tim yang pernah saya lihat, Anda mendapatkan estimasi yang meleset 3-4 kali lipat, backlog yang diprioritaskan ulang setiap minggu bagaimanapun juga, dan item tindakan retro yang tidak dimiliki siapapun pada hari Rabu.

Pertanyaan nyatanya bukan "bagaimana kita merencanakan lebih baik?" Melainkan "untuk apa perencanaan sebenarnya?" Sederhanakan. Perencanaan menghasilkan tiga hal yang dibutuhkan tim: daftar pendek apa yang harus dilakukan selanjutnya, pemilik yang jelas, dan pemahaman bersama tentang apa yang berisiko. Selebihnya adalah sandiwara.

Jebakannya adalah upacara perencanaan terasa produktif. Anda keluar ruangan dengan papan sprint yang terisi. Itu terlihat seperti pekerjaan telah selesai. Tapi papan sprint yang terisi tidak mengirimkan kode. IC yang menulis PR yang mengirimkan kode. Setiap jam yang Anda tahan seorang engineer dalam rapat perencanaan adalah satu jam mereka tidak merumuskan masalah atau membuka PR.

Perencanaan sebagai Spike, Bukan Upacara

Inilah cara pandang yang berbeda: perencanaan adalah sebuah spike. Penyelidikan singkat dan terfokus dengan input dan output yang jelas. Bukan upacara berulang. Bukan blok kalender yang ditakuti.

Satu jam. Sekali seminggu. Seluruh tim opsional, EM dan tech lead wajib.

Contoh agenda yang pernah saya gunakan dengan tiga tim berbeda:

• 0-10 menit, apa yang dikirimkan, apa yang tidak. Tinjau papan minggu lalu. Tidak ada saling menyalahkan. Hanya status. Jika sesuatu tidak dikirimkan, sebutkan alasannya dalam satu kalimat: "terhambat pada tinjauan," "cakupan lebih besar dari yang kami perkirakan," "terganggu oleh insiden." Selesai.
• 10-25 menit, apa yang terhambat. Apa pun yang sudah tidak bergerak lebih dari 48 jam. Tech lead dan EM membuat keputusan: buka blocker-nya sekarang, hapus, atau eskalasikan. Keputusan, bukan diskusi.
• 25-50 menit, 5-7 tiket berikutnya. Bukan seluruh sprint. Lima hingga tujuh hal berikutnya saja. Untuk masing-masing: pemilik, perkiraan ukuran kasar (kecil/sedang/besar), dan satu risiko yang mungkin meledak. Tanpa story points. Tanpa Fibonacci. Tanpa planning poker.
• 50-60 menit, pertanyaan terbuka. Apa pun yang dikhawatirkan siapapun yang tidak pas di atas. Catat secara tertulis jika tidak bisa diselesaikan dalam 10 menit.

Itulah semuanya. Tim yang saya tangani di organisasi engineering 40 orang memangkas perencanaan dari 8 jam per minggu menjadi 1 jam menggunakan sesuatu yang mendekati ini. Throughput mereka naik, tidak turun, pada bulan pertama.

Bagian paling sulit adalah disiplin untuk meninggalkan ruangan ketika jam habis. Ada pertanyaan terbuka? Catat, bawa offline, putuskan secara async. Jangan perpanjang pertemuan. Pertemuan berakhir tepat satu jam, setiap kali, atau semuanya runtuh kembali menjadi upacara.

Perdebatan Shape Up 6 Minggu vs. Sprint 2 Minggu

Ada perdebatan panjang dalam manajemen engineering tentang ritme: sprint 2 minggu (model Scrum) versus siklus shape up 6 minggu (model Basecamp dari "Shape Up"). Saya akan menghemat waktu Anda dari perang keyakinan ini.

Gunakan siklus 6 minggu ketika pekerjaan Anda berbentuk fitur. Anda punya 3-6 minggu cakupan yang bermakna dan terdefinisi dengan baik. Tim bisa berkomitmen pada satu taruhan besar, mengerjakannya dengan sengaja, dan mengirimkan sesuatu yang substansial. Shape Up bersinar di sini karena appetite (waktu maksimum yang akan Anda habiskan sebelum memotong cakupan) sudah tertanam dalam modelnya.

Gunakan sprint 2 minggu ketika pekerjaan Anda bersifat reaktif. Eskalasi pelanggan, insiden infrastruktur, engineering support, pekerjaan platform di mana permintaan masuk lebih cepat daripada yang bisa Anda rencanakan. Sprint 2 minggu memberi Anda putaran umpan balik yang lebih ketat dan memungkinkan Anda memprioritaskan ulang tanpa terasa seperti pembalikan strategi.

Uji yang jujur: tanyakan kepada tim Anda pertanyaan ini tanpa pemanasan. "Apakah Anda lebih suka berkomitmen pada satu taruhan besar selama 6 minggu, atau 5 taruhan kecil dalam 2 minggu?" Tim yang berbeda memberi jawaban yang berbeda. Keduanya valid. Jawaban yang salah adalah mencampurnya. Menjalankan sprint 2 minggu dengan pekerjaan berbentuk 6 minggu berarti setiap sprint terasa seperti kegagalan sebagian, dan menjalankan siklus 6 minggu pada pekerjaan reaktif berarti siklus tersebut diledakkan oleh insiden pelanggan di minggu kedua setiap kali.

Pilih satu. Komitmen selama satu kuartal. Evaluasi ulang.

Ticket-to-PR Latency: Sinyal yang Sesungguhnya

Lupakan velocity points. Lupakan "burn-down chart yang sebenarnya burn-up chart karena kita terus menambahkan cakupan." Ada satu angka yang memberi tahu Anda apakah ritme pengiriman Anda berhasil: ticket-to-PR latency.

Definisi: waktu yang berlalu dari saat tiket ditugaskan ke seorang engineer hingga mereka membuka PR pertama untuknya.

Itulah semuanya. Tanpa story points. Tanpa estimasi. Hanya dua stempel waktu.

Jika angka itu lebih dari 4 hari pada tiket yang Anda estimasikan memakan waktu 5 hari, perencanaan Anda rusak. Bukan karena engineer itu lambat. Karena tiket tidak cukup dirumuskan untuk memulai. Mereka menghabiskan hari pertama, kedua, dan ketiga mencari tahu apa sebenarnya arti tiket itu, apa yang tercakup, apa yang tidak, dan apa yang harus dilakukan ketika mereka menghantam lubang kelinci yang tak terelakkan. Itu perencanaan yang bocor ke dalam eksekusi.

Seperti apa yang baik: median ticket-to-PR latency di bawah 24 jam. p75 di bawah 48 jam. p90 di bawah 5 hari. Jika distribusi Anda memiliki ekor panjang (beberapa tiket duduk di 10+ hari), tiket-tiket itulah yang memakan sprint Anda dan merekalah yang perlu diselidiki.

Buat chartnya sekali, di alat apa pun yang Anda gunakan. Linear, Jira, dan Shortcut semuanya mengekspos data ini melalui API mereka. Ambil datanya mingguan. Pantau mediannya. Ketika naik, perencanaan telah menurun. Ketika turun, ada sesuatu yang berhasil.

Pola "Diestimasi 3 Hari, Memakan 11 Hari"

Setiap EM pernah mengalami ini. Tiket diestimasi 3 hari. Sebelas hari kemudian, masih dalam tinjauan. Sang engineer tidak bermalas-malasan. Tiket itu tidak cukup dirumuskan.

Ini bukan masalah estimasi. Estimasi yang lebih baik tidak akan memperbaikinya. Pekerjaan itu ambigu saat masuk ke sprint, dan "ambigu + saya akan mencari tahu sambil berjalan" itulah yang mengubah tiket 3 hari menjadi 11 hari.

Solusinya adalah sesi shaping 30 menit sebelum tiket masuk ke sprint. Dipimpin oleh tech lead atau IC senior. Hasilnya adalah dokumen shaping singkat yang mencakup empat hal:

1. Yang tercakup. Perilaku atau kemampuan spesifik yang sedang kita bangun. Konkret, tidak abstrak.
2. Yang tidak tercakup. Dua atau tiga hal yang tampaknya terkait tapi secara eksplisit tidak kita kerjakan. Ini adalah bagian terpenting. Tanpanya, cakupan tanggung jawab merayap setiap saat.
3. Lubang kelincinya. Risiko yang sudah diketahui: "ini mungkin memerlukan menyentuh auth service, dan jika iya, kita berhenti dan meninjau ulang cakupan." Menamakannya lebih awal berarti engineer tidak menghilang ke dalamnya selama seminggu.
4. Appetite-nya. Waktu maksimum yang akan kita habiskan sebelum kita memotong cakupan atau mengeskalasikan. Bukan estimasi. Sebuah anggaran.

Tiga puluh menit. Satu dokumen. Tiket yang keluar dari shaping 4-5 kali lebih mungkin dikirimkan mendekati appetite-nya daripada yang tidak. Saya telah melihat ini bertahan di tim berukuran 6 maupun 60. Matematika investasi waktu itu jelas.

Penganggaran Utang Teknis: Aturan 20%

Dua puluh persen dari setiap sprint dialokasikan untuk utang teknis. Bukan "jika ada waktu." Bukan "kita akan mengerjakannya kuartal depan." Sebuah alokasi yang berkomitmen, diberi nama, sebagai pos anggaran.

Jika Anda melewati ini, utang terakumulasi. Pada kuartal ketiga kecepatan pengiriman Anda tinggal setengah dari sebelumnya, dan tidak ada yang bisa menjelaskan mengapa dengan tepat. Tes yang tidak stabil yang membutuhkan tiga percobaan untuk lulus. Migrasi yang seharusnya sementara 18 bulan lalu. Layanan yang tidak ada yang tahu cara men-deploy kecuali satu engineer yang akan cuti orang tua.

Dua puluh persen bukan angka ajaib. Itu adalah batas di bawahnya utang terakumulasi lebih cepat dari yang bisa Anda bayar. Beberapa tim memerlukan 30% selama periode pemulihan. Beberapa tim bisa berjalan di 15% jika codebase mereka benar-benar masih muda. Di bawah 15%, Anda sedang meminjam dari kecepatan pengiriman kuartal depan dan Anda akan merasakannya.

Cara memilih utang mana yang harus dilunasi, dalam urutan prioritas:

1. Masalah yang dihadapi pelanggan. Bug yang telah disiasati tim tapi masih dihadapi pelanggan. Masalah kinerja yang muncul dalam tiket support. Selalu yang pertama.
2. Masalah yang dihadapi developer. Tes lambat, pengembangan lokal yang rusak, jebakan deployment. Apa pun yang menghabiskan waktu tim satu jam per minggu atau lebih.
3. Pembersihan teoritis. Refactor yang akan terasa bagus tapi tidak punya pemicu nyata. Prioritas terakhir. Jujurlah tentang apakah ini layak masuk ke sprint sama sekali.

Buat 20% terlihat di papan. Beri tag tiket dengan "tech-debt." Laporkan persentasenya dalam spike perencanaan mingguan Anda. Jika sprint turun di bawah 20% selama tiga minggu berturut-turut, itu sinyal peringatan.

Pola Membuka Blocker: SLA Tinjauan PR + Kalender Keputusan

Dua mekanisme spesifik yang menggerakkan jarum lebih dari perubahan perencanaan manapun:

SLA Tinjauan PR. Tinjauan pertama dalam 4 jam selama jam kerja. Bukan pedoman. Komitmen yang mengikat. Jika PR duduk tidak ditinjau selama 4+ jam, reviewer yang ditugaskan meninggalkan apa yang sedang mereka kerjakan dan meninjau. Ini terdengar keras. Ini berhasil.

Tim yang saya lihat mengadopsi ini mengirimkan 2-3 kali lebih banyak dari sebelumnya, dan alasannya lugas: PR yang duduk dalam tinjauan selama 2-3 hari berarti engineer berpindah konteks ke hal lain, lalu berpindah konteks kembali saat tinjauan masuk, lalu berpindah konteks lagi untuk menangani umpan balik. Setiap perpindahan menghabiskan 30-60 menit waktu produktif nyata. SLA 4 jam menghilangkan putaran itu.

Kata-kata yang akan saya masukkan ke dalam perjanjian kerja tim Anda, kata per kata:

Tinjauan pertama dalam 4 jam selama jam kerja, kecuali saat seorang engineer sedang dalam blok fokus yang ditandai sebelumnya. Tinjauan memblokir pekerjaan lain, termasuk tiket aktif reviewer sendiri. Tinjauan komentar-saja dihitung. Ekspektasinya adalah umpan balik, bukan persetujuan.

Kalender Keputusan. Satu slot 30 menit per minggu di mana EM dan tech lead memutuskan semua hal yang sudah menunggu. Keputusan arsitektur. Pilihan vendor. Keputusan "apakah kita menggunakan library A atau library B?". Pertanyaan apa pun yang sudah duduk di Slack thread lebih dari 48 jam.

Tanpa ini, keputusan berlarut-larut selama berminggu-minggu. Para engineer bertanya sekali, mendapat "izinkan saya memikirkannya," dan pertanyaannya mati di sebuah thread. Kalender keputusan membuat komitmen publik: pada Jumat pukul 11.00, pertanyaan itu mendapat ya, tidak, atau "kami butuh 30 menit lagi untuk meninjau ini." Tidak ada lagi putaran "saya akan menghubungi Anda kembali."

Kedua mekanisme ini bersifat mekanis. Tidak memerlukan perubahan budaya atau kampanye penerimaan. Anda berkomitmen pada Senin dan mulai menjalankannya pada Selasa.

Kapan Mengeskalasikan (dan Apa Arti "Eskalasi" Sebenarnya)

Kebanyakan EM menyalahgunakan kata "eskalasi." Mereka mengira artinya pergi ke atasan Anda ketika sesuatu sedang terbakar. Itu bukan eskalasi. Itu pembaruan status dengan langkah tambahan.

Eskalasi adalah membuat keputusan tak kasat mata yang tepat menjadi terlihat.

Tiga pemicu eskalasi nyata:

1. Cakupan lebih besar dari appetite. Anda merumuskan tiket untuk appetite 1 minggu. Engineer kini memberi tahu Anda bahwa ini masalah 3 minggu. Keputusan (apakah kita tetap melakukannya? apakah kita memotong cakupan? apakah kita mendorong ke kuartal berikutnya?) berada di luar tim. Eskalasikan.
2. Ketergantungan pada tim lain memblokir Anda selama 2+ hari. Anda sudah bertanya. Anda sudah menindaklanjuti. Tidak ada yang bergerak. Eskalasikan ke EM tim lain itu, dengan permintaan spesifik dan tenggat waktu spesifik. Bukan "bisakah Anda membantu kami?" melainkan "kami membutuhkan ya/tidak tentang apakah tim auth bisa memprioritaskan ini sebelum EOD Kamis."
3. Keputusan arsitektur mempengaruhi lebih dari tim Anda. Anda akan memperkenalkan database baru. Pola auth baru. Pendekatan deployment baru. Jika radius dampaknya lebih besar dari tim Anda, eskalasikan ke atas agar keputusan dimiliki di level yang tepat.

Template eskalasi 3 baris yang berhasil di Slack atau email:

Keputusan dibutuhkan: [pertanyaan spesifik, dirumuskan sebagai ya/tidak atau pilih-satu-opsi]
Mengapa sekarang: [apa yang terhambat, siapa yang terpengaruh, apa biaya menunggu]
Tenggat waktu: [kapan Anda membutuhkan jawaban, dengan tanggal dan waktu spesifik]

Itulah seluruh templatenya. Tiga baris. Tanpa paragraf latar belakang. Jika penerima membutuhkan konteks, mereka akan bertanya. Kejelasan itu sendiri adalah yang membuka blocker.

30 Hari Pertama Ritme Baru Ini

Jangan terapkan semua ini pada hari Senin. Cara tercepat untuk kehilangan kepercayaan tim adalah mengumumkan model operasional baru dan meminta mereka mengikutinya sebelum mereka melihat bahwa itu berhasil.

Peluncuran 30 hari yang berhasil:

Minggu 1: Hapus satu rapat berulang. Pilih yang tidak disukai siapapun. Refinement pertengahan sprint, kemungkinan. Batalkan. Lihat apa yang rusak. Biasanya tidak ada. Jika ada yang rusak, Anda telah mempelajari apa yang sebenarnya dilakukan rapat itu.

Minggu 2: Luncurkan spike perencanaan 1 jam baru. Jalankan sekali. Kirimkan catatan singkat kepada tim yang menjelaskan format baru dan alasannya. Selesaikan jamnya. Patuhi batas waktunya.

Minggu 3: Ukur ticket-to-PR latency. Ambil data dari alat Anda. Buat chartnya. Jangan bagikan dulu. Lihat sendiri selama seminggu agar Anda memahami seperti apa distribusi Anda sebenarnya.

Minggu 4: Tinjau data bersama tim dan sesuaikan. Bawa chartnya. Tanya: "apa yang kita lihat? apa yang mengejutkan kita? apa satu hal yang akan kita ubah?" Biarkan tim bersuara. Sesuaikan ritme berdasarkan apa yang mereka katakan.

Pada hari ke-30 Anda akan telah menggantikan 6+ jam perencanaan dengan 1 jam, mengukur satu sinyal yang penting, dan memberi tim ritme yang bisa mereka pertahankan. Anda juga akan mendapat waktu Anda kembali. Gunakan untuk melakukan pekerjaan yang sebenarnya dibayar untuk dilakukan seorang EM: merumuskan masalah, membuka blocker orang-orang, dan mengembangkan engineer Anda.

Gambaran Jumat sore dari awal artikel ini? Dalam 60 hari Anda tidak akan mengenalinya. Kalender Anda akan memiliki satu blok perencanaan, satu blok kalender keputusan, dan banyak ruang kosong. Tim Anda akan mengirimkan lebih banyak. Dan IC senior yang dulu mengirimkan sesuatu meskipun ada proses Anda akan mengirimkan sesuatu karenanya.

Pelajari Lebih Lanjut

• Deskripsi Jabatan Staff Software Engineer
• Menjalankan 1:1 yang Dinantikan Bawahan Anda
• Menetapkan Tujuan untuk Tim yang Enggan