Artikel ini adalah lanjutan dari Analogi Kapal: Cara Termudah Menjelaskan "Apa Itu Agile?" Apa itu "Analogi Kapal" dan beberapa terminologi di artikel ini dijelaskan di artikel tersebut. Analogi Kapal Bagus Karena Tiga Alasan Berikut: 1. Menempatkan 'Agile' di Tempat yang Tepat Saya sering bertemu dengan orang yang yakin semua pengembangan software harus Agile — lagi-lagi mungkin karena definisi 'Agile' dia berbeda dengan saya. Fanboy seperti mereka biasanya akan sulit menjelaskan definisi Agile ke orang-orang yang konvensional. Karena biasanya mereka akan terdengar menyerang. Padahal faktanya, 'Agile' itu merujuk ke 'praktik-praktik Agile'. Yang mana Scrum, Kanban, dll adalah bungkusan praktik-praktik kerja. Praktik-praktik tersebut hanyalah sekumpulan senjata yang pas di suatu kondisi — namun kurang pas di kondisi lain. Berikut kondisi-kondisi saat praktik-praktik utama Agile jadi kurang pas di sebuah pengembangan software: Setelah Product-Market Fit Software yang sudah melewati masa eksplorasi, lalu cukup matang untuk rutin digunakan pengguna tanpa banyak komplain (biasa

"Agile", sebuah kata abstrak multi-tafsir yang bisa menimbulkan pertentangan di sebuah organisasi. Kalau definisinya saja orang-orang masih belum sepakat, bagaimana bisa jalan? Bankwest di Australia sampai mengumpulkan seluruh pimpinan (20-an orang) di satu ruangan, dan dilarang bubar sampai sepakat akan 'Agile' versi mereka. Mudah-mudahan setelah membaca tulisan ini, Anda tidak lagi bingung. Bahkan Anda bisa dengan mudah mengajarkan definisi Agile ke orang lain. Syarat pertama adalah memahami dulu, bahwa hanya ada dua jenis mode pekerjaan di bawah kolong langit ini. Pekerjaan Kapal Ferry Kita semua tahu, sebuah Kapal Ferry ditugaskan pemiliknya untuk mengantarkan penumpang dari satu pelabuhan ke pelabuhan lain. Seperti kereta api, jadwalnya juga sudah jelas. Di tengah jalan mungkin saja ada masalah. Mungkin jalur jadi berputar sedikit — bahkan perlu singgah darurat di pelabuhan lain dulu. Tapi yang pasti, titik akhir pelabuhan tidak berubah. Kru-kru kapal dapat gaji tetap. Peluang gagal rendah, tapi — jika hanya

Seorang teman mengaku kalau panjang Sprint-nya tidak konsisten. Dia bilang normalnya satu minggu, tapi kadang bisa lebih beberapa hari. Masalahnya, perusahaan dia mengaku pakai Scrum. Sementara Scrum Guide mewajibkan panjang Sprint yang konsisten. "Lalu kenapa memang Scrum bilang 'konsisten' lebih baik?". Jawabannya penting diketahui, agar tidak bertaklid pada Scrum Guide. Jadi, kenapa? Ada banyak alasan. Tapi yang paling utama adalah: Melatih estimasi tim developer agar lebih akurat. Pihak bisnis ingin sekali punya DT yang bisa akurat estimasinya. Dengan begitu, mereka jadi lebih PD dalam mengambil peluang bisnis & membuat deal-deal dengan pihak luar. Apakah berarti DT-nya tinggal jadi super pesimis & kasih 'buffer' sebanyak-banyaknya? Jadi, kalau selesai lebih cepat bisa main game diam-diam? Tentu tidak. DT wajib kerja optimal 8 jam sehari sesuai kontrak, namun tetap akurat estimasinya. Bagaiman Sprint yang konsisten bisa membantu? 1. Melatih DT untuk mengukur kapasitas mereka per-X-minggu Karena di setiap awal Sprint

Pusing dengan Scrum? Ingin coba sebuah bingkai kerja Agile yang super simpel? Buat saja sebuah papan Kanban. Caranya mudah. Pertama, bayangkan langkah-langkah pekerjaan Anda—dari awal sampai akhir. Sekedar contoh, berikut langkah-langkahnya jika pekerjaannya membuat software: deciding (meriset apakah dari sisi bisnis sebuah fitur layak disegerakan), detailing (mendetailkan fitur apa yang diinginkan bisnis), developing (membuat fitur), acceptance testing (pengujian akhir sebelum rilis), deploying (rilis). Setelah dipetakan, buat sketsa papannya di kertas terlebih dahulu. Lalu. coba tentukan mana-mana saja yang waktu pengerjaannya bisa sebentar dan satu langkah. Dalam contoh ini, kita menilai hanya 'deploying' yang memenuhi kriteria tersebut. Karna selain 'deploying' dirasa tidak sebentar dan lebih dari satu langkah, buat garis pembagi di masing-masing kolom. Isi dengan 'in progress' dan 'done'—atau istilah lain yang berkesuaian. Buat aturan main seperti berikut: Perbarui papan kanban secara real-time. Masukan kartu ke 'in progress' hanya jika akan langsung dikerjakan. Artinya, jika satu

Ini adalah hukum alam: permintaan fitur hampir selalu melebihi kapasitas produksi developer. Artinya, seorang Product Owner (PO) harus bisa menolak, dan membuat paham & tenang orang-orang yang permintaannya ditolak. Bagaimana? Ada banyak cara, tapi yang utama adalah transparansi Product Backlog (PB). Contoh Kasus Anda adalah pimpinan tim entri data di perusahaan. Sekarang adalah awal bulan. Tim Anda punya target  A di setiap akhir bulan. Dengan cara manual saat ini, tim Anda butuh waktu kurang lebih dua minggu untuk menyelesaikan target A—masih sangat aman sebenarnya. Muncul ide fitur baru, yang bisa mempersingkat pengerjaan target A dari 2 minggu menjadi 3 hari. Setelah dihitung-hitung, Anda butuh fitur X, selesai selambat-lambatnya di petengahan minggu kedua bulan ini. Kenapa? Karena jika ternyata ada masalah, masih ada minggu ketiga & keempat untuk entri data dengan cara lama. Anda datang ke PO, beliau menolak. Sebelum Anda melobi, PO menunjukkan PB

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

Lanjutan dari tulisan Kesalahan Populer saat Menulis Scrum di Proposal. 1. Kelebihan Scrum dibanding Cara Konvensional "Apa untungnya buat saya?" Pembaca proposal bisa jadi belum tahu Scrum, atau bahkan, punya pandangan buruk. Buka proposal dengan keunggulan Scrum, sehingga mereka makin tertarik membaca. 2. Otoritas Penuh Product Owner dalam Arah Produk & Riset Pengguna Salah satu konsep paling revolusioner di Agile Software Developement adalah keberadaan Product Owner / Product Manager. Di manajemen konvensional ada Project Manager. Tanggung jawabnya hanya memastikan inisiatif pimpinan dieksekusi dengan baik sesuai rencana. Terlihat perannya berbeda sekali dengan Product Owner. Di sisi lain, janji Scrum adalah nilai manfaat produk yang setinggi-tingginya. Kuncinya, juga ada di peran Product Owner. Maka, pastikan perannya dijelaskan dengan baik & ringkas di awal. Pro tips: Cantumkan nama orang yang diproyeksikan mengisi peran Product Owner. Ini akan memudahkan pembaca membayangkan implementasi. Jika hubungannya adalah klien-vendor, usahakan Product Owner ada di sisi

Tulisan ini akan membantu Anda menyelamatkan proyek/inisiatif Anda—mulai dari proposalnya. Sepengamatan saya, banyak implementasi Scrum yang sudah bermasalah sejak dalam kandungan. Um, maksudnya, sejak dalam proposal. Kita semua tahu, baik di hubungan kerja klien-vendor eksternal ataupun lintas divisi internal, semua inisiatif dimulai dari proposal. Proposal memicu pembahasan proses kerja (baca: cara berkomunikasi & berkoordinasi). Semua pihak berdiskusi mencari win-win solution. Hingga akhirnya disahkan di kontrak kerja. Scrum sendiri—sebagaimana sebuah proses kerja—tentu harus dibahas & disepakati implementasinya di awal. Berikut dua kesalahan populer saat menjelaskan Scrum di proposal—dilanjutkan dengan solusinya. 1. Tidak Detail Karena Berasumsi Semua Orang Membaca Scrum Guide Bila melihat proposal yang bagian metode kerjanya hanya berisi: Pernyataan bahwa pengembangan akan memakai Scrum, Definisi Scrum yang dikutip dari Scrum Guide: "Scrum (kb): Sebuah kerangka kerja dimana orang-orang dapat mengatasi masalah kompleks adaptif, dimana

Navigasi esai: Intro & Pilar 1 | Pilar 2 | Pilar 3 (bagian 1) | Pilar 3 (bagian 2) (Sambungan dari bagian 1) Navigasi poin masalah: l) Pengetahuan yang Kurang Tersebar m) Banyak Gangguan saat Berkerja n) Developer Masih Dicekoki Deadline Masalah l: Pengetahuan Kurang Tersebar "Ingin memperlambat jalannya pengembangan? Gampang. Tambahkan saja programmer baru." Orang IT tentu familiar dengan pernyataan di atas. Berbeda dengan pekerja pembangun rumah, menambah developer tidak akan langsung meningkatkan kecepatan pengembangan. Kenapa? Karena ada jauh lebih banyak pengetahuan yang perlu diserap oleh developer baru, dibanding tukang bangunan baru. Mulai dari sisi bisnis produk, arsitektur software, gaya menulis kode, teknologi-teknologi baru, workflow tim, bingkai kerja tim, sampai tentunya, basis kode software. Kecil kemungkinan ada satu orang di tim, yang bisa mengajarkan seluruh basis kode software. Biasanya, si anak baru perlu bertanya ke beberapa orang. Pengetahuan untuk mengerjakan software tersebar di banyak kepala. Tidak ada mandor yang

Navigasi esai: Intro & Pilar 1 | Pilar 2 | Pilar 3 (bagian 1) | Pilar 3 (bagian 2) Jika hanya membaca pilar 1 & pilar 2, programmer pemula pasti langsung khawatir, "kalau requirement bisa berubah drastis—apalagi dipaksa rilis setiap minggu—pasti fase testing dikorbankan. Kode juga jadi berantakan. Agile ini lebih neraka dari waterfall." ~ seorang programmer pemula Mereka tahu 3 bulan lagi, kode program mereka sendiri akan seperti sphagetti. Cukup berantakan hingga mereka kesulitan menulis kode fitur baru. Mereka tahu akan dibangunkan tengah malam, karena harus memperbaiki bug fitur pembayaran yang merugikan kas perusahaan. Jangan sampai ketangkasan Agile Software Development justru membuat perusahaan rugi milyaran rupiah, karena bug yang krusial, serta penurunan performa developer. Lebih-lebih, membuat developer mengundurkan diri. Ingat pilar 1? Makin lambat tim developer berkerja, makin sulit untuk tangkas. Untuk itu, Agile Software Development butuh pilar ketiga. Pilar yang umumnya diketahui & dikuasai programmer tingkat ahli. Pilar 3: Kualitas Teknis yang