Apa yang Anda dapatkan ketika melewati departemen TI, ulasan Sprint, tekad, dan pizza yang salah? Kebesaran, itulah yang terjadi.
Upaya pertama kami untuk memperkenalkan
ulasan sprint di Dodo Pizza gagal secara spektakuler. Anda akan berpikir, mungkin, bahwa rantai pizza tidak memerlukan praktik Scrum sama sekali. Namun, anehnya kelihatannya, salah satu keuntungan utama dari
Dodo Pizza adalah sistem IT-nya sendiri yang mengontrol semua proses kerja dari 430 pizza di 11 negara.
Lebih dari 60 programmer dan analis bekerja di sistem kami sekarang, dan kami berencana untuk meningkatkan jumlah itu menjadi
lebih dari 200 . Seperti halnya start-up yang tumbuh cepat, kami bertujuan untuk efisiensi maksimum, jadi kami menggunakan banyak kerangka kerja Agile, termasuk Scrum, LeSS, dan pemrograman ekstrim. Tetapi bagaimana Anda menggunakan Scrum tanpa ulasan sprint? Itu pertanyaan yang mungkin Anda tanyakan - dan Anda akan benar.
Seperti yang kita ketahui, tinjauan sprint menetapkan ritme kerja untuk sebuah tim dan memotivasi untuk menyelesaikan tugas pada akhir sprint. Lebih penting lagi, tinjauan sprint membantu menciptakan produk yang berharga untuk bisnis, bukan hanya menyelesaikan masalah dari jaminan simpanan. Setidaknya, itulah yang dikatakan buku-buku itu.
Tetapi entah bagaimana, pendekatan ini tidak pernah berhasil untuk kita. Misalnya, di salah satu ulasan sprint pertama kami, kami menyajikan situs web baru (dodopizza.kz) kepada pemegang waralaba Kazakhstan kami. Umpan baliknya menginspirasi, mitra kami memberi tahu kami bahwa situs webnya tampak hebat, dan dibandingkan dengan para pesaing, itu praktis sebuah mahakarya. Tetapi setelah diluncurkan, ternyata itu benar-benar kurang. Jadi, kami membuang waktu untuk ulasan sprint tetapi belum mendapatkan umpan balik yang berguna.
Segera, kami diam-diam menghentikan ulasan sprint ini.
Beberapa bulan berlalu, dan saya memutuskan untuk mencoba lagi. Pada saat itu, kami memiliki delapan tim yang mengerjakan satu simpanan dalam kerangka
LeSS . Kami mencoba mematuhi semua aturan Scrum Skala Besar, dan pembatalan ulasan sprint merupakan pelanggaran.
Saya mempersiapkan diri untuk hasil awal yang buruk - jelas kami harus menemukan format yang tepat melalui coba-coba. Setelah setiap ulasan, saya meminta para peserta untuk menilai pada skala 1 sampai 10. Awalnya, nilai kami sangat rendah, tetapi kami tidak menyerah dan terus bereksperimen, jadi dalam beberapa bulan, ulasan mulai pindah ke bagian atas skala.
Inilah yang kami lakukan secara berbeda.
Melakukan pekerjaan rumah kita
Menjadi jelas bahwa persiapan tinjauan sprint membutuhkan waktu tidak kurang dari ulasan sprint itu sendiri, atau bahkan lebih. Review membutuhkan dua jam, dan saya menghabiskan tiga jam untuk mempersiapkannya. Ada ulasan tujuan untuk dibahas dan disepakati dengan tim, mitra, manajer perusahaan induk, karyawan, dan tamu lain untuk diajak bicara, ruang konferensi untuk dipesan, poster yang akan dibuat, fasilitator untuk menemukan dan menginstruksikan, jadwal untuk menyusun , umpan balik flip chart untuk digantung, dll. Dan tanpa semua itu, kekacauan terjadi kemudian.
Jika belum selesai, jangan tampilkan
Pada awalnya, kami menunjukkan fitur setengah jadi di ulasan sprint. Kemudian terpikir oleh kami bahwa ini berarti menipu tim kami dan, lebih buruk lagi, klien kami. Kami menunjukkan kepada CEO layanan pemetaan caching data kartografi satu kali. Pada ulasan berikutnya, kami menunjukkannya lagi, dengan bug diperbaiki. Ketika kami membawanya kepadanya untuk ketiga kalinya dan menunjukkannya di situs web langsung, dia punya pertanyaan yang sangat sah: mengapa dia harus melihat hal yang sama berulang kali? Sekarang, di ulasan sprint, kami hanya menunjukkan fitur yang ada di situs langsung. Jika sesuatu hampir selesai dan kami hanya perlu memperbaiki bug, mengujinya, dan meluncurkannya, kami belum menunjukkannya.
Ruang Konferensi Alih-alih Ruang Terbuka
Pembuat LeSS merekomendasikan melakukan tinjauan sprint sebagai "bazaar," di mana semua tim menunjukkan pekerjaan mereka di ruangan yang besar, dan orang-orang mengunjungi stasiun yang mereka minati. Kami mencobanya beberapa kali, dan banyak kebisingan dan kebingungan.
Layar laptop kecil dan tidak nyaman, Anda tidak dapat berkonsentrasi dengan baik karena kebisingan di stasiun lain, dan Anda mendapatkan kekacauan ketika orang-orang terus-menerus berkeliaran. Jadi sekarang kita semua berkumpul di ruang konferensi besar hanya di awal dan di akhir ulasan. Aksi utama berlangsung di ruang konferensi kecil, di mana masing-masing tim mempresentasikan hasil kerjanya. Ini lebih nyaman, ada semua peralatan yang diperlukan, layar lebar, dan akses internet untuk peserta jarak jauh, dan Anda dapat mengumpulkan umpan balik dengan tenang.
Berkeliaran tidak diizinkan
Pada awalnya, para pemangku kepentingan berjalan bebas di antara tim, tapi itu menjengkelkan. Bayangkan Anda melakukan presentasi, berbicara selama sepuluh menit, dan kemudian seseorang datang dan menanyakan pertanyaan tentang hal-hal yang baru saja Anda liput.
Jika Anda menjawab, semua orang bosan. Jika tidak, orang ini mungkin membencinya. Jadi kami memutuskan untuk tidak mengizinkan pengembaraan antar kelompok. Jika Anda telah memilih subjek, silakan, duduk di ruang konferensi dan tunggu 20 menit sampai istirahat berikutnya.
Tamu yang terhormat
Kami menyadari bahwa daftar tamu sangat penting. Tidak ada yang memotivasi pengembang lebih dari CEO perusahaan yang mengunjungi tinjauan sprint, terutama ketika Anda menunjukkan beberapa hal teknis, seperti hosting layanan microsoft di Kubernetes atau memigrasikan komponen Auth ke .Net Core. Maka Anda harus menjelaskan mengapa Anda melakukan semua hal ini sejak awal.
Fyodor Ovchinnikov, CEO Dodo Pizza , dapat mengisi energi audiens dengan energi, mengangkat semangat mereka dalam tiga menit, dan menguraikan prospek luas pengembangan perusahaan, tetapi ketika mendemonstrasikan fitur front-end, seperti fitur pizza build-your-own-pizza Anda sendiri di aplikasi seluler kami, kami mengundang tamu luar, sebagian besar kenalan dan teman dari Facebook.
Presenter Lucu dan Topi
Ternyata presenter membuat setengah dari keberhasilan ulasan sprint yang menarik dan menarik. Banyak orang telah memainkan peran itu; Saya mencobanya terlebih dahulu, dengan bantuan master Scrum kami.
Kemudian Sergey Gryazev, pemilik produk aplikasi seluler kami, menjadi presenter, dan sekarang kita tidak bisa membayangkan kejadian seperti itu tanpa leluconnya. Dan baru-baru ini, kami memperoleh artefak ritual, Topi Pembicara. Pembicara harus mengenakan topi. Itu tidak berarti sesuatu yang istimewa, itu hanya sebuah ritual, tetapi itu menghibur semua orang.
Peserta jarak jauh
Sangat mudah untuk melakukan tinjauan sprint ketika semua orang duduk di ruangan yang sama. Tetapi kami memiliki banyak karyawan jarak jauh di Syktyvkar, Nizhny Novgorod, Kazan, dan Goryachy Klyuch, dan penting bagi mereka untuk terlibat juga.
Pada awalnya, mereka mengeluh bahwa mereka tidak dapat mendengar atau melihat apa pun secara praktis, tetapi kami telah belajar untuk peduli tentang mereka serta tentang para peserta offline kami. Dalam daftar periksa persiapan sprint review, ada pengingat bahwa kita perlu memeriksa koneksi internet dan menyesuaikan peralatan. Kami memposting pembaruan acara melalui Slack, dan baru-baru ini, kami mulai mengalirkan pertemuan kami di
saluran Youtube Dodo Pizza .
Jangan Kumpulkan Umpan Balik
Ketika kami sudah mulai berpikir bahwa semuanya baik-baik saja dan kami tidak perlu memperbaiki hal lain, kami bertanya pada diri sendiri apakah kami benar-benar melakukan hal yang benar. Ulasan sprint adalah urusan yang agak mahal, dengan mempertimbangkan jumlah peserta, upah mereka, dan waktu yang dihabiskan. Apakah kita menggunakan dua jam ini dengan efisiensi maksimum? Akibatnya, kami memutuskan untuk tidak mengumpulkan umpan balik di ulasan sprint. Dalam kondisi seperti itu, umpan balik tidak pernah komprehensif atau berkualitas baik (ulasan situs web Kazakhstan adalah contohnya). Selain itu, kami mengumpulkan banyak umpan balik yang bermakna dan berguna selama sprint itu sendiri, mempertanyakan semua pihak yang berkepentingan, dari pelanggan internal hingga pengguna.
Anda akan terkejut, tetapi bahkan dalam Panduan Scrum, tidak ada sepatah kata pun tentang mengumpulkan umpan balik pada ulasan sprint. “Selama Tinjauan Sprint, Tim Scrum dan pemangku kepentingan berkolaborasi tentang apa yang dilakukan dalam Sprint.” Tim Scrum dan pemangku kepentingan, bukan pengguna. Dan mereka berkolaborasi, bukan mengumpulkan umpan balik. Sama sekali bukan tentang itu.
Selamat datang di belakang panggung
Tidak semua pemangku kepentingan mengambil bagian aktif dalam proses pembangunan, tetapi mereka semua ingin mendapat informasi tentang apa yang terjadi di sana. Dan itulah tujuan ulasan sprint kami sekarang. Kami masih menunjukkan apa yang telah kami lakukan, tetapi selain itu, tim kami berbicara tentang asal-usul fitur baru. Apa tujuan kami? Apa yang terjadi selama sprint? Apa yang mengganggu atau menghambat kita? Langkah apa yang kami ambil untuk mencapai tujuan kami? Dan itu membantu; dengan cara ini, manajer dapat memahami, misalnya, mengapa menyembunyikan alamat email klien dalam tanda terima dengan tanda bintang sama sekali bukan tugas sepele dan bukan hanya "setengah jam pemrograman," seperti yang mereka pikirkan sebelumnya. Dan dialog semacam itu membantu pengembang perangkat lunak kami memikirkan masalah klien, tidak terbawa oleh solusi yang mereka kerjakan.
Ini adalah hal-hal utama yang kami ubah dalam pendekatan kami untuk ulasan sprint. Pasti ada kemajuan, tetapi masih ada ruang untuk perbaikan, jadi kami melanjutkan percobaan kami.
Yang terpenting, kami memahami satu hal - Anda tidak perlu terlalu terobsesi dengan rekomendasi Panduan Scrum. Anda harus pergi dengan coba-coba. Tidak ada solusi universal; Anda harus mencari mereka yang bekerja untuk Anda.
Jadi, sebagai kesimpulan, saya hanya ingin memperingatkan Anda. Jangan menyalin format kami. Ini bekerja untuk kita, karena lahir dari percobaan. Cari pendekatan Anda sendiri dan Anda akan berhasil. Apa hal terburuk yang bisa terjadi?