Agile & Scrum, our two besties

Anwar Farihin
8 min readApr 13, 2020

--

Apa itu agile?

Pada proses produk Advokasimu, bisa dibilang tim kami merancang segala produk dari 0. Tim kami yang hanya terdiri dari 5 Developers + 1 Scrum Master + 1 Product Owner tentunya tidak mudah dalam menghadapi puluhan fitur yang requirement-nya belum cukup jelas untuk diimplementasikan. Dalam proses development, beberapa fase yang perlu dilakukan yaitu : analisis requirement, design planning, membuat prototype, testing, hingga akhirnya tahap terakhir yaitu acceptance testing.

Jika kami menggunakan metodologi tradisional seperti waterfall, maka waktu dan usaha yang dihabiskan sangatlah banyak karena pada setiap fase harus dijalankan sampai sempurna, sebelum bisa lanjut ke fase berikutnya. Namun, untungnya kami menggunakan metodologi agile. Jika kamu bekerja di Start-up atau menggeluti bidang IT, pasti kamu sering mendengar kata agile, ataupun scrum. Memang apa sih artinya? dan kenapa sering dipakai di dunia start-up? dikutip dari Agile Allegiance, agile adalah

“The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.”

Simpelnya, agile dilatarbelakangi dengan kesulitan yang dihadapi organisasi yang masih belum stabil dan memiliki prioritas yang berubah-ubah, sehingga organisasi tersebut bisa tetap fleksibel dan tenang dalam menghadapi banyaknya perubahan yang terjadi. Pada agile, developer bebas untuk mengerjakan proses development mana yang dilakukan.

Sebagai metodologi pada software development, agile memiliki beberapa keunggulan utama, yaitu release yang cepat, produk yang berkualitas, serta tanggap terhadap perubahan. Pengembangan produk pada agile didasari dengan iterative (berulang) and incremental (cenderung bertambah) development. Jika diterapkan dengan benar, maka pada setiap iterasi, kualitas suatu tim pasti akan semakin meningkat dari segala sisi.

Contohnya pada Advokasimu. Pada Sprint (iterasi) ke-1, kami mengambil 4 PBI (Product Backlog Items). Kemudian, pada Sprint ke-2 kami mengambil 5 PBI. Dan yang lebih mengejutkan, pada Sprint ke-3 ternyata kami memutuskan untuk improve ke 6 PBI. Wow. Ternyata, agile memang bukan metodologi kaleng-kaleng, karena jujur kami sendiri pun terkejut bagaimana kami melakukan improvisasi tersebut.

Ibarat ninja melempar shuriken, agile sangat cepat (hemat waktu) dan tepat sasaran (mampu menghasilkan produk sesuai keinginan klien).

Agile bukanlah sekadar metodologi saja, namun agile merupakan cara berpikir sebuah tim yang dideklarasikan dengan The Agile Manifesto. Adapun, The Agile Manifesto sendiri didasari pada 12 Principles of Agile. Sebuah tim yang ‘memilih’ agile sebagai metodologi development-nya, harus mengimplementasikan seluruh manifesto dan prinsip dari agile itu sendiri.

The Agile Manifesto dan 12 Principles ofAgile

Pada awalnya kami agak struggle dalam beradaptasi dengan agile. khususnya dengan prinsip nomor 4 dan 11. Hambatan pada prinsip nomor 4 terjadi karena keterbatasan klien yang terkadang tidak bisa fast response, sehingga dalam beberapa hal kecil kami terkadang menggunakan asumsi kami, bukan sesuai klien. Namun hal itu dilakukan mengingat Pak John sebagai klien kami merupakan orang yang sangat fleksibel dan percaya terhadap pertimbangan-pertimbangan kami. Masalah pada nomor 11 muncul ketika kami sudah mulai sprint ke-3, kami baru sadar ada beberapa requirement yang implisit, seperti halaman login pada web admin Advokasimu dan integrasi flutter pada halaman kasus saya. Sehingga, kami secara tidak langsung harus menambah PBI dan melakukan penyesuaian kembali. Namun, diantara hambatana-hambatan yang ada untungnya seiring berjalan nya waktu kami menjadi semakin terbiasa dan semakin nyaman dengan prinsip-prinsip dan manifesto-manifesto tersebut.

Jika ditanya manifesto atau prinsip mana yang paling penting, jawabannya adalah semua sama-sama penting. manifesto dan prinsip ini adalah sebuah kesatuan yang idealnya harus diterapkan secara kesatuan, yang mana jika ditinggalkan maka akan menghambat asas agile itu sendiri.

Jika Agile tadi diibaratkan sebagai ninja, maka ninja butuh tools (framework) untuk menyokong keberlangsungan hidupnya.

Ada 3 framework agile yang paling banyak dipakai: Scrum, Extreme Programming (XP), dan Kanban. Namun, karena kami mengimplementasikan scrum, saya akan membagi pengalaman saya dalam Menggunakan scrum.

Apa itu Scrum?

Menurut scrumguides.org,

“ Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”

Graf Scrum

Sifat unik scrum yaitu: ringan, mudah dipahami, susah dikuasai. Idealnya, sebuah tim scrum terdiri dari 4–13 orang, tergantung dengan kebutuhan masing-masing tim. Tim tersebut haruslah tim yang fleksibel dan adaptif, sesuai dengan prinsip agile. Tim pada scrum terdiri dari 3 role: Product Owner, Developer, dan Scrum Master. Saya akan mencoba menjelaskan rol-role tersebut sesuai dengan kenyataan yang kami lakukan pada progress keseharian kami (sekalian apresiasi :D).

  1. Product Owner (PO): Ka Lila

PO adalah 1 orang yang bertanggung jawab mendefinisikan dan mengurutkan prioritas PBI, sehingga tujuan dan misi dari produk tercapai. PO juga mengoptimisasi performa kinerja tim. Setiap Product Backlog yang ada, maka harus dipastikan sudah jelas, deskriptif, dan bisa menjelaskan apa yang harus dikerjakan oleh tim. Peran PO yang ideal sangat penting bagi sebuah tim. Jika tidak, maka bisa menghambat kinerja tim tersebut. Keputusan PO dalam mengganti Backlog yang ada juga harus dihargai oleh tim agar tim berhasil. Untungnya, Ka Lila sangat rapih dan teliti, sehingga kami tidak terlalu sulit dalam memahami PBI yang ada hehe.

2. Scrum Master (SM): Ka Aci

Seperti namanya, SM adalah orang yang memiliki pengalaman dan pemahaman mendalam mengenai scrum. SM bertanggung jawab untuk memastikan tim berjalan sesuai dengan Scrum Guide. SM juga memastikan tim memahami tujuan, ruang lingkup, serta domain produk sebaik mungkin. Jika ada scrum event, SM juga harus mengfasilitasi tim. SM yang baik akan menghasilkan tim dan produk yang optimal. Ka Aci sangat sabar menghadapi kami Developer Team yang kadang banyak tanya ataupun belum paham mengenai sesuatu yang disampaikannya. The Best Scrum Master deh.

3. Developer Team (DT): Saya, Naufal, Igna, Cici dan Falya

DT merupakan tim yang akan mengimplementasikan fitur-fitur yang ada. DT lah yang akan men-deliver increment (jumlah PBI yang diselesaikan pada 1 sprint) sehingga memenuhi Definition of Done (DoD) pada setiap akhir sprint. DT harus bisa mandiri, yang artinya memahami cara menerapkan setiap PBI tanpa bantuan SM atau PO. Oleh karena itu, pada setiap Sprint Planning, DT harus memahami semua PBI yang akan di deliver secara mendalam. Pada sprint ke-1 kami memahami dengan baik PBI yang diambil, yang mengakibatkan hasil produk masuk sebagai salah satu product of the sprint (siapa sangka :D).Namun, pada Sprint ke-2 contohnya tim kami belum secara penuh memahami PBI, sehingga lumayan memakan waktu untuk memahami bersama-sama lagi sebelum kemudian men-deliver PBI tersebut.

Scrum Event

Ada beberapa event pokok yang harus dilakukan pada saat mengimplementasikan scrum. Ada event yang dilakukan tiap sprint, atau harian. 1 sprint umumnya berlangsung selama 2–4 minggu. Kami menggunakan durasi 2 minggu, yang artinya pada setiap Sprint atau durasi 2 minggu tersebut, semua PBI yang kami ambil harus ter-deliver dengan baik agar bisa increment pada sprint berikutnya.

tim kami (minus PO) pada saat simulasi Sprint Planning
board task kami di gitlab, setiap card menunjukkan PB, dengan label dibawahnya menunjukkan PBI. avatar menunjukkan orang yang di-asign untuk PB tersebut

Sprint diawali dengan Sprint Planning, yang mana disitu kami bersama-sama mendefinisikan di board gitlab apa goal kami pada sprint di tersebut serta PBI mana yang akan kami kerjakan untuk mencapainya. Jumlah PBI yang diambil harus pas, karena jika kurang maka produk akan terhambat dan jika berlebih maka pada akhir Sprint ditakutkan DoD tidak tercapai. Kami juga berdiskusi mengenai rencana dan strategi kami selama Sprint tersebut, kemudian setelah itu kami membagi-bagi Product Backlog untuk diimplementasikan.

Setelah Planning, maka Sprint sudah resmi berjalan. Daily Scrum adalah meeting harian (namun kami selama seminggu dua kali) selama 15 menit yang berisi sharing masing-masing progress serta hambatan yang ditemukan. Pada daily scrum kami juga bersama-sama mencoba memberi saran solusi dari hambatan yang teman-teman kami hadapi, untuk dicoba diimplementasikan setelah daily scrum. harapannya, dengan adanya daily scrum hambatan-hambatan yang ditemukan menjadi terminimalisir sehingga produk bisa ter-deliver dengan baik.

Ka Aci super konstan mengajak daily terus-terusan :(

Selanjutnya, pada tiap akhir sprint, diadakan Sprint Review untuk mendemonstrasikan output sementara produk kepada klien kami, Pak John. Pada saat sprint review semua anggota tim harus hadir. Seperti yang sudah disebutkan, maka DoD yang sudah didefinisikan untuk setiap PBI, harus terpenuhi pada saar review. Hasil dari sprint review bukan hanya feedback dari klien, namun juga diskusi mengenai kemungkinan perubahan fitur, serta apa yang akan dilakukan pada sprint berikutnya.

tim LePepe bersama client kami Pak John setelah sprint review pertama(pria di tengah yang memakai topi).

Pada waktu yang berdekatan setelah Sprint Review, diadakan Sprint Retrospective, yaitu sesi sekitar 30–60 menit yang bertujuan untuk meng-improve performa tim kami. pada saat retro, kami melihat selama 1 sprint kebelakang, mencari hal-hal yang harus dipertahankan, ataupun hal-hal yang harus kami tinggalkan karena menghambat produk kami. Hal-hal tersebut tidak terbatas di sisi teknis, namun juga termasuk keserasian sebagai tim, prosedur, serta hal-hal lainnya. Biasanya pada saat retro, Ka Aci memimpin kami untuk menuliskan list good things, bad things, to-start, dan to-stop pada web metroretro.io

Retro yang kami lakukan setelah sprint-1

Setelah retro, maka iterasi dimulai dari awali lagi dengan sprit planning, dan seterusnya hingga semua PBI terimplementasi.

Akhir kata, dengan segala kelebihan yang dimilik, agile bukanlah metodologi terbaik. Penggunaan metodologi harus disesuaikan dengan kebutuhan masing-masing organisasi. Ada saat dimana agile justru bisa menghambat terdeliver nya suatu product dengan baik, misal pada produk yang requirement nya sudah sangat jelas dan tidak berubah-ubah. Pun tim yang mengimplementasikan Scrum haruslah siap, karena seperti yang sudah disampaikan, scrum itu susah untuk dikuasai karena perbedaan yang lumayan banyak dibanding metodologi tradisional.

Sekian pembahasan mengenai penerapan Agile dan Scrum pada proyek Advokasimu, semoga bermanfaat ya :D

--

--