Kemarin gw liat dashboard Jira founder tim dev kita. Velocity naik 40% dari kuartal lalu. Burndown chart-nya rapi banget, piramida sempurna. Tapi email masuk dari klien utama: "Buat apa semua ini kalau release kemarin masih nyangkut di QA, dan budget udah overran 2 minggu?"

Yang ngeselin? Tim lo beneran kerja keras. Mereka ngelaporin angka bagus tiap standup, PM nya juga tenang karena sprint achievement rate tembus 95%. Tapi secara nyata,交付 (delivery) ke client makin jelek. Bug numpuk di production, dokumentasi API kosong, dan client mulai minta meeting emergency tiap Jumat sore.

Ini bukan masalah kerja keras. Ini masalah lo lagi jatuh ke dalam anti pattern agile agency klasik: mempercayai metrik yang mengukur aktivitas, bukan hasil.

3 metrik produktivitas tim yang diam-diam ngebunuh quality

Kalau lo scale up dari 5 orang ke 15+ developer, instinct lo pasti ngesuggest buat ngasih target harian atau mingguan. Entah itu dipaksa sama founder yang maunya feel "on top", atau didorong sama kebutuhan laporan ke client. Biasanya yang muncul:

1. Jumlah tiket tertutup per hari/person
Awalnya kelihatan efisien. Dev yang ngeclose 3-4 ticket sehari dapet bonus atau pujian di review mingguan. Akibatnya? Mereka mulai mikir "bagaimana caranya ngedrop tugas yang paling kecil", daripada ngerjain task kompleks yang butuh arsitektur matang. Ticket dikit-doang di-split jadi tiga, dan kode yang di-push jadi kurang matang karena dipaksa cepet-cepetan.

2. Jam kerja tim / Utilization rate
"Dev harus fill 40 jam/minggu." Aturan ini terdengar disiplin, tapi secara praktik dia mematikan manajemen kualitas project. Ketika deadline jam yang ketat lebih diutamakan daripada kedalaman kerja, yang pertama dihilangkan ya non-coding activity: testing, peer review, refactoring, dan bahkan komunikasi singkat soal edge-case logic.

3. Sprint completion percentage
"Target sprint 20 story points, capai 19 = gagal." Metrik ini bikin tim takut estimate. Estimasi jadi terlalu optimis demi selamat, atau malah padding disengaja supaya aman. Yang terjadi? Scope creep diam-diam masuk karena dev takut nyatakan hambatan sejak awal. Client baru ngeh pas demo hari terakhir, dan semuanya panik.

Ketiga metrik ini punya satu pola umum: mereka reward kecepatan keluaran, bukan kedalaman proses. Dan di stage A agency yang lagi scaling, kecepatan semu ini mahal harganya.

Kenapa cut-test dan skip-doc adalah konsekuensi logisnya?

Bukan karena dev malas. Tapi karena sistem insentif lo lagi bicara lain.

Gw pernah case di salah satu client agency Jakarta. Tim 8 orang, velocity stabil di 45 SP/minggu. Founder bangga banget. Tapi setiap 2 sprints, client complain soal regression bug yang sama terus. Awalnya dibales "udah fixed kok, next patch stable". Padahal akar masalahnya sederhana: dev di-pressure buat ngeclose tiket sebelum weekend, sehingga integration testing selalu digenepin, dan commit message jarang jelas.

Yang terjadi bukan pelanggaran disiplin. Itu perilaku rasional terhadap metrik yang salah.

Ketika targetnya "jumlah close", maka quality adalah biaya yang mau dikorbankan. Ketika targetnya "jam fill", maka deep work jadi ilusi karena context-switching terus menerus.

Ganti dengan: First-Pass Yield & Cycle Time per Feature

Lalu gimana kalau mau tetep scalable tapi kualitas delivery-naik?

Shift fokus lo ke dua metrik ini:

First-Pass Yield (FPY)
Persentase fitur/tiket yang berhasil di-deploy ke staging atau production tanpa perlu rework, rollback, atau bug return dalam 7 hari pertama. Bukan sekadar "status closed". Tapi benar-benar survive di lingkungan real.

FPY memaksa tim untuk berhenti menganggap QA sebagai pintu akhir, dan menjadikannya bagian dari definition of done. Kalau FPY tim lo turun di bawah 75%, artinya ada gap di requirement clarity, code review, atau automated testing. Angka ini jauh lebih jujur daripada velocity.

Cycle Time per Feature
Waktu aktual dari saat developer mulai ngerjain task (In Progress) sampai feature benar-benar ready for user (Deployed/Closed). Beda sama lead time yang menghitung dari creation ticket. Cycle time murni ngukur efisiensi eksekusi.

Di satu tim gw, average cycle time turun dari 5.2 hari ke 3.1 hari setelah kita stop ngepush "spike velocity" dan mulai block task yang stuck lebih cepat. Caranya? Gak pakai jam kerja. Pakai blocking visibility dan daily async update via diskusi.

Cycle time yang pendek + FPY tinggi = client retention yang sehat. Client gak peduli lo kerjas berapa jam. Client peduli: request A selesai dalam 3 hari, setelah deploy gak ada rollback, dan perubahan berikutnya gampang diintegrasikan.

Tabel pembanding: Anti Pattern Agile Agency vs Healthy Tracking

| Metrik | Fokus Tersembunyi | Dampak ke Delivery | Kapan Bahaya |
|---|---|---|---|
| Tiket tertutup/hari | Volume output | Code review terlewat, scope splitting | Velocity naik tapi bug return rate >20% |
| Jam kerja / Utilization | Kehadiran aktif | Testing & doc dipangkas, burnout laten | Developer bilang "mager ngerjain refactor" |
| Sprint achievement % | Target compliance | Padding estimate, hidden tech debt | Demo hari terakhir selalu ada last-minute fire drill |
| First-Pass Yield | Kualitas pertama kali | Rework turun, stabilitas produksi naik | FPY <75% selama 2 sprints berturut |
| Cycle Time | Alur penyelesaian | Feedback loop client lebih cepat, predictability naik | Varians cycle time >50% antar task sejenis |

Perlu ditekankan: tabel ini bukan daftar pantangan mutlak. Velocity tetap berguna buat forecasting kapasitas jangka panjang. Tapi kalau lo pakai velocity buat menghakimi performa individu mingguan, lo lagi main api.

Cara nerapin tanpa bikin tim panic atau drop revenue

Gagalnya transisi metrik biasanya bukan karena datanya susah diambil. Tapi karena mental model foundationernya belum berubah.

Pertama, hentikan public ranking individu berdasarkan tiket tertutup. Ganti jadi team-based FPY tracker. Bikin dashboard internal yang cuma liat trend mingguan, bukan leaderboard harian. Gw personally pernah nyoba pasang target individual "max 2 bug return/minggu", hasilnya justru dev saling blokir PR dan komunikasi jadi defensif. Yang jalan? Dashboard transparan + blameless post-mortem tiap FPY drop di bawah threshold.

Kedua, integrasikan cycle time tracking tanpa nambah overhead meeting. Di SatuTim kita biasanya pakai Discussion thread buat async status update, jadi developer gak perlu repot isi Jira comment yang sering jadi spam. Tinggal flag blocking issue, PM bisa langsung intervene sebelum cycle time meledak.

Ketiga, ajak client align ke metrik baru ini. Jangan bilang "kita sekarang pakai first-pass yield". Bilang aja, "kami ganti reporting focus ke stability & delivery speed, jadi kamu bakal dapat update lebih konsisten dan rollback berkurang." Client stage B/C biasanya appreciative karena mereka lelah sama admin report yang banyak tapi hasil minim.

Yang paling kritis: founder harus siap liat angka velocity turun sebentar di awal transisi. Itu normal. Otak tim butuh 2-3 sprints buat nyesuaikan kebiasaan. Biarkan dulu. FOKUS ke tren FPY dan cycle time consistency. Nanti velocity bakal naik sendiri, tapi kali ini didukung oleh kode yang stable dan dokumentasi yang readable.

Satu hal yang sering dilewatkan: metrik yang sehat butuh investasi di tooling otomatis. Linting, CI pipeline, smoke test dasar, dan template PR yang enforce checklist minimal. Tanpa itu, FPY cuma jadi teori manis di spreadsheet.

Kalau lo pengen coba, di SatuTim ada fitur Discussions buat async standup dan decision logging, plus task dependency view yang bikin cycle time bottleneck keliatan jelas tanpa harus ngerapihin burndown chart palsu. Gak perlu tambah software, cukup ubah habit reporting.

Coba minggu ini: buka backlog lo, pilih 5 ticket yang baru di-close bulan ini. Cek di staging atau production: berapa yang udah kena bug report atau revisi ulang dalam 7 hari? Hitung persentasenya. Kalau angkanya ngelewatin 25%, mungkin saatnya gonta-gini mindset produktivitas tim lo sebelum client mulai cari vendor lain.