Kematian Agile dan Jira yang Lambat dan Menyakitkan
(ehandbook.com)"Karena Agile tidak lagi menjadi Agile, sekarang saatnya Agile lenyap bersama Jira"
- Siklus pengembangan perangkat lunak semakin panjang, tim teknis semakin besar, pengelolaan pengembangan membutuhkan semakin banyak aplikasi, jumlah orang yang benar-benar menulis kode terus berkurang, dan dalam periode yang makin pendek, kemajuan di antara checkpoint berkelanjutan juga makin sedikit
- Dari mana Agile mulai salah arah?
- Agile adalah metodologi yang dikembangkan pada awal 2000-an sebagai alternatif bagi proses pengembangan perangkat lunak lama yang berat dan berpusat pada dokumentasi
- Namun kini Agile justru berubah menjadi metodologi manajemen proyek kompleks seperti yang lama
Pembengkakan Teknologi (Tech Bloat) adalah masalah utamanya
- Alasan utama banyak orang meninggalkan atau ingin meninggalkan Agile adalah pembengkakan teknologi
- Pembengkakan teknologi adalah musuh semua perusahaan teknologi, dan juga berbahaya bagi perusahaan non-teknologi yang memiliki tim pengembangan internal maupun outsourcing
- Pembengkakan teknologi berbeda dari utang teknis, tetapi dapat menciptakan utang teknis
- Gejala pembengkakan teknologi antara lain:
- Berulang kali berbicara dengan pelanggan, tetapi tidak pernah benar-benar menjadi ahli atas perilaku pelanggan
- Terus-menerus menilai dan menilai ulang tenggat waktu dan tanggal pengiriman
- Sangat enggan memulai proses pengembangan sampai semua detail terdokumentasi
- Terdorong untuk memulai dari pekerjaan yang paling mudah, bukan yang paling berisiko
Dampak kacau dari pembengkakan teknologi
- Peningkatan dokumentasi
- Dokumentasi yang melacak bukan hanya apa yang dibangun dan mengapa, tetapi juga "bagaimana" proses itu dibangun, meresap ke seluruh proses
- "Bagaimana" ini menjadi fokus pembaruan status, sehingga tim terus-menerus menilai ulang cara mereka bekerja
- Tim menghabiskan lebih banyak waktu membahas mengapa pekerjaan belum selesai daripada benar-benar mengerjakannya
- Penetapan tenggat yang terlalu sering
- Lebih banyak tenggat ditetapkan pada checkpoint yang lebih sering, yang pada dasarnya melahirkan micromanagement di setiap titik belok dari proses yang secara inheren kreatif
- Ini justru bertentangan dengan produksi perangkat lunak berkualitas, karena semua pekerjaan dikirim sesuai tenggat yang ditetapkan, terlepas dari seberapa baik pelaksanaannya
- Keraguan terus-menerus dalam proses evaluasi ulang
- Karena keraguan yang tak henti selama periode evaluasi ulang, best practice tidak pernah ditetapkan, pemborosan tidak dihilangkan, dan skala ekonomi tidak pernah dikenali
- Micromanagement pada proses produksi
- Ketika sekitar 30% dari sebuah fitur selesai, fitur itu sering kali sudah bukan lagi prioritas
- Organisasi terjebak dalam spiral kematian memproduksi apa yang ada di roadmap, terlepas dari apakah roadmap itu masih mendefinisikan pembangunan produk yang sukses atau tidak
- Hasil akhirnya
- Produk terbebani oleh beragam kebutuhan pelanggan yang saling bertentangan
- Fitur sering terlambat masuk pasar dan disajikan dengan cara serta urutan yang paling cocok bagi tim teknis, bukan yang paling cocok bagi pasar
- Pada akhirnya tim sales/marketing melawan karena mereka tidak tahu apa yang mereka jual dan pelanggan pun tidak tahu apa yang mereka beli
- Lalu organisasi memulai perombakan besar-besaran
Dunia membutuhkan perangkat lunak ringan yang lebih baik dalam mengerjakan hal penting, bukan lebih banyak fitur
- Ini bukan konsep baru, tetapi semua metodologi pada akhirnya menjauh dari konsep ini
- Orang-orang pada akhirnya mulai bertanya apakah cara Toyota sudah cukup "Toyota", dan itu pun berubah menjadi pekerjaan tambahan
- Agile kini telah menjadi PMP dengan nama yang lucu, rapat yang lebih singkat, dan aturan yang lebih banyak
- Masalahnya bukan pada ide Agile, melainkan pada pelaksanaannya dan kurangnya kepemimpinan untuk mengendalikannya
- Ini adalah masalah lapisan manajemen menengah yang lebih berfokus pada tenggat daripada utilitas, pemangkasan daripada pertumbuhan, dan penghematan daripada kemajuan
Opini GN⁺
- Agile, berlawanan dengan niat awalnya, telah menjadi birokratis dan formalistis sehingga justru memperlambat pengembangan perangkat lunak
- Pembengkakan teknologi adalah faktor risiko yang perlu diwaspadai bukan hanya dalam Agile, tetapi di semua organisasi teknologi
- Dokumentasi, penetapan tenggat, dan micromanagement justru bisa menurunkan kualitas dan kecepatan
- Karena esensi Agile terletak pada orientasi pelanggan, kolaborasi, dan fleksibilitas, kita perlu kembali mengingat prinsip-prinsipnya alih-alih terjebak pada formalitas
- Yang penting dalam pengembangan perangkat lunak bukanlah lebih banyak fitur, melainkan mengeksekusi fitur inti dengan baik
- Budaya organisasi dan kepemimpinan menentukan keberhasilan atau kegagalan Agile, sehingga para manajer teknis perlu memberi perhatian pada hal ini
- Tampaknya sudah waktunya untuk mencari metodologi baru setelah Agile
17 komentar
Karena artikel aslinya berbayar, saya tidak bisa membacanya sampai akhir, tetapi menurut saya ungkapan terjemahannya sebaiknya sedikit diperhalus.
"Agile sudah bukan lagi Agile, jadi sekarang saatnya Agile menghilang bersama Jira"
=> "Karena Agile sudah berhenti being agile, sekarang saatnya Agile menghilang bersama Jira"
Ada konsep yang membedakan penggunaan Agile dengan huruf besar dan agile dengan huruf kecil,
serta being agile dan doing agile itu saling terhubung, tetapi dipahami secara terpisah.
being agile by doing agile.
Alasan penerapan Agile itu penting. Apakah diterapkan supaya pengembangan berjalan lebih baik? Tidak, melainkan karena saya tidak tahan melihat kalian santai-santai. Saya akan lihat sendiri seberapa giat kalian bekerja. Dengan pola pikir seperti itulah Agile diterapkan. Jadi ya akhirnya jadi neraka.
Sampai di titik ini, sepertinya kita perlu checklist kepatuhan Agile.
Sebelum memperdebatkan Agile atau waterfall, kalau lingkungan seperti orang dan budayanya tetap sama, sehebat apa pun metodologi pengembangan yang diterapkan, ujung-ujungnya hanya akan menjadi versi K-OOO.
Jika perubahan kebutuhan (hampir) tidak ada, memang benar bahwa dari sudut pandang pengembang, waterfall adalah metode yang benar-benar nyaman. Asalkan memang tidak ada perubahan kebutuhan, tentu saja…
Agile versi K memang tidak pernah dievaluasi ulang ya.!
Pelanggan: sepertinya tombolnya lebih bagus di sini pada layar ini
Developer: (berarti harus lembur semalaman, padahal ada kerjaan baru juga)
Pelanggan: sepertinya tombolnya harus ada di layar lain
Developer: (tolong ada yang pakai jurus membelah diri) iya, haha..
Pelanggan: masih belum jadi ya? Bukannya sesuai jadwal semuanya seharusnya sudah selesai?
Developer: (tolong selamatkan aku) iya..;;
Tidak banyak kasus Agile dimanfaatkan secara benar-benar agile dalam jangka panjang,
dan tampaknya sebagian besar organisasi pada akhirnya mengerucut ke pekerjaan waterfall dengan tenggat yang singkat.
Masalahnya bukan Agile. Yang bermasalah adalah orang yang menjalankannya. Metodologi apa pun yang dibawa, pada akhirnya semuanya bergantung pada bagaimana orang yang menjalankannya melaksanakannya. Saya menganggap Agile bukan sebagai metodologi, melainkan lebih dekat dengan semangat untuk mengembangkan produk secara berkala. Jika poin ini terlewat lalu orang hanya merencanakan dan melakukan retrospektif secara membabi buta, rasanya itu hanya membuang waktu.
Saya kira cuma
k-agileyang begitu, ternyata ini fenomena global juga.Rasanya seperti terus memukul hal yang salah... Seharusnya penilaiannya berdasarkan apakah itu sesuai atau tidak dengan Manifesto Agile...
Bahkan
uncle bob, yang ikut serta dalam Agile Manifesto, memahami masalah ini sejak awal dan menerbitkan buku Clean Agile pada 2019 untuk meluruskan Agile yang keliru, tetapi masalah seperti ini masih terus berlanjut. Secara pribadi, saya pikir penyebabnya adalah karena Agile tidak memiliki pedoman standar dan menggunakan ungkapan yang samar seperti "budaya". Akan bagus jika ada pedoman standar yang lebih konkret.Penulis tampaknya akan berargumen agar metode apa pun ditinggalkan begitu mulai menjadi birokratis.
Saya setuju. Sepertinya makin banyak yang menjalankan Agile dengan keliru lalu mengatakan bahwa Agile itu salah.
Di sisi lain, saya juga berpikir bahwa meskipun sudah cukup lama sejak kemunculannya, tampaknya memang tak terhindarkan bahwa membangun praktik yang matang itu sulit.
Muter-muter, akhirnya balik lagi ke semula?
Opini Hacker News
Masalah Agile
Prinsip Agile Manifesto
Inti Agile
Fleksibilitas Agile
Pendapat tentang JIRA
Asal-usul Agile
Kondisi Agile saat ini
Masalah JIRA
Penerapan Agile