Belajar Mengenal Scrum 101 — Bahasa Indonesia
Bacaan untuk individu atau tim yang penasaran tentang apa itu Scrum serta cara kerjanya.
Scrum belakangan ini sering diperbincangkan, khususnya bagaimana membantu startup atau perusahaan membangun produk mereka agar lebih teroganisir dan efisien.
Buat kamu yang penasaran dan masih bertanya-tanya apa itu Scrum, bagaimana cara kerjanya, dan hal lain seputar Scrum. Tulisan ini untuk kamu banget.
Ini bersumber saat saya menjadi bagian dari tim Scrum selama lebih dari setahun di salah satu perusahaan software di Surabaya sebut saja “Pied Paper” (Bukan nama perusahaan sebenarnya) yang bisa saya katakan, CEO saya waktu itu cukup fanantik dengan Scrum.
Setelah membaca tulisan ini sampai akhir, kamu akan mengetahui tentang SCRUM.
Siap? Mari kita mulai. Sebelum itu, silakan ubah posisi senyaman mungkin, lalu siapkan teh, kopi, atau makanan ringan untuk menemanimu membaca karena tulisan ini sedikit panjang.
Tulisan ini saya bagi menjadi beberapa bab besar agar kamu memahami lebih mudah tentang Scrum itu sendiri.
- Pondasi Scrum (Tentang Scrum, Pilar dan Nilai yang dijunjung)
- Tim Scrum (Product Owner, Scrum Master, Development Team)
- Aktivitas Scrum(Sprint Planning, Sprint, Daily Standup, dll)
- Referensi lanjutan untuk belajar SCRUM (buku, situs, dll)
Pondasi Scrum
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum hadir karena kondisi di lapangan saat ini yang penuh dengan tantangan dan perubahan dalam membangun sebuah produk.
Cara kerja Waterfall (atas ke bawah, dari bos nyuruh ke tim) kurang mampu membantu perusahaan dalam membangun produk yang besar dan berkualitas tinggi karena kondisi bisa berubah sewaktu-waktu.
Produk disini yang saya maksud adalah produk dalam bentuk software (produk digital). Konteks yang saya bawa didalam keseluruhan tulisan ini.
Berdasarkan beberapa artikel yang saya pelajari, Scrum juga bisa diterapin diberbagai tim (marketing, sales, dll) maupun berbagai tipe perusahaan.
Namun, ada pedekatan berbeda disana yang menyesuaikan dengan situasi tim dan kebutuhan customer. Saya yakin pondasi dan cara kerja nya tetap sama.
3 Pilar Penopang Scrum
1. Transparansi pekerjaan
Hal-hal kurang jelas yang berkaitan dengan dengan task/backlog seperti scope dan ekspektasi perlu diperjelas karena nantinya berpengaruh pada hasil akhir.
Misalnya dalam mengerjakan setiap backlog Scrum ada namanya “Definition of Done” yaitu, bagaimana kondisi sebuah task bisa dikatakan selesai. Hal ini akan membantu tim yang mengerjakan memiliki patokan yang dituju.
2. Pemeriksaan yang berkala
Tim yang terlibat di Scrum akan melakukan pemeriksaan berkala untuk terus memonitor progress yang telah dikerjakan serta mengetahui sedini mungkin bila ada sebuah hambatan.
Dalam aktivitas Scrum ada “Daily Standup”, dimana setiap anggota tim development saling berbagi progress pekerjaannya. Lebih detail tentang daily standup akan saya tulis di bawah, pada bab Aktivitas Scrum.
3. Adaptasi terhadap kondisi dan situasi
Suatu waktu misalnya dalam pengerjaan Scrum ada aspek yang menyebabkan hasil dari Scrum kurang maksimal, maka akan ada penyesuaian.
Dengan kata lain Scrum sendiri tidak kaku. Scrum fokus, namun ada saatnya juga adaptasi diperlukan agar sesuai dengan suasana tim.
Nilai-nilai yang dijunjung di Scrum
Selanjutnya setelah mengetahui pilar penopang Scrum, ada juga nilai-nilai yang dijunjung agar Scrum bisa berjalan sebaik mungkin sehingga produk yang dihasilkan berkualitas serta tim development merasa bahagia.
Nilai tersebut adalah komitmen dan fokus dalam pengerjaan task, keberanian dalam menyampaikan pendapat sebenarnya yang berkaitan dengan task, serta respect antar anggota Scrum.
Tim Scrum
Tim Scrum terdiri dari Product Owner (1), Scrum Master (1), dan Tim Development(Berbagai Roles). Akan saya jabarkan tanggung jawab nya setelah ini.
Kami dalam tim Scrum memiliki ruang dan fleksiblitas sendiri-sendiri guna menghasilkan produktifitas yang tinggi.
Mari kita mulai dari Product Owner.
Product Owner
Seseorang yang bertanggung jawab mengenai visi dari produk yang dikerjakan adalah Product Owner atau dulu kami singkat PO.
Product Owner juga bertanggung jawab memanage product backlog
- Bercerita tentang user stories nya, atau bahasa sederhananya user bisa melakukan apa saja dalam produk tersebut.
- Menjelaskan sedetail mungkin tentang produk backlog yang akan dikerjakan kepada seluruh tim sampai mereka paham.
- Mengurutkan berdasarkan prioritas yang telah dipertimbangkan sehingga produk bisa mencapai goal yang telah di tentukan.
Product owner biasanya hanya terdiri dari satu orang, dia yang menentukan kemana arahnya pengembangan produk.
Di Pied Paper dulu CEO kami lah yang berperan sebagai PO.
Karena PO lebih fokus kepada gambaran besar produk, ada kalanya dia belum mengetahui detail product backlog/task yang perlu dikerjakan oleh tim lalu PO memberikan kebebasan kepada tim untuk menentukan apa yang perlu dikerjakan sendiri atas persetujuan PO.
Hal tersebut sangat wajar di Scrum.
Untuk tim atau perusahaan yang berbasis proyek, yang menjadi PO biasanya adalah si klien.
Tim Development
Tim Development terdiri dari berbagai role yang dibutuhkan untuk mengerjakan produk backlog yang telah ditentukan oleh produk owner menjadi selesai (siap di lempar ke user).
Umumnya role tersebut terdiri dari developer, designer, dan tester.
Beberapa perusahaan memiliki Copywriter dan UX Writer sendiri dalam tim development. Hal tersebut tentu boleh-boleh saja. Mungkin lebih baik karena lebih terspesialisasi.
Adapun karakter dari tim development yang perlu dijunjung adalah:
- Mereka bekerja secara self-organizing, yang berarti tidak ada satupun (PO maupun Scrum Master) yang berhak mendikte terlalu teknikal bagaimana mereka mengerjakan sebuah backlog.
- Semua roles yang dibutuhkan untuk mengerjakan product backlog bergabung menjadi satu tim dengan title Tim Development. Tidak ada sebutan khusus walaupun nantinya ada spesialisasi tertentu misalnya designer mengerjakan desain. Akuntabilitas tinggi diperlukan karena agar tercapainya goal dalam Sprint.
Saat di Pied Paper dulu, kami sebagai desainer pun bahkan sering melakukan testing dari hasil teman-teman developer. Hal itu kami lakukan menyesuaikan dengan kondisi tim yang belum punya tester.
Yang penting goals keseluruhan tim tercepai.
Selanjutnya berapa jumlah anggota tim development yang optimal?
Tim development yang optimal seharusnya cukup kecil agar tetap lincah dalam mengerjakan task dan perubahan serta cukup besar agar mampu mengerjakan suatu pekerjaan yang signifikan.
Dari panduan yang saya baca di scrumguide.org anggota tim development yang kurang dari 3 orang akan menyebabkan tim kurang dalam hal produktifitas yang dihasilkan. Sedangkan jika lebih dari 9 orang dikhawatirkan akan membutuhkan terlalu banyak koordinasi sehingga kurang efisien.
Di Pied Paper dulu, tim development kami terdiri dari 5–6 orang.
Scrum Master
Seseorang yang bertanggung jawab agar nilai-nilai Scrum berjalan seutuhnya dalam pengembangan produk adalah tanggung jawab dari Scrum Master (SM).
Tanggung jawab Scrum Master terhadap Product Owner
- Membantu PO menyampaikan tujuan dan visi produk serta scope dari product backlog kepada keseluruhan tim Scrum.
- Membantu PO menyusun dan memprioritaskan product backlog
- Coahing kepada PO bagaimana menjadi PO yang lebih baik.
Tangung jawab Scrum Master terhadap Tim Development
- Melakukan coaching secara berkala kepada tim development agar mereka tumbuh sebagai sebagai tim yang lebih baik lagi daripada sebelumnya.
- Membantu tim bila ada hambatan dalam pengerjaan. Bukan teknikal ke tools, namun lebih kepada misalnya butuh akses atau klarifikasi suatu task.
- Membantu menyampaikan ke PO bila ada task yang dirasa cukup besar dan perlu dipecah-pecah lagi.
Tanggung jawab Scrum Master terhadap keseluruhan tim Scrum
- Memfasilitasi keseluruhan event yang berjalan di Scrum sebaik mungkin terutama saat Sprint Planning dan Retrospective.
- Menjadi penengah antara kemauan Product Owner dan kemampuan Tim development dalam merealisasikannya agar sama-sama memahami dan menemukan titik tengah.
- Terus belajar bagaimana menciptakan sebuah lingkungan bekerja yang kondusif dan nyaman untuk tim development agar produktifitas lebih tinggi.
Aktivitas dalam Scrum
Aktivitas dalam Scrum adalah nyawa dari berjalannya Scrum itu sendiri untuk mengembangkan produk.
Aktivitas scrum terdiri Sprint Planning, Sprint(Kerja, kerja, kerja), Daily Standup, Sprint Review, dan Sprint Retrospective.
Mari kita bahas satu-persatu.
Sprint Planning
Pekerjaan yang akan kami kerjakan dalam satu sprint kedepan ditentukan saat sesi Sprint Planning ini.
Saat sesi Sprint Planning, Product Owner akan menentukan product backlog apa saja yang perlu dikerjakan.
Untuk mempermudah nya kami biasanya membuat sebuah “user stories”. Contoh dari user stories seperti dibawah ini.
Selanjutnya dari user stories akan dipecah menjadi beberapa task backlog yang mendukung.
Kami menulis backlog nya di Sticky note.
Di tahap ini PO harus menjelaskan task backlog secara jelas kepada tim development. Bila ada pertanyaan Tim Development harus berani bertanya dan klarifikasi untuk mencegah misunderstanding di belakang.
Lalu kita biasa mengadakan scoring tiap task untuk mengukur effort yang dibutuhkan dalam mengerjakan task tersebut.
Di Pied Paper dulu, kami scoring antara 1–8 per task. Jika kami pikir lebih dari 8, maka task akan kami pecah lagi.
Sebelumnya kami scoring 1–13, namun ada perubahan. Scrum Master menyarankan agar pekerjaan bisa selesai dan lebih terukur, kami turunkan nilai pertask nya.
Setelah di scoring, kemudian Task akan diurutkan oleh Product Owner dibantu oleh Scrum Master untuk memprioritaskan apa yang perlu dikerjakan lebih dahulu.
Scrum Master akan menjaga sesi Sprint Planning tetap dalam Time-box yang berjalan. Dalam panduan di scrumguide.org Ken Schwaber dan Jeff Sutherland (Founder Framework Scrum) menuliskan estimasi Sprint Planning maksimal 4 jam untuk satu bulan per sprint.
Di Pied Paper dulu, Sprint Planning berjalan antara 30 menit sampai 1 jam saja untuk satu minggu per Sprint.
Masa Sprint
Setelah Sprint Planning selesai, kita langsung masuk ke Sprint. Scrum Sprint. Kalau Sprint Planning selesai siang hari, berarti kita bisa mulai mengerjakan backlog yang ada pada sisa hari tersebut.
Developer bisa mengambil tasknya. Begitupun desainer. Serta roles yang lain.
Setelah Scrum Master menyusun semua sticky note yang berisikan backlog di papan Scrum baris Commitment/Sprint Backlog.
Kami bisa mulai mengambilnya lalu pindahkan di In Progress.
Masa Sprint ideal nya tidak terlalu lama. Di scrumguide.org menyarankan maksimal 1 bulan sprint.
Di Pied Paper masa sprint kita adalah 4 hari kerja + Setengah hari setelah Sprint Review, Retrospective, Planning.
Di beberapa startup yang cukup ternama di Jakarta menggunakan Sprint per 2 minggu.
Daily Standup
Daily standup adalah ritual harian dalam Scrum yang bertujuan untuk memonitor progress pengerjaan backlog yang dilakukan oleh tim development tanpa PO dan Scrum Master.
Di daily standup ini juga diharapkan misalnya ada hambatan atau masalah, maka akan diketahui sedini mungkin sehingga menjadi kesempatan bagi anggota lain untuk membantu.
Di Pied Paper dulu kami melakukan Standup saat tim development sudah tiba dikantor semua.
Salah satu dari kami menekan bell, kringgggg tanda kita harus berdiri dari meja kerja menuju papan scrum.
Salah satu template umum dalam sharing progress di daily standup adalah menyampaikan hal yang menjawab 3 pertanyaan dibawah ini.
- Apa yang kamu lakukan kemarin? Dan bagaimana jalannya? Sudah selesai kah?
- Apa yang akan menjadi fokus kamu hari ini?
- Apakah ada hambatan yg menyebabkan kamu tidak bisa mengerjakan task tersebut?
Daily standup fokus pada sharing progress. Diluar itu misalnya ada diskusi yang terlalu teknikal sebaiknya dibicarakan diluar standup.
Standup maksimal 15 menit. Lebih cepat lebih baik namun tetap mengutamakan kualitas dari standup itu sendiri.
Sprint Review
Setelah masa Sprint selesai. Selanjutnya ada hari dimana kita melakukan Sprint Review, Retrospective, dan Sprint Planning lagi.
Sprint Review dimulai dengan mendemokan lagi backlog yang telah selesai dikerjakan dan berada di QA oleh tim kepada Product Owner.
Dalam tahap mendemokan ini tim akan bercerita juga misalnya ada pertimbangan tertentu kenapa melakukan suatu hal sehingga hasilnya seperti itu.
Product Owner memiliki wewenang apakah backlog atau hasil yang dikerjakan cukup baik untuk dikatakan done atau belum sehingga akan diperbaiki di Sprint berikutnya.
Sprint Review juga di Timebox oleh Scrum Master agar berjalan seefisien mungkin.
Sprint Retrospectives
Sesi ini adalah kesempatan bagi tim development untuk melihat Sprint ke belakang. Apa yang berjalan serta dan apa yang berjalan kurang baik.
Kemudian dari situ kesempatan bagi tim untuk menyampaikan bagaimana untuk memperbaikinya.
Bisa dibilang retro adalah salah satu sesi yang penting. Banyak perusahaan yang melakukan aktivitas Scrum seperti daily standup, namun tanpa retro.
Ini menyebabkan bila ada kesalahan atau kurang pas pada perusahaan tersebut, maka mereka akan terus menerus mengulangi kesalahan yang sama.
Waktu di Pied Paper sendiri dulu, sesi yang paling saya tunggu adalah sesi retro ini karena Scrum Master tahu banget bagaimana cara coaching kami untuk menjadi tim yang lebih baik lagi. Beberapa kali lakukan games, tim building, dll.
Beberapa referensi yang bisa dilakukan saat Sprint Retro
- Activities and ideas for making agile retrospectives more engaging https://www.funretrospectives.com/
- 5 Ideas to improve your next retrospective https://www.hexacta.com/2017/09/25/5-ideas-to-improve-your-next-scrum-retrospective/
Sampai sejauh ini, sebenarnya cukup untuk mengenal Scrum. Bonus dari saya. Akan saya tambahkan tentang urutan workflow di Papan Scrum yang kami gunakan dulu saat di Pied Paper.
Di Pied Paper dulu kami urutan workflow scrum kami berawal dari Backlog, Commitment, In Progress, Review, dan Done. Serta ada tambahan Blocked.
Backlog/Product Backlog
Di baris Backlog ini kami menaruh semua ide fitur dan user stories dari produk yang akan dikembangkan.
Commitment/To Do/Sprint Backlog
Saat Sprint Planning, Scrum Master, Product Owner, dan Tim berdiskusi menentukan apa yang akan menjadi fokus satu Sprint kedepan.
Setelah task yang akan dikerjakan selama satu sprint kedepan ditentukan di Sprint Planning. Selanjutnya task tersebut akan kita taruh di Commitment yang menandakan itu menjadi komitmen kami untuk diselesaikan.
Selanjutnya kami akan fokus menyelesaikan yang ada di komitmen.
In Progress
Dari task yang ada di Commitment, misalnya saya ingin mengerjakan suatu task, maka akan saya ambil task tersebut. Tulis tanda nama saya di pojok kiri bawah, lalu saya pindahkan ke In Progress.
Review
Setelah task yang saya kerjakan selesai, maka akan saya pindahkan ke Review untuk direview oleh tim yang lain maupun PO.
Done
Hanya PO yang berwewenang memutuskan suatu task telah selesai atau belum dengan mempertimbangkan Definition of Done yang disepekati sebelumnya.
Blocked.
Bloked berisi task atau feature yang belum bisa dikerjakan oleh tim karena suatu hambatan yang memang diluar kontrol tim. Misalnya ketergantungan pihak ketiga.
Bonus kedua. Beberapa produk yang cukup sering kami pakai dalam workflow Scrum.
Dot Voting
Kami gunakan saat Sprint Retrospective untuk melakukan voting.
Di marketplace Indonesia kamu bisa menemukannya dengan menggunakan kata kunci “stiker bulat kecil”, “label stiker bulat kecil”
Timer Mekanik
Kami gunakan saat meeting agar tetap on time dan efektif.
Kamu bisa mencarinya diberbagai marketplace Indonesia.
Bel Resepsionis
Lebih efisien dan efektif sebagai penanda waktunya daily standup. Daripada salah satu dari kami bilang “gaes, standup gaes”, salah satu dari kami tinggal tekan bel, lalu semua nya paham kalau waktunya standup.
Bola
Kami gunakan saat Daily Standup. Anggota yang ambil bola berarti yang mulai standup, selanjutnya bila selesai, bola akan diberikan pada anggota tim yang lain yang berarti saat nya dia ngomong di standup.
Bacaan dan link menarik untuk memperdalam Scrum
Buku Manajemen Modern dengan Scrum
Buku yang ditulis oleh Joshua Partogi ini membuka banyak wawasan bagi kami yang membaca nya tentang bagaimana memanusiakan software developer sehingga mereka bisa bahagia dan menghasilkan produk berkualitas dan berdaya jual tinggi.
Untuk membelinya bisa melalui ofisial website nya disini atau kalau kami ingin lebih cepat bisa cari di marketplace tokopedia, shopee, atau yang lainnya.
Situs ScrumGuide.org
Ofisial situs dari panduan Scrum ditulis langsung oleh creator Scrum Jeff Sutherland dan Meet Ken Schwaber.
Merasa artikel ini tidak terlalu buruk buat kamu? Silakan Clap 👏👏👏 dengan senang hati atau bagikan ke kerabat, teman kerja, atau siapa saja yang ingin kamu bagikan.
Terima kasih banyak buat teh Riana Mahilda 👧 UX Writer di Gadjian, karena telah membantu saya memperhatikan titik koma, huruf besar- kecil, dan keseluruhan penulisan tulisan ini. 🙏🙏🙏
