Berapa kali Anda menghadapi situasi seperti ini dalam tim Agile/Scrum Anda?
- User Story hanya ada dalam pikiran seseorang, dan Anda diminta untuk mengerjakan sesuatu yang disebut “just a small feature” (fitur kecil). (Para Super Developer dianggap mampu melakukan semuanya tanpa perlu QA/FA). “Fitur kecil” ini ternyata lebih kompleks, bagaikan menarik ekor naga, yang pada akhirnya mengakibatkan masalah besar.
- Pekerjaan yang direncanakan untuk sprint dua minggu sebenarnya realistisnya membutuhkan tiga sprint, tetapi tidak ada yang berani mengatakannya dengan tegas.
- Fokus utama hanya pada memenuhi tenggat waktu (the timeline), bukan pada kualitas hasil akhir (the quality of deliverable).
- Semua proses dihilangkan, dan kecepatan (speed) menjadi satu-satunya prioritas.
- Tim ini tidak lintas-fungsional (cross-functional)—pengembang enggan melakukan pengujian, begitu pula sebaliknya.
- Retrospeksi (Retrospective) diabaikan atau masukan dari retrospeksi tidak pernah ditindaklanjuti.
Jika Anda sering menemui situasi ini, maka kemungkinan besar tim Anda bukanlah tim Agile, melainkan tim FrAgile.
Apa itu FrAgile?
FrAgile merupakan gabungan dari dua kata: Fragile (rapuh) dan Agile (lincah). Istilah ini menggambarkan tim yang berusaha menerapkan metode Agile, tetapi gagal melakukannya dengan benar, sehingga hasil yang didapat justru tidak optimal. Tim FrAgile sering menunjukkan tanda-tanda seperti yang disebutkan di atas.
Fokus tim FrAgile telah bergeser dari memberikan nilai bagi pelanggan menjadi sekadar menyelesaikan proyek secepat mungkin. Dalam prosesnya, kualitas sering kali dikorbankan. Ketika pengembang bekerja dengan terburu-buru, kesalahan lebih mudah terjadi. Begitu pula ketika penguji tidak teliti karena tekanan waktu, lebih sedikit kesalahan yang terdeteksi. Akibatnya, produk akhir dari tim perangkat lunak yang terburu-buru ini cenderung memiliki kualitas yang jauh lebih rendah.
Dampak Buruk dari Pendekatan FrAgile
Di dalam tim FrAgile, kecepatan menjadi satu-satunya hal yang dikejar, tanpa memperdulikan proses yang seharusnya membantu meningkatkan kualitas. Hal ini berpotensi menyebabkan kerusakan jangka panjang, baik dalam produk maupun semangat tim itu sendiri. Ketika kualitas tidak diutamakan, pelanggan mungkin menerima produk yang penuh dengan cacat dan masalah.
Penting untuk diingat bahwa pengembangan perangkat lunak adalah kombinasi antara ketepatan waktu dan kualitas. Jika hanya salah satunya yang dijadikan fokus, maka hasil akhir yang diinginkan tidak akan tercapai. Prinsip-prinsip Agile, yang mengedepankan komunikasi, kolaborasi, dan perbaikan berkelanjutan, harus benar-benar diterapkan untuk menciptakan keseimbangan yang sehat dalam tim pengembang.
12 Prinsip Agile sebagai Panduan
Untuk membedakan tim Agile dan FrAgile, penting untuk kembali kepada 12 prinsip pengembangan Agile. Prinsip-prinsip ini menyediakan panduan bagi tim perangkat lunak untuk bekerja secara efektif dan efisien, tanpa mengorbankan kualitas.
Dengan membandingkan perilaku tim FrAgile dengan prinsip-prinsip Agile, kita dapat dengan mudah melihat di mana tim telah menyimpang dan bagaimana pendekatan tersebut dapat diperbaiki. Misalnya, dalam tim Agile, proses retrospeksi adalah hal yang wajib dilakukan untuk melihat apa yang bisa ditingkatkan di sprint berikutnya. Dalam tim FrAgile, retrospeksi seringkali diabaikan, atau jika dilakukan, hasilnya tidak pernah diterapkan.
Mengubah Tim FrAgile Menjadi Agile
Pertanyaan yang sering muncul adalah, apakah mungkin mengubah tim FrAgile menjadi Agile? Jawabannya adalah ya, tetapi perjalanan ini tidak singkat.
Dengan komitmen untuk mengikuti prinsip-prinsip Agile secara benar, dan menempatkan kualitas serta kolaborasi sebagai prioritas, tim dapat perlahan-lahan beralih dari FrAgile menjadi Agile, menciptakan lingkungan kerja yang lebih produktif dan menghasilkan produk berkualitas tinggi bagi pelanggan.
Konklusi
Untuk memastikan bahwa tim pengembang perangkat lunak Anda benar-benar Agile, bukan FrAgile, perhatikan bagaimana tim bekerja dan pastikan bahwa prinsip-prinsip Agile diimplementasikan dengan benar. Dengan fokus yang seimbang antara kecepatan dan kualitas, tim dapat mencapai hasil yang jauh lebih baik dan menciptakan nilai nyata bagi pelanggan.
—
Artikel ini memberikan panduan bagi tim pengembang perangkat lunak untuk mengevaluasi apakah mereka sudah benar-benar Agile atau masih berada di wilayah FrAgile, dan langkah-langkah apa yang dapat diambil untuk bertransformasi.
Referensi:
- Misra, A., (2016). Agile Vs FrAgile – Where do you stand???. [Pos LinkedIn]. Diakses dari https://www.linkedin.com/pulse/agile-vs-fragile-where-do-you-stand-anshika-misra/
- Reymenants, J., Corrigan, S., Fisher, D., 2020, (Fr)AgileGetting Your Agile Project to Work, York Publishing Services Ltd, York, United Kingdom.