Gw udah pause semua Jira ticket Scrum board selama enam bulan penuh. Dan tim gw yang delapan orang ini, yang sehari-harinya cuma urus landing page sama campaign launch, justru gak kacau — malah lebih stabil dari sebelumnya.

Bukan karena kita jadi malas, tapi karena Scrum itu over-engineering buat tipe kerja kita

Coba lo liat workflow agensi atau startup product team yang handle klien berantai. Brief masuk hari Senin, deadline client geser hari Rabu, revision naik turun kayak rollercoaster, dan designer harus adaptasi ulang dua kali dalam seminggu. Di skenario begini, paket sprint dua minggu plus burndown chart plus daily standup 15 menit itu bukan disiplin. Itu teater.

Gw sendiri dulu nyoba keras banget. Setiap pagi jam 9, kita stand up. Lo kasih update progress, dia bilang lagi nunggu approval client, si design bilang lagi revisi aset. Meeting kelar, tetep aja task gantung di inbox masing-masing. Yang parah, burndown chart kami sering ‘hijau’ secara visual padahal deliverable belum pernah dicek client satu kali pun. Itu vanity metric, guys. Kita pake Scrum biar kelihatan profesional di depan investor atau klien besar, padahal overhead ceremonialnya makan waktu produktif 12-15 jam per minggu per orang.

Beneran loh. Dulu gw hitung manual: 8 orang kali 3 jam per minggu buat standup, planning, retro, dan refinement = 24 jam. Buat apaan? Buat narasi bahwa kita memang ‘agile’. Padahal realitanya, agility kan bukan soal ketepatan jadwal ritual, tapi seberapa cepat kita bisa deliver value ke user tanpa nyangkut di proses internal. Time spent on process vs time spent on actual work—yang pertama malah tumbuh, yang kedua stagnan.

Flow-based: Nyetop maksa kotak, mulai ngalirin pekerjaan

Pas kita mutusin break Scrum, langkah pertama gampang: cabut board dua mingguan. Ganti dengan flow-based setup yang cuma pegang tiga hal. Pertama, WIP limit. Gak boleh lebih dari tiga task aktif per orang di kolom ‘In Progress’. Kalau mau ambil baru, harus kelarin atau drop yang lama. Prinsip dasar, tapi sering dilupakan pas deadline ngejar dan client minta tambahan scope di tengah sprint.

Kedua, cadence delivery tetap dua minggu, tapi gak dikunci rigid. Kami sebut ini ‘biweekly release window’. Nggak ada sprint goal yang kaku, cukup target output yang jelas. Misal: ‘Sebelum Jumat pekan kedua, semua landing page Q3 harus udah live dan QA pass.’ Gak perlu cerita panjang lebar di awal sprint, fokusnya cuma kelar dan validasi.

Ketiga, retrospective dipotong jadi sesi singkat pas milestone selesai. Cuma 20 menit. Gw ajak tim bahas tiga pertanyaan: apa yang bikin kita macet? apa yang bisa diotomatisasi atau dipotong? next cycle kita tweak di mana? Gak perlu slide deck, gak perlu sticky notes ratusan lembar yang cuma jadi hiasan dinding setelah rapat. Cukup catatan di channel diskusi tim, terus eksekusi di cycle berikutnya.

Di platform kayak SatuTim, fitur Discussions dan Task Limit ini bantu banget soalnya update jadi async. Gak perlu ngeblock kalender cuma buat ngeraporin status. Statusnya keliatan dari flow-nya, bukan dari lisan di Zoom yang ujungnya cuma diulang-ulang sama yang belakang duduk.

Angka beneran berubah: cycle time turun 30%, tidur tim kembali normal

Gw gak janjiin angka ajaib, tapi data enam bulan terakhir jujur: average cycle time turun dari 11 hari jadi 7.8 hari. Itu bukan karena tim gw kerja superhuman atau ngerjain lembur sampe subuh. Mereka cuma berhenti multitasking sambil menunggu approval. Dengan WIP limit, setiap task yang masuk langsung dapat perhatian penuh sampai selesai. Gak ada lagi status ‘sedang diproses’ yang sebenarnya cuma numpang lewat di inbox sambil ditunda.

Yang lebih penting: kelelahan tim berkurang drastis. Dulu, akhir sprint itu biasanya hari paling stressful. Deadline nekat, client minta revisi dadakan, PM harus mediasi antara dev dan design yang saling lempar blame. Sekarang? Karena rhythm-nya lebih natural, kalau ada client yang request change mendadak, kita tinggal adjust capacity di window berikutnya. Gak perlu panic mode atau emergency standup yang malah bikin produktivitas harian lumpuh.

Ini relevan banget buat konteks manajemen proyek agile di indonesia sekarang. Banyak agensi masih terjebak budaya ‘paling cepat kelar tapi asal jadi’ versus ‘paling rapi tapi telat’. Scrum vs flow based bukan perang ideologi, tapi pilihan tools berdasarkan volume work, volatility client, dan maturity tim. Kalau work lo sifatnya exploratory atau high-touch client, flow-based usually wins. Kalau produk software dengan roadmap jangka panjang dan stakeholder fixed, Scrum mungkin still applicable. Tapi jangan paksa lingkaran ke persegi hanya karena influencer tech bilang gitu.

Metodologi project management sederhana: yang penting mensempitkan masalah, bukan nambah overhead

Jujur, awalnya gw takut. Nggini-gitu kok bisa kelar? Apa nanti chaos? Ternyata chaos yang bikin kita sakit itu bukan karena kurang proses, tapi karena proses yang salah tempat. Metodologi project management sederhana itu bukan berarti setengah-setengah atau asal-asalan. Artinya: minimal friction, maximum clarity. Sistem harus nyaring noise, bukan menambah layer birokrasi internal.

Gw pribadi gak setuju kalau kita menjadikan framework sebagai ID profesional. Sprint Review yang megameg? Daily report yang di-copy paste ke grup WhatsApp? Atau malah jargon ‘synergy cross-functional’ yang cuma isian performa tahunan? Itu semua distraksi. Yang lo butuhkan cuma: tahu siapa pegang apa, tau batas kapasitas, tau kapan deliverable harus keluar, dan tau cara feedback tanpa drama.

Dalam pengalaman gw ngelola tim di berbagai phase growth stage, efisiensi operasional agensi selalu datang dari pengurangan context switching, bukan penambahan meeting. Waktu yang lo hemat dari canceling ritual kosong itu bisa lo return ke strategic thinking, client relationship building, atau sekadar recharge mental. Jangan remehkan recharge. Burnout gak muncul karena workload tinggi, tapi karena workload yang gak jelas endpoint-nya.

Kalau lo lagi coba skalain tim dari lima ke lima belas orang, jangan lupa: flow skalanya jauh lebih murah daripada ceremony. WIP limit tetap jalan. Cadence delivery tetep bisa disesuaikan. Retrospective malah lebih efektif karena datanya fresh, bukan ingatan menumpuk sejak dua minggu lalu yang akhirnya jadi debat tentang siapa yang salah di masa lalu.

Jadi, gimana pilih framework yang nggak bikin tim burnout?

Gw usually tanya tiga hal sebelum rekomendasikan setup kerja:

  • Seberapa tinggi volatilitas input (brief, client, stakeholder)?
  • Apakah output-nya deterministik (fixed spec) atau probabilistik (exploratory/testing)?
  • Berapa maturity komunikasi tim sekarang?

Kalau jawabannya high volatility, probabilistic, dan communication masih butuh scaffolding—skip Scrum. Pakai Kanban light atau flow-based setup. Fokus ke throughput dan queue reduction. Kalau jawabannya stable spec, low change rate, dan tim udah self-organizing—Scrum mungkin bosenin, tapi masih valid buat alignment. Tapi ingat, framework adalah alat, bukan tuhan.

Gw pernah liat founder startup di Jakarta coba migrasi tim sales plus product ke Scrum strict. Resultnya? Marketing delay, sales komplain quote tidak konsisten, dan CEO stress karena burndown chart merah tiap Jumat. Padahal mereka butuh CRM integration plus fast turnaround pipeline. Framework yang dipakai justru bikin bottleneck baru di tengah-tim, dan alih-alih ngebantu, malah nge-block calendars setiap orang buat meeting yang gak nunjukkin progres nyata.

Intinya: method harus mensempitkan masalah, bukan nggeblet overhead baru. Kalau lo merasa seperti sistem operasi laptop yang berat karena banyak background apps, uninstall dulu yang gak kepake. Keep it lean. Cek berkala apakah ritme kerja lo masih sesuai sama sifat pekerjaan, atau lo cuma ikut-ikutan trend biar feels productive.

Coba minggu ini: bongkar semua ritual weekly meeting tim lo. Tanya satu hal, “Kalau meeting ini hilang besok, apa kerjaan yang bakal langsung macet?” Kalau jawabannya nihil, matikan. Serahkan status update ke async di SatuTim Discussion, dan ganti waktunya buat deep work atau client sync yang benar-benar butuh dialog.

Kalau sprint lo selama ini lebih mirip lomba maraton yang dipaksa lari sirkuit, coba tanya ke tim: metrik apa yang paling bikin lo tidur nyenyak akhir-akhir ini? Cycle time? Client satisfaction score? Atau jumlah hari lo gak buka Slack selepas jam 6 malam? Share di komentar, gw bacaa.