"Mendaki pagar" atau cerita bagaimana menjadi tim dalam tiga jam

Ada pendapat berbeda tentang bagaimana tim menjadi tim. Ada beberapa model yang lebih populer yang berbicara tentang ketidakmampuan menjadi tim dengan cepat. Ini bisa menjadi proses yang panjang dengan dinamikanya sendiri.



Dalam konteks topik, bisnis sering kali tertarik pada kenyataan bahwa meskipun tidak dalam waktu singkat, lalu seberapa cepat Anda dapat mengubah transformasi menjadi sebuah tim, karena diketahui bahwa "kerja tim" yang dapat mencapai hasil yang paling efektif. Di sini mereka mengandalkan para pemimpin - manajer proyek, Scrum Master, pemimpin tim. Seseorang akan berbicara tentang pentingnya “pergi ke bar bersama-sama” di tahap awal, seseorang akan berbicara tentang memilih nama atau logo sebagai cara untuk mendefinisikan dan menekankan identitas tim.



Yang paling saya sukai adalah pandangan tim sebagai sekelompok orang yang pertama kali memiliki pengalaman bersama yang sukses. Dalam pembinaan tentang topik serupa, saya telah menemukan metafora "melewati pagar". Di dalamnya, pembatas adalah kemampuan kita untuk mengembangkan solusi bagi masalah umum, dan untuk "mengatasinya", kita membutuhkan kehangatan, selera humor, dan keinginan untuk bekerja sama.



Musim panas ini, saya mulai mengerjakan proyek yang saat ini menjadi salah satu prioritas tertinggi di perusahaan. Tujuan utamanya adalah untuk mengganti backend warisan kuno dengan arsitektur layanan mikro modern dan dengan demikian menjadikan dunia Telecom tempat yang lebih baik. Harapannya cukup tinggi dan kecepatannya cepat, yang memerlukan pertumbuhan yang kuat dan kebutuhan untuk merekrut dan meluncurkan tim baru. Salah satu tim baru ini akan dikumpulkan dan diluncurkan oleh saya.





Nah, Anda mengerti.



Saya terjerumus dalam periode pemilihan kandidat yang berlangsung selama beberapa waktu. Saya berkenalan dengan orang-orang dan dalam percakapan informal mencoba mencari tahu sudut pandang mereka tentang berbagai masalah, tetapi dengan pensiun penuh dan tanggal peluncuran proyek yang berbeda, kami semua tidak memiliki kesempatan yang baik untuk benar-benar mengenal satu sama lain. Namun demikian, komposisi “profesional yang bermotivasi tinggi dan lintas fungsi” (kami bekerja di Scrum) secara bertahap direkrut.



Dan, seperti yang sering terjadi, di beberapa titik, roda gila mulai berputar semakin cepat, dan sekarang tidak ada waktu untuk menjelaskan, atau untuk kick-off yang rapi. Anda perlu menarik orang yang direkrut ke dalam tim dan mulai dengan cepat. Pada saat yang sama, rezim pandemi telah memberlakukan pembatasan yang ketat terhadap kemungkinan acara team building yang terkenal kejam. Meskipun pasti tidak ada gunanya menyesali ini: dengan semua persiapan, kami masih tidak punya waktu untuk kenalan biasa.



Jadi untuk pertama kalinya kita semua "melihat" satu sama lain hanya dalam perencanaan pertama. Dan karena ini bukan hanya perencanaan, tetapi PIP (Product Increment Planning - sebuah acara di SAFe yang didedikasikan untuk perencanaan tingkat tinggi dari kerja tim untuk beberapa sprint berikutnya), maka kami harus memikirkan banyak hal dalam waktu terbatas.



Bayangkan momen ini. Ini adalah pengalaman pertama Anda dalam acara semacam itu. Anda mendapati diri Anda berada dalam panggilan konferensi dengan sembilan orang asing, dan meskipun Anda baru saja dinyatakan sebagai "tim", Anda tidak tahu siapa orang-orang ini, keterampilan apa yang sebenarnya mereka miliki, dan Anda memiliki tiga jam untuk membuat "tim" bersama. rencana kerja untuk tiga bulan ke depan.



Anda juga agak takut dengan tugas yang sulit, yang diusulkan untuk diuraikan menjadi beberapa poin rencana, karena uraiannya tidak ambigu.





Omong-omong, Perencanaan Penambahan Produk kami, jika offline, bisa terlihat seperti ini.



Pada awalnya, kami benar-benar berdiri, secara metaforis berkerumun di sekitar backlog yang ada, dan mendiskusikan apa yang bisa dilakukan. Menanggapi hal tersebut, tim pengembang seringkali merespon dengan diam saja, prosesnya tidak berjalan dengan mudah.



Namun saya, seperti pembuat api itu, tanpa lelah memukuli batu di atas batu berulang kali, terus menyemangati tim pengembangan dengan ramah. Betapa percikan yang diukir tak terduga berubah menjadi nyala api kecil.



Sebagai tanggapan, salah satu pengembang berhenti dan ... hanya menyuarakan semua yang mengkhawatirkan masing-masing yang hadir. Ketidakpastian, kecanggungan, tingkat ketidakpastian yang tinggi ... Ya, semua ini ada, dan kita semua merasakannya. Tetapi apakah ini akan menghalangi kita untuk memenuhi apa yang telah kita kumpulkan untuk saat ini? Katakan itu padaku!



Tiba-tiba seorang insinyur lain mengaku ragu-ragu. Dan kemudian yang lainnya. Seseorang menganggap tingkat keahliannya tidak mencukupi, seseorang ragu-ragu untuk mengajukan pertanyaan klarifikasi yang "bodoh". Seseorang hanya merasa tidak nyaman, karena baru saja bertemu dengan kami, dan tidak ingin memberikan kesan yang “salah”.



Saat kami mengatakan semua sumber kecemasan kami dengan lantang, sepertinya menjadi lebih mudah untuk bernapas. Masing-masing dari kami membuat pengakuannya sendiri, dan tidak ada yang mengutuk kami. Suasana semakin hangat. Ada lelucon.



Api yang malu-malu berkobar menjadi nyala api terang yang percaya diri.



Kelompok orang kami yang hampir tidak mengenal satu sama lain merasa sangat berbeda. Secara bertahap, kami mengembangkan strategi untuk menganalisis backlog. Pengembang mengevaluasi persyaratan dan bekerja sama: mereka membahas apa yang perlu dilakukan dan tingkat dekomposisi apa yang diperlukan untuk tugas tertentu. Semua ini segera dicatat di JIRA. Kemudian mereka membagikan karya tersebut. Semua orang ambil bagian dalam diskusi.



Sungguh menakjubkan melihat bagaimana mereka menemukan dalam hitungan menit bahwa mereka semua adalah bagian dari tim.



Saya menemukan ceramah TED tentang topik ini lama kemudian.



Sementara itu, Product Owner juga bekerja keras, meskipun sebenarnya dia telah melakukan banyak pekerjaan sebelum rapat ini: bagaimanapun, dia telah menyiapkan semua persyaratan. Dia menjelaskan tujuan tingkat tinggi yang perlu difokuskan oleh tim, memperbarui backlog, menjawab pertanyaan, mengklarifikasi apa pun yang dapat diklarifikasi.



Saya sebagai Scrum Master mengarahkan pergerakan diskusi pada saat diperlukan, mencegah munculnya perasaan bahwa diskusi itu sendiri menemui jalan buntu.



Setelah tiga jam kerja keras, tim selesai membangun peta jalan untuk mencapai tujuan mereka selama tiga bulan ke depan, dan menyelesaikan perencanaan.



Keesokan harinya, Pemilik Produk mempresentasikan rencana ini kepada pemangku kepentingan, dan, dengan mempertimbangkan beberapa komentar kecil pada kata-kata, itu disetujui dan diadopsi.



Kami semua berhasil melakukan ini dengan bertindak bersama. Saling membantu, kami mendapatkan pengalaman bersama pertama yang sukses bahkan sebelum mulai mengerjakan tugas. Dalam perencanaan ini, tim kami menemukan pencapaian yang sama (tentu saja, yang pertama dari banyak pencapaian). Kami menjadi "penakluk perencanaan PI", dan ini memberi kami perasaan bahwa kami pasti mampu melaksanakan semua bagian lain dari proyek kompleks kami dengan sukses.



Dan jika saya ditanya: “Bagaimana tim menjadi tim? Apakah ini proses yang panjang? ”, Saya akan menjawab bahwa mereka memperoleh identitas tim yang sebenarnya ketika mereka“ memanjat pagar ”, yaitu mengatasi kesulitan pertama, bertindak secara terkoordinasi dan bersatu. Dan itu adalah tanggung jawab pemimpin untuk mewujudkannya secepat mungkin.



Dan apa yang sebenarnya bisa dia lakukan untuk ini kedengarannya seperti topik untuk artikel selanjutnya :)



All Articles