"Kami berbaring, kami menyalakan lampu, di Semesta kami satu-satunya." Tampaknya baris ini dari lagu grup Splin dapat dikenali dengan aman sebagai soundtrack pengenalan praktik Ulasan Sprint di Dodo Pizza.
Penafian: dalam sebuah artikel, Anton menjelaskan versi pertama dari sprint review yang layak. Kami sudah memiliki yang lebih maju, tetapi tentang hal itu di seri berikutnya.
Upaya pertama untuk meluncurkan praktik ulasan sprint di Dodo Pizza gagal total.
Mungkin Anda berpikir bahwa praktik rantai pizza scrum umumnya tidak berguna. Namun, salah satu keunggulan utama Dodo Pizza adalah, anehnya, sistem IT-nya sendiri, yang mengelola semua proses di 495 pizza rantai di 12 negara.
80+ pengembang dan analis sedang mengerjakan sistem ini hari ini (dan lebih dari dua ratus akan datang seiring waktu). Sebagai startup yang tumbuh cepat, kami berusaha untuk efisiensi maksimum, oleh karena itu, kami menggunakan banyak kerangka kerja "pengembangan fleksibel": Scrum, LeSS, pemrograman ekstrim.
Tapi apa scrum ini, Anda bertanya, tanpa ulasan sprint? Dan kamu akan benar.
Seperti yang Anda tahu, sprint review menetapkan ritme untuk tim dan memotivasi untuk menyelesaikan pekerjaan pada akhir sprint. Lebih penting lagi, ini membantu menciptakan produk berharga yang dibutuhkan bisnis, dan tidak hanya melakukan tugas-tugas simpanan. Jadi, bagaimanapun, mereka menulis di buku.
Namun, untuk beberapa alasan pendekatan ini tidak berhasil bagi kami. Misalnya, di salah satu ulasan sprint pertama kami menunjukkan kepada franchisee Dodo Pizza dari Kazakhstan situs baru mereka - dodopizza.kz. Umpan baliknya menginspirasi: para mitra mengatakan bahwa situs tersebut terlihat cantik, dan dengan latar belakang para pesaing itu akan tampak seperti sebuah mahakarya.
Ketika kami meluncurkannya, ternyata banyak hal yang hilang di dalamnya. Artinya, kami menghabiskan waktu untuk ulasan sprint, tetapi sebenarnya tidak mendapatkan umpan balik yang berguna dari mitra.
Secara umum, segera kami dengan tenang menghentikan ulasan sprint tersebut.
Setelah beberapa bulan, saya memutuskan untuk mencoba lagi. Pada saat itu, kami sudah memiliki delapan tim yang mengerjakan backlog yang sama dalam kerangka LeSS. Kami mencoba mengikuti semua aturan Scrum Skala Besar, dan kurangnya ulasan sprint adalah salah satu pelanggarannya.
Saya mempersiapkan sebelumnya untuk fakta bahwa pada awalnya semuanya akan buruk, dan Anda harus mencari format yang benar menggunakan metode coba-coba. Setelah setiap ulasan, saya meminta peserta untuk menilai acara pada skala 1 hingga 10 (Bawah - Omnische). Pada awalnya, peringkatnya sangat rendah, lebih dekat ke "bawah". Namun, kami tidak menyerah, bereksperimen, dan di suatu tempat dalam beberapa bulan mereka mulai beralih ke Ognist.
Itulah yang kami ubah
Melakukan pekerjaan rumah
Kami menyadari bahwa Anda perlu menghabiskan waktu tidak sedikit untuk persiapan dibandingkan dengan ulasan sprint itu sendiri - atau bahkan lebih. Seluruh acara memakan waktu dua jam, dan saya bersiap-siap selama tiga jam. Lagi pula, Anda perlu mengoordinasikan tujuan dengan tim, mengatur dengan mitra, manajer perusahaan manajemen, karyawan restoran pizza dan tamu lain, memesan percakapan, membuat poster, mencari fasilitator, menginstruksikan, menyusun dan menggambar jadwal, menggantung sandal obrolan untuk mengumpulkan umpan balik, dll. Tanpa semua ini, akan ada kekacauan.
Jangan tampilkan yang belum selesai
Pada awalnya, kami menunjukkan fitur setengah jadi. Tetapi kami menyadari bahwa ini adalah cara kami menipu tim dan, yang paling penting, pelanggan. Suatu kali kami menunjukkan CEO dari perusahaan geoservice yang melakukan cache data peta. Kemudian pada ulasan berikutnya ditampilkan lagi - hanya dengan bug yang diperbaiki. Ketika kami masuk untuk ketiga kalinya dan menunjukkan layanan yang sama, tetapi sudah ada di situs web pertempuran, CEO memiliki pertanyaan alami: "Apa yang Anda tunjukkan hal yang sama untuk ketiga kalinya?"
Sekarang di ulasan sprint kami hanya menunjukkan apa yang diposting di situs pertempuran. Jika ada sesuatu yang hampir siap - hanya ada bug untuk diperbaiki, uji dan lay out bug - kami tidak menunjukkan.
Negosiasi bukannya ruang terbuka
Penulis LeSS merekomendasikan tinjauan sprint dalam bentuk "bazaar". Semua tim harus menunjukkan pekerjaan mereka di satu ruangan besar, dan mereka yang tertarik dapat pergi ke stasiun yang menarik perhatian mereka. Kami mencobanya beberapa kali, ternyata berisik dan rewel.
Layar laptop kecil, tidak ada yang terlihat pada mereka, kebisingan dari stasiun tetangga membuatnya sulit untuk berkonsentrasi, dan pergerakan orang yang konstan menciptakan kekacauan. Oleh karena itu, sekarang di ruang konferensi semua orang hanya mengumpulkan di awal dan di akhir. Aksi utama berlangsung di ruang pertemuan, di mana masing-masing tim mempresentasikan pekerjaannya. Di sana, peralatan, layar besar, Anda bisa duduk dengan nyaman, peserta jarak jauh terhubung dan ada tempat untuk mengumpulkan umpan balik.
Transisi dilarang!
Pada awalnya, para pemangku kepentingan kami bergerak bebas antar tim. Tapi itu menyebalkan. Bayangkan Anda mulai menceritakan sesuatu dan dalam sepuluh menit seseorang baru bergabung dengan grup dan mengajukan pertanyaan tentang apa yang baru saja Anda bicarakan.
Mulai menjawab - sisanya bosan. Abaikan - orang itu kesal. Karena itu, kami memutuskan untuk melarang perpindahan antar kelompok. Saya memilih topik yang menarik minat Anda - duduk di ruang rapat selama dua puluh menit sampai istirahat berikutnya.
Tamu yang terhormat
Kami menyadari bahwa komposisi "tamu" sangat penting. Tidak ada yang memotivasi pengembang seperti tampil di sprint review CEO. Terutama ketika Anda perlu menunjukkan kepadanya beberapa hal-trik teknis seperti layanan dalam kubus atau transfer Auth ke .Net Core. Kami harus menjelaskan mengapa kami melakukan ini. Fedor Ovchinnikov, CEO Dodo Pizza, memberi energi dan tahu bagaimana menghibur semua orang dan menguraikan cakrawala perkembangan perusahaan dalam tiga menit. Nah, ketika kami menampilkan fitur klien, misalnya, perancang setengah pizza dalam aplikasi seluler, kami sekarang memanggil tamu eksternal, biasanya kenalan dan teman dari Facebook.
Anggota yang dihapus
Sangat mudah untuk mengadakan rapat ketika semuanya ada dalam satu ruangan. Tetapi kami memiliki banyak karyawan jarak jauh di Syktyvkar, Nizhny Novgorod, Kazan dan Goryachy Klyuch. Penting juga bagi mereka untuk hadir.
Pada awalnya, "pekerja jarak jauh" mengeluh bahwa mereka sulit mendengar dan hampir tidak melihat apa-apa. Sekarang kami merawat mereka dan juga peserta offline. Ada item dalam daftar periksa persiapan sprint review yang mengingatkan kita untuk memeriksa koneksi dan mengatur peralatan. Kami menyiarkan di Slack, dan baru-baru ini, kami telah streaming acara di saluran youtube kami Dodo Pizza .
Sangkalan umpan balik
Ketika mulai tampak bahwa semuanya baik-baik saja dan tidak ada tempat untuk memperbaiki format, kami bertanya pada diri sendiri: apakah kita tidak membuang sampah? Tinjauan sprint adalah acara yang agak mahal (jika Anda melihatnya secara sinis - dalam hal jumlah peserta, gaji dan jam yang dihabiskan). Apakah kita menggunakan dua jam ini seproduktif mungkin? Akibatnya, kami memutuskan untuk sepenuhnya menolak untuk mengumpulkan umpan balik selama tinjauan sprint.
Dalam format acara seperti itu, itu tidak dapat dilakukan secara mendalam dan kualitatif (ingat kasus dengan Kazakhstan). Selain itu, kami mengumpulkan sebagian besar ulasan penting dan berkualitas tinggi selama sprint, menarik semua orang yang tertarik, dari pelanggan internal ke pengguna ... Anda akan terkejut, bahkan Panduan Scrum tidak mengatakan bahwa umpan balik harus dikumpulkan pada ulasan sprint: "Selama Tinjauan Sprint , Tim Scrum dan para pemangku kepentingan berkolaborasi tentang apa yang dilakukan dalam Sprint. " Tim dan pemangku kepentingan, bukan pengguna. Berinteraksi, tidak mengumpulkan umpan balik. Makna yang sama sekali berbeda.
Buka "dapur"
Tidak semua pemangku kepentingan tenggelam dalam proses pembangunan. Tetapi semua orang ingin tahu apa yang sedang terjadi di sana. Untuk tujuan inilah kami memutuskan untuk mengarahkan ulang ulasan sprint.
Kami masih menunjukkan pekerjaan yang dilakukan, tetapi di samping itu, tim menceritakan kisah di balik fitur-fitur baru. Apa tujuannya? Apa yang terjadi selama sprint? Apa yang mengalihkan perhatian kita atau mencegah kita mencapai tujuan? Tindakan apa yang telah kita ambil untuk menyelamatkan tujuan? Ini membantu: dengan cara ini menjadi jelas bagi manajer, misalnya, mengapa "menyembunyikan email klien dengan tanda bintang" adalah tugas yang sangat sulit ("setengah jam kerja programmer", seperti yang dipikirkan manajer). Sebaliknya, dialog semacam itu membantu pengembang berpikir tentang "pelanggan" dan masalah mereka, bukan dalam hal solusi spesifik yang sedang mereka kerjakan.
Ini mungkin hal utama yang kami ubah dalam pendekatan kami. Kemajuan terbukti, tetapi seperti biasa, masih ada sesuatu untuk diperbaiki. Eksperimen sedang berlangsung.
Hal utama yang kami pahami adalah bahwa kami tidak perlu menutup telepon pada format yang diusulkan dalam manual Scrum. Anda perlu mencoba, membuat kesalahan, dan bereksperimen. Tidak ada solusi universal - Anda perlu mencari solusi yang sesuai dengan situasi Anda.
Karena itu, saya ingin memperingatkan Anda pada akhirnya: jangan menyalin format kami. Dia bekerja dengan baik dengan kita karena dia dilahirkan sebagai hasil dari banyak percobaan. Carilah pendekatan Anda - dan Anda akan berhasil. Tentu tidak akan lebih buruk.