Saat Mereka Menolak Agile
Tulisan ini menjelaskan apa yang tidak bisa dikompromikan di rangka kerja Agile.
Di tulisan sebelumnya, Poin-Poin Inti Scrum yang Harus Ada di Proposal, kita bicara kondisi ideal. Kondisi di mana, seluruh poin-poin inti Scrum bisa diperjelas & disepakati oleh semua pihak.
Kali ini, kita fokus ke skenario buruk:
Bagaimana kalau, saat pembahasan draf proposal, ada yang pihak yang tidak setuju dengan beberapa poin implementasi Agile?
Bayangkan posisi kita sebagai Scrum Master (atau Agile Coach jika tidak menggunakan Scrum). Timbul pertanyaan dalam benak kita:
- Apakah kita harus hantam terus? Ancam akan mundur kalau tidak sesuai Scrum/Kanban/XP?
- Atau berkompromi?
Akar kedua pertanyaannya tersebut sebenarnya sama:
Di pengembangan gaya Agile, mana saja aturan yang tidak bisa dikompromikan?
Menurut saya pribadi, jawabannya adalah: Product Owner & Product Backlog-nya yang jelas. Dua itulah yang harus ada di awal. Selain dua itu, pelan-pelan bisa diedukasi sambil jalan.
Kenapa? Ada empat alasan:
1. Pekerjaan fleksibel berubah, karena ada Product Backlog.
Inti Agile (baca: tangkas) ada di sini. Di tiga pilar Agile, ini ada di pilar kedua.
Tentu orang bisnis akan suka, kalau mereka bisa mendapatkan apapun yang dibutuhkan di masa depan—yang berarti belum terpikir sekarang.
Masalah muncul jika mereka tetap mengunci fitur-fitur di kontrak kerja. Padahal secara harfiah itu jelas-jelas berkontradiksi dengan fleksibilitas Product Backlog.
Banyak yang bilang ini fenomena terbiasa-gaya-waterfall. Saya tidak setuju. Mereka orang pintar. Mereka paham kontradiksi. Kalau buat saya, ini fenomena takut-etos-kerja-tim-developer-buruk. Seandainya mereka sudah percaya dengan profesionalitas & kemampuan estimasi tim developer, tentu tidak perlu mengunci fitur-fitur di kontrak.
Jika masih ingin mengunci daftar pekerjaan di kontrak—karena belum percaya dengan etos kerja tim developer—buat kontrak kerja kecil (1-3 bulan) antar mereka. Dari situ, orang bisnis akan mengetahui langsung profesionalitas tim developer.
Pro tips: Di kelas training atau di meja konsultasi, saya suka sekali memakai analogi renovasi rumah. Bahwa kita sebagai pemilik rumah, cenderung enggan membayar berdasarkan waktu (harian) saat belum kenal dengan si tukang. Kalaupun kita bayar, kita ingin sering mengintip-intip untuk melihat bagaimana mereka berkerja saat tidak ada kita. Gunakan analogi tersebut untuk memudahkan proses edukasi.
2. Satu pintu, karena ada Product Owner
Hilangnya kontrak kerja yang mengunci daftar pekerjaan (waterfall), bisa membuka akses ke semua pihak untuk mengubah software. Karena di gaya kerja sebelumnya, kontrak dijadikan acuan.
Makin besar organisasi, makin banyak pihak-pihak yang berkepentingan, makin besar kemungkinan kehebohan terjadi. Semua berebut menambahkan/merubah fitur.
Untuk itu, Product Backlog saja tidak cukup. Harus ada Product Owner, sebagai satu orang pengambil keputusan. Istilah kerennya: Person in Charge. Semua pihak menjelaskan kebutuhannya ke satu orang: Product Owner.
Dengan begitu, produk jadi terarah & tim developer tidak stres melayani banyak orang.
Pro tips: pilih kandidat Product Owner yang 1) cukup punya otoritas & karisma sehingga keputusannya dihargai; 2) cukup punya waktu untuk mengurus produk di lapangan; 3) cukup punya pengalaman programming untuk tidak menekan tim developer dengan beban kerja yang berat. Ini jadi penting saat kita hanya bisa menerapkan Product Backlog & Product Owner1.
3. Estimasi tim developer lebih akurat, karena Product Backlog -nya cukup jelas
Bagian ini lebih ke kualitas implementasi Product Backlog.
Dengan rencana pekerjaan yang detail saja, tim developer sudah dihadapkan segudang hal-hal tidak terduga. Apalagi kalau recana pekerjaannya belum jelas di awal?
Masalahnya, Product Backlog memungkinkan rencana pekerjaan berkembang secara evolusioner. Jika kurang detail, mustahil buat developer bisa mengestimasi dengan akurat—karena banyaknya revisi di tengah pengerjaan. Di sisi lain, mendetailkan semua ide fitur yang ada di Product Backlog jelas-jelas melanggar Agile.
Bagaimana cara mengelola Product Backlog dengan baik?
- Definisikan target rilis terdekat.
- Coba buat lingkup target tersebut sekecil-kecilnya (Masih ingat konsep Minimum Viable Product/Feature?)
- Fokus detailkan rencana pekerjaan dari target rilis terdekat tersebut.
Siapa yang harus memimpin orang-orang untuk melakukan langkah di atas? Tidak lain dan tidak bukan, Product Owner.
4. Tim Developer jadi Lebih Berani Menolak, karena Product Backlog-nya cukup jelas.
Selain etos kerja yang profesional, yang dibutuhkan pihak bisnis ke pihak teknis adalah akurasi estimasi. Dengan begitu, mereka bisa mudah mengelola langkah-langkah strategis—dan pada akhirnya—ekspektasi mereka sendiri.
Masalahnya, tim developer2 sering tidak berani berbicara apa adanya. Di depan bilang “ahsiap bisa bos!”, di belakang “#$&$#% !!!”. Ujung-ujungnya, pihak bisnis kecewa.
Banyak faktor memang, yang menyebabkan fenomena ini ada. Salah satu yang terbesar adalah ketidakdetailan pekerjaan di awal.
Dengan adanya Product Backlog yang jelas—dan satu orang yang akuntabel & siap sedia untuk mengklarifikasi—tim developer jadi merasa lebih aman untuk berbicara apa adanya. Kalau memang ekspektasi Product Owner tidak memungkinkan, mereka akan dibilang “tidak memungkinkan” ke beliau.
Pro tip: Edukasi Product Owner untuk tidak menekan tim developer, agar menerima jumlah pekerjaan seperti yang beliau mau. Bahkan dalam bentuk ‘bercadaan’ alias ‘lobi halus’. Contoh: “kalau kamu bisalah satu jam beres”. Aksi tersebut bisa membuat tim developer tidak jujur atas penilaian kapasitas diri mereka. Sehingga sulit untuk melatih diri mereka dalam memberikan estimasi yang akurat. Artinya, yang rugi adalah Product Owner juga.
Dari empat poin di atas. Terlihat bahwa aktor utama dari pengembangan produk, adalah Product Owner & Development Team. Mereka mewakili pihak bisnis & pihak teknis.
Agile, waterfall, atau gaya kerja apapun, bertujuan mengharmoniskan kedua pihak tersebut. Membuat ekskpetasi keduanya, tidak terlalu berjarak dengan realita.
Agile mengejarnya lewat komunikasi yang intens dan jujur, dimulai di pihak-pihak intinya (Product Owner & tim developer), dengan bantuan Product Backlog. Tanpanya, jangan mau jadi seorang Agile Coach.
- Ingat, dalam kasus ini, kita belum bisa melakukan aturan Sprint & Sprint Goal, atau aturan Work in Progress Limit di rangka kerja Kanban. Kita sebagai Agile Coach harus memastikan tim developer bisa berkerja dengan laju yang berkelanjutan (pilar ketiga).
- Penasaran kenapa saya selalu menyebutnya ‘tim developer’, bukan ‘tech lead’? Itu karena akurasi estimasi seluruh anggota tim yang mengerjakan akan lebih akurat dari estimasi seorang bos.
