By
Agile Development, Software Engineering

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

By
Agile Development

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

By
Agile Development, Agile Operational, Software Engineering, User Research

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

By
Agile Development, Agile Operational

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. [caption id="" align="aligncenter" width="460"] Kaum Luddite muncul di awal abad 19 dengan satu tujuan: menghancurkan mesin-mesin yang mencuri pekerjaan mereka di pabrik. Ingat demo supir taksi Bluebird

By
Agile Development, Crash Course

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:

  1. Tidak mengerti Scrum (berdasarkan Scrum Guide)
  2. Tidak cukup berani
  3. 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”?

By
Agile Development, Crash Course, User Research

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 software1 yang cukup berkualitas untuk digunakan pengguna.

Sprint di Design Sprint, adalah rentang waktu singkat untuk fokus mengideasi dan memvalidasi rancangan terbaik dari potongan software2.

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, bisa dinilai kalau Scrum dan Design Sprint adalah dua makhluk berbeda, yang menyelesaikan masalah yang berbeda.

Jadi Apa Itu Design Sprint?