* Scrum (kata benda) adalah kerangka kerja yang membantu menyelesaikan tugas yang berubah selama proses kerja agar dapat secara efisien dan kreatif mengirimkan produk ke pelanggan dengan nilai setinggi mungkin.
Kenapa saya memutuskan untuk menulis artikel ini
Sangat sering di lingkungan kerja, di Internet dan pada wawancara Anda dapat mendengar, misalnya, ini:
“Ada begitu banyak pertemuan dengan Scrum ini! Kapan harus bekerja?! ";
"Yah, biarlah setidaknya Scrum, paling tidak Malu, letakkan saja dan biarkan aku menulis kodenya!";
“Kami juga memberlakukan Scrum ini, secara umum tidak jelas mengapa”;
“Setiap hari, stand-up sekitar empat puluh menit, untuk apa aku harus menghadiri mereka? Ingin tahu apa yang telah saya lakukan dan apa yang sedang saya kerjakan sekarang - lihat Jira, Confluence, Git, dll. "
"Master Scrum umumnya pelawak, dia harus pergi menari daripada mengelola proyek!";
"Ya, kami menggunakan Scrum: yang utama adalah kami melakukan retrospektif."
Tujuan artikel ini adalah untuk menunjukkan bahwa negativitas, yang masih mengalir deras ke arah Scrum, sebenarnya tidak berlaku untuk itu, dan masalahnya perlu dicari di tempat lain.
Selanjutnya, saya ingin berbicara tentang kasus-kasus khas dari mana masalah ini berasal.
Saya sendiri adalah karyawan Scrum bersertifikat (scrum.org) dari satu organisasi besar dari sektor keuangan (bukan "hijau" jika itu). Saat ini, kami tidak memiliki Scrum, tetapi kami bergerak ke arah ini, dan secara pribadi saya memiliki visi tentang mengapa dan bagaimana kami akan terus melakukan ini.
Sebenarnya, ketertarikan dengan metodologi yang fleksibel dan Scrum khususnya datang kepada saya belum lama ini, tetapi menurut pendapat saya, penting bukan "berapa lama", tetapi "seberapa kualitatif dan sadar".
Dan semakin Anda terjun ke topik ini, semakin Anda menyadari bahwa kerangka kerja ini adalah "alat" yang ampuh, dan semakin menyedihkan setiap kali Anda bertemu frasa dan ulasan di awal artikel, yang, sebagai suatu peraturan, merupakan bukti dari upaya canggung untuk beralih ke Scrum.
Mengapa mencoba, dan bahkan yang canggung: karena mereka tidak menyadari mengapa semua Scrum ini, dan Agile, pada prinsipnya, berhenti sedikit lebih awal daripada pada awal transisi.
Perusahaan yang mengerti mengapa Scrum diperlukan dan bagaimana menggunakannya, menurut saya, tidak sering terjadi di negara kita.
Kekuatan Scrum, tidak terlihat oleh banyak orang, dapat dibandingkan sampai batas tertentu dengan kekuatan Excel: semuanya terlihat sangat sederhana, tetapi jika Anda menggali ...
Namun demikian, saya tidak menganggap Scrum sebagai peluru perak, sama seperti pembuatnya (saya tidak akan memberikan tautan ke artikel yang baru-baru ini diterbitkan dalam satu publikasi resmi), dan ini sudah menjadi topik untuk artikel terpisah.
1. "Dipaksakan"
Menurut pendapat saya, salah satu alasan utama mengapa Scrum memprovokasi keengganan semacam itu adalah ketika ia hanya "diturunkan dari atas" selama transformasi organisasi. Dan masalahnya di sini adalah persis bagaimana transformasi terjadi:
- Apakah manajemen menyadari mengapa ia akan pergi ke metodologi dan Scrum yang fleksibel khususnya?
- Bagaimana mereka memberi tahu karyawan tentang perlunya transformasi, dan mengapa metodologi dan Scrum yang fleksibel khususnya membantu dalam hal ini?
- Bagaimana Anda mendukung karyawan dalam kondisi transformasi, apakah Anda memberikan pelatihan, sertifikasi, dan bantuan berkualitas dalam meluncurkan tim?
Sebuah kisah yang sangat umum adalah ketika perusahaan bertransformasi, hanya karena itu "modis."
Pada akhirnya, sesuatu yang baik tidak mungkin terjadi, dan murmur yang dihasilkan, kemudian mengalir ke gelombang negatif.
Dalam hal ini, saya menyukai satu frasa dalam topik: "Di perusahaan tradisional, manajer tradisional mengatur transformasi tradisional."
Namun, saya akan jujur dengan Anda: ketika kami pertama kali dibawa ke Agile / Scrum / Kanban, itu tentang Scrum yang awalnya saya anggap sebagai semacam sampah dengan pertemuan tanpa akhir. Perubahan sikap saya terhadapnya datang setelah saya bertanya pada diri sendiri pertanyaan: "Bagaimana jika ...?" Kepada diri saya dalam proyek yang sangat keren.
2. Penceritaan oleh Scrum
Alasan lain untuk kemarahan dan bahkan beberapa kepahitan di Scrum adalah interpretasinya yang salah, terutama terkait dengan di mana kita mendapatkan pengetahuan darinya. Sebagai hasilnya, misalnya, kita memiliki "upacara minum teh," atau "ritual pengorbanan" alih-alih "acara."
Saya juga tidak mengecualikan kehadiran orang-orang skismatik yang berdebat tentang berdiri di Scrum Harian dengan lingkaran, kotak, atau figur lain. Jika bulat, maka berikan kata searah jarum jam, melawan, atau entah bagaimana.
Pada saat yang sama, sama sekali tidak ada pemahaman mengapa pertemuan (peristiwa) wajib yang terkenal ini ada di Scrum, yang, dengan cara, dapat dihitung dengan jari satu tangan.
Melihat aliran besar informasi di jaringan, tampaknya banyak yang tidak tahu apa sumber utama dan di mana mendapatkan pengetahuan dasar tentang kerangka tersebut.
Jadi, dokumen utama Scrum adalah The Scrum Guide, ditulis bersama oleh Ken Schwaber dan Jeff Sutherland, tersedia dalam banyak bahasa, termasuk Rusia.
Menurut pendapat saya, untuk mendapatkan pengetahuan dasar tentang Scrum dan, selanjutnya, untuk tidak menyumbat pikiran Anda dengan segala macam penambahan yang disalahpahami ke Scrum, Anda hanya perlu dua komponen utama: keinginan dan bacaan yang cermat dari The Scrum Guide, dan lebih dari sekali. Dokumen ini cukup kompak - Anda dapat menguasainya kurang dari dua puluh halaman.
Adapun pelatihan, saya akan katakan secara singkat: hati-hati! Saya tidak akan mengiklankan siapa pun dalam kerangka artikel ini, tetapi saya percaya bahwa di negara kita hanya satu atau dua perusahaan yang dapat dipercaya dengan “pelatihan yang tepat” tentang topik ini.
3. "Interpretasi" dari beberapa bagian Panduan Scrum dan tidak hanya
Dalam konteks berapa banyak diskusi serupa dalam jaringan mengelilingi Scrum, saya akan mencoba menarik perhatian mereka dan menyatakan pemahaman saya sesuai dengan panduan dan pengalaman Scrum.
Scrum adalah ...
Saya akan memilih dua dari tiga karakteristik:
sederhana untuk memahami dan
sulit untuk penguasaan yang sempurna .
Sebagian orang mengira ada kontradiksi.
Sprint
Dalam subbagian ini, saya akan dengan sengaja mengajukan beberapa pertanyaan yang dapat membuat Anda berpikir dan memikirkan kembali pendekatan Anda terhadap kerangka kerja.
- Apa yang menurut Anda masuk akal untuk memanggil Sprint diperbaiki dalam interval waktu? Misalnya, dapatkah lebih mudah mengirimkan laporan kemajuan setiap dua minggu?
- Jika Anda sedang dalam proses beralih ke Scrum, lalu berapa lama Anda memilih Sprint? Ketika saya mengajukan pertanyaan ini, saya paling sering bertemu dengan ekspresi heran dan kemudian jawabannya: "Standar - 2 minggu."
- Mengapa Anda memilih sprint dengan panjang seperti itu?
- Mengapa tidak disarankan untuk mengatur panjang sprint lebih dari sebulan?
Beberapa mungkin tidak mempercayainya, tetapi jawaban untuk pertanyaan-pertanyaan ini ada di Panduan Scrum.
4. Scrum Harian
Salah satu topik paling kontroversial adalah Daily Scrum, alias Daily Standup Meeting, alias Daily Scrum, atau sekadar “Stand-up”.
Anda mungkin tidak percaya kepada saya, tetapi acara ini memiliki waktu tetap (kotak waktu) - tidak lebih dari 15 menit, terlepas dari panjang Sprint.
Tim itu sendiri menentukan format pertemuan. Dan hal terpenting dalam periode lima belas menit ini adalah untuk memahami status kemajuan menuju Tujuan Sprint.
Sekarang pertanyaan untuk mengisi ulang: berapa banyak dari Anda yang tahu apa Sasaran Sprint? Berapa banyak dari Anda yang tahu cara merumuskannya? Dan siapa yang merumuskannya?
Dalam sebagian besar kasus, Scrum marah karena ketidaktahuan dan kesalahpahaman mereka, karena acara ini disebut Daily Scrum diperlukan.
Ini bukan pertemuan pelaporan! Dalam pertemuan-pertemuan yang sering saya tonton, tidak ada informasi yang cukup kecuali tentang berapa kali seseorang minum kopi, teh, air, dan juga pergi ke toilet. Dan "tidak lebih dari 15 menit" dapat meregang selama satu setengah jam.
Sekali lagi: Scrum Harian adalah tentang bergerak menuju Tujuan Sprint!
Menyadari hanya bagian dari Scrum ini, Anda, menurut saya, akan dapat membuat terobosan yang signifikan.
Dan komentar lain, yang bagi banyak orang menjadi wahyu, Daily Scrum adalah peristiwa di mana ia dapat mengambil bagian (perhatikan, "ambil bagian" dan "siaga, dengarkan" adalah dua hal berbeda) hanya Tim Pengembangan! Bahkan Scrum Master (Scrum master) dan Pemilik Produk (Pemilik Produk), jika mereka bukan anggota paruh waktu dari Tim Pengembangan, tidak terlibat langsung dalam pertemuan ini!
5. Scrum master bukan Manajer Proyek dan bukan pelayan
Topik lain yang sangat umum: Scrum Master (SM) = Project Manager (PM).
Anda dapat menemukan banyak artikel di SM vs. PM
Saya akan menyoroti yang utama:
- Scrum Master bertanggung jawab untuk mempromosikan dan mendukung Scrum sesuai dengan Panduan Scrum.
- Kesalahpahaman utama tentang Scrum-master:
- Scrum master TIDAK mengelola proyek;
- Scrum master TIDAK mengelola tim (siapa yang akan dibawa, siapa yang harus dihapus);
- Scrum-master tidak dipilih berdasarkan karyawan perusahaan yang paling berpengalaman atau jangka panjang;
- Scrum-master BUKAN sekretaris tim, "menyumbat pelepasan".
- Tugas-tugas Master Scrum TIDAK mencakup pengiriman pizza pada hari Jumat (topik favorit di pelatihan), mencuci kaus kaki dan menyeterika tali-tali Pemilik Produk, atau anggota Tim Pengembangan.
Area tanggung jawab Master Scrum juga dijabarkan dalam Panduan Scrum.
Di akhir bagian ini, saya dapat memberikan beberapa topik lagi, untuk studi independen, jika ada yang tertarik:
- Scrum sebagai kultus kargo vs. Scrum dan shuhari.
- Pemilik Produk adalah manajer produk, bukan proyek atau tim. Inilah PO vs. PM
- Pemilik Produk dan Master Scrum dalam satu paket.
- Hal utama dalam Scrum adalah Retrospektif, atau Anda telah menemukan hampir seperti ini: Scrum = Retrospektif (tetapi retrospektif dari apa pertanyaan lain)!
- ...
Ini matang mengingat apa yang ditemukan dalam karya, dalam komentar, termasuk di Habré.
Scrum adalah Ken Schwaber, Jeff Sutherland dan Panduan Scrum mereka. Lihat Catatan Akhir.
Scrum - ini adalah apa yang ada di Panduan Scrum, dan bukan apa yang biasa Anda panggil di perusahaan Anda.
Kami juga belum memiliki Scrum, tetapi kami memahami ini, mengakuinya, dan tahu bagaimana bergerak ke arahnya. Selain itu, kami juga memahami bahwa sangat penting untuk pindah ke sana, karena ini benar-benar dapat membawa manfaat besar bagi organisasi.
Untuk meringkas
Jika catatan di atas, setidaknya saya membuat seseorang berpikir dan memikirkan kembali apa Scrum ini, dan metodologi fleksibel secara keseluruhan, maka saya akan berasumsi bahwa saya telah mencapai tujuan!
Air mengikis batu dan, mungkin, dalam waktu dekat kita tidak akan mendengar sesering yang sekarang kita dengar: "Anda sangat terbawa oleh Scrum ini, dan berdasarkan hasil dari tim ini dan itu (menggunakan ScramNO sebenarnya) itu tidak layak."
Terima kasih atas perhatian Anda dan saya akan senang atas komentar dan komentar Anda!
Referensi
www.scrumguides.org/index.html