Agile Development

Tahukah kamu bahwa Scrum akan memasuki usia kepala 3? Apakah Scrum masih bermanfaat? Jawaban saya: “tergantung”. Scrum hanya akan menambah kerumitan, jika: Pihak bisnis sudah intens berkomunikasi dengan tim pengembang, dengan ciri-ciri: Semua uneg-uneg langsung terangkat & ditindaklanjuti. Tim pengembang benar-benar memahami alasan bisnis dari setiap fitur yang akan mereka kerjakan. Sudah ada komunikasi intens dengan pengguna-pengguna software, dengan ciri-ciri: Rilis fitur baru yang dalam hitungan minggu, bahkan hari. Menggunakan analytic software untuk membaca prilaku pengguna. Pengguna rutin ditanya pendapatnya terkait fitur-fitur baru &  keluhan-keluhan lain mereka. Temuannya harus bisa jadi landasan mengubah arah pengembangan bulan depan. Tim pengembang sudah berkerja secara transparan, dengan ciri-ciri: Pihak-pihak lain memandang mereka sudah punya etos kerja yang baik. Estimasi mereka atas lama pengerjaan sudah dihargai (maksudnya tidak dilobi-lobi lagi). Produknya berkualitas secara teknis, dengan ciri-ciri: Punya standar kualitas minimal — baik di sisi ‘dapur mesin’ yang tidak terlihat pengguna (contoh: kode software), maupun di sisi […]

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 disebut product-market fit), […]

“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 menghitung variabel uang […]

Agile alias tangkas saat ini sering digunakan sebagai solusi dalam pengembangan program. Awalnya Manajemen Tangkas atau lebih dikenal dengan Agile Management disusun beberapa orang yangberkumpul untuk memecahkan masalah pengembangan software yang lebih baik. Mengapa mereka akhirnya berkumpul? Karena awalnya software dikerjakan dengan metode tradisional yang mana seringkali software developer seringkali menjadi sering ditekan. Dari situ terlahirlah sebuah pakta yaitu Agile Management. Walaupun pembuat awal adalah software developer, sebenarnya dasar pemikiran Agile Management adalah berdasar tindakan LOGIS yang dilakukan manusia dalam menghadapi sebuah permasalahan. Jadi prinsip LOGIS ini tidak terbatas pada pengembangan software saja, tapi juga ke pengelolaan managemen umum. Sebelum terburu-buru mengubah menjadi Agile, sebenarnya ada hal yang perlu diperhatikan: Training for Executive. Pemimpin perusahaan sudah siap untuk berubah dan belajar apa itu Agile Management. Dari situ, para senior ini perlu sampai di titik apakah perbedaan manajemen yang lama dengan manajemen tangkas ini. Fungsinya apa? Executive inilah yang akan merevisi […]

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 pertanyaannya selalu konsisten. […]

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 pekerjaan hanya dikerjakan satu orang, […]

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 ke Anda. Di sana, Anda bisa melihat […]

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 […]

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 klien. 3. Fleksibilitas […]

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…”, Tautan ke Scrum Guide (buku resmi yang menjelaskan Scrum), maka proposal tersebut masuk ke kategori ini. Kemungkinan […]

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 tahu kondisi semua pekerjaan, […]

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 Tinggi & Terjaga […]

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, […]

Kenapa Tiga Pilar Agile Harus Ada dan Populer? Singkatnya, karena dia adalah solusi sesungguhnya bagi pengembangan software yang bermasalah. Berikut elaborasi lengkapnya… Semua orang memulai sebuah bingkai kerja Agile (Scrum/Kanban/XP/SAFe/Less/dll) dengan harapan hidupnya akan jadi lebih baik. Kadang, kenyataan berkata lain. Setelah belajar dan coba mempraktikkan, pertanyaan-pertanyaan berikut tetap muncul: Mana ‘estimasi yang lebih akurat’ itu? Kenapa developer saya tetap banyak yang keluar? Produk lebih sering dirilis, tapi jumlah pengguna kok masih stagnan? Semua aturan Scrum sudah dijalankan berbulan-bulan, apakah Agile itu cuma seperti ini saja? Di titik itu, yang cukup bijak biasanya mulai curiga: “Jangan-jangan ada yang salah di pemahaman saya akan Scrum?” “Jangan-jangan ada yang salah dari tempat/cara saya belajar dulu?“ Sementara yang cukup bijak menunda ambil kesimpulan, sisanya, langsung menghakimi bahwa Agile hanyalah minyak ular terbaru jualan kaum konsultan. Sebagian dari yang bijak mulai datang ke meetup-meetup, demi mencari guru yang mumpuni. Sebagian bahkan langsung mengundang trainer Agile ke […]

Ibu Silvana Wasitova adalah teladan bagi profesional Indonesia. Besar di Indonesia, Bu Silvana pernah jadi Project Manager & Agile Coach di Silicon Valley & Eropa. Silahkan baca Linkedin Bu Silvana untuk lebih detailnya. Apa kunci pencapaian Bu Silvana? Tidak lain dan tidak bukan adalah belajar. Lebih tepatnya, belajar tiada henti. Okay. The devil is in the details, maka pertanyaan berikutnya: seperti apa metode belajar seperti yang efektif? Hanya Satu: Praktik Langsung Teknik belajar yang efektif adalah pratik langsung. Membaca buku bisa membantu orang mendapatkan ide. Tapi ide akan menguap jika tidak dipraktikkan. Mempraktikkan ide-ide baru akan lebih mudah jika didampingi oleh coach. Ada banyak konteks & nuansa di lapangan yang terlewat oleh buku–sebagus apapun bukunya. Di situlah pentingnya peran konsultan eksternal atau peran manajer yang juga seorang coach. Studi Kasus Mungkin ada yang menduga pendapat Bu Silvana di atas cukup bias. Karena profesi beliau sekarang sebagai Entreprise Agile Coach. Jika kamu […]

Tulisan ini pertama kali dipublikasikan di Medium Organisasi Agile. Langgan publikasi tersebut untuk membaca tulisan Rizky lebih awal dari yang lain. Ya, Agile memang aneh — dan manjur. Buku yang ditulis tahun 1987 telah menjelaskan kenapa. Kenapa Agile? Tepat saat esai ini ditulis, warga Indonesia sedang berada di atas ombak transformasi digital: pembayaran online. Promo Gopay & OVO ada di mana-mana. Cukup scan QR code, pembayaran beres. Transfer dana cukup pakai nomor telepon. Tujuan akhirnya, akan seperti yang Dahlan Iskan rasakan saat bayar ke pedangan kaki lima di Cina: bayar dengan uang cash dianggap aneh. Ombak transformasi digital ini bukan yang pertama & terakhir. Sebelum perihal pembayaran, ada Whatsapp dengan grupnya, ada Gojek & Grab dengan kemudahan transportasinya. Setelah pembayaran, entah apa lagi yang akan didigitalisasi. Sekarang, cara hidup kita bisa berubah drastis dalam hitungan 1–2 tahun. Sebagaimana masyarakat Inggris di akhir abad 18 & awal abad 19 terhadap kemunculan mesin uap, kita sedang jadi saksi hidup […]

Ingin pengembangan software kamu sukses? Optimal? Ingin coba dengan cara Scrum? Punya Scrum Master yang baik adalah syarat wajib kesuksesan implementasi Scrum kamu. Saya ulangi: syarat wajib. Di podcast terbaru (episode 2), saya jelaskan panjang lebar tiga pertanda Scrum Master yang buruk: Tidak mengerti Scrum (berdasarkan Scrum Guide) Tidak cukup berani Tidak menghidupi sifat agile dalam dirinya Ya, betul. Poin kedua dan ketiga memang terkait erat dengan karakter. Ingat berdebatan klasik “pemimpin hanya dilahirkan vs pemimpin bisa dididik”?

Design Sprint? Pernah dengar makhluk tersebut? “Uh, kalau ‘Sprint’-nya sih saya sering dengar dari Scrum” Iya. Nampaknya perancang Design Sprint, Jake Knapp, dapat inspirasi nama ‘Sprint’ dari Scrum. Karena memang secara konsep mirip. Sprint di Scrum, adalah rentang waktu singkat untuk fokus menggubah rancangan, menjadi potongan software yang cukup berkualitas untuk digunakan pengguna. Sprint di Design Sprint, adalah rentang waktu singkat untuk fokus mengideasi dan memvalidasi rancangan terbaik dari potongan software. Persamaan: sama-sama singkat, sama-sama fokus, sama-sama bicara tentang potongan kecil dari software, sama-sama berada di dalam keluarga besar agile—yang berarti membuat bisnis lebih tangkas melayani pelanggan. Perbedaan 1, keluaran: Sprint di Scrum keluarannya potongan software yang berkerja, Sprint di Design Sprint keluarannya rancangan yang sudah divalidasi nilai manfaatnya oleh responden dari pengguna. Perbedaan 2, masukan: Sprint di Scrum masukannya rancangan software. Sprint di Design Sprint masukannya bisa 0 atau bisa masalah besar bersama—ini karena proses ideasi sudah berada dalam Sprint. Dari perbedaan tersebut, […]

Agile adalah topik yang cukup kontroversial. Serius! Baru-baru ini terjadi diskusi hangat di Linkedin. Singkatnya, di diskusi Linkedin tersebut, terdapat diskusi panas pro-kontra Scrum, pro-kontra Design Sprint, dll.

Versi singkat opini ini: Perusahaan yang baik, ingin melayani balik pegawai-pegawai yang sudah berkerja keras membangun perusahaan—turn-over tinggi itu biaya yang mahal. Menariknya, umat manusia mulai menyadari, uang bukan segalanya. (baca: menurut penelitian, kebahagiaan anda tidak jauh meningkat dengan gaji lebih dari ini)

Oleh Brian Chesky, CEO dan cofounder Airbnb. Startup yang terkenal rela berjualan sereal agar tetap hidup saat tak ada pendanaan. Hari Senin, 21 Oktober 2013, saya mengirim surat ini ke seluruh tim di Airbnb. Saya sudah memutuskan untuk mempublikasikannya agar pengusaha lain terbantu untuk membangun budaya mereka. Hey tim,   Rapat kita selanjutnya akan difokuskan untuk membahas nilai-nilai inti, yang mana penting sekali untuk membangun budaya kita. Sebelum rapat tersebut, saya pikir saya harus menulis surat, yang menjelaskan kenapa budaya amat penting buat Joe, Nate, dan saya. Setelah kami menutup seri C dengan Peter Thiel pada tahun 2012, kami mengundang beliau ke kantor. Saat itu sedang akhir tahun dan kami semua duduk di ruangan menunjukan berbagai macam metrik. Di pertengahan diskusi, saya bertanya, “apa satu nasihat paling penting untuk kita?” Dia menjawab, “Jangan Rusak Budayamu.”

“Antifragility to business is analogous with fitness and immune system to human body.” “Antifragile is more than agile, lean, or healthy; it’s to grow by (purposely) deal with big and unpredictable problems. In business, it means hurt your company enough so you can must innovate.” “In the first half of 21th century, software is the key of business antifragility“ “The fast, the self-learning, and the flexibility of agile software development are the key, of innovative and disruptive software.” “Moreover, you can must also adapt the core values of agile software development to your general organization. The practices will increase your organization agility, to thrive on antifragile way of life.” Which one were you?