Praktik penggunaan peringkat pribadi setiap anggota tim dalam konteks Scrum dan SAFe

Dalam artikel ini saya berencana menceritakan bagaimana dalam praktik kami menerapkan Peringkat pribadi setiap anggota tim dalam Scrum selama proses kerja dengan framework SAFe

Mungkin banyak yang setuju bahwa (terutama di Rusia) orang-orang kita cukup sering berusaha bekerja (menghantarkan produk akhir dalam kerangka kompetensi mereka atau melalui memperoleh kompetensi baru) sesedikit mungkin dan mendapatkan uang sebanyak mungkin. Seiring ukuran perusahaan, peluang untuk ini tampaknya tumbuh berbanding lurus. Hal ini, biasanya, ditangani oleh berbagai pihak yang mirip HR, yang berusaha dengan segala cara membangun sistem motivasi yang benar. Termasuk juga OKR dan lain-lain. Secara umum, tampaknya semua ini ditujukan pada keseimbangan beban setiap orang di dalam korporasi dan kenyamanan semua kelompok pemangku kepentingan/tim korporasi. Dalam artikel ini saya akan berbagi metrik yang saya sendiri ciptakan dan terapkan dalam tim. Metrik ini memungkinkan, menurut saya, melengkapi upaya para HR dan OKR dalam menyeimbangkan beban di dalam satu tim tertentu atau melihat ketidakseimbangan, tentu saja. Selain itu, metrik ini juga cukup bisa diskalakan ke tim dari tim-tim, saya tidak melihat masalah khusus dalam hal itu.

Dengan demikian, bagi saya sebagai Scrum Master cukup jelas bahwa terkadang beban dalam tim tidak seimbang, ada yang bekerja untuk dua orang, ada yang tidak melakukan apa-apa (ini bentuk ekstrem dan, tentu saja, masalah serius, tetapi metrik ini menunjukkan bukan hanya bentuk ekstrem). Situasi seperti ini terjadi pada saya dan saya berpikir tentang metrik apa yang bisa dengan jelas menyorot masalah ini. Akhirnya, hal itu bermuara pada peringkat pribadi setiap anggota tim.

Sebelum menjelaskan metrik itu sendiri, saya ingin juga menyoroti satu ide yang menurut saya sangat penting. Saat ini saya benar-benar yakin akan hal itu.

Metrik harus dibangun berdasarkan data yang sudah Anda peroleh. Memperoleh suatu metrik tidak boleh memaksa tim untuk secara sistematis menghabiskan lebih banyak waktu dan menyesuaikan proses penghantaran nilai mereka dengan metrik itu sendiri. Lebih lanjut tentang ini saya akan coba ceritakan dalam salah satu artikel berikutnya.

Jadi, contoh kasus konkret. Tentu saja, kami menggunakan papan untuk memindahkan User Stories berdasarkan status dari DOR (Definition Of Ready) hingga DOD (Definition Of Done). Papan kami virtual (yaitu terletak di internet melalui tautan. Tim kami juga tersebar dan standup dilakukan melalui Skype korporat dengan transmisi papan.

Anggota tim merasa nyaman menempatkan diri sebagai peserta User Story, sehingga saat menggunakan filter berdasarkan diri sendiri dapat dengan cepat menyisakan hanya cerita yang sedang ia ikuti pada saat itu (paling sering filter ini kami gunakan saat standup).

Di sini juga, saya ingin memberikan penjelasan: ini tidak berarti bahwa anggota tim tersebut tidak dapat berpartisipasi dalam cerita lain (jika, misalnya, pada standup salah satu anggota tim meminta bantuan, ia bisa saja menjadi peserta cerita baru atau sebaliknya, jika merasa bahwa partisipasinya tidak diperlukan, ia bisa berhenti menjadi peserta cerita mana pun.

Dengan demikian, untuk menghitung peringkat setiap anggota tim, kita perlu melihat seberapa besar SP yang dipengaruhi setiap anggota tim. Dalam kasus kami, Arkady memengaruhi 29 SP (cerita 1, 2, 5, 6), Tatyana memengaruhi 33 SP (Berpartisipasi dalam semua cerita), Vasily 23 SP (cerita 1, 3, 5, 6).

Selesai (DOD terpenuhi) pada Arkady 5 dari 29 SP, pada Tatyana 6 dari 32 SP, pada Vasily 5 dari 23. Dengan pengurutan saya cukup lama berjuang dan sampai pada formula perbandingan dua anggota tim seperti ini (team[i] - satu anggota tim dan team[j] - anggota tim lainnya):

Menurut pengurutan ini kita akan mendapatkan peringkat anggota tim saat ini dalam bentuk berikut.

• Peringkat 1. Vasily (Selesai 5 dari 23)
• Peringkat 2. Arkady (Selesai 5 dari 29)
• Peringkat 3. Tatyana (Selesai 6 dari 32)

Sekarang mari kita hasilkan semua data per sprint. Bayangkan bahwa sprint berlangsung 5 hari kerja.

• Hari 1
  

  

  
  Peringkat 1: Vasily (terbakar 0 dari 23)
  Peringkat 2: Arkady (terbakar 0 dari 29)
  Peringkat 3: Tatyana (terbakar 0 dari 32)
  
• Hari 2
  

  

  
  Peringkat 1: Vasily (terbakar 0 dari 23) dinamika(1->1)
  Peringkat 2: Arkady (terbakar 0 dari 29) dinamika(2->2)
  Peringkat 3: Tatyana (terbakar 0 dari 32) dinamika(3->3)
  
• Hari 3
  

  

  
  Peringkat 1: Vasily (terbakar 5 dari 23) dinamika(1->1->1)
  Peringkat 2: Arkady (terbakar 5 dari 29) dinamika(2->2->2)
  Peringkat 3: Tatyana (terbakar 5 dari 32) dinamika(3->3->3)
  
• Hari ke-4
  

  

  
  Peringkat 1: Vasily (terbakar 8 dari 23) dinamika(1->1->1->1)
  Peringkat 2: Arkady (terbakar 8 dari 29) dinamika(2->2->2->2)
  Peringkat 3: Tatyana (terbakar 9 dari 32) dinamika(3->3->3->3)
  
• Hari ke-5
  

  

  
  Peringkat 1: Vasily (terbakar 23 dari 23) dinamika(1->1->1->1->1)
  Peringkat 2: Tatyana (terbakar 24 dari 32) dinamika(3->3->3->3->2)
  Peringkat 3: Arkady (terbakar 21 dari 29) dinamika(2->2->2->2->3)
  

Dengan demikian, menggunakan metrik ini kita dapat mengakumulasi statistik pribadi setiap anggota tim dan membantu mereka menarik kesimpulan yang tepat. Misalnya, di sini kita melihat bahwa Vasily merencanakan waktunya dengan sangat baik sejak awal (yaitu pada perencanaan sprint ia menyepakati dengan tim tentang volume pekerjaan yang ia selesaikan secara faktual.) Namun, pada saat yang sama, mungkinkah ia bisa membantu anggota tim lainnya? Mungkin tidak, tetapi patut dipikirkan pertanyaan ini sebelum retrospektif.

Tatyana dan Arkady memiliki masalah yang lebih serius. Jelas bahwa sejak awal pada perencanaan sprint mereka menyepakati dengan tim untuk berpartisipasi dalam semua cerita dan pada faktanya tidak mampu memenuhi komitmen. Penyebabnya juga patut dipikirkan sebelum retrospektif. Mungkin sebaiknya merencanakan lebih sedikit untuk diri sendiri, mungkin memperluas kompetensi agar dapat menyelesaikan semua yang direncanakan, mungkin ada solusi lain.

Dengan demikian, kita dapat mengakumulasi statistik tidak hanya untuk seluruh tim dan tidak hanya untuk satu sprint, tetapi juga untuk peserta tertentu di DEV TEAM sepanjang waktu dan menggunakan informasi ini untuk perbaikan tim secara berkelanjutan.

Sebagai penutup, saya ingin menarik perhatian khusus pada fakta bahwa sebelum menggunakan metrik ini di tim, sebagian besar tim harus sudah memiliki tingkat kepercayaan yang cukup tinggi. Selain itu, saya akan merekomendasikan untuk menekankan pada hal yang utama - tidak adanya kerja lembur dan aktivitas yang nyaman.

Kami menekankan pada peramalan hasil yang tepat, bukan pada motivasi untuk bekerja lembur agar menempati peringkat 1. Pada akhirnya, metrik ini bertujuan untuk meningkatkan kemampuan perencanaan setiap anggota tim secara individual.