By
Agile Development

Menghitung story points dari durasi jam selalu beresiko terjadi korupsi waktu alias dilambat-lambatkan. Biasa dikenal dengan sebutan Parkinson's Law. Memang di zaman product management sebelum Agile metode dulu akurasi dan predictability itu sesuatu yang bagus. On time, on budget itu adalah bola yang disasar. Nah pas kita sudah mencoba masuk ke Agile dan emang benar-benar mampu menerapkan value-valuenya maka di otak kita itu adalah memaksimalkan value dari product yang sedang kita kembangkan. Tentunya pengembangan produk di Agile sifatnya berkelanjutan jadi tidak ada target waktu, yang ada adalah terus menerus meningkatkan value.  Tentunya di awal-awal penerapan Agile wajar ditemukan kondisi “Oh ternyata estimasinya salah, wah ngerjain lebih cepet, waduh jadi ada waktu kosong nih" Kondisi ini sebenarnya bisa untuk mengerjakan sprint berikutnya, tugas berikutnya ditarik untuk dikerjakan karena toh tugas tersebut memang sudah didetailkan oleh Product Owner. Jadi mindsetnya udah berubah soal thrive

By
Agile Development

Product owner wajib memastikan requirementnya itu cukup detail buat developer dan dirinya sendiri. Kedetailannya itu harus dipastikan oleh dia atau syukur-syukur product owner itu bisa dibantu oleh orang lain. Sehingga sebagai product owner, dia bisa mendelegasikan pendetailan itu ke orang lain tapi tetap yang namanya delegasi, akuntabilitas itu sebenernya ya di posisi si product owner. Lengkapnya bisa ditonton di Youtube:  [embed]https://www.youtube.com/watch?v=FI9ndphXniE[/embed]

By
Agile Development

Perihal Scrum Master bisa jadi Product Owner sebenarnya sudah pernah kami bahas di Youtube Channel kami di [embed]https://www.youtube.com/watch?v=ZVQ1dtAb9Bw[/embed] Intinya Scrum Master bisa menjadi Product Owner di saat darurat. Dia tidak mengorbankan tanggung jawab dia sebagai scrum master karena memang proses scrum udah berjalan dengan baik, komunikasi si Scrum Master ini juga sudah oke banget sampai ke posisi stakeholder. Sehingga boleh mengurangi waktu dia sebagai internal consultant buat tim scrum-nya yang udah di fase tinggal pengayaan atau fase enhancement. Scrum Master tinggal mengajarkan best practices baik sisi technical maupun sisi product. Urusan managerial dia kurangi lalu mengisi peran day to day as a product owner sementara. Mengapa Scrum Master bisa menjadi Product Owner? Sebab Scrum Guide sendiri tidak secara eksplisit menyatakan Product Owner dan Scrum Master tidak boleh satu orang yang sama. Kami sendiri di Agile Campus sebenarnya setuju praktek ini tidak baik tapi

By
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

By
Agile Development

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

By
Agile Development, Agile Operational

"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

By
Agile Development

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

By
Agile Development

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

By
Agile Development, Agile Operational

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

By
Agile Development, Agile Operational

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