Daily Scrum : Penting gak sih ?

Pertanyaan yang sering saya dapatkan ketika sedang coaching atau memberikan training adalah “Mas, memangnya Daily Scrum itu perlu ya ? Gunanya untuk apa sih mas setiap hari meeting ? 15 menit gak pernah cukup mas”.

Pertanyaan-pertanyaan seperti ini akhirnya men-trigger saya untuk bikin artikel sederhana ini untuk membahas sedikit kenapa sih kita perlu melakukan Daily Scrum.

Sebelumnya, saya ingin mengutip dari Scrum Guide tentang definisi Daily Scrum :

“The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.”

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:

What did I do yesterday that helped the Development Team meet the Sprint Goal?

What will I do today to help the Development Team meet the Sprint Goal?

Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Saya menekankan terhadap Sprint Goal.

Sprint Goal adalah komitmen bersama di dalam Scrum Team dimana komitmen tersebut yang akan menjadi visi kecil bersama dalam menyelesaikan 1 siklus sprint. Setiap anggota Scrum Team baik itu Product Owner, Development Team dan Scrum Master harus menjunjung tinggi komitmen bersama tersebut agar Sprint berjalan bisa berjalan dengan sukses. Tanpa adanya Sprint Goal, bisa dipastikan Sprint tersebut akan berjalan ke arah yang tidak jelas dan umumnya akan berujung ke ambiguitas dimana sprint sudah berjalan lebih dari 15 atau 20 sprint tetapi belum ada satupun valuable increment yang di release.

Re planning Sprint Backlog

Anggaplah dalam sebuah pertandingan sepakbola “kemenangan” adalah goal dari pertandingan yang akan dijalankan sebuah team. Seorang pelatih dan teamnya akan menyiapkan strategi yang jitu dalam menghadapi lawan bertanding mereka berikutnya untuk mencapai goal tersebut. Ada kalanya strategi tersebut sudah dipersiapkan beberapa hari atau mungkin beberapa minggu sebelumnya untuk pertandingan yang akan dijalankan hari ini. Tetapi saat pertama kali para pemain menginjakan kakinya di lapangan pertandingan yang ditunggu-tunggu dan pluit kick-off dibunyikan , semua persiapan yang telah dilakukan bisa saja berubah total atau separuhnya melihat kondisi saat itu misalanya pemain yang cedera, pemain lawan yang diturunkan, kondisi lapangan, pertandingan team lain yang sudah lewat karena harus mengejar selisih goal, dll.. Sehingga setiap pemain di lapangan tersebut harus beradaptasi dan “merencanakan ulang” skema permainan agar tetap bisa memenangkan pertandingan.

Salah satu Agile Value , Responding to Change over Following a Plan, mungkin secara sederhana bisa menggambarkan situasi diatas. Sebenarnya, di hari pertama Sprint berjalan, seketika itu juga Sprint Planning yang sudah dilaksanakan menjadi obsolete \ tidak berlaku. Perlu diingat bahwa Sprint Planning adalah initial plan / rencana awal berdasarkan estimasi saat itu yang akan dijalankan oleh Development Team sepanjang sprint berjalan dalam bentuk Sprint Backlog. Ketika Sprint dimulai, maka para developer akan menemui banyak sekali aspek yang tidak teridentifikasi sebelumnya saat Sprint Planning, seperti misalnya : hidden task, informasi PBL yang perlu di elaborasi kembali dengan Product Owner, depedensi terhadap fitur yang lain yang melibatkan developer yang berbeda, kematangan skill tiap developer, tempat kerja yang berubah, developer yang tiba-tiba sakit, informasi tambahan terhadap PBL yang mempengaruhi task yang harus dikerjakan, otomasi test script yang perlu eksplorasi lebih, dll. Kondisi seperti inilah dibutuhkan adanya adaptasi secara terus-menerus sepanjang Sprint agar Sprint Goal yang sudah ditentukan saat Sprint Planning bisa tercapai.

Beberapa kali saya selalu perhatikan saat Sprint dijalankan, task yang dimasukan oleh Development Team adalah PBL yang sudah dibuat oleh Product Owner tanpa di elaborasi lebih jauh menjadi sebuah Sprint Backlog. Hal ini mengakibatkan saat Daily Scrum, inspeksi yang dilakukan adalah PBL , bukannya Sprint Backlog. Yang perlu dipahami , Sprint Backlog adalah task yang dibuat oleh Development Team untuk mencapai Sprint Goal yang dimanifestasiakan oleh Product Owner dalam bentuk PBL. Sprint Backlog ini tidak baku, bisa bergerak sangat dinamis saat sprint berjalan dari mulai menambah, mengurangi sampai mengubah task yang ada selama tidak mengubah dari Sprint Goal nya. Saat Daily Scrum dilaksanakan, pastikan Scrum Board harus selalu dibuka (bisa physical board atau virtual board seperti JIRA\Trello) sebagai bagian dari Transparansi dan Inspeksi. Go through kembali setiap Sprint Backlog yang ada apakah masih sejalan dengan Goal bersama? Visualkan semua impediments\hambatan yang ada yang dapat menyebabkan tidak tercapainya Sprint Goal. Setelah itu beradaptasilah dengan kondisi yang terjadi saat itu dengan cara mengatur ulang Sprint Backlog kita.

Daily Scrum bisa juga disebut sebagai reality check terhadap Sprint Goal. Output yang dihasilkan dari event ini adalah perencanaan ulang dari Sprint Backlog kita berdasarkan realitas yang ada agar development team bisa segera beradaptasi dengan kondisi tersebut untuk mencapai goal yang telah ditentukan.

Mengapa 15 menit ? apakah cukup ?

Beberapa bulan lalu saya merenovasi rumah saya untuk bikin kamar tidur anak saya yang sudah besar (sebelumnya satu kamar berdua sama adiknya). Sebelum renovasi saya dan kontraktor merencanakan apa-apa saja yang dibutuhkan selama pembangunan dari mulai design, material sampai budget. Saat renovasi dimulai, saya selalu perhatikan tiap pagi sebelom para tukang bekerja mereka berkumpul dulu untuk bicarain apa2 aja yang akan mereka kerjain hari ini, termasuk apabila perlu ada material baru yang perlu ditambahin atau diganti karena mungkin struktur tembok asli rumah saya atau struktur tanah yang mengharuskan adanya penggantian material. Mereka lakukan ini gak lebih dari 5–10 menit, seperti semacam “ice breaking” di pagi hari walaupun dengan sebatang rokok & kopi :D

Setelah itu baru mereka akan lakukan pekerjaannya masing-masing, dan si mandor setelah itu akan ngobrol dengan saya apabila dibutuhkan untuk mengubah material atau penambahan biaya lainnya, mandor ini seperti menyampaikan impediment\hambatan yang terjadi untuk mencapai goal nya (bikin kamar) ke saya dan ini dilakukan diluar kumpul-kumpul para tukang pagi-pagi itu.

Beberapa kali yang selalu terjadi , Daily Scrum menjadi semacam progress report dimana Developers melaporkan progress pekerjaan kepada Product Owner atau Scrum Master. Dari sini saja sudah ada 2 kesalahan fatal :

• Daily Scrum adalah eventnya Development Team, Product Owner dan Scrum Master hanya optional dan kalaupun ikutan, tidak boleh menginterupsi event tersebut.
• Daily Scrum bukan progress meeting.

Event ini tidak membicarakan solusi apalagi reporting, tidak perlu ada yang “siapa report ke siapa”. Ingat, Development Team adalah Self-Organize team yang mengatur dirinya sendiri untuk mewujudkan PBL yang diberikan oleh Product Owner.

Daily Scrum memberikan kesempatan untuk para Developer untuk saling berkordinasi karena di event ini semua akan saling sharing apa-apa saja yang telah dan mereka lakukan untuk bersama-sama mencapai Goal-nya. Dengan adanya transparansi seperti ini maka setiap developer dapat cepat mengidentifikasi apabila ada hal-hal yang depedensi dalam setiap pekerjaan mereka atau apabila ada hambatan yang saling terkait satu dengan yang lainnya.

Untuk bicara soal solusi atau penyelesaian terhadap hambatan, akan dilakukan di diskusi terpisah, karena bisa saja membutuhkan pihak lain dalam menyelesaikan masalah tersebut atau bisa saja hambatan yang ada hanya terkait 1–2 orang developer saja sehingga yang lainnya tidak perlu hadir dalam meeting lanjutan.

Selain itu, di dalam Daily Scrum ada kesempatan untuk saling mengidentifikasi knowledge gap antar developer sehingga mereka secara self-organized akan saling melengkapi gap yang ada dengan caranya mereka masing-masing. Dengan adanya pertemuan singkat seperti ini, pelan-pelan bisa membentuk lingkungan yang penuh dengan transparansi dan kejujuran sehingga team yang ada bisa semakin dewasa dan tentu benefitnya adalah terhadap Sprint Goal itu sendiri.

Jadi apakah 15 menit tersebut cukup : iya, pasti cukup, Selama daily scrum tidak diberlakukan sebagai status meeting.

Bagaimana dengan Daily Scrum anda ?