Geliştirme Yöneticilerinin Scrum Ustaları olarak olumsuz yönleri nelerdir?

Genelde ekip yöneticilerinin aldatmaca olmaması gerektiği konusunda hemfikirdir, ancak nedenini görmek için mücadele ediyorum. Bağlamda, Scrum Takımı'nda 4 devs olan bir Uygulama Geliştirme Yöneticisiyim. Ben bir Scrum Master arka planından geliyorum ve organizasyonu scrum ile tanıştırdım. Takımı sıfırdan oluşturdum ve yaptığım her şeyin takımı kolaylaştırmak olduğunu ve kararları aldıklarını açıkça belirttim. Bir ekip olarak çok açıkız - bir an için beni stand-up'ta susturuyorlardı. Açıklık eksikliği genellikle yöneticiye karşı scrum ustası olarak en büyük argümandır, ancak iyi işlenirse, doğru kültürle kolayca üstesinden gelinir.

Tecrübeli antrenörler tarafından bunun tehlikeli bir durum olduğu konusunda uyarıldım ve 'işler kötü giderse' riskleri var. Gördüğüm şekilde 2 pozisyonun çatışması yok, her iki rolde de takım ve bireyler için aynı amaç var. Scrum, geleneksel olarak bir yönetici rolü olabilen takım içindeki çatışmaları çözer. Sprintlerin kendini yöneten doğası, bir yöneticinin geleneksel olarak yapacağı iş tahsisini elinden alır.

Geliştirme yöneticisi olarak görmeyi bıraktığım tek şey, bireylerin ihtiyaçlarının karşılanmasını, kariyer hedeflerini, işyerini vb. Sağlamalarını sağlamaktır. Her takım üyesini, sorunları dile getirmek ve yönetici görevlerini yerine getirmek için haftalık olarak bilgilendiririm. Bunların çoğu doğrudan takımla ya da yine de scrum master olarak görevimle ilgilidir.

Büyük kuruluşlarda bunun nasıl yönetilemez ve ayrı bir rol olabileceğini anlıyorum, ancak küçük bir kuruluş için kesinlikle başka bir Scrum Master veya Geliştirme Yöneticisini haklı çıkaramadık.

Lütfen beni yukarıda belirttiğim ve şimdiden üstesinden geldiğim noktalar haricinde, Geliştirme Yöneticilerinin Scrum Ustaları arasındaki tuzaklara karşı aydınlatın.

Temel olarak, bir çıkar çatışması var. Bir yöneticinin işi son başvuru tarihlerini karşılamaktır. Bir aldatmaca ustasının işi, tahminlerin mümkün olduğunca doğru olmasını sağlamak ve sürdürülebilir bir hızda çalışmaktır. Bir yönetici bir sprint içine daha fazla iş çekilmesini isteme eğilimindedir ve bir scrum ustası dış sürelerden bağımsız olarak gerçekçi bir şekilde bitebilecek bir miktar isteme eğilimindedir. İyi bir yönetici bu çatışmayı dengeleyebilse de, iş iki kişi arasında bölündüğünde çok daha kolaydır. Yöneticiler genellikle ürün sahibi rolü için çok daha uygundur.

Eğer takımınızdaki hiç kimse aşina değilse, scrum ustası olarak hareket etmenin yanlış bir tarafı yoktur, ancak birkaç ay sonra bu rolü yerine getirirseniz, takımınız fayda görecektir. Bu rolün bir akran olarak görülmesi önemlidir. Yönetim dışı scrum ustaları bile çoğu zaman bir süre sonra geri dönmek zorunda kalıyorlar çünkü takım onlara bir menajer gibi davranmaya başlıyor.

Asıl sorunun, yönetici olarak, takıma ne yapacağını söyleme yetkisine sahip olduğuna inanıyorum. Bir scrum ustası bu yetkiye Scrum prensiplerini uygulamaktan başka sahip değildir.

Ne anlama geliyor? Yöneticinin girişi dolaylı olarak daha fazla ağırlık taşıyacaktır. Bunu kastetmeyebilir veya istemeyebilirsiniz, ancak günün sonunda ekip üyelerinizin kariyer ve maaşları bir şekilde size bağlı. Ve onlar bunu biliyor. Ve bu ilişkiyi gösterir.

Hala yapabilir misin? Tabii ki. Hizmetçi lideri olduğunuzu ve yukarıdan aşağıya uçmayacağınızı güçlendirmek için çok çalışmanız gerekir.

Aslında bir "teknik müdür" bir projenin günlük mekaniğine çok fazla karıştığında ne olduğunu gördüm ve bu pek hoş değil. Bizim durumumuzda, söz konusu yönetici aldatmaca ustası değildi , fakat bu kararların bazılarını birlikte seçmeye çalışıyordu; biz aslında olmasaydı vardı sonra savunma oynamak için ayrı bir saldırı ustası bu çok daha acı olurdu.

(Bu arada, bu benim yöneticim değildi , bu yüzden bu noktada kendimi oldukça tarafsız hissediyorum.)

Başlıca çıkar çatışmaları olarak gördüklerimin üzerinden geçeceğim; bunlardan herhangi birinin sizin durumunuz için geçerli olduğunu düşünmüyorsanız, o zaman belki ikisini de yapabilirsiniz. Ancak , bu tuzakların hiçbirine düşmediğinizden emin olmak için bu varsayımları düzenli olarak tekrar kontrol ettiğinizden emin olun:

1. Teknik müdürler tipik olarak birden fazla takımda belirli bir rolden sorumludur. Eğer sadece bir takımsa, o zaman bir "menajer" den ziyade "öncü" dür. Bu sorumluluğun yayılması, ekiple daha az zaman geçirme ve proje / ürünle daha az zaman geçirme anlamına gelir ve stil yönetimine "vur ve koş" anlamına gelir.

2. Teknik yöneticilerin işletmede birçok başka yönetici görevi vardır. Koçluk / eğitim, performans değerlendirmeleri, röportajlar / işe alma, uzun vadeli altyapı / kaynak planlaması ve daha fazlasını yapmaları gerekir. Bu kolayca tam zamanlı bir iş haline gelebilir ve kolaylaştırmak için harcanacak çok az kalıntısı anlamına gelir.

3. Yoğun bir program kendini takıma da yükleyebilir; teknik yöneticiler, ekip üyelerini, ekibin uygun olmayan bir zaman olarak gördüğü toplantılara toplantılara çekmesi gerekebilir (veya isteyebilir). Normalde bu scrum ustasının işi kesintileri yönetmek ve ortadan kaldırmak için çalışmaktır, ancak endişelenmek için kendi zamanlamanız varken bunun nesnel olması imkansızdır. Scrum ustalarının nadiren ekip üyeleriyle ayrı ayrı görüşmeleri gerekir, çünkü bu toplantıların tümü önceden planlanmıştır (stand-up'lar, retrospektifler, vs.).

4. Teknik yöneticiler, çapraz proje endişeleriyle başa çıkmak zorundadır ve doğal dürtüleri, kütüphaneleri, kaynak kontrolünü, algoritmaları, düzenleri, renkleri, her şeyi standartlaştırmaya çalışmak olacaktır. Bu aslında şirket için iyi bir şey olsa da, nihayetinde ekibin yapmak istediği şey için sopayla yarışacak kimseyi bırakmıyor ve farklı bir şey yapmak istemek için çok iyi nedenleri olabilir. Bu, Scrum ve benzeri metodolojilerin altında yatan “sürekli iyileştirme” ideallerine karşı gelir.

5. Yönetdikleri rol konusunda uzman bir geçmişe sahip olan yöneticilerin, işin nasıl yapılması gerektiği ve ne kadar sürmesi gerektiği konusunda oldukça güçlü fikirleri olacaktır. Bu bir yönetici olarak kötü bir şey değildir , ancak bir scrum ustası olarak, genellikle ekip üyelerini başka türlü kararlaştırmayacakları tasarımlara veya tahminlere itmek anlamına gelir - ve muhtemelen eldeki sorun hakkında sizden daha fazla şey bilirler.

6. Ekip üyeleri her zaman bir istek ile bir sipariş arasında ayrım yapmakta zorlanırlar. Bunu size söylemeyecekler ve kendileri bile fark etmeyebilirler. Sadece sormakta olduğunuzu ve söylemediğinizi açıkça belirtmiş olsanız bile, zihinlerinde hala menajerleriniz ve “hayır” demek için kariyer düzeyinde riskler var. Bunun nedeni muhtemelen sorunların en önemlisi sinsidir bu konuda yapabileceği bir şey yok - bu onların tutum ve senin önemli olan bu.

Eğer değilseniz emin bu tuzakların hiçbirine düşecek asla olduğunuzu, o zaman ne duruyorsunuz ... ama emin olun tekrarlamak sık doğrulamak ekibinize konuşarak varsayımlarınızı (ve diğer ekipler / yöneticileri!) ve belki de farketmediğiniz, ince veya bilinçsiz bir şekilde olmadıklarından emin olun.

Olumlu bir kayda göre, konuyu soruyu sormak için yeterince önemli gördüğünüz gerçeğinin, her iki rolde muhtemelen oldukça iyi olduğunuz anlamına geldiğini ekleyeceğim. Ekibi önemsiyorum ve sadece kendi kariyer hedeflerinize değil, muhtemelen kitaplarımda iyi yönetimin yarısından fazlasını oluşturuyor.

... ama ikisinde de iyi olmak, her zaman aynı anda, her zaman iyi olabileceğiniz anlamına gelmez . Buna dikkat et.

Bu din değil ve Scrum'ın kuralları dogmatik değildir. Birleştirilmiş bir İK Müdürü / Srum Master rolü için bir durum olmuşsa, iyi bir rol oynadınız. Bahsettiğiniz tuzakları aramaya devam edin, ancak hiçbir zaman her duruma mükemmel bir şekilde uyan tek bir kurallar dizisi olmayacak.

Ekibiniz her iki rolü yerine getirme konusunda rahatsa, o zaman bir kitabın kurallarına uymak için işleri sallamak için hiçbir sebep yoktur.

Gördüğüm en büyük sorun, ekibin sizinle ilgili bir sorunu olduğu, yönetici olduğu durum. Küçüklerse veya güvenleri eksikse, retrospektifler sırasında konuşmaktan korkabilirler. Bu retrospektiflerin etkinliğini sınırlayabilir. Birçok kişi yönetici olduğunda "Yöneticinin gerçekçi olmadığını hissediyorum" demekten korkuyor.

Yani, belki de bu sorunu çözmek için retrospektiflerden mazeretin. Artık ekibiniz bir scrum ustası olmadan retrospektifler yapıyor ve aynı zamanda retrospektifin etkinliğini de sınırlandırıyor.

Her iki durumda da, takım üzerinde olumsuz bir etkiye sahipsiniz.

Gördüğüm en temel sorun, ekibin ekibinin organizasyonu hakkında çelişkili mesajlar gönderiyor olmasıdır.

Aşağıda iki olası takım organizasyonu vardır. Her ikisi de başarılı olabilir. Onlar farklı. (Onlar mümkün olan tek seçenek değiller.)

1. Takımın resmi olarak belirlenmiş bir lideri var. Takım lideri sonuçta takımların genel performansından sorumludur. Takım lideri tüm kararları vermeyebilir, ancak takım lideri tüm kararlar üzerinde son sözü söyler.
2. Takım kendi kendini organize etti ve resmi olarak belirlenmiş bir lider yok. Takımdaki herkes kendi ve takımların genel performansından sorumludur. Scrum Master, Scrum sürecini kolaylaştırır, ancak takım için tek taraflı kararlar alma yetkisi yoktur.

Gerçek takım yapınız # 1 gibi gözüküyor, ancak terminolojiyi ve Scrum'dan birkaç işlemi kullanarak yapının 2 olduğunu ima ediyorsunuz. Bence # 1 Scrum değil.

Aşağıda çatışmanın nasıl çözüleceği ile ilgili iki öneri var.

1. Her şeyi olduğu gibi yapmaya devam edin, ama takım lideri olduğunuzu ve% 100 Scrum'u takip etmediğinizi netleştirin. Muhtemelen, bir yönetici ve scrum master'ın görevlerini ayırmadaki değeri görürken, bunun şirket için uygun olmadığını açıklamaya yardımcı olacaktır.
2. Scrum Master'ın sorumluluklarını mümkün olduğu kadar başkasına verin. Barikatları temizlemek ve kurumun geri kalanından dikkat dağıtıcıları saptırmak gibi bazı sorumlulukları yerine getirmeniz gerekse bile, Scrum Master çalışmalarının çoğunun bir akran tarafından yapılması size yardımcı olacaktır.

Geliştirme Yöneticilerinin Scrum Ustaları olarak olumsuz yönleri nelerdir?

Geliştirme yöneticileri işe alındı:

• Gelişim problemlerini çözün .
• Teknik borcu izleyin ve azaltın.
• Teknik personeli büyütün.

Geçmişleri ve uzmanlıkları, teknik konulara odaklanmalarını sağlar .

Öte yandan, proje yöneticileri / scrum ustaları;

• Proje başarısını sağlamak.
• İş ve çalışma hatalarını / sorularını uygun geliştirme kaynaklarına atayın.
• Projenin tamamlanmasını geciktirebilecek tüm engelleri kaldırmak için geliştirme ekibi ile işbirliği yapın.
• Proje durumunu üst yönetime aktarın.

• Bir proje veya şirket belirli bir boyuta büyüdüğünde, bir geliştirme yöneticisinden her iki görevi de yerine getirmesini istemek etkin değildir.

• Bir geliştirme yöneticisi, "derin dalışları" kodlamaya ve / veya mimariye sokmaya meyilliyken, bir proje yöneticisi / aldatmaca ustası her zaman "50.000 ayak" görüşüyle ​​ilgilenmelidir.

• Çoğu geliştirme yöneticisi kod geliştirmek için yıllarını harcadı. Kalkınma sorunları onlara çok aşinadır.

  • Bu nedenle teknik problemleri çözerken çok faydalıdırlar.
• Proje yöneticisi / scrum master rolleri çok organize ve çok ayrıntılı odaklı fakat süper teknik olmayan insanları gerektirir.
• Bu insanların iyi oldukları şeyler konusunda uzmanlaşmasına izin verebileceğiniz zaman, işletme en verimli olanıdır.
• Ve bir gelişim müdürünün tabağından scrum ile ilgili sorumlulukları boşaltabildiğinizde, teknik konularda daha fazla zaman harcayabilir ve teknik borcu azaltabilir.

Tecrübeli scrum antrenörlerini dinlerdim. Zamanın% 99'unda gayet iyi çalışmanız mümkündür. Bununla birlikte, bu% 1'lik korku ortaya çıktığında ve roller çatışırsa, sadece bir bireyin sizinle olan ilişkisini değil tüm takımın iyiliğini berbat etme şansınız olur. Ve bir berbat edildikten sonra hem scrum master hem de manager olarak rolünüz baltalanacak.

Yerinde olsam, ekipte scrum-master olma potansiyeli olan bir kişiyi teşhis eder ve onunla giderdim. Ben her zaman bir scrum ustasını ekibin güvendiği ve süreci, işi ve korkunç teknik olayları anlayan biri olarak gördüm. Yetenekli bir insanı seçtiyseniz, aldatmaca ustası rolü tam zamanlı bir iş değildir (ve olmaya bile yakın değildir).