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 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

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