Sebagai pihak yang mempopulerkan konsep Sprint, Scrum Guide mendapatkan keistimewaan tersendiri: menjadi acuan dasar definisi Sprint di laman wiki ini. Pendetailan praktik diperbolehkan, asalkan tidak melanggar definisi praktik Sprint di Scrum Guide.
Sprint adalah praktik agar kita bisa:
Apa yang dimaksud dengan ‘stakeholder’? Semua pihak di luar tim pengembang (pihak bisnis & developer) yang terkena dampak langsung dari produk yang dibuat. Stakeholder termasuk dan tidak terbatas pada: pengguna langsung software, bos/divisi dari pengguna langsung software (misal itu software yang membantu perusahaan), pemimpin di organisasi pembuat software, dan pemilik organisasi pembuat software.
Apa yang dimaksud dengan ‘tema besar pekerjaan’? Di dalam sebuah sprint bisa dikerjakan lebih dari satu pekerjaan. Semua pekerjaannya harus memiliki benang merah yang sama, yaitu tema besar tersebut. Di pertengahan sprint, detail sebuah pekerjaan boleh berubah-ubah — bahkan pekerjaannya itu sendiri boleh keluar-masuk. Namun tema besarnya harus sama sampai semua pekerjaan-pekerjaan yang terkait dengan tema besar tersebut selesai — bisa di akhir atau di pertengahan sprint. Tujuannya adalah agar bisnis memiliki fokus & perbedaan perubahan permintaan bisnis tidak terlalu membuat developer stres.
Apa yang dimaksud dengan ‘siap rilis’? Sudah dites sehingga tidak ada lagi keraguan untuk merilis hasil kerja tersebut ke pengguna. Jadi, istilah ‘pengembangan’ di sprint berarti sudah termasuk ‘pengujian akhir’ di dalamnya. Tujuannya agar minimal di setiap sprint, pihak bisnis mampu untuk merilis sesuatu guna mendapatkan data empirik baru terkait kebutuhan pengguna.
Apa yang dimaksud dengan ‘konsisten’? Konsisten dengan panjang sprint-nya. Kalau satu minggu, sprint selanjutnya juga satu minggu. Saat berjalan, panjang sprint tidak boleh berubah secara ad-hoc. Jangan diperpanjang karena pekerjaan belum selesai, atau justru diakhiri lebih cepat karena selesai lebih cepat.
Setelah sebuah sprint selesai, baru dipersilahkan mengubah panjang sprint untuk sprint selanjutnya. Namun, tujuan perubahan hanyalah untuk mencari panjang sprint yang pas buat tim & pekerjaan. Setelah dirasa pas, wajib kembali konsisten. Dengan panjang sprint yang konsisten, tim developer jadi terlatih mengukur kapasitas mereka setiap X minggu. Estimasi mereka akan lebih akurat.
Apa yang dimaksud dengan ‘tanpa jeda’? Di antara dua sprint, tidak ada waktu kosong. Tujuannya agar melatih akurasi estimasi & menjaga momentum.
Seperti yang sudah dijelaskan di atas, ‘Sprint’ bisa melatih akurasi asalkan:
Tiga syarat di atas sebenarnya masih kurang. Yang kurang adalah ‘Hak penuh developer untuk mengestimasi kapasitas tanpa intervensi’. Kenapa?
Idealnya di awal sprint, developer atau tim developer mengambil sendiri pekerjaan-pekerjaan mereka, sesuai prioritas bisnis yang sudah ditentukan. Jika di awal sprint mereka dituntut/dirayu untuk mengambil (baca: mengestimasi) lebih, maka, saat di akhir sprint ternyata mereka tidak bisa menyelesaikan semua pekerjaan mereka akan cenderung menyalahkan pihak yang menuntut/merayu di awal. Padahal bisa jadi kelalaian internal mereka, atau faktor-faktor eksteral turut mengambil peran. Intervensi ke estimasi membuat mereka jadi sulit mempelajari berapa sebenarnya kapasitas produksi mereka. Padahal bisnis akan sangat terbantu kalau estimasi mereka akurat.
Lalu bagaimana jika pihak bisnis punya target besar dengan waktu yang terbatas? Justru di kondisi seperti inilah akurasi estimasi makin dibutuhkan. Di kondisi krusial seperti ini, pihak bisnis makin butuh estimasi yang jujur & akurat. Karena kegagalan bisa memalukan di mata klien/publik. Istilahnya, “kalau memang tidak bisa, bilang tidak bisa dari awal”.
Jika mempraktikkan Sprint dan berada di kondisi seperti di atas (ada target besar dan strategis namun waktu terbatas), pihak bisnis bisa buka-bukaan ke developer, terkait kenapa ekspektasi beliau bisa krusial untuk kesukesan produk. Jika developer bisa memahami, mereka bisa jadi akan bersedia menambah jam kerja (lembur) — asalkan tidak burnout / merekomendasikan developer freelance ahli kenalan mereka untuk bergabung / memberikan alasan yang masuk akal untuk mengurangi ekspektasi fitur.
Jangan pernah coba-coba menego estimasi mereka, jika ingin kultur keterbukaan seperti di atas tercapai. Anggap Anda adalah pihak bisnis. Anda takut otonomi terhadap estimasi ini membuat developer sengaja mengambil pekerjaan sesedikit mungkin — sehingga jam berkerja mereka jauh lebih sedikit dari jam kerja yang kalian sepakati (9-to-5 misalnya) — lakukan dua hal berikut:
Bagaiamana Sprint bisa melatih akurasi estimasi developer / tim developer?
Di dalam sebuah sprint, ada 4 tahap yang terjadi secara berurutan: planning, development, review, retrsopective.
Planning
Sprint dibuka dengan kegiatan planning. Berikut garis besar agendanya:
Artinya, di akhir planning sudah ada tema besar sprint, pekerjaan-pekerjaan sprint yang cukup detail buat developer, dan strategi pengerjaannya.
Kegiatan planning ini maksimum 8 jam untuk sprint yang panjangnya satu bulan. Untuk sprint yang lebih pendek, waktu planning bisa lebih pendek.
Development
Pihak bisnis hanya bisa menulis ekspektasi hasil kerja dengan bahasa bisnis (baca: bahasa orang awam) — bukan bahasa teknis. Jadi, kegiatan diskusi pertama tim developer untuk membahas desain/arsitektur teknis, sudah terhitung kegiatan development sebenarnya.
Kalau itu ujung awal development, ujung akhirnya apa? Ujung akhirnya adalah saat waktu development-nya habis. Ingat, panjang sprint tidak boleh berubah. Idealnya, di penghujung waktu development (baca: tepat sebelum kegiatan review), semua pekerjaan yang diestimasikan di awal sudah selesai dites dan siap rilis. Jika belum selesai, waktu review tidak bisa diundur.
Bagaimana jika development pekerjaan-pekerjaan yang diestimasi di planning, selesai jauh lebih awal dari jadwal review? Apakah boleh liburan? Atau boleh langsung mengeksekusi ide-ide developer sendiri terhadap produk? Keduanya tidak boleh. Yang boleh adalah mengambil antrian pekerjaan berikutnya — meski tema besarnya mungkin berbeda. Akan bagus jika pekerjaan(-pekerjaan) berikutnya sudah dalam kondisi cukup detail untuk dikerjakan developer — yang juga berarti planing sprint berikutnya sudah lebih siap. Jika pekerjaan(-pekerjaan) teratas di antrian belum cukup detail, sementara di tengah sprint developer sebentar lagi akan menyelesaikannya, segera hubungi pihak bisnis untuk mendetailkan pekerjaan berikutnya.
Diskusi developer dan pihak bisnis, untuk membahas spesifikasi pekerjaan (baik untuk sprint ini maupun sprint-sprint berikutnya) bisa terjadi di tengah development. Dengan syarat waktunya tidak melebihi 10% dari panjang sprint.
Review
Spesial untuk kegiatan review, pihak bisnis juga mengundang perwakilan stakeholder. Tujuan review memang untuk menutup semua kegiatan terkait pekerjaan dengan demo produk dan diskusi. Hadirnya perwakilan stakeholder jadi krusial. Berikut garis besar agenda Review:
Kegiatan review ini maksimum empat jam untuk sprint yang satu bulan.
Retrospective
Review adalah penutup semua kegaitan terkait pekerjaan. Namun sprint belum berakhir. Review dilanjutkan oleh retrospektif. Di retrospektif, bukan pekerjaan yang dibahas, melainkan cara berkerja & segala perasaan-perasaan positif/negatif tiap-tiap orang pihak bisnis maupun tim developer.
Selepas retrospective, harusnya sudah ada aksi perbaikan untuk dieksekusi di sprint berikutnya — dan dibahas hasilnya di retrospektif sprint tersebut. Agar tidak lupa mengeksekusi aksi perbaikan, diwajibkan untuk mengikutkannya ke to-do-list visual pekerjaan-pekerjaan sprint berikutnya.
Tips & trik implementasi retrospective di sprint bisa dibaca di praktik Retrospektif Tim.
Bayangkan: di awal sebuah inisiatif — sebelum ada pengembangan sama sekali — sudah diplot tema besarnya…
Apakah prediksi di atas akan jadi kenyataan?
Jawabannya tidak mungkin.
Pertama, sisi lama pengembangan yang sulit diestimasi. Di programming, banyak variabel yang sulit diprediksi di awal. Realitanya, bisa saja fitur ‘Register’ baru selesai di Sprint 3. Tentu plot-plot tema besar di bawahnya juga ikut turun.
Kedua, kebutuhan bisnis terus berubah. Ingat, pengembangan yang tangkas pasti mempraktikkan ‘MVP’ & menjiwai Build-Measure-Learn (Pilar 2). Bisa jadi baru diketahui di tengah-tengah sprint 3, bahwa ‘Chat gambar 1-on-1’ lebih dibutuhkan pengguna daripada ‘Chat emoji 1-on-1’.
Biasanya pihak bisnis punya bayangan yang cukup jelas akan tema-tema besar & pekerjaan-pekerjaan terkait untuk 3-4 sprint ke depan. Lebih jauh dari itu, makin kabur. Ini adalah hal kunci yang membedakan praktik-praktik agile dengan praktik-praktik era sebelumnya (waterfall).
Kebutuhan apa dulu? Bugfix dari hasil pekerjaan sprint sebelumnya? Jika tidak punya tim khusus untuk bugfix, mau bagaimana lagi? Tentu dibolehkan. Silahkan kerjakan meski tidak ada hubungan dengan tema besar sprint saat ini.
Fitur baru? Ini yang tidak boleh. Karena tidak sesuai dengan tema besar. Kalau dibolehkan, developer bisa pusing. Karena sayangnya, pekerjaan programming tidak seperti pekerjaan membuat bangunan — yang bisa dengan mudah ditinggal di tengah-tengah, pindah ke pekerjaan lain, lalu kembali mengerjakan pekerjaan yang ditinggal. Ada banyak informasi yang harus dimasukkan ke otak programmer saat dia mengerjakan sebuah fitur. Jika ada fitur lain yang jauh berbeda dengan fitur yang dia kerjakan, dia harus mengosongkan otaknya dan mengisi dengan informasi lain. Di programming, perpindahan konteks itu tidak mudah, tidak sebentar, dan memakan banyak energi.
Lalu bagaimana solusinya? Tunggu sprint berikutnya. Atau jika bisnis punya justifikasi yang bagus kenapa tidak bisa menunggu, batalkan sprint yang berjalan. Pembatalan dibolehkan, asalkan ditutup dengan baik-baik (jelaskan justifikasinya & terima semua pekerjaan developer). Developer atau tim developer pasti kecewa pekerjaannya diinterupsi, namun jika masuk akal buat mereka, pada akhirnya mereka akan menerima.
NB: Kasus pembatalan sprint ini juga bisa terjadi misal tiba-tiba pemerintah merilis regulasi yang melarang fitur yang dibuat di sprint ini.
Jelas, praktik Sprint mempercepat & mempersering rilis. Bahkan dalam satu Sprint bisa jadi lebih dari satu rilis. Karena Sprint tidak mewajibkan rilis harus di akhir / setelah sprint. Yang diwajibkan adalah merencanakan & mengusahakan adanya hasil kerja yang kondisinya siap rilis selambat-lambatnya di akhir sprint — perihal dirilis atau tidak, tidak dibahas di praktik Sprint.
Sebagaimana yang disebutkan di atas, praktik Sprint tidak mewajibkan rilis di akhir sprint. Kalau sebuah MVP ternyata membutuhkan 5 sprint, berarti rilis pertama baru terjadi setelah menunggu 5 sprint. Dalam konteks ini, Sprint tidak mempunyai peran langsung ke Pilar 2.
Namun, karena praktik Sprint mewajibkan adanya demo hasil kerja & pembahasan bersama stakeholder di akhir sprint, praktik Sprint bisa jadi pemicu untuk munculnya ide-ide baru terkait produk. Ide-ide baru tersebut bisa merubah arah produk ke depannya. Artinya, Sprint berperan langsung menegakkan Pilar 2.
Jika estimasi developer atau tim developer diintervensi & tidak dihargai, maka itu bukanlah praktik Sprint — silahkan baca Scrum Guide jika tidak percaya.
Apakah developer pasti tidak akan ‘burnout’ kalau dibebaskan mengestimasi? Belum tentu. Contoh kasus: sebuah tim developer mengambil pekerjaan terlampau banyak. Karena mereka berkerja secara otonom, mereka dibiarkan saja saat memutuskan untuk tetap menyelesaikan semuanya — bahkan sampai harus lembur berhari-hari. Akhirnya, jatuh sakit (alias burnout). Hal ini mungkin terjadi saat mempraktikkan Sprint yang benar. Namun — juga karena praktik Sprint yang benar — di sprint berikutnya mereka sudah belajar untuk mengambil pekerjaan lebih sedikit. Jadi, tetap happy ending.
Riwayat perubahan halaman ini github.com/3pillarsofagile/3pillarsOfAgile.github.io/commits/master/_practices/sprint.md