Get best of the week

Antipatterns dari retrospektif dalam tim Agile. Bagian 1

Saya baru-baru ini menghitung bahwa selama beberapa tahun sebagai Scrum Master, saya menghabiskan lebih dari 100 retrospektif dalam tim Agile. Saya ingin berbicara tentang pentingnya retrospektif dan bagaimana hal itu mencerminkan situasi di tim dan memengaruhi perkembangannya, dalam artikel ini.



Beberapa kata tentang saya. Sejak 2015, saya telah fokus membangun tim Agile yang bahagia dan efektif di perusahaan internasional. Selain itu, saya menikmati melakukan pelatihan internal. Selain pekerjaan utama bersama tim, saya mengajar Scrum Masters di sekolah dan melakukan pelatihan di bidang Agile / Scrum / Agile testing. 

Sejak awal karir saya sebagai Scrum Master, saya beruntung bisa bekerja secara langsung dengan 10 tim yang sangat berbeda dan menarik. Masing-masing dari mereka berkembang dengan kecepatan uniknya masing-masing, namun mereka memiliki kesamaan - kualitas retrospektif sangat memengaruhi efektivitas tim secara keseluruhan. Pada saat yang sama, saya perhatikan bahwa, di tim mana pun, cepat atau lambat retrospektif berhenti bekerja. Sesuatu terjadi dan alat Inspeksi dan Adaptasi yang paling populer ini rusak, yaitu berhenti membantu tim beradaptasi dan meningkat.

Saya mensistematisasikan pengamatan saya dan ingin berbagi 5 antipattern utama yang saya temui di tim saya. 

Dalam setiap antipattern, saya ingin membahas:

  • tanda dan penyebab perilaku tertentu;
  • apa yang harus dilakukan Scrum kepada Master dan tim untuk memperbaiki situasi.

Di bagian pertama artikel ini saya akan berbicara tentang tiga antipattern. Pada bagian kedua, saya akan membagikan pengamatan tentang dua antipatterns lainnya, serta rekomendasi saya: apa yang dapat dilakukan oleh Scrum Masters dan tim secara proaktif, mis. di muka, bahkan sebelum perilaku yang dijelaskan dalam artikel muncul, sehingga retrospektif terus bekerja dan menjadi alat yang efektif untuk perbaikan dalam tim.
 

Antipattern No. 1 "Semuanya baik-baik saja dengan kami"




Tim memegang retrospektif, tetapi menganggapnya sebagai formalitas. Antipattern terwujud dalam kenyataan bahwa tim, pada prinsipnya, memutuskan untuk tidak melakukan retrospektif (tidak ada masalah, semuanya baik-baik saja - mengapa berkumpul bersama?). Tetapi dalam praktik saya, kasus ini sangat jarang dan penolakan retrospektif didikte bukan karena alasan lain. Saya akan menulis artikel terpisah tentang mereka nanti. Sementara itu, kembali ke bagaimana mengenali antipattern ini.

Tanda dan alasan:

Tim mengumpulkan, membuka templat kegiatan standar dalam retrospeksi (gila / sedih / senang atau mulai / hentikan / lanjutkan), tuliskan momen positif utama dari iterasi dan setelah 20-30 menit menyimpang tanpa membahas masalah dan rencana untuk peningkatan dalam tim. Tim menghindari pembicaraan tentang masalah, atau meyakinkan Scrum of the Master dan satu sama lain bahwa tidak ada tempat untuk meningkatkan.
Apa yang bisa menjadi alasan perilaku ini?

  • Orang-orang dapat dengan tulus percaya bahwa semuanya baik-baik saja dengan mereka: mereka memberikan produk, pemilik produk puas, apa lagi yang dibutuhkan?
  • Ini adalah tim super-kohesif yang telah bekerja bersama untuk waktu yang lama dan tidak dapat membayangkan bagaimana Anda bisa menjadi lebih baik, karena semua orang di perusahaan setara dengan mereka.
  • Saya bertemu tim yang anggotanya percaya bahwa semua masalah yang ada yang ada di zona kontrol atau pengaruh tim sudah diperbaiki, dan tim masih tidak ada hubungannya dengan masalah lain, apa gunanya membuang-buang waktu dan membahasnya lagi. Untuk masalah seperti itu, saya bahkan mendapat istilah - "diberikan perusahaan".

Apa yang harus dilakukan:

Dalam cerita ini, bagi saya banyak tergantung pada seberapa banyak saya, sebagai Scrum Master, percaya bahwa semuanya baik dalam tim, atau saya ragu akan hal itu.

Jika Anda memiliki perasaan bahwa semuanya berjalan dengan sangat baik dalam tim, Anda dapat melanjutkan sebagai berikut:

- Untuk menawarkan tim dalam retrospeksi pertanyaan kompleks yang mengarah keluar dari zona nyaman. Misalnya, "apa yang kami, sebagai tim, dapat buat untuk memberikan fungsionalitas 10 kali lebih banyak dari sekarang, pada saat yang sama." Atau "bagaimana Anda bisa sepenuhnya keluar dari proses regresi manual." Untuk beberapa tim saya, pertanyaan kedua terdengar lebih tidak memadai daripada yang pertama.

Reaksi pertama terhadap pertanyaan ini kemungkinan besar akan mengejutkan dan mengejutkan, tetapi langkah selanjutnya bisa berupa brainstorming yang menarik, melihat sistem secara keseluruhan dan ide-ide menarik untuk mengoptimalkan seluruh proses pengiriman nilai.

- Manfaatkan kesempatan bagi anggota tim untuk mengenal satu sama lain dengan lebih baik dan memompa kerja tim melalui permainan. Saya tidak akan membahas topik permainan secara terperinci, saya hanya bisa mengatakan bahwa ada kegiatan luar biasa untuk bekerja dengan nilai-nilai Scrum, untuk membangun fokus pada tujuan bersama, untuk membangun kepercayaan dalam tim. Ada banyak format game yang dijelaskan dalam sumber terbuka. Tentang hal-hal yang saya lakukan, saya membagikan di blog profesional saya Scrum Masters.

Tentu saja, permainan tidak boleh sepenuhnya diganti oleh retrospektif, tetapi mereka dapat menjadi "jeda" untuk tim, kesempatan untuk mengubah konteks kerja dan melihat efektivitas kerja tim di sisi lain.

Namun, apa yang harus dilakukan Scrum kepada sang Guru, jika tidak ada keyakinan batin ini bahwa semuanya baik-baik saja? Untuk kasus ini, saya punya dua ide.

Yang pertama adalah memperluas konteks retrospektif untuk tim, mis. perluas sudut pandang tentang situasi di tim. Misalnya, ini dapat dicapai dengan menambahkan peserta baru ke retrospektif. Saya melihat banyak tim yang melakukan retrospektif tanpa partisipasi pemilik produk karena berbagai keadaan (dia tidak mau, jadi secara historis, hambatan bahasa). Untuk tim semacam itu, retrospektif dengan partisipasi pemilik produk akan dilakukan dengan cara yang benar-benar baru. Gagasan yang sama dapat diwujudkan dengan mengundang anggota tim terkait lainnya yang ada di depan atau setelah tim dalam rantai pasokan nilai. Satu detail penting - semua ini harus dilakukan dengan persetujuan tim, tamu undangan sebagai kejutan kemungkinan akan membawa rasa sakit dan ketidakpercayaan kepada Scrum Master, daripada membantu membangun retrospektif.

Gagasan kedua adalah menawarkan Scrum kepada Master atau kepada salah satu anggota tim untuk mengumpulkan data yang belum pernah mereka kumpulkan sebelumnya. Saya memiliki contoh yang bagus dalam pengalaman saya ketika analisis statistik yang dikumpulkan pada jumlah cacat yang ditemukan di dalam sprint (yaitu, tren metrik ini selama 4 sprint terakhir) memimpin tim untuk diskusi yang sangat produktif tentang bagaimana meningkatkan kualitas pengujian di antara pengembang dan bagaimana mengatur interaksi yang erat antara pengujian dan pengembangan di dalam sprint. Sering terjadi bahwa secara umum tim mengatasi dengan baik perasaan mereka dan umpan balik dari luar, tetapi masih ada banyak poin untuk perbaikan, Anda hanya perlu menarik perhatian tim kepada mereka.

Antipattern No. 2 “Nuh, kami mengeluh, tidak ada rencana”




Cerita bahwa tim siap datang ke retrospektif untuk mengeluh, membenci, berduka, merengek, tetapi tidak ada rencana untuk bekerja dengan masalah, seperti rencana perbaikan, sebagai hasil dari retrospektif. Lebih tepatnya, tim memiliki rencana, serangkaian tindakan telah disusun, ada yang bertanggung jawab, tetapi rencana ini tidak membantu tim benar-benar membaik, tidak membantu untuk mengatur eksperimen dan menguji hipotesis untuk meningkatkan efisiensi kerja atau meningkatkan kualitas produk. Rencana ini agak formalitas, rencana demi rencana.

Tanda-tanda:

  • Tim dengan penuh semangat membahas apa yang terjadi di dalam tim, tetapi tidak ada cukup waktu untuk merencanakannya, dan itu menyimpang sampai waktu berikutnya, paling banter, dengan daftar apa yang mereka rencanakan untuk dikerjakan beberapa waktu kemudian. Pertanyaan tentang siapa, kapan, dan bagaimana cara kerjanya akan tetap terbuka.
  • , , , , : , - , .
  • , , 80-90% – , , , . , , . , ( , , ) , .

Mari kita lihat bagaimana Anda dapat bekerja dengan situasi ini.

Apa yang harus dilakukan:

Mari kita mulai secara berurutan. Agar rencana perbaikan muncul di tim, pertama-tama, perlu bahwa agenda retrospektif (yaitu, semua fase - pendaftaran, pengumpulan ide, analisis ide, pengembangan rencana perbaikan, penyelesaian dan umpan balik) menjadi transparan bagi tim dan ada waktu untuk menyusun rencana untuk tindakan selanjutnya. Saya memiliki kasus ketika kami tidak punya waktu untuk mengerjakan rencana tindakan secara mendalam dan kemudian saya menunjuk sesi terpisah untuk menyelesaikan retrospektif dan merumuskan rencana. Saya percaya bahwa lebih baik untuk memperluas waktu yang diberikan untuk retrospektif daripada menyelesaikannya tepat waktu, tetapi keluar tanpa hasil.

Jika ada masalah dalam tim agar sesuai dengan waktu pertemuan yang dijadwalkan, ada pendekatan untuk mengatur beberapa timer, misalnya, selama 15, 8 dan 5 menit. Sejak awal, tim tahu bahwa diskusi harus diakhiri pada akhir penghitung waktu ketiga dan lebih fokus pada negosiasi. Secara umum, teknik fasilitasi, pengorganisasian kerja dalam kelompok-kelompok kecil dan waktu yang tetap untuk diskusi dan fase individual dari pekerjaan retrospektif menakjubkan dan membantu mengarah pada pengembangan solusi bahkan untuk kelompok dengan dinamika yang kompleks.

Jadi apa yang harus dilakukan Scrum kepada Master jika tim membawa kembali masalah organisasi dalam retrospeksi dan menghindari masalah nyata? Ada beberapa alat yang menurut pengalaman saya telah membantu:

  • – – , , , , « , ».
  • , (, ). , . , , .
  • , , , , , . . , , - .
  • , , , , . , !

№3 « , »




Nama berbicara untuk dirinya sendiri - sebuah rencana dibuat untuk tim, tetapi tindakan atau percobaan yang diciptakan tidak dilakukan.

Tanda: Tanda-

tanda antipattern cukup jelas - di retrospektif berikutnya, tim tidak memiliki apa-apa untuk dibagikan sebagai hasil dari implementasi tindakan atau kesepakatan yang dipikirkan sebelumnya. Setiap orang, tentu saja, memiliki alasan yang bagus - dia tidak punya waktu, tangannya tidak mencapai, dia terlibat dalam masalah yang lebih penting, dia lupa. Tetapi sebagai hasil dari kemajuan dalam hal peningkatan dan percobaan, tidak.

Berbicara tentang antipattern ini, saya ingin memikirkan "panggilan yang mengganggu" pada tahap penyusunan rencana, yang dalam praktik saya paling sering merupakan sinyal bahwa tindakan dari rencana tersebut tidak akan dilakukan:

  • action items (.. ) «, , ». , , .
  • , , . , , « unit ». , , , « », « », , . «, , » .
  • , : «, , , wiki , », « / , , », «, 3 , , , », « , , , »

Apa yang saya lakukan dalam situasi di mana rencana muncul di tim saya yang ditulis tetapi tidak dilakukan? Saya ingat bahwa jika orang tidak melakukan sesuatu, mungkin ada alasan berikut:

1. Saya tidak mengerti
2. Saya tidak bisa
3. Saya tidak bisa
4. Saya tidak mau.

Pikiran ini banyak membantu saya untuk berhenti dan berpikir apakah mungkin untuk mengecualikan opsi "Saya tidak mengerti, saya tidak bisa, saya tidak tahu bagaimana", sebelum mulai bekerja di lapangan "Saya tidak ingin" dan berurusan dengan motivasi orang tersebut, mengapa ia berada di tim dan apa tujuannya.

Apa yang harus dilakukan?

Mari kita lihat apa sebenarnya yang bisa dilakukan, tergantung pada apa alasan untuk tidak bertindak.

Alasan 1: seorang anggota tim yang setuju untuk mengambil beberapa item tindakan benar-benar tidak mengerti apa yang diharapkan darinya.

  • , .
  • , , , , .
  • , , , - . 

Alasan 2: anggota tim dan akan senang untuk memenuhi item tindakan yang dia ambil pada dirinya sendiri, tetapi secara fisik tidak dapat melakukan ini, karena sibuk dengan tugas-tugas lain dan dia tidak punya waktu untuk ini di sprint.
 
Scrum Master dapat menambahkan aktivitas paling penting dari rencana mulai dari retrospektif hingga sprint backlog (setelah menyetujui ini dengan pemilik produk pada retro atau setelahnya), mengevaluasinya, mencatat siapa yang akan melakukannya, membuatnya transparan bagi semua orang bahwa tim akan menghabiskan waktu untuk hal ini. 

Alasan 3: seorang anggota tim akan dengan senang hati lagi memenuhi apa yang dia daftarkan, karena dia benar-benar tertarik dan penting (misalnya, memilih kerangka kerja yang paling cocok untuk stress testing), tetapi dia tidak pernah memiliki bisnis dengan ini sebelumnya dan tidak pernah dapat mencari tahu di mana untuk memulai. Di sinilah dia berakhir, karena bisa menyenangkan untuk menjelaskan kepada tim mengapa dia mengambil kegiatan ini jika dia tidak tahu caranya.

Scrum Master dapat memeriksa dengan seseorang yang siap untuk melakukan aktivitas di bawah rencana retro, jika dia harus melakukan sesuatu seperti ini sebelumnya. Jika tidak, pasti ada seseorang dalam tim yang lebih berpengalaman dalam hal ini yang bisa membantu. Dan jika seluruh tim tidak memiliki keahlian di lapangan, Scrum Master dapat mengambil tugas mencari ahli di tim lain atau komunitas.

Saya memiliki satu latihan bonus lagi, yang benar-benar membantu tim untuk memenuhi rencana - gantung kegiatan dari rencana di tempat yang menonjol bagi tim. Idealnya, setiap anggota tim yang mengambil semacam aktivitas mengambil stiker dengan TO DO ini untuk menggantungnya di tempat yang menonjol di desktop dan tidak melupakannya. Mereka mengatakan bahwa jika tujuannya ada di depan mata, seseorang secara sadar dan tidak sadar pergi ke sana. Saya suka pendekatan ini lebih dari sekadar mengingatkan tim bahwa retro sedang mendekati dan layak menyegarkan dalam ingatan tentang apa rencana itu terakhir kali.

Jadi, saya membagikan pemikiran saya tentang tiga antipatterns retrospektif pertama dalam tim Agile yang saya temui dalam praktik saya, dan ada dua antipengganti yang lebih menarik dan tidak kalah umum.

Saya akan senang mendengar cerita dan pengamatan Anda tentang retrospektif yang berhasil dan yang tidak. Beri tahu kami teknik dan teknik apa yang Anda miliki untuk membangun retrospektif yang efektif. Anda dapat menebak dua antiputral apa yang saya rencanakan untuk diceritakan dalam sekuel ini?
 

More articles:


All Articles