Menjadi manajer tim dan pengembang dalam tim Scrum

Saya mengelola tim yang terdiri dari 6 orang yang baru saja pindah ke Scrum.

Kami memiliki Scrum Master (salah satu pengembang di tim) dan Pemilik Produk.

Karena saya mempunyai cukup banyak waktu luang (karena banyak pekerjaan manajemen yang dulu saya lakukan sekarang dilakukan oleh Scrum Master dan Pemilik Produk), dan karena saya ingin tetap relevan secara teknis, saya melakukan beberapa pekerjaan pengembangan teknis.

Saya bertindak sebagai bagian dari tim pengembangan, berkomitmen untuk beberapa cerita di setiap sprint, dan berpartisipasi dalam semua pertemuan sebagai bagian dari tim.

Apakah menurut Anda itu ide yang bagus? Bisakah itu bertentangan dengan "pengaturan diri" tim?

Bacalah pemikiran Roy Osherove tentang kepemimpinan tim dalam dunia Agile di 5whys.com

Dia banyak berbicara tentang tiga tahap kunci yang dilalui tim saat berevolusi dari Waterfall ke Scrum.

Fase bertahan hidup (di mana sebagian besar tim yang saya lihat berada) - di mana tim tidak memiliki waktu untuk belajar - membutuhkan lebih banyak jenis kepemimpinan dan kontrol untuk menciptakan waktu belajar dari ketiadaan.

Fase pembelajaran - di mana tim memiliki waktu untuk belajar dan menggunakannya - membutuhkan pelatih seperti pemimpin, dengan semburan kontrol ketika hal-hal akan terlalu lama untuk belajar dengan cara yang sulit (misalnya, tidak memilih kontrol sumber)

Fase Pengorganisasian Sendiri - Di mana tim dapat menyelesaikan masalah mereka sendiri - membutuhkan lebih banyak tipe pemimpin fasilitator, yang tidak memberi tahu orang apa yang harus dilakukan, tetapi hanya memberikan kendala dan tujuan akhir. Tim akan sampai di sana sendiri.

Ketika saya menemukan ide-ide Roy, di OpenVolcano '10 , saya benar-benar bingung mengapa tim saya berhenti membaik. Kemudian saya menyadari bahwa tim telah beralih dari Survival ke Learning dan saya tidak mengubah gaya manajemen saya sama sekali. Saya melakukannya dan itu banyak membantu.

Jadi saya sarankan mencari tahu dari tiga fase mana Anda berada dan mengelola sesuai.

Juga, buat keputusan sekarang dan jadilah pemimpin atau pengembang. Jangan terjebak dalam pemikiran bahwa Anda memiliki waktu luang sampai Anda memasuki fase Swasembada. Dan, jika Anda sampai di sana, sadarilah bahwa Anda adalah pemimpin tim yang baik ( sulit ) dan pindah ke tim lain daripada mengintegrasikan kembali diri Anda sendiri.

Komentar pdr valid, dan saya setuju dengannya. Tapi saya tidak percaya itu universal untuk semua kasus.

Gaya manajemen Anda akan menentukan seberapa baik atau jika Anda bahkan harus mempertimbangkan bekerja dalam dua peran.
Sebagai manajer tim, Anda memegang otoritas atas keputusan kinerja dan tipe karier untuk karyawan Anda. Dipakai dengan keliru, perbedaan kekuatan antara Anda dan majikan Anda dapat merusak upaya Anda untuk menjadi bagian dari tim pengembangan.

Selama Anda menyadari perbedaan itu, dan Anda dengan jelas menggambarkan peran Anda, saya pikir Anda bisa menjadi manajer dan pengembang. Saya telah melihatnya berhasil beberapa kali, dan saat ini saya sedang mengerjakan sebuah tim dalam situasi yang sama.

Perlu dicatat bahwa Anda tidak dapat menghilangkan semua efek dari perbedaan tersebut. Akan ada saat-saat ketika Anda perlu menggigit lidah dan menahan diri dari perdebatan yang bersemangat. Akan ada orang lain ketika Anda perlu menarik kartu truf dan menunjukkan bahwa tanggung jawab utama untuk tim terletak pada Anda, sehingga Anda membuat diktat.

Anda membutuhkan setidaknya dua pengembang yang kuat dan berpengalaman di tim Anda yang aman secara politik. Peran mereka adalah untuk menjaga disparitas kekuasaan dan untuk memanggil Anda keluar jika semuanya menjadi tidak seimbang. Anda bisa bertahan dengan hanya satu pengembang kuat lainnya, tetapi memiliki yang kedua memberikan objektivitas jika Anda berdua menemui jalan buntu karena suatu masalah.

Jujur saya suka ketika atasan langsung saya menjaga dirinya relevan secara teknis. Ini memfasilitasi pemahaman mereka tentang kesulitan saya, dan saya pikir kami berakhir dengan tim yang berkinerja lebih baik.

Saya telah melalui pengalaman yang sama sebelumnya, memimpin tim yang terdiri dari 6 pengembang dalam tim Scrum. Selain apa yang pdr dan GlenH7 sebutkan, hal-hal yang membantu:

1. Penguji terbaik di tim QA benar-benar pandai menjaga kami bertanggung jawab atas kualitas pekerjaan kami, termasuk pekerjaan yang saya lakukan. Ketika saya menulis kode kereta, dia memanggil saya dengan cara yang akan sulit dilakukan pengembang lain.
2. Saya biasanya melakukan Demo Sprint, terutama ketika kami memiliki sprint buruk. Karena saya melakukan demo ke CEO, itu memalukan ketika hal-hal tidak berhasil. Selain memastikan bahwa saya memahami fitur yang dikembangkan orang lain, itu juga berarti bahwa barang saya harus sekokoh milik orang lain.
3. Saya membiarkan orang lain membuat keputusan. Pengalaman saya berbeda dari GlenH7, saya selalu menemukan kesalahan menarik kartu truf. Sebagai gantinya, saya berbicara melalui konsekuensi keputusan yang berbeda, dan menjelaskan kepada pengembang mana yang pernah mengerjakan sesuatu apa akibatnya bagi hal yang saya pikir merupakan cara "salah" dalam melakukan sesuatu. Ada banyak alasan untuk melakukan ini, tetapi yang terbesar adalah bahwa sebagai pemimpin tim, Anda tidak punya waktu untuk membuat semua keputusan.
4. Menggunakan produk seperti Sonar dapat membuat hal-hal seperti kualitas kode lebih objektif.