Sumber foto
Untuk tahun ketiga ini, saya telah memperkenalkan nilai dan prinsip Agile dalam kehidupan tim pengembangan. Di belakang bahu - bekerja sebagai master Scrum di dua perusahaan besar, pengalaman penerapan jarak jauh dari metodologi tangkas di industri yang sangat berbeda, buku yang tak terhitung jumlahnya telah dibaca dan menghadiri pertemuan.
Tapi semuanya dimulai dari yang kecil, dan selama ini saya telah mengisi lebih dari satu tonjolan. Dan seiring waktu, saya mulai memperhatikan bahwa benjolan ini cukup khas, dan rekan-rekan pemula saya menemuinya secara teratur. Tidak ingin mengesampingkan, dan untuk memperingatkan rekan kerja terhadap kemungkinan kegagalan, saya memutuskan untuk membagikan pengalaman saya di artikel ini.
Jadi, pelajaran apa yang saya pelajari dan kesimpulan yang dibuat di tahun pertama saya bekerja sebagai Scrum master (yang saya uraikan secara singkat dalam poin di bagian paling akhir):
Kacamata merah muda
Setelah dua hari pelatihan Scrum, saya siap untuk memindahkan gunung, mengubah dunia dalam perjalanan perusahaan menjadi lebih baik. Tidak ada yang menginspirasi lebih dari seorang pelatih yang kompeten dan tim yang terdiri dari orang-orang yang berpikiran sama! Tetapi begitu Anda mulai, tiba-tiba Anda ditinggalkan sendirian dengan kerangka kerja Scrum Anda. Ada orang yang sarat dengan tugasnya sendiri, ada kebiasaan dan nilai yang sudah terbentuk dalam kerja tim, ada manajemen yang melihat proses dengan caranya sendiri, dan ini tidak selalu sejalan dengan nilai. dan ide Agile. Secara keseluruhan, selamat datang di dunia nyata .
Oleh karena itu, pada awalnya, Anda harus mendapatkan kepercayaan dan keterbukaan tim. Penting untuk mengandalkan pengalaman dan akal sehat Anda sebelumnya.Pahami apa yang benar-benar dibutuhkan tim Anda sekarang, masalah dan pernyataan yang meremehkan apa yang ada dan bagaimana Anda dapat membantu mereka untuk menutup setidaknya beberapa pertanyaan yang muncul.
Perlawanan
Tentu saja, inovasi dan perubahan yang akan datang tidak terlalu menggembirakan. Dalam kasus saya, itu lebih merupakan pengunduran diri terhadap fakta bahwa orang lain datang untuk mengelola dan mengajar: " Yah, bagaimanapun juga, semuanya baik-baik saja ." Tidak ada yang bisa dilakukan - saya harus membuktikan bahwa saya datang untuk membantu, dan dalam praktiknya untuk mendemonstrasikan ini.
Poin penting: jika di awal Anda tidak menemukan pendukung di tim pengembang, Anda berisiko ditolak.
Hal pertama yang dihadapi oleh master Scrum baru ketika mencoba berubah adalah penolakan. Prosesnya, tentu saja, alami, tetapi bukannya tanpa rasa sakit. Orang siap untuk berubah hanya jika mereka melihat nilai di dalamnya untuk diri mereka sendiri.Oleh karena itu, pilihan terbaik adalah memberikan kesempatan kepada tim untuk sampai pada gagasan bahwa Scrum akan meningkatkan proses dan kehidupan mereka.
Tanyakan pada diri Anda, "Apa tujuan kehadiran saya dalam peran ini dan bagaimana saya dapat membantu tim saya meningkatkan proses kerja yang ada?" Jika Anda dapat menemukan jawabannya - bagus, mari kita lanjutkan ke perubahan! Jika tidak, ada baiknya menonton lagi.
Berbicara tentang peningkatan, Anda dapat mengadakan serangkaian pertemuan yang bertujuan untuk mengidentifikasi rasa sakit tim dan menciptakan keterbukaan, misalnya. Tetapi saya ingin membicarakan hal ini di artikel berikut.
Tergesa-gesa adalah penolong terburuk
Ketergesaan dan keinginan untuk menunjukkan diri Anda sejak hari-hari pertama bekerja mungkin adalah kesalahan terbesar yang dilakukan oleh seorang Scrum master pemula. Sangat penting untuk mengetahui bahwa perubahan drastis tanpa memahami mengapa hal itu perlu dan bagaimana hal itu akan memengaruhi cara hidup tim saat ini dapat menyebabkan lebih banyak penolakan dan ketidakpercayaan. Ada kalanya Scrum Master merugikan tim justru karena perubahan yang tidak dipahami dan belum selesai.
Kesiapan untuk perubahan datang dari tim secara bertahap.Amati tim selama 1-2 minggu tanpa mengganggu proses "alami". Pada tahap pertama, Anda perlu memahami sendiri rantai proses logis dan nilai-nilai yang ditetapkan, melihat kerentanan dalam pekerjaan, dan, pada kenyataannya, mengusulkan solusi. Selangkah demi selangkah, cobalah untuk memperkenalkan peristiwa dan nilai metodologi ke dalam kesadaran dan kehidupan tim Anda.
Fasilitasi pertemuan, interaksi yang sering dengan tim, baik secara pribadi maupun dalam format acara, pembinaan akan membantu Anda dalam hal ini. Dan, tentu saja, kepercayaan dan keterbukaan terhadap dialog.
Memahami lingkungan
Ketika saya pertama kali mulai bekerja dengan tim, saya membuat kesalahan besar, yang pada awalnya tidak menarik perhatian saya dan tampak sepele. Yakni, saya kehilangan banyak obrolan tematik pengembang yang mengungkapkannya dari sisi lain. Dia menjauhkan diri dari manajemen dan melewatkan informasi penting, yang pada gilirannya dapat disampaikan kepada tim.
Jangan ulangi kesalahan saya: tidak masalah apakah perusahaan Anda kecil atau besar, tetapi Anda perlu memahami komunikasi antar departemen dan mengenal secara pribadi beberapa kolega kunci . Dikatakan bahwa Scrum Master harus menghilangkan hambatan yang mengganggu tim dalam membuat produk IT. Tetapi bagaimana Anda bisa melakukan ini jika Anda tidak tahu harus berpaling kepada siapa?
Jadi, pada awalnya, ini sangat penting:
- pergi ke semua obrolan dan lihat bagaimana dan dengan siapa tim berkomunikasi, masalah apa yang mereka hadapi;
- berkomunikasi dengan manajemen, melacak tujuan global dan sekunder yang dikejar perusahaan dalam jangka waktu tertentu;
- berkomunikasi dengan orang-orang yang berpikiran sama jika perusahaan telah memiliki scrum master yang lebih berpengalaman.
Saya yakin semua hal di atas kemungkinan besar akan membantu Anda dengan cepat membenamkan diri dalam lingkungan dan melakukan pengamatan proses yang lebih lengkap.
Kehadiran strategi
Jadi kami berbicara dengan tim dan manajemen, mengajukan pertanyaan yang menarik, menerima jawaban, memasuki semua obrolan dan menerima undangan ke semua acara. Kami melihat masalahnya, kami tahu tujuan manajemen - tetapi harus mulai dari mana untuk menyelesaikannya belum jelas. Apa yang harus dilakukan selanjutnya?
Untuk mengambil keputusan, penting untuk merumuskan tujuan yang jelas tentang apa sebenarnya dan mengapa kita ingin berubah . Dan kemudian - untuk membuat rencana kerja menjawab pertanyaan, “ bagaimana kita akan melakukan ini? ".
Paling sering, ketika saya datang ke tim, saya melihat bagaimana orang-orang mengadakan rapat harian selama 1,5-2 jam, di mana mereka mencoba menyelesaikan semua masalah. Dan ini, omong-omong, adalah jumlah waktu yang sangat besar yang dipotong dari jam kerja dan mengurangi efisiensi kerja tim. Dan Panduan Scrum menyarankan hanya 15 menit untuk acara ini dan tidak satu menit lagi.
Bagaimana menjadi: pendekatan yang paling benar, menurut saya, adalah memisahkan aktivitas ini dan fokus pada tugas yang ditetapkan dalam tujuan Sprint.
Berdasarkan rasa sakit dan pertanyaan yang paling sering, selain acara utama Scrum (perencanaan, harian, demo, retro), misalnya, pertemuan penelitian mingguan, diskusi tentang tumpukan ide, atau sesi curah pendapat untuk berdiskusi secara mendalam masalah dapat dibentuk, seperti yang terjadi hari ini di Layanan ICL. ... Kami melihat rasa sakitnya, kami tahu bagaimana memperbaiki situasi dan apa yang perlu dilakukan - yang tersisa hanyalah mendiskusikan perubahan format kerja dengan manajemen dan tim untuk mencapai efek terbaik.
Rencana tersebut juga harus fleksibel dan berubah tergantung pada kondisi dan karakteristik anggota tim. Penting untuk mendiskusikan jalur yang direncanakan dengan manajemen, karena tidak selalu semua yang Anda usulkan akan segera diimplementasikan ke dalam pekerjaan. Dan sesuatu dapat berubah seluruhnya tergantung pada penetapan tujuan dan permintaan manajemen itu sendiri.
Kurangnya pengetahuan teknis
Saya tidak memiliki pendidikan teknis, dan oleh karena itu, untuk benar-benar memahami terminologi ekstensif dari tim pengembangan (dan di beberapa tempat tetap) tugas yang agak sulit bagi saya, mengingat teknologi tidak berhenti.
Tapi di sini, juga, ada beberapa peretasan hidup yang cukup sederhana:
- jangan takut untuk meminta bantuan tim;
- mempelajari literatur yang relevan;
- cari di Internet untuk kamus terminologi untuk boneka atau dapatkan kamus pribadi jika perlu.
Ringkasan singkat
- Kembangkan pengalaman sebelumnya. Pahami apa yang dibutuhkan tim, apa masalah dan pernyataan yang meremehkan, dan bagaimana Anda dapat membantunya.
- Identifikasi bagaimana perubahan dapat bermanfaat bagi tim dan tunjukkan kepada mereka. Orang tidak siap untuk berubah sampai mereka melihat sendiri nilainya.
- Sprint, , .
- – , , – -.
- « ?», . « ?» , , . . .
- Kurangnya pengetahuan teknis. Jika Anda tidak memiliki latar belakang teknis, tetapi ingin atau perlu menguasai terminologi, jangan takut untuk meminta bantuan. Kamus terminologi pribadi juga bisa menjadi penolong yang baik.
Saya yakin bahwa semua pelajaran yang telah saya pelajari akan membantu Anda menarik kesimpulan dan membangun kembali ke arah yang benar, karena saya sangat menyukai apa yang saya lakukan. Dan, yang terpenting, jangan takut akan kesalahan, tetapi belajarlah darinya. Semoga berhasil!