Mencari Teknik Pengembangan "Agile" Terbaik dengan Scrum agar menjadi Agile

"Agile" sangat erat kaitannya dengan pengembangan perangkat lunak (Agile Software Development), meskipun saat ini ramai dibicarakan di luar pengembangan perangkat lunak juga. Berbicara definisi "Agile", saat ini banyak orang mendefinisikan berdasarkan versinya masing-masing. Namun ketika merujuk kepada Agile Manifesto, Agile bisa dibilang sekumpulan nilai dan prinsip yang diterapkan ketika mengembangkan perangkat lunak.

Kali ini saya berbagi sedikit pengalaman (karna pengalaman saya memang masih sedikit :D) dalam mengembangkan perangkat lunak dengan mengadopsi Scrum dan metodologi. Loh bukannya Scrum itu metodologi ya? Ya bukan, silahkan baca definisinya di sini. 

Kurang lebih setahun yang lalu, saya bersama tim mengembangkan sebuah produk perangkat lunak dari nol hingga saat ini pengembangan masih berlanjut dan produk terus disempurnakan untuk bisa memenuhi kebutuhan konsumen.

Produk yang dikembangkan tersebut sebenarnya bukanlah produk yang benar-benar baru, tetapi produk yang dikembangkan untuk menyempurnakan produk sebelumnya yang sudah berjalan kurang lebih 10 tahun dan sudah ada ribuan organisasi sebagai pelanggannya. Penyempurnaan yang diharapkan dari pemilik produk saat itu meliputi teknologi, keamanan dan keindahan tampilan antar-muka. Namun saya melihat sisi lain yang justru paling wajib dibenahi dahulu yaitu "Proses Pengembangan Perangkat Lunak" yang berjalan. Membangun produk dengan mindset proyek adalah hal yang mengganjal bagi saya begitupun bagi rekan-rekan pengembang itu sendiri (Baca juga: Manajemen Proyek dalam Sudut Pandang Scrum). Akhirnya semua orang bahkan seluruh elemen organisasi sepakat untuk meninjau ulang visi dan misi serta belajar (kembali) kenapa harus mengembangkan produk yang berkualitas dan bagaimana mengembangkan produk berkualitas tersebut.

Disini kesempatan bagi saya untuk mengenalkan Agile Software Development dengan Scrum di lingkungan kerja. Lalu manajemen merespon sangat positif dan yang terpenting ada harapan baru untuk para pengembang perangkat lunak agar mereka difasilitasi dalam berkreasi dan mengembangkan kemampuan mereka lebih baik dibandingkan dengan cara lama. Akhirnya Scrum Team dibentuk lalu Sprint-1 dimulai. Namun tidak semata-mata langsung Adopsi Scrum sepenuhnya, tapi bertahap, sebagaimana pilar dasar dalam Scrum : transparansi-inspeksi-adaptasi. 

Seiring berjalannya waktu dalam mengadopsi Scrum. Tim menjadi banyak belajar bahkan sebenarnya mengimplementasikan metodologi-metodologi lain dalam pengembangan produk, seperti : Lean Startup, Test-Driven Development (TDD & ATDD), Spotify Model, Devops. Ini dilakukan secara alami dan muncul dari tim itu sendiri, karena Scrum memfasilitasi tim untuk terus belajar (Continuous Learning & Improvement). Bahkan beberapa orang sebenarnya tidak sadar kalau mereka banyak menerapkan metodologi di proses pengembangan produk tersebut. Ya mereka kenalnya hanya Scrum karna itu yang saya kenalkan di awal.

Lean Startup

Di Sprint-1 hingga beberapa sprint berikutnya kami belum sepenuhnya adopsi Scrum (baca juga : Bukan Scrum), peran masih hanya ada founder dan co-founder produk, seperti halnya start-up yang baru lahir. Namun elemen scrum lainnya sudah mulai diterapkan di sini seperti : Sprint, Sprint Planning, Sprint Review, Sprint Retrospective dan Product Backlog. 3 pilar Scrum: transparansi-inspeksi-adaptasi menurut kami cukup selaras dengan konsep Lean Startup:  Build-Measure-Learn (BML).

Kami terus belajar dari apa yg sudah kami buat dan deliver kepada user. Saat itu kami dibantu oleh internal user (tim support) yang cukup mengerti tentang kebutuhan end user, karena produk belum bisa di rilis secara langsung ke publik. Cara mengukurnya pun masih sangat sederhana, cukup dengan pertanyaan "apakah fitur tersebut berguna atau tidak?". Hingga saat ini dilakukan terus-menerus dengan tujuan mendapat feedback agar produk yang dikembangkan sesuai dengan kebutuhan. Salah satu fungsi dengan adanya Sprint Review dan Retrospective ya untuk melakukan review dan belajar dari feedback yang didapatkan.
Dengan Lean Startup ini kami berhasil merilis MVP (Minimum Viable Product) ke production dan mendapat sambutan baik dari pengguna. Walaupun MVP ini belum 100% bisa meng-cover kebutuhan pengguna namun produk bisa berjalan dan digunakan dengan baik oleh pengguna. Meski sudah rilis ke production, tim tetap berkomitmen untuk terus menyempurnakan dan mengembangkannya. 

Tidak hanya fokus ke pengembangan produk saja, tapi juga pengembangan tim. Awal tim hanya 2 orang lalu bertambah menjadi lebih dari 3 orang. Dilakukan dengan melihat hasil yang dideliver produk dan estimasi kebutuhan. Disamping itu juga adanya faktor ketertarikan anggota tim lain untuk bergabung serta dukungan manajemen untuk memperkuat tim.

Acceptance Test-Driven Development (ATDD) dan Test-Driven Development (TDD)

Metodologi ini diterapkan dari mulai awal pengembangan produk hingga dikenalkan kepada tim setelah terbentuk Scrum Team. Alasan kuat kenapa kami sangat memerlukan ini adalah karena kami serius ingin membangun produk dengan kualitas terbaik. Testing juga salah satu kendala yang dihadapi tim saat itu yang baru mengandalkan manual test (click test) dari tester. Kendala tidak hanya kurang akuratnya test tapi juga jeda waktu dalam mengeksekusi test yang cukup lama sehingga proses pengembangan maupun delivery (pengiriman) produk ke konsumen lama. Kualitas dari hasil testing pun kadang dipertanyakan karena seringkali banyak hal yang terlewatkan / tidak teruji dengan baik dan benar. Akhirnya masih ditemukan bugs bahkan fatal error di banyak fitur dan lebih sering ditemukan oleh end user ketimbang oleh tester.

Berbicara TDD tidak terlepas dari Automated-Testing. Sebelum benar-benar menerapkan TDD, tim memutuskan untuk terlebih dahulu membiasakan diri dengan Automated-Testing yang belum pernah dilakukan sebelumnya. Jadi menulis unit test, functional test dan acceptance test masih dilakukan diakhir setelah coding, hanya lebih canggih dari kemarin dengan adanya Automated-Testing.

Setelah beberapa sprint melakukan ini, tim pun merasakan langsung manfaatnya. Tim developer tidak lagi terbayang-bayang dan harap-harap cemas dengan code atau fitur yang sudah dirilisnya ke publik, karna semuanya sudah teruji secara otomatis dan cukup baik sehingga mampu meminimalisir bahkan menghindari kesalahan (bugs & fatal error) pada fitur tersebut atau dampaknya ke fitur lain (defect). Yang terpenting adalah tim bisa menulis code secara bersih (clean code) dan tim merasa lebih tenang ketika melakukan refactoring code agar code tetap bersih. Dengan cara lama (manual test) tentu refactoring ini menjadi momok yang menakutkan untuk dilakukan, bahkan ya hampir tidak pernah dilakukan, code jadi kotor dan jorok, banyak bugs sehingga perfoma aplikasi pun buruk. 

Disuatu Sprint Retrospective, tim memutuskan dan menyepakati bersama untuk menjadikan test tersebut sebagai salah satu poin Definition of Done (DoD). Mulai unit test, functional test, acceptance test, code coverage. Test yang sudah dibuat pun terus dikembangkan secara berkelanjutan. Dan tim juga terus mencoba membiasakan dengan TDD dan ATDD ini. Tujuannya tidak lain untuk menghasilkan produk yang berkualitas.
Sebagai referensi, mengenai ATDD dan TDD bisa baca juga di artikel berikut.

Spotify Model

Jika melihat gambaran tentang Spotify Model diatas atau lebih lengkapnya bisa lihat disini, tentu banyak sekali perbedaan dengan yang terjadi di lingkungan kerja kami. Kami tidak sepenuhnya mengadopsi itu, bahkan tidak sampai separuhnya, karna kami rasa banyak hal-hal seperti budaya dan pola pikir yang sudah dikanalkan lebih dulu di Scrum, misalnya tentang Servant Leadership, Cross-functional Team dan Self-organizing Team. Namun ada salah satu yang khas dari spotify model ini yang hampir mirip dengan budaya di organisasi kami yaitu mengenai Community: tribe, squad.
Struktur organisasi saat ini terbagi tidak hanya berdasarkan pengelompokan fungsi namun ada juga produk. Ini secara alami terbentuk atas dasar kebutuhan bukan kekuatan politik. Misalnya untuk tribe, kami ada dua divisi pengembang yaitu : mobile & ecosystem dan enterprise. Di dalam masing-masing divisi terbagi juga beberapa team misalnya : infrastructure & data, support, product development. Masing-masing team saling berkaitan satu sama lain dan bisa berubah tergantung sprint goal yang ingin dicapai saat itu. Misal dalam satu sprint tim memerlukan bantuan orang infrastructure karena ada kaitan dengan server, lalu sprint selanjutnya tim memerlukan support untuk membantu mensosialisasikan rilis produk ke pelanggan. Bahkan bentuk kerjasama tidak hanya dalam satu divisi saja tapi juga bisa lintas divisi, misalnya tim Produk A dalam satu sprint perlu ada integrasi dengan Produk B jadi ada sebagian anggota Produk B yang ikut berkolaborasi di tim Produk A untuk mencapai sprint goal.
Pembagian team berdasarkan fungsi bisa dianggap sebagai Community / Chapter, dan pembagian berdasarkan produk bisa dianggap sebagai Tribe. Namun meskipun terbagi, kami tidak pernah merasa terkotak-kotakan. Selama pekerjaan dan keahlian setiap individu diperlukan untuk menghasilkan suatu nilai, maka anggota tim tersebut bisa saling membantu tanpa melihat jabatan. Menurut kami, ini sejalan dengan konsep Scrum itu sendiri yaitu cross-functional and self-organizing team.

Devops

Salah satu metodologi atau teknik pengembangan yang cukup hangat diperbincangkan saat ini. Tidak seperti Scrum yang terdokumentasi dengan reliable dalam Scrum Guide, Devops lebih seperti Agile yang didefinisikan hampir bebas oleh para penggunanya. Ada yang menyebutkan bahwa devops adalah budaya bukan metodologi, ada yang menyebutkan devops adalah metodologi bahkan ada yang menganggap devops sebagai teknik pengiriman perangkat lunak (Software Delivery). Namun kebanyakan sepakat bahwa Devops terdiri dari dua kata yaitu Development and Operations, yang berarti kolaborasi antara yang mengembangkan produk dan yang mengoperasikan / menggunakan perangkat lunak.
Berbicara Devops saat ini identik dengan teknologi automasi yang digunakan dalam Continuous Integration / Continuous Delivery. 

Dari gambar yang cukup populer dalam menggambarkan devops diatas menggambarkan bagaimana kolaborasi dan integrasi antara Developer dan Operation dalam menghantarkan perangkat lunak ke pengguna (end user) yang sebenarnya pengguna adalah bagian dari Operation itu sendiri. Developer yang secara umum bertugas dalam plan, code, build dan test, sementara Operations bertugas dalam melakukan release, deploy, operate, monitor.
Berbeda dengan yang di gambar, devops bukan membuat jarak antara lingkaran Developer dan lingkaran Operation, tapi justru mempersatukan Developer dan Operation kedalam satu lingkaran dalam mengefektifkan proses pengiriman perangkat lunak (Software Delivery). Devops mengenalkan suatu budaya agar developer dan operation dianggap sebagai satu bagian yang tak terpisahkan. Jadi jangan terjebak dengan gambar tersebut (dua bulatan terpisah).
Namun pengertian, pemahaman dan pandangan orang terhadap devops kian berkembang. Sekarang lebih dikenal dengan sebagai teknik (engineering practice) ketimbang budaya (culture). Kita akan sering menemukan titel "Devops Engineer", yang bertugas dalam mengembangkan automasi dalam software delivery atau dikenal dengan istilah CI/CD (Continuous Integration & Continuous Delivery / Deployment). Padahal CI/CD hanya baru sebagian dari devops itu sendiri, mungkin seperti orang yang mengaku sudah Scrum karna tiap hari ada Daily Scrum. Tapi untuk devops tidak ada mempermasalahkan ini jadi ya kita terima apa adanya, yang terpenting esensinya bisa kita terapkan.
Kaitannya dengan Scrum, tak lama setelah Devops booming, CEO dari Scrum.org berkolaborasi dengan Devops Institute dan memperkenalkan ScrumOps (Scrum+Devops), informasi lengkap bisa dibaca disini.
Konsep yang ada di Devops cukup sejalan dengan Scrum. Ini yang juga dirasakan oleh kami dalam mengembangkan dan menghantarkan perangkat lunak. Karna kami benar-benar ingin mengembangkan produk yang bisa memenuhi kebutuhan pengguna maka hal pertama yang harus didobrak adalah sekat antara pengembang dan pengguna atau pengoperasi. Sepanjang sprint berjalan tim pengembang selalu berkoordinasi dengan tim infrastruktur sebagai pengoperasi dan tim support sebagai pengguna. Bahkan untuk seorang Product Owner bisa berkoordinasi langsung dengan End User untuk mendapatkan umpan balik.
Tapi kolaborasi saja masih belum cukup, kami juga tetap perlu automasi baik itu dalam merilis produk ke pengguna ataupun menangkap umpan balik dari pengguna dan monitoring. Maka di Sprint Retrospective, kami memutuskan untuk menambahkan CI/CD yang terotomatisasi sebagai syarat tercapainya suatu inkremen dari produk kedalam Definition of Done (DoD) melengkapi dan menyambung rantai dari Automated-Testing yang sudah dilakukan sebelumnya. Automatisasi ini bertujuan untuk mengefektifkan proses deploy dan mengurangi jeda waktu dari Tested ke Ready to Use. Karna jika proses tersebut lama, selain pengguna harus menunggu lama mendapatkan apa yang dia perlukan, pengembang juga bisa menunggu lama umpan balik dari pengguna. Ketika feedback loop lambat maka bisa jadi inspeksi-adaptasi juga terhambat.

Scrum bukanlah sebuah teknik atau metodologi apalagi "alat"

Cukup banyak orang menyebut Scrum sebagai metodologi Agile dan membandingkan dengan metodologi lainnya seperti yang dijelaskan diatas. Bahkan ada yang menyebutkan bahwa Scrum adalah sebuah "alat" yang tidak semua pengembang cocok dengan alat tersebut. Jadi Scrum tidak bisa dijadikan sebagai best practice (memang bukan). Hingga akhirnya tak sedikit orang mengubah, memodifikasi, mengurangi elemen-elemen Scrum tanpa diiringi dengan pemahaman Scrum yang benar.

Bagi kami, Scrum bukanlah sebuah metodologi dan bukan untuk dibandingkan dengan metodologi lainnya, apalagi menganggapnya sebagai "Alat". Scrum adalah kerangka kerja, budaya kerja, kebiasaan baik serta nilai-nilai yang patut kita adopsi tidak hanya dalam mengembangkan produk dan menyelesaikan masalah kompleks namun juga dalam pekerjaan sehari-hari. Scrum memfasilitasi tim untuk menemukan proses dan alat terbaik untuk menunjang produktifitas dan kreatifitas tim dalam mengembangkan produk. Scrum juga mendorong tim agar terus belajar dan terus meningkatkan kualitas secara berkelanjutan (Continuous Learning & Improvement), mengembangkan produk secara iteratif dan inkremental. Sehingga tidak ada titik akhir dalam scrum. 

Inilah kenapa kami bisa mengenal bahkan mencoba banyak metodologi pengembangan perangkat lunak sepanjang mengadopsi Scrum. AKan tetapi kami tidak mengklaim sudah berhasil melakukan semuanya (mengkombinasikan Scrum dan Metodologi) karena kami sadar yang dilakukan masih sangat sederhana dan jauh dari kata sempurna. Kami berusaha untuk terus mencari cara terbaik dalam mengembangkan perangkat lunak, diatas pilar : transparansi-inspeksi-adaptasi. Scrum on!
Mungkin berikutnya kami akan mencoba Kanban terutama untuk mengefektifkan workflow yang sekarang berjalan yang melibatkan lintas divisi.

Semoga artikel ini bermanfaat. Jangan sungkan untuk bertanya, berdiskusi atau memberikan saran di kolom komentar. Silahkan bagikan artikel ini dengan menuliskan sumbernya.