Scrum takımında takım yöneticisi ve geliştirici olmak

Son zamanlarda Scrum'a taşınan 6 kişilik bir ekibi yönetiyorum.

Bir Scrum Master (ekibin geliştiricilerinden biri) ve bir Ürün Sahibimiz var.

Oldukça fazla boş zamanım olduğu için (eskiden yaptığım birçok yönetim işi Scrum Master ve Ürün Sahibi tarafından yapıldığından) ve teknik olarak alakalı kalmak istediğim için, bazı teknik geliştirme çalışmaları yapıyorum.

Geliştirme ekibinin bir parçası olarak hareket ediyorum, her sprint'teki bazı öyküleri taahhüt ediyorum ve tüm toplantılara ekibin bir parçası olarak katılıyorum.

Sizce bu iyi bir fikir mi? Ekibin "kendi kendini örgütlemesi" ile çelişebilir mi?

Roy Osherove'un Çevik bir dünyada takım liderliği hakkındaki gelişmekte olan düşüncelerini 5whys.com'da okuyun

Bir takımın Şelaleden Scrum'a doğru geliştiği üç önemli aşamadan bahsediyor.

Hayatta kalma aşaması (gördüğüm çoğu takımın bulunduğu yer) - takımın öğrenmeye vakti yok - bu öğrenme zamanını hiçlikten yaratmak için daha fazla komuta ve kontrol liderliği gerektirir.

Öğrenme aşaması - bir takımın öğrenmek için zamanının olduğu ve kullandığı - lider gibi koç gerektirir, işlerin zor yolu öğrenmesi çok uzun zaman alacağı kontrol patlamaları gerektirir (örneğin, kaynak kontrolü seçmemek gibi)

Kendi Kendini Örgütleme Aşaması - Ekiplerin kendi sorunlarını çözebileceği yer - insanlara ne yapacaklarını söylemeyen, ancak kısıtlamalar ve hedefler sağlayan daha kolaylaştırıcı bir lider türünü gerektirir. Takım oraya kendi başına gelecek.

Roy'un fikirleriyle karşılaştığımda, OpenVolcano '10'da ekibimin neden gelişmeyi bıraktığı konusunda tam bir kayıptaydım . Sonra ekibin Hayatta Kalmadan Öğrenmeye geçtiğini fark ettim ve yönetim tarzımı hiç değiştirmedim. Ben yaptım ve çok yardımcı oldu.

Bu nedenle, bu üç aşamadan hangisinde olduğunuzu bulmanızı ve buna göre yönetmenizi öneririm.

Ayrıca, şimdi bir karar verin ve lider veya geliştirici olun. Kendi Kendini Örgütleme aşamasına gelene kadar boş vaktin olduğunu düşünme tuzağına düşmeyin. Ve eğer oraya gelirseniz, iyi bir takım lideri olduğunuzu ( zor ) fark edin ve kendinizi yeniden entegre etmek yerine başka bir takıma geçin.

pdr'nin yorumları geçerlidir ve onlara katılıyorum. Fakat onların tüm davalar için evrensel olduklarına inanmıyorum.

Yönetim tarzınız, iki rolde çalışmayı ne kadar iyi veya hatta düşünmeniz gerektiğini belirleyecektir.
Ekip yöneticisi olarak, çalışanlarınız için performans ve kariyer tipi kararları konusunda yetki sahibi olursunuz. Yanlış bir şekilde kullanıldığında, sizinle işverenleriniz arasındaki güç eşitsizliği, geliştirme ekibinin bir parçası olma girişimlerinizi bozabilir.

Bu eşitsizliğin farkında olduğunuz ve rolleriniz arasında net bir şekilde tanımladığınız sürece, hem yönetici hem de geliştirici olabileceğinizi düşünüyorum. Birkaç kez başarılı bir şekilde yapıldığını gördüm ve şu anda aynı durumda bir ekip üzerinde çalışıyorum.

Eşitsizliğin tüm etkilerini ortadan kaldıramayacağınızı belirtmek gerekir. Dilinizi ısırmanız ve canlı bir tartışmadan uzak durmanız gereken zamanlar olacaktır. Trump kartını çekmeniz ve takım için nihai sorumluluğun size ait olduğuna dikkat etmeniz gerektiğinde başkaları da olacaktır, bu yüzden bir diktat yapıyorsunuz.

Ekibinizde politik olarak güvenli olan en az iki güçlü, deneyimli geliştiriciye ihtiyacınız olacak. Onların rolü, güç eşitsizliğini kontrol altında tutmak ve dengeden çıkıp çıkmadığını size bildirmektir. Sadece bir güçlü geliştirici ile uğraşabilirsiniz, ancak ikinizin bir konuda kilitlenmesi durumunda ikinci bir nesnelliğe sahip olmak.

Derhal amirim teknik olarak alakalı kaldığında dürüst olmak isterim. Zorluklarımı anlamalarını kolaylaştırıyor ve bence daha iyi performans gösteren bir takımla karşılaşıyoruz.

Daha önce benzer bir deneyim yaşadım, bir Scrum takımında 6 geliştiriciden oluşan bir takıma liderlik ettim. Pdr ve GlenH7'nin bahsettiklerinin yanı sıra, yardımcı olan şeyler:

1. KG ekibindeki en iyi testçi, yaptığım işler de dahil olmak üzere bizi işimizin kalitesinden sorumlu tutmada gerçekten iyiydi. Buggy kodu yazdığımda, beni başka bir geliştiricinin yapması zor olacak şekilde çağırdı.
2. Sprint Demosunu genelde yaptım, özellikle de kötü sprintlerimiz olduğunda. CEO'ya tanıtım yaptığımdan beri, işler çalışmadığında utanç vericiydi. Başkalarının geliştirdiği özellikleri anladığımdan emin olmanın yanı sıra, eşyalarımın herkes gibi sağlam olması gerekiyordu.
3. Başkalarının karar vermesine izin verdim. Deneyimlerim GlenH7'den farklı, her zaman koz kartını çekmenin bir hata olduğunu gördüm. Bunun yerine, kararların farklı sonuçları hakkında konuştum ve hangi geliştiricinin bir şey yapmanın "yanlış" yolu olduğunu düşündüğüm şey için sonuçlarının ne olduğu üzerinde çalıştığını açıkça belirttim. Bunu yapmanın birçok nedeni var, ama en büyüğü takım liderliği yaparken tüm kararları vermek için zamanınız yok.
4. Sonar gibi bir ürünü kullanmak, kod kalitesi gibi şeyleri daha objektif hale getirebilir.