20 Tahun Agile: Pemberontakan yang Gagal
(simplethread.com)<p>- Dua fakta yang jelas sekarang, 20 tahun setelah Agile Manifesto diumumkan, adalah:<br />
1. Menang dalam hal penamaan sebagai Agile. Tidak ada yang ingin disebut non-Agile<br />
2. Dalam praktik penerapan Agile, hasilnya jauh tertinggal dibanding gagasan revolusioner para pendirinya<br />
- "Semua orang bilang mereka melakukan Agile, tetapi hampir tidak ada yang benar-benar agile." Mengapa bisa menjadi seperti ini?<br />
<br />
[ Whence The Manifesto : Dari mana manifesto ini bermula ]<br />
- Pada Februari 2001, sekelompok 17 profesional perangkat lunak mengadakan pertemuan di sebuah resor ski di Utah<br />
- Melalui diskusi selama beberapa hari, mereka bersama-sama menulis "Agile Software Development Manifesto"<br />
<br />
- Poin pentingnya adalah mereka adalah para "Practitioner". Mereka bukan PM, CTO, VP Eng, dan semacamnya. Mereka adalah developer, programmer, ilmuwan, dan engineer. Saat itu pun mereka masih terus menulis kode dan bekerja sama dengan para pemangku kepentingan untuk memecahkan masalah. Ini sangat penting.<br />
- Poin lainnya adalah Agile Manifesto tidak lahir dari kehampaan. Banyak dari mereka sudah memiliki metodologi yang mereka ciptakan atau sedang mereka sebarkan. <br />
→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Pragmatic Programming <br />
<br />
- Semua orang dalam kelompok itu memiliki banyak pengalaman dalam pengembangan perangkat lunak, dan mereka sedang mencari pengganti bagi proses pengembangan perangkat lunak berat yang berpusat pada dokumentasi, yang saat itu menjadi arus utama di pasar.<br />
- Inti manifesto adalah penjelasan tentang empat nilai<br />
<br />
"Kami sedang menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan mengerjakannya dan membantu orang lain melakukannya. Melalui pekerjaan ini kami belajar untuk lebih menghargai:<br />
- Individu dan interaksi daripada proses dan alat<br />
- Perangkat lunak yang berfungsi daripada dokumentasi yang komprehensif<br />
- Kolaborasi dengan pelanggan daripada negosiasi kontrak<br />
- Merespons perubahan daripada mengikuti rencana<br />
Artinya, meskipun hal-hal di sebelah kiri juga memiliki nilai, kami lebih menghargai hal-hal di sebelah kanan."<br />
<br />
[ A New Hope : Harapan baru ]<br />
- Jika dilihat dari perspektif 2021, mudah untuk menerima praktik pengembangan perangkat lunak modern sebagai sesuatu yang wajar, tetapi pada 2001 ide-ide ini sangat radikal.<br />
- Mulai mengembangkan perangkat lunak sebelum semua requirement dikumpulkan dan semua fitur dievaluasi? Gila!<br />
- Hal penting yang mulai dilupakan adalah bahwa pada awalnya Agile secara terbuka dan militan bersifat anti-manajemen<br />
<br />
- Misalnya, Ken Schwaber, salah satu pencipta Scrum, pernah berargumen agar semua project manager dihapuskan; bukan hanya mengeluarkan PM dari proyek, tetapi menghapus profesi itu dari industri itu sendiri.<br />
<br />
"Kami menemukan bahwa peran project manager tidak produktif dalam pekerjaan yang kompleks dan kreatif. <br />
Pemikiran project manager yang diwujudkan dalam rencana proyek, <br />
alih-alih mengumpulkan kecerdasan semua orang untuk menyelesaikan masalah sebaik mungkin, <br />
justru membatasi kreativitas dan kecerdasan semua orang pada apa yang tertulis di dalam rencana."<br />
<br />
- Scrum master hampir tidak memiliki otoritas, dan bahkan tidak punya hak suara atas isu. Mereka adalah servant leader*, melindungi tim dan menyingkirkan hambatan, tetapi tidak mengelola tim. <br />
→ servant leader: pemimpin yang melayani bawahannya, membantu pertumbuhan dan perkembangan mereka, membangun kepercayaan antara pemimpin dan bawahan, dan mendorong bawahan untuk berkontribusi sendiri dalam mencapai tujuan organisasi <br />
- Dalam XP juga awalnya ada peran Tracker dan Coach, yang bekerja dengan cara serupa. <br />
<br />
- Alistair Cockburn, pencipta Crystal dan arsitektur Hexagonal, pernah mengatakan hal berikut dalam sebuah thread Twitter baru-baru ini <br />
"Scrum menutup kesepakatan besar di wilayah yang bermusuhan:<br />
- Para eksekutif bisa mengubah arah sesuka mereka 12 kali setahun, setiap selesai sprint<br />
- Tim mendapatkan satu bulan yang benar-benar tenang, tanpa interupsi atau perubahan arah, untuk melakukan pemikiran dan pekerjaan yang berat <br />
- Tim bisa menyatakan dalam Bid (untuk menentukan prioritas), tanpa campur tangan eksekutif, apa yang bisa dan tidak bisa mereka lakukan selama satu bulan<br />
- Tidak ada eksekutif yang pernah mendapatkan kesepakatan yang lebih baik dari ini<br />
- Tidak ada tim pengembang yang pernah mendapatkan kesepakatan yang lebih baik dari ini<br />
"<br />
(Catatan penerjemah: thread Twitter ini dimulai dari pertanyaan, "Dari mana datangnya ide bahwa tim Scrum harus menyelesaikan 100% semua item yang dialokasikan ke sprint? Ini tidak masuk akal." Saya sarankan membaca seluruh thread aslinya.)<br />
<br />
- Sebagai certified scrum master yang telah bekerja di tim Agile selama lebih dari 15 tahun, dan telah membaca banyak buku populer di bidang ini, saya belum pernah melihat ide tentang Scrum dijelaskan sejelas dan sesingkat ini. <br />
- Scrum dibuat untuk dapat berjalan di lingkungan yang bermusuhan. Ini adalah kontrak antara developer yang membutuhkan waktu untuk berpikir dan mengeksplorasi, dan manajer yang suka memaksa.<br />
<br />
[ The Empire Strikes Back : Kekaisaran menyerang balik ]<br />
- Dalam beberapa hal, Agile adalah gerakan buruh akar rumput. Ia dimulai dari praktisi lalu naik sampai ke jajaran eksekutif. Bagaimana ini bisa berhasil?<br />
- Sebagiannya karena jumlah developer bertambah dan nilai yang mereka berikan kepada bisnis meningkat<br />
- Alasan yang lebih besar adalah karena cara pengembangan waterfall tradisional tidak berjalan dengan baik<br />
- Ketika perangkat lunak menjadi lebih kompleks, kecepatan bisnis meningkat, dan ekspektasi pengguna naik, menjadi mustahil untuk merencanakan semuanya sejak awal.<br />
- Menerima pengembangan iteratif itu logis, tetapi bagi para manajer yang terbiasa merencanakan semuanya, ini agak menakutkan. <br />
<br />
- Pada pertengahan 2000-an, para eksekutif belum benar-benar menerimanya. <br />
- Lalu muncullah pembicaraan seperti, "Mari kita coba ide gila yang terus dibicarakan para engineer ini. Deadline kita toh sudah tidak akan tercapai, seberapa buruk hasilnya?"<br />
- Namun yang mengejutkan, itu mulai berhasil. Tim pada awalnya sedikit tertekan (dan lambat), tetapi perlahan mulai menemukan pola yang bekerja untuk masing-masing tim, lalu kecepatannya mulai meningkat<br />
- Setelah beberapa sprint, mereka menyadari kekuatan dari perangkat lunak yang berfungsi, kolaborasi, menyediakan waktu untuk inspeksi dan adaptasi, serta memprioritaskan hal-hal itu di atas yang lain<br />
<br />
- Selama sekitar 5 tahun, Agile berubah dari metodologi yang pernah didengar orang menjadi sesuatu yang meski belum familier bagi semua orang, semakin menyebar. <br />
- Pada 2005, Agile dan TDD adalah pembeda yang nyata <br />
- Pada 2010, tim perangkat lunak modern semuanya melakukan Agile dalam satu bentuk atau lainnya.<br />
- Setidaknya di industri konsultasi, itu seperti gelembung. Meski perusahaan besar selalu bergerak lebih lambat.<br />
<br />
"Kita berhasil! Kita menang! Mari semua merayakannya"<br />
Sampai di sini seharusnya ceritanya selesai, dan Anda bisa menutup tab browser ini.<br />
<br />
"Winning was easy, young man. Governing’s harder."<br />
"Menang itu mudah, anak muda. Memerintah lebih sulit." <br />
→ George Washington sebagaimana digambarkan dalam Hamilton (musikal)<br />
<br />
- Sayangnya, seperti banyak revolusi lainnya, sejarah Agile tidak berkembang sesuai cara yang dibayangkan para pendirinya.<br />
→ Ternyata memprioritaskan "individu dan interaksi" adalah konsep yang sulit dijual. Menjual proses dan alat jauh lebih mudah.<br />
(Catatan penerjemah: di sini Sell dipertahankan apa adanya karena maknanya lebih dekat ke membuat orang lain memahami atau menerima, bukan sekadar menjual.)<br />
→ Ternyata "perangkat lunak yang berfungsi" lebih sulit dibuat daripada rencana yang tidak realistis dan banyak dokumentasi.<br />
→ Ternyata "kolaborasi dengan pelanggan" membutuhkan kepercayaan dan vulnerability, yang tidak selalu ada dalam bisnis.<br />
→ Ternyata "merespons perubahan" sering kalah bobot dibanding para eksekutif yang harus membuat rencana jangka panjang dan melakukan kontrol.<br />
<br />
"Ternyata ketika Agile tidak dijalankan dengan benar, itu sering terasa seperti kekacauan"<br />
<br />
- Tetapi bukan berarti keempat nilai ini salah<br />
- Ini berarti semua itu membutuhkan sedikit upaya agar berjalan dengan baik, dan membutuhkan keberanian untuk menerima bahwa perangkat lunak pada dasarnya memang berantakan dan kacau <br />
- Kita harus memahami dan percaya bahwa jika terus belajar, beradaptasi, memperbaiki, dan merilis, pada akhirnya kita akan sampai ke tempat yang jauh lebih baik daripada waterfall; tempat yang jauh lebih jujur, realistis, dan produktif.<br />
<br />
"Gerakan Agile bukan anti-metodologi. <br />
Faktanya, banyak dari kami ingin kepercayaan terhadap kata 'metodologi' dipulihkan. Kami ingin keseimbangan dipulihkan. <br />
Kami menerima modeling, tetapi bukan untuk menyimpan diagram di gudang perusahaan yang berdebu. <br />
Kami menerima dokumentasi, tetapi bukan buku ratusan halaman yang tidak dipelihara dan hampir tidak pernah digunakan. <br />
Kami membuat rencana, tetapi mengakui batasan rencana dalam lingkungan yang bergolak. <br />
Mereka yang memberi cap 'Hacker' pada para pendukung XP, Scrum, atau metodologi Agile lainnya tidak memahami definisi asli dari istilah 'metodologi' dan 'hacker'."<br />
- Jim Highsmith, History: The Agile Manifesto<br />
<br />
- Inilah poin-poin pentingnya. Kita tetap membuat rencana dan dokumentasi, dan kita harus disiplin terhadap Agile. Ini soal keseimbangan.<br />
- Namun jika organisasi Anda kesulitan dalam transformasi Agile dan terjebak dalam kekacauan, lalu ada seseorang yang menawarkan sekoci seperti sertifikasi, proses, dan alat, Anda akan cenderung melompat ke sana.<br />
- Para eksekutif memahami proses dan alat jauh lebih baik daripada "tim yang mengorganisasi diri sendiri". <br />
<br />
[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : Rogue One (yang kembali) ]<br />
- Di sini struktur tiga babak saya agak runtuh. Karena saya tidak melihat adanya pemberontak pemberani yang kembali tanpa memakai nama Agile<br />
(Catatan penerjemah: ini merujuk pada judul seri Star Wars, maksudnya tidak muncul sesuatu yang lain selain Agile.)<br />
<br />
- Vendor alat, konsultan proses, dan para ahli sering kali menjanjikan hal-hal yang sama sekali tidak bisa mereka berikan.<br />
- Inilah alasan kita membuat SAFe (Scale Agile Framework for Enterprise), Scaled Scrum, dan versi Agile lain untuk enterprise<br />
- Framework seperti ini tidak dibuat dengan niat jahat, dan mungkin punya nilai tertentu dalam konteks yang tepat.<br />
- Tetapi, saya tidak akan menyebut mereka sebagai Agile<br />
- Jika Anda mencoba menskalakan metodologi yang berfokus pada individu dan interaksi, masalah hampir pasti akan muncul dan nilai asli metodologi itu akan rusak.<br />
<br />
- Tulisan terkenal dari Ron Jeffries, penandatangan Agile Manifesto dan salah satu pencipta XP, yang ditulis pada 2018<br />
<br />
"Developer harus meninggalkan Agile.<br />
Jika ide 'Agile' diterapkan dengan buruk, hasilnya adalah lebih banyak campur tangan terhadap developer, lebih sedikit waktu untuk bekerja, tekanan yang lebih tinggi, dan tuntutan untuk 'bergerak lebih cepat'. Ini tidak baik bagi developer, dan pada akhirnya juga tidak baik bagi perusahaan. Karena jika 'Agile' tidak dilakukan dengan benar, yang sering terjadi adalah lebih banyak cacat dan progres yang lebih lambat daripada yang sebenarnya bisa dicapai. Sering kali developer yang unggul meninggalkan perusahaan seperti itu, dan hasil akhirnya adalah perusahaan menjadi kurang efisien dibanding sebelum mengadopsi "Agile"."<br />
<br />
- Tulisan terkenal lainnya dari Dave Thomas, penandatangan lain dan salah satu pencipta Pragmatic Programming, yang ditulis pada 2014 <br />
<br />
"Agile sudah mati. (Hidup Agility)<br />
Kata 'Agile' pada praktiknya telah diselewengkan sampai hampir tidak lagi memiliki makna, dan komunitas Agile sebagian besar telah menjadi tempat bagi konsultan dan vendor untuk menjual layanan serta produk mereka. Ketika Manifesto menjadi populer, kata Agile berubah menjadi magnet yang menarik segala sesuatu yang punya sesuatu untuk didukung, punya jam penagihan, atau punya produk untuk dijual, sehingga ia menjadi istilah pemasaran. <br />
<br />
Karena itu, saya pikir sudah waktunya untuk memensiunkan kata 'Agile'."<br />
<br />
[ Retro : Kembali ke masa lalu ]<br />
- Hal yang benar-benar menyedihkan adalah melihat developer muda meremehkan Agile dan menganggapnya sebagai sarana bagi eksekutif untuk memaksakan janji-janji yang tidak realistis dan mendorong developer bekerja dalam jumlah jam yang sangat besar.<br />
- Satu-satunya Agile yang mereka kenal adalah mekanisme kontrol yang dipaksakan kepada mereka, bukan alat pemberdayaan diri yang dulu disambut dengan antusias.<br />
- Namun, saya berharap memulai diskusi tentang sejarah dan visi aslinya bisa membantu kita mengingat bagaimana seharusnya kita melangkah ke depan. <br />
<br />
- Meski begitu, kabar baiknya adalah prinsip-prinsip Agile Manifesto tetap sama bijak dan relevannya hari ini seperti 20 tahun lalu. Dan bahkan orang-orang yang dianggap seperti apostates seperti Jeffries atau Thomas pun masih berpikir demikian.<br />
<br />
- Dalam tulisan yang disebutkan di atas, Jeffries mengatakan ini <br />
"Namun, nilai dan prinsip dari Manifesto for Agile Software Development masih memberikan cara terbaik yang saya ketahui untuk membangun perangkat lunak, dan berdasarkan pengalaman saya yang panjang dan beragam, apa pun metodologi yang digunakan dalam organisasi yang lebih besar, saya akan tetap mengikuti nilai dan prinsip tersebut."<br />
<br />
- Saya setuju dengan pendapat ini<br />
- Berbicara tentang Agile sekarang bukanlah hal yang hip atau keren. Agile itu membosankan. <br />
"Semua orang sudah Agile, kan?"<br />
- Sekarang adalah waktu yang sempurna untuk menengok kembali 20 tahun terakhir dan mengajukan beberapa pertanyaan kepada diri sendiri <br />
→ Apa yang berjalan dengan baik?<br />
→ Apa yang salah?<br />
→ Apa yang ingin dilakukan secara berbeda lain kali?<br />
- Dalam beberapa bulan ke depan, saya berencana meninjau kembali 12 prinsip Agile yang asli, memberi konteks pada makna aslinya, dan mempertimbangkan nilainya dalam lingkungan pengembangan perangkat lunak saat ini <br />
<br />
"Harapan saya adalah bahwa dengan mempelajari prinsip-prinsip pendiriannya, kita dapat belajar dari masa lalu, dan seperti kata Dave Thomas, meskipun kita meninggalkan 'Agile', kita tetap bisa mempertahankan 'Agility'."</p>
3 komentar