Pilar Kedua Agile Software Development: Build-Measure-Learn, Baik atas Produk Maupun Proses

Navigasi esai: | Intro & Pilar 1 | Pilar 2 | Pilar 3 (bagian 1) | Pilar 3 (bagian 2)


Sebelum menjabarkan isi pilar kedua, mari kita bahas apa itu Build-Measure-Learn (BML). Karena mungkin ada teman kita yang baru mendengar.

BML adalah siklus pembelajaran yang dilakukan semua organisasi:

  • Build adalah eksekusi rencana perbaikan,
  • Measure adalah pengukuran dampak-dampak dari Build,
  • Learn adalah penarikan kesimpulan dari hasil Build & Measure guna memutuskan apa yang akan di-Build di iterasi berikutnya.

Kalau Anda pernah ikut rapat tahunan perusahaan, berarti Anda pernah ambil bagian dalam BML—tentu hanya jika hasil Build & Measure tersedia dan Learn-nya dibahas di sana.

Rapat tahunan perusahaan adalah aktifitas BML pada organisasi. Karena produk dari organisasi adalah proses kerja mereka.

Bagaimana dengan aktifitas BML pada software? Mungkin teman-teman sudah mulai melihat polanya: mayoritas kegiatan di Scrum, Kanban, & XP—bingkai kerja dasar Agile Software Development—tidak lain tidak bukan adalah aktifitas BML.

Sebuah proyek waterfall (non-Agile) sendiri bisa dipandang sebagai satu iterasi BML, perbedaannya ada di frekuensi siklus. Satu iterasi BML di gaya waterfall bisa tahunan. Di gaya Agile, satu bulan adalah waktu iterasi yang paling lama—yang mana terkait ke pilar pertama (Rilis yang Segera).

Kalau mayoritas isi bingkai kerja Agile Software Development adalah cara melakukan BML pada software, maka sisanya untuk apa? Jawabannya, BML pada organisasi pembuat software. Mari kita ambil contoh Scrum. Kita bisa lihat, Sprint Planning, Development, Sprint Review adalah BML pada software (produk). Sementara Sprint Retrospective & Daily Scrum adalah BML pada organisasi pembuat software (proses).

Itulah definisi BML dan kenapa ada BML di sisi produk dan proses.

Sisi Produk

“Anda bisa saja sudah sering rilis, tapi itu akan sia-sia jika yang sering dirilis itu keren-hanya-menurut-bos.”

Masalah e: Bos yang Semua Maunya Harus Dituruti

Bos, pemilik, presiden. CEO, walikota, atau apapun namanya, semua punya satu benang merah. Semua merasa akan jadi orang pertama yang digantung, kalau organisasinya gagal.

Agar tidak gagal, mereka biasanya memimpin inisiatif inovasi. Kebetulan di zaman sekarang, inovasi seringnya berwujud software. Tidak ada yang aneh.

Sampai…

  1. Mereka hampir selalu jatuh cinta dengan ide inovasi mereka, dan
  2. Mereka (kebetulan) adalah juga pimpinan.

Kenapa masalah? Bukankah itu memang tugas pimpinan? Mengatur organisasi sesuai visi-misi-nya? Sesuai maunya mereka?

Memang. Sayangnya, mengembangkan software itu tidak sama dengan mengurus operasional: mengatur jadwal kerja kurir, mencari orang untuk mengisi jabatan kosong, memilih vendor untuk mengadakan barang/jasa, dan pekerjaan-pekerjaan umum lainnya (masalah ‘rumit’ di teori Cynefin). Mengembangkan software itu adalah kegiatan R&D alias riset dan pengembangan, yang mana peluang gagalnya jauh lebih besar (masalah ‘kompleks’ di teori Cynefin). Jadi, tidak bisa sekedar bilang “jangan banyak tanya, pokoknya bos bilang harus seperti ini”.

Masalah pemimpin-yang-memaksakan-eksekusi-idenya-tanpa-riset ini jadi makin parah saat ide-idenya besar-besar. Kenapa? Karena jadi tidak bisa rilis segera. Ingat masalah a di pilar pertama?

Solusi:

  • Biasakan menggunakan format User Story untuk mendeskripsikan pekerjaan. Di sebuah user story, manfaat dari sebuah fitur ke pengguna harus jelas tertulis.
  • Terapkan proses kerja yang memungkinkan ide muncul dari mana saja. Di proses kerja tersebut, ide-ide akan diriset terlebih dahulu ke pengguna sebelum bermuara ke antrian pekerjaan. Tentu, akan jadi keributan kalau semua pihak bisa langsung mengubah arahan produk. Maka harus ada satu orang yang memimpin kegiatan riset ini. Di Scrum, dia biasa disebut Product Owner. Semua orang di organisasi—CEO termasuk—diwajibkan menghargai keputusan Product Owner.
  • Jika Anda membuat software untuk klien, edukasi juga bos klien agar mengecilkan lingkup proyek—solusi yang sama untuk masalah a di pilar 1. Jadikan proyek sebagai satu siklus BML yang kecil.

Masalah f: Pengguna yang Tidak Didengar

Masalah f ini salah satu penyebabnya adalah masalah e (bos yang tidak empirik). Banyak sekali yang mengaku Agile, tapi tidak mendengar penggunanya—bahkan tidak mengidentifikasi siapa mereka.

Saat menulis artikel ini, saya membuka aplikasi Tokopedia dan cukup terkejut. Ada instruksi untuk melakukan swipe dua jari dari samping kanan layar, sehingga saya bisa memasukan komplain atau ide terkait aplikasi.

Swipe dua jari dari kanan, dan temukan ini.

Saat ada yang tidak kita suka dari aplikasi, kita bisa melakukan hal tersebut—di setiap halaman di aplikasi Tokopedia.

“Keren! Kenapa baru sekarang ya Tokopedia pasang Instabug?”, itu yang saya bilang dalam hati.

Instabug belum sempurna. Masalah yang mungkin muncul, adalah pengguna yang lupa. Di masa depan, saat kesal dengan aplikasi, pengguna mungkin sekali lupa bahwa dia bisa komplain di Instabug.

Sekedar informasi tambahan: cara mendengar pengguna ada banyak. Selain Instabug yang sifatnya menunggu, ada pula borang pop-up yang langsung menjemput pengguna dengan menanyakan kesan atas perubahan terbaru. Selain via software, pendapat pengguna bisa digali via tatap muka langsung. Minat bidang ini? Langgankan email kamu di topik User Research Agile Campus.

Borang pop-up yang muncul tiba-tiba.

Solusi:

  • cari tahu tentang cara-cara meriset pengguna;
  • terapkan.
  • meski produk belum dirilis, rekrut beberapa pengguna awal yang berkomitmen untuk menggunakan produk dan memberikan pendapat yang jujur. (Beta User)

Sisi Proses

“Produk yang baik hanya muncul dari proses kerja yang baik. Maka, proses kerja wajib terus diperbaiki.”

Masalah g: Retrospektif yang Tidak Berjalan

Bagaimana cara memperbaiki proses kerja? Retrospektif.

Retrospektif adalah pertemuan singkat yang rutin terjadwal—paling lama tiap bulan, dengan tujuan mengangkat semua keluhan anggota tim, guna menentukan beberapa eksperimen perbaikan, untuk ditinjau dampak eksekusinya di retrospektif berikutnya.

Banyak yang mengaku Agile, tapi tidak melakukan retrospektif rutin. Padahal retrospektif adalah jalan untuk meningkatkan ketangkasan tim. Masalah g ini bersaing dengan masalah f (pengguna yang tidak didengar), sebagai faktor utama penyebab banyaknya Fake Agile.

Kira-kira kenapa? Tentu bukan karena tidak tahu. Jelas-jelas retrospektif ada di Scrum. Sepengamatan saya, mayoritas tim meninggalkan retrospektif karena tidak lagi percaya akan efektifitasnya. Biasanya karena:

  • Tidak didukung pimpinan
    Bayangkan di sebuah sesi retrospektif diidentifikasi sebuah masalah. Masalah ini spesial. Penyebabnya ada di luar tim, sehingga hanya direktur yang bisa menghilangkannya. Sayangnya, karena satu atau banyak hal, direktur tidak bisa menanggapinya dengan baik. Sehingga dari retrospektif ke retrospektif, tidak pernah ada solusi. Tim akhirnya frustasi. Contoh masalah di tipe ini:

    1. Masalah e (CEO tidak menghargai riset PO dalam mengatur produk),
    2. Masalah a (rencana yang terlalu besar),
    3. Divisi marketing selalu menjanjikan sesuatu tanpa koordinasi dengan tim pengembang, atau
    4. Tim developer yang tidak diperbolehkan mengestimasi sendiri pekerjaan mereka (salah satu pelanggaran Scrum paling populer).

    Ini adalah kasus nyata kenapa pemahaman dan dukungan pimpinan itu wajib ada.

  • Tim tidak cukup nyaman untuk transparan
    Ada tingkah satu developer yang menyebalkan buat yang lain, tidak ada yang berani mengangkat. Product Owner tidak suka dengan kebiasaan seorang developer yang nonton Netflix di jam kerja, beliau hanya berani curhat ke Scrum Master. Tim developer tidak puas dengan cara Product Owner melakukan riset produk, tapi semua bungkam. Jika itu terjadi, fasilitator retrospektif—biasanya si Agile Coach atau Scrum Master—harus memperbaiki metodenya. Kunci pertama Agile adalah retrospektif. Kunci pertama retrospektif adalah terangkatnya masalah.

Solusi:

  • Jangan menyerah berusaha sampai pimpinan tertinggi paham & mendukung Agile.
  • Ajak Product Owner (dan timnya) untuk ikut di sesi retrospektif—banyak yang tidak tahu kalau Scrum mewajibkan ini.
  • Jika kamu Agile Coach atau Scrum Master, pastikan pihak-pihak lain cukup nyaman dengan diri kamu sehingga mereka mau curhat secara personal. Sehingga kamu bisa membayangkan retrospektif yang ideal harusnya mengangkat masalah apa saja.
  • Maksimalkan alat survei anonimus untuk retrospektif. Menghilangkan identitas akan membantu orang untuk terbuka di grup.

Masalah h: Terlalu Pasif untuk Self-Organization

Saya sering mendengar pesimisme berikut: “Agile tidak akan berjalan di Indonesia, orang Indonesia itu terlalu pasif”. Setuju? Apapun jawaban Anda, kita seyogyanya sepakat: sikap pasif adalah pintu masuk untuk ribuan masalah lain. Karena menyebabkan orang-orangnya jadi:

  • kurang percaya diri,
  • kurang inisiatif,
  • kurang kreatif,
  • tidak terbuka (ingat masalah g?).

Hasilnya: retrospektif tidak akan berjalan baik, self-organization yang dicita-citakan Agile hanya jadi utopia.

Kecil kemungkinan ‘budaya pasif’ ini teridentifikasi sebagai masalah di retrospektif. Itu karena Product Owner & Tim Developer sendiri tidak menyadarinya. Masalah bersemayam di alam bawah sadar, di level budaya. Tersebar ke seluruh perusahaan lewat pilihan kata, mimik muka, gestur tubuh, peraturan perusahaan, pemilihan KPI, & mekanisme promosi jabatan.

Apa akar masalah dari ‘budaya pasif’? Tidak lain dan tidak bukan, adalah karena ‘tidak cukup rasa aman bagi orang untuk menjadi aktif’. Singkatnya: ‘kurangnya otonomi’.

Bayangkan kita di posisi ini:

  • Menyuarakan perasaan, malah di-bully semua anggota tim;
  • Mencoba sesuatu yang baru, hanya dipermalukan saat gagal;
  • Menyarankan ide baru ke bos, ide ditolak dengan defensif & penjelasan yang tidak rasional;
  • Melakukan kesalahan, habis dimaki-maki di depan orang banyak;
  • Punya kontribusi krusial di sebuah inisiatif, kredit dicuri semua oleh bos—bahkan tidak ada kolega yang mengapresiasi.

Apa hasilnya? Tentu, kita jadi takut bertindak & takut bersuara.

Ini bukan masalah individu. Tidak ada orang yang bisa diperintah “jadi lebih aktif ya”.

Ini masalah budaya perusahaan. Artinya, solusi hanya ada di kendali CEO. Agar budaya bisa bergeser, CEO harus membuat gebrakan dengan menunjukkan dirinya:

  • Rutin mendengar keluhan dan saran semua lapis pegawai;
  • Rutin mencari solusi untuk meminimalisir keluhan;
  • Tidak malu mengakui di depan pegawai saat eksperimennya gagal;
  • Melakukan hal-hal di atas secara transparan & komunikatif;
  • Menegakkan mekanisme evaluasi & promosi yang berdasarkan data empirik.

Dengan kata lain, CEO harus menahkodai perusahaan secara Build-Measure-Learn.

Solusi:

Perlu diulangi? CEO harus menjadi suri tauladan, dengan menahkodai perusahaan secara BML. Baru setelah itu semua manajer dan pegawai mencontoh & menjiwai, sehingga mereka menegakkan BML di divisi/unit masing-masing. Yang mana, tidak lain tidak bukan, adalah self-organization itu sendiri.

Tiga penyebab utama kegagalan transformasi Agile berada langsung di bawah kendali CEO. Sumber: survei Version One (2018)


Masalah e, f, g, h di atas hanyalah beberapa contoh. Terpikir masalah lain yang memperlambat gerak organisasi? Atau punya pengalaman pribadi? Tulis kotak komentar di bawah ya… 🙂

Selanjutnya: pilar ketiga. (Tulisan masih kami masak, daftarkan email Anda di http://eepurl.com/ghFmBX agar kami beritahu saat sudah siap.)

Product Manager dari Learn.AgileCampus.org

Sorry, the comment form is closed at this time.