Client ganti brief untuk ketiga kalinya setelah sprint dua kelar. Dan PM tim malah bilang, "Ah santai, kita just-in-time aja." Gw cuma bisa ngegas di grup WhatsApp internal. Itu bukan fleksibilitas. Itu pintu belakang scope creep yang lagi nginap gratis di calendar lo.
Kenapa Agile Murni Jeblok di Agency?
Kita semua udah pernah baca manifest-nya Scrum atau Kanban. Looping kerja dua minggu, daily sync, retrospective buat continuous improvement. Masuk akal banget kalau tim dalam atau product company. Tapi begitu client mulai masuk ke dalam workflow, aturan mainnya langsung berubah. Client gak peduli sama burndown chart. Mereka peduli sama timeline finalisasi dan budget cap.
Gw pernah coba implementasi full agile buat project redesign website client retail lokal. Tim gw 6 orang. Sprint 2 minggu. Kelar sprint kedua, client minta tambah fitur checkout express karena "competitor lagi on". Secara teknis sih gampang. Tapi itu artinya re-plan backlog, geser milestone QA, dan potentially delay handover. Di enterprise, ini masih bisa didiskusin dengan roadmap tahunan. Di agency? Deadline udah terpaku di PO. Kalau lo ngerempongkan schedule gara-gara request baru, client bakal naik pitak duluan.
Yang ngeselin, banyak PM di agency justru ikut-ikutan gaya tech startup. Padahal konteksnya beda total. Agency jual time-for-money yang dikemas jadi deliverable. Kalau delivery-nya kabur, margin ambyar. Dan sekali margin ambyar, bukan cuma bulan ini yang rugi. Next renewal conversation langsung jadi negosiasi putus asa. Waterfall sering dicibir karena kaku, tapi pure agile murni seringkali bikin scope creep parah di dunia service-based.
Rhythm Hybrid yang Gw Implementasiin
Jadi apa solusi? Bukan balik ke waterfall kaku. Bukan juga ngikutin agile dogma sampai ujung tombak. Kita akhirnya nemu rhythm sendiri: hybrid cadence dengan boundary yang jelas. Praktisnya simpel, tapi efeknya gila-gilang.
Pertama, kita pecah project jadi tiga phase keras: Discovery, Build, UAT/Delivery. Tiap phase punya gate approval dari client sebelum masuk ke phase berikutnya. Di phase Build, kita tetep pakai sprint dua minggu. Tapi sprint planning gak dibuka lebar-lebar buat request baru. Cuma ada slot khusus buat "change requests" yang harus lewat impact assessment dulu. Gw suruh PM tim ngerjain quick calculation: tambahan jam man-hour, biaya extra, atau geser deadline mana. Client pilih satu. Gak ada opsi "coba dulu aja".
Contoh konkretnya? Bulan lalu kita handle migrasi database client logistik. Ada 12 module yang harus dimigrasi dalam 6 minggu. Midway sprint ke-3, client bilang mau tambah auto-reporting PDF. Tim desain udah siap wireframe. Biasanya di agile biasa, ini bakal masuk backlogsprint berikutnya. Gw block. Kita kasih impact report: tambah 3 hari dev, 1 hari testing, atau kita kurangi scope jadi 11 module dulu. Client pilih kurangi scope. Deliverable tepat waktu, budget aman, dan client senang karena gak ada hidden cost yang numpuk tiba-tiba.
Guardrail QA yang Gak Disakrifikasi
Masalah terbesar hybrid approach sering dianggap mengurangi kualitas karena terlalu terstruktur. Padahal justru sebaliknya. Di agency, QA bukan sekadar bug hunting di akhir sprints. Dia adalah checkpoint compliance terhadap brief awal.
Gw terapkan practice: setiap akhir sprint, wajib ada internal review cross-functional sebelum client meeting. Design lead cek consistency, dev cek integration points, PM cek against acceptance criteria. Baru setelah itu kita present ke client. Hasilnya? Revisian selama UAT turun drastis. Dari rata-rata 4-5 round revision-an jadi maksimal 2 round. Waktu testing tim gak habis buat ngejar perubahan mindset client yang nggak terkendali.
Di SatuTim, kita manfaatin fitur Discussions buat async review. Nggak perlu rapat 1 jam cuma buat approve mockup atau ngebacain changelog. Tim tinggal leave comment, PM track status-nya, dan semua audit trail tersimpan rapi. Lebih transparan, less noise. Task gantung berkurang signifikan karena accountability-nya jelas di level individu.
Handle Scope Creep Client Tanpa Jadi Musuh
Banyak PM takut bilang "no" karena takut kehilangan account. Akibatnya, mereka jadi accommodating berlebihan. Brief yang sebenernya ambigu dibiarin terus berkembang sampai jadi monster yang nggak bisa di-deliver sesuai budget. Itu bukan loyalitas. Itu poor boundary management.
Cara praktisnya? Gunakan contract clause sebagai penjaga gawang, bukan senjata. Di setiap kickoff meeting, kita tunjukin matrix klarifikasi: apa yang termasuk fixed scope, apa yang termasuk change request, dan bagaimana proses eskalasinya. Client tanda tangan bersama. Bukan buat njlimet. Buat align expectation sejak menit pertama.
Gw ingat kasus client F&B yang mau launch app loyalty program. Po awalnya 8 minggu. Minggu ke-4, client minta integrasi payment gateway pihak ketiga yang belum certified. Dev team siap kerjain karena skillset tersedia. Tapi gw tolak di sprint planning. Kita kasih opsi: delay launch 1 minggu, atau drop fitur payment gateway dulu, fokus ke core reward redemption. Client pilih opsi kedua. Launch jalan, rating user naik 200%, dan payment gateway masuk di phase post-launch dengan budget terpisah.
Intinya, scope creep itu wajar. Manusia pasti butuh penyesuaian. Tapi di dunia service, penyesuaian harus punya harga. Kalau lo kasih gratis terus, client bakal anggap itu hak default. Dan ketika tagihan datang di bulan keenam, lo yang bakal nangis lihat cashflow minus.
Metric yang Sebenarnya Wajib Diukur
Kalau lo masih pakai velocity atau story points sebagai KPI utama di agency, coba stop bentar. Angka-angka itu valid buat internal tracking, tapi gak ngomongin real business health.
Gw ganti metric internal tim jadi: On-Time Delivery Rate, Change Request Ratio, dan Client Satisfaction Score (post-UAT). Dulu tiap bulan, gw cek berapa banyak ticket yang lewat deadline, berapa persen request baru yang berhasil ditolak/dialihkan via proper channel, dan apakah client puas saat sign-off. Kalau ratio change request di atas 25%, otomatis kita panalah internal: apakah brief discovery-nya kurang matang, atau memang client yang gak jelas? Kalau Under 10%, biasanya berarti tim terlalu kaku dan mungkin kehilangan value-add opportunity.
Data ini jadi bahan diskusi kuat waktu quarterly business review (QBR) sama client. Gak perlu debat emosional. Cukup tunjukin angka. "Bulan ini kita handle 3 change request sesuai protokol, tapi untuk project selanjutnya, kita usul dedicasikan 2 week sprints buat exploration feature baru biar gak ganggu core delivery." Client biasanya langsung setuju karena merasa dihargai strukturnya, bukan diperlakukan sebagai sumber masalah.
Adaptasi Framework Itukan Seni, Bukan Dogma
Ngomong-ngomong soal struktur, banyak founder agensi yang still percaya bahwa agile harus di-copy-paste persis sama buku panduan. Padahal framework itu kayak pakaian. Dipakai buat kondisinya. Kalau dipakai ke luar hujan tanpa jakket, ya basah. Di agency, lingkungan kita penuh ketidakpastian eksternal. Client berubah pikiran, vendor telat kirim asset, regulasi mendadak update. Agile murni terlalu idealis buat lingkungan dinamis kayak gitu.
Yang kita butuhin bukan disiplin kaku, tapi flexibility dengan guardrails. Sprint tetep jalan, tapi boundary-nya tegas. Daily sync diganti async kalau memang gak perlu. Retrospective focus pada client communication flow, bukan sekadar teknikal debt. Semua disesuaikan biar delivery-nya tetap konsisten tanpa mengorbankan relasi bisnis. Adaptasi framework agile itu bukan tentang meninggalkan prinsip, tapi tentang menjembatani teori akademis sama brutalnya kenyataan lapangan.
Coba minggu ini: audit satu project aktif lo. Cek berapa kali brief berubah, berapa jam meeting yang dihabisin buat nyari kejelasan, dan berapa budget yang terkuras buat revisi di luar PO. Taruh angkanya di kertas. Lalu coba pasang satu rule baru: no new feature request tanpa impact statement. Lihat gimana respon tim dan client-nya. Biasanya, ketakutan akan "nggangu alur kerja" itu lebih besar daripada real impact-nya.
Kalau standup tim lo masih rutin lebih dari 30 menit padahal cuma buat status-update kosong, itu bukan stamina tim yang lemah. Itu symptom dari lack of clear scope definition. Coba minggu ini: ganti standup ke async di SatuTim Discussion. Lihat berapa menit yang lo dapet balik. Atau jujur deh, selama ini scope creep di tim lo lebih sering disabotase oleh client yang gak jelas, atau PM yang takut bilang stop?