Hari ini saya akan membagikan pengamatan Scrum Master tentang tahun pertama kehidupan tim dalam kerangka baru.
Mengapa kami memutuskan untuk pergi ke Scrum? Alasannya lumrah bagi banyak perusahaan:
- hubungan yang tidak terlalu sederhana antara "bisnis" dan "pembangunan";
- kebutuhan untuk mempercepat pengiriman;
- memahami bahwa perlu untuk membangun kembali proses.
Perpindahan ke Kick-Off memakan waktu sekitar enam bulan (dari awal 2019): belajar, melatih, menyiapkan materi, dan mengumpulkan informasi yang diperlukan. Dan akhirnya,
pada 3 Juni 2019, kami memulai sprint pertama.
Tahun pertama dalam kerangka baru ini merupakan tantangan bagi tim dan Scrum Master. Penting untuk mengubah pola pikir secara radikal dan mulai melakukan sesuatu secara berbeda.
Apa yang harus diingat oleh Scrum Master selama periode ini?
Scrum Master bukanlah sebuah sepatu, ia tidak harus merasa nyaman. Keterampilan yang berkelanjutan untuk mencerminkan tim dan anggota individu dari pola perilaku tidak sehat perlu dikembangkan. Sangat penting untuk mempelajari bagaimana memberikan umpan balik dengan benar dan tepat waktu, bahkan jika itu akan membawa baik Scrum Master dan lawan keluar dari zona nyaman.
Anda perlu berpikir dalam kerangka tim, bukan individu. Anda perlu melihat tim sebagai organisme hidup dan ingat bahwa jika "organ individu sakit", maka seluruh organisme dapat mulai mengeluh. Untuk melanjutkan analoginya, Scrum Master adalah seorang terapis. Bukan ahli bedah, tetapi terapis, oleh karena itu, kasus klinis yang sulit ditujukan untuk spesialis lain.
Scrum, seperti LeSS, tidak mentolerir ketidakdewasaan pribadi anggota tim. Jika tim tidak tahu apa itu Scrum, tidak pernah bekerja dalam framework ini dan, terlebih lagi, jika sudah berfungsi dalam komposisi saat ini, saya akan merekomendasikan untuk tidak langsung membalik LeSS.
Mengidentifikasi sukarelawan untuk Kick-off (yang biasanya membutuhkan waktu tiga hari) dalam tim yang sebelumnya tidak pernah bekerja di Scrum kemungkinan besar palsu. Jika orang belum pernah bekerja dalam kerangka ini sebelumnya, mereka hampir tidak benar-benar memahami apa itu, dan benar-benar dapat berbicara tentang kesediaan mereka untuk bekerja dengan cara ini.
Hardy tidak semuanya. Jika ada masalah dengan perangkat lunak, bahkan pengembang yang sangat keren dalam hal kekerasan bisa menjadi masalah besar.
Dalam tim yang mengatur diri sendiri, orang dengan refleksi yang berkembang, kecerdasan emosional dan keinginan untuk pengembangan diri yang berkelanjutan, perluasan kesadaran dan kemauan untuk mengubah paradigma dapat hidup dan eksis secara harmonis.
Naif jika Anda percaya bahwa Anda adalah yang paling pintar. Pesan ini sangat penting untuk disampaikan kepada setiap anggota tim. Penetrasi ke dalam pola pikir yang paling sederhana ini menimbulkan banyak keuntungan dan bukan kerugian: dari saling menghormati hingga "perasaan kebersamaan".
Bagian tersulit adalah bekerja secara bertanggung jawab. Penting bagi orang-orang untuk memahami bahwa "kesukarelaan" tidak hanya tentang kemauan dan kesediaan untuk bekerja di Scrum. Ini tentang kesiapan untuk berkembang, tumbuh di atas diri sendiri, belajar memberi dan menerima umpan balik, berefleksi dan melakukan perubahan. Ini tentang proses terus menerus untuk meningkatkan tidak hanya proses, tetapi juga diri kita sendiri.
Orang sering tidak mengerti mengapa Scrum Master dibutuhkan. Dan di sini, setelah banyak dialog dan lokakarya, diskusi dan percakapan yang berbeda, saya sampai pada kesimpulan bahwa kesalahpahaman ini sering kali disebabkan oleh kurangnya kesiapan untuk memahaminya. Scrum Master harus mengingat hal ini dan terus mengerjakannya.
Apa yang diberikan Scrum dalam setahun?
"Bisnis" dan "pembangunan" menjadi tidak terpisahkan - pemahaman tentang "kami" dan "mereka" tidak ada lagi. Pakar bisnis bekerja sama dengan pengembang di tim yang sama. Sekarang pemahaman tentang apa yang dibutuhkan bisnis hidup dalam tim pengembangan. Hasilnya, kami telah meningkatkan kecepatan pengiriman secara signifikan: sekarang rilis dilakukan satu kali per sprint. Kami saat ini hidup dalam sprint tiga minggu. Sebelumnya, rasio rilis sebenarnya tidak lebih dari sekali setiap 1,5 bulan.
Kami telah melegalkan hutang teknis dan mulai meluangkan waktu untuk itu dalam sprint. Kami menyetujui proporsi 70% vs 30%, di mana 30% dialokasikan untuk hutang teknis.
Dalam setahun, kami dapat menarik semua kompetensi penting ke dalam tim, meninggalkan vendor, dan menginternalisasi pengembangan. Pengaruh masing-masing pada hasil pengembangan dan solusi yang diterapkan telah meningkat secara signifikan. Perendaman pengembang dalam produk dan konteks klien telah meningkat secara signifikan. Dengan demikian, beban semantik “Why?” Telah berubah secara kualitatif.
Kami meluncurkan proses Penemuan - secara signifikan meningkatkan perendaman dalam "kulit klien". Sekarang semua ide kami, tentang apa yang menurut kami klien akan berguna, kami periksa langsung dengan klien. Menciptakan lingkungan yang siap untuk bereksperimen dan budaya kesediaan untuk bereksperimen.
CI / CD yang diterapkan.
Kami mencakup hampir semua fungsionalitas aplikasi WEB dengan tes otomatis, yang secara signifikan mengurangi waktu dan biaya tenaga kerja untuk regresi manual.
Kami telah memulai transisi ke arsitektur layanan mikro, yang akan menambah kemandirian tim pengembangan.
Kami telah memperkenalkan sistem untuk memantau aplikasi dan perangkat keras: sekarang dalam mode on-line dimungkinkan untuk memantau status satu dan lainnya, dan terkadang menerima sinyal sebelum panggilan dari pelanggan pergi. Kami telah membangun sejumlah dasbor untuk memantau indikator bisnis, termasuk KPI dalam mode otomatis.
Selama setahun kami berhasil melakukan banyak hal, tetapi jalan kami masih terus berlanjut.
PS: Sengaja saya tidak menulis tentang tahapan pelaksanaan Scrum. Anda dapat membaca banyak tentang ini sekarang. Jika tertarik, maka saya bisa menulis artikel terpisah.