Apa tugas utama Scrum Master atau Agile Coach? Kegiatan sehari-harinya apa saja? Apa saja ilmu-ilmu minimal yang harus dikuasai? Lalu apa saja agar bisa dianggap pakar? Bagaimana saya bisa memilih Agile Coach yang bagus untuk perusahaan saya? Langkah-langkah apa yang harus saya lakukan setelah ditunjuk jadi Agile Coach? Punya salah satu pertanyaan di atas? Atau semuanya? Tenang, Anda tidak sendiri. Anda punya banyak teman. Rangkaian tulisan ini akan menjawab pertanyaan-pertanyaan di atas. Bukan dengan teori bin konsep, tapi dengan cerpen. Berikut daftar isi cerpennya: 0. Intro (tulisan yang Anda baca sekarang) 1. Menjadi pendengar (sedang ditulis)

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

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

Navigasi esai: | Intro & Pilar 1 | Pilar 2 | Pilar 3 (bagian 1) | Pilar 3 (bagian 2) Semua orang memulai Scrum/Kanban/XP/SAFe/Less/dll dengan harapan hidupnya akan jadi lebih baik. Kadang, kenyataan berkata lain: Mana 'estimasi yang lebih akurat' itu? Kenapa developer saya tetap banyak yang keluar? Produk lebih sering dirilis, tapi jumlah pengguna masih stagnan..  Di titik itu, biasanya kita mulai curiga: Jangan-jangan ada yang salah di pemahaman saya akan Scrum/Kanban. Sebagian dari kita mulai datang ke meetup, sebagian bahkan langsung mengundang trainer ke kantor. Berharap bisa ditunjukkan jalan yang lurus mengenai Agile Software Development. Rangkaian artikel tiga pilar ini, memiliki tujuan yang sama: menunjukkan jalan lurus penerapan Agile Software Development. Saya berharap semua Agile Coach, Scrum Master, Product Owner, dan Developer yang membaca, bisa mengecek kesehatan & ketangkasan timnya. Untuk CEO dan investor yang membaca tulisan ini, saya berharap inisiatif produk/proyek apapun di dalam benak bapak/ibu statusnya

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

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