Günaydın.
Duyuru
(Resim:
Stefan Mintert
)
Stefan Mintert, yazılım geliştirmede şirket kültürünü geliştirmek için müşterileriyle birlikte çalışıyor. Şu anda liderlikte en büyük potansiyeli görüyor; hiyerarşik seviyeden bağımsız olarak Bazı yön değişiklikleriyle bir kariyer yolunun ardından bu potansiyelden yararlanmayı kendine görev edindi. Birkaç yıllık danışmanlık deneyimine sahip bir BT geçmişinden gelen, başlangıçta kendi yazılım geliştirme şirketini kurdu. Liderliğin öğrenilmesi gerektiğini ve iyi rol modellerinin nadir olduğunu buldu. Müşterilerinin yazılım geliştirmede en büyük desteğe ihtiyacının kod üretiminde değil liderlik olduğu ortaya çıktı. Dolayısıyla Kutura şirketinin nereye doğru gittiği onun için açıktı: ürünleri geliştiren insanların gelişip büyüyebilmesi için liderliği geliştirmek. Stefan, 1994'ten bu yana iX'te uzun süredir serbest çalışan olarak Haberler için yazıyor.
Bugün aslında hangi kişilerin veya rollerin bir takıma ait olduğunu yazmak istiyorum.
Scrum Kılavuzuna göre bir Scrum takımı şu kişilerden oluşur:
Bana göre bu iki nokta uyumlu değil. Takım tanımının Scrum tasarımında bir kusur olduğunu düşünüyorum. Nasıl olur?
Her işbirliğinde bazen sürtüşme veya çatışma ortaya çıkar. Birlikte çalışan insanların daha da gelişmesinin bir kısmı da sürtüşmeleri ve çatışmaları yönetmeyi öğrenmeleridir.
Scrum'da retrospektif, bir takımın işbirliğini geliştirdiği önemli bir etkinliktir. Çevik manifestoya sadık geliştiriciler girişimcilerle günlük olarak çalışırsa, bu iki grup arasındaki işbirliğinin ne ölçüde geliştirilmesi gerektiği sorusu ortaya çıkıyor. Geriye dönük olarak değil çünkü Scrum takımına ayrılmıştır.
Scrum takımının tanımını göz ardı edip, ürün üzerinde birlikte çalışan tüm insanlardan oluşan takımı kastediyorsanız, iş adamlarının da retrospektifte yer aldığı sonucu çıkar.
Belki bu ekibin anlaşılmasıyla grup çok büyük olacaktır. Dolayısıyla benim görüşüme göre, Scrum takımıyla retro yapmak ve daha büyük bir katılımcı grubuyla takımlar arası retro yapmakta yanlış bir şey yok. İlginç bir şekilde, bu anlayışla tek takımlı Scrum diye bir şey olmazdı.
Bu geliştiriciler için ne anlama geliyor?
Bazı geliştiriciler için bunun en önemli sonucu ürün sahibinin arkasına saklanamamaktır. Özellikle geliştiricilerin ürün sahibini “dışa dönük” bir arayüz olarak gördüklerinde saklandıklarını gözlemledim. Burada sunulan anlayışla “dışarıdakiler”, geliştiricilerin çalıştığı ekibin bir parçasıdır; ancak bu durumda ürün sahibinin devralabileceği bir arayüz işlevi yoktur.
Sonuçlar çok geniş kapsamlı ve ben bunun bir sonucu olduğuna inanıyorum: Çeviklik gelişti.
Scrum Rehberinin Scrum Master'ın silo zihniyetiyle mücadele etmesi gerektiğini çok açık bir şekilde ifade ettiğine itiraz eden herkes haklıdır. Kelimenin tam anlamıyla “Paydaşlar ve Scrum Takımları arasındaki engelleri kaldırın” diyor. Ancak aynı zamanda retrospektifin bir Scrum Takımı etkinliği olduğunu da söylüyor. İşin içinde yabancı yok. Ben buna engel derim.
Ayrıca bu blog Scrum Master'lara değil, yazılım geliştiricilere yöneliktir. Onların girdisi olmadan çeviklik işe yaramaz ve bunun yerine geliştiricilerin yalnızca silolarına dışarıdan beslenen biletleri işlediği bir özellik fabrikasına yol açar.
İşte bu yüzden özellik fabrikasından kaçmak isteyen yazılım geliştiricilere, iş adamlarını ve diğer paydaşları ekiplerinin bir parçası olarak görmelerini ve onlara bu şekilde davranmalarını öneriyorum.
MERHABA. Stephen
(kendim)
Haberin Sonu
Duyuru
(Resim:
Stefan Mintert
)
Stefan Mintert, yazılım geliştirmede şirket kültürünü geliştirmek için müşterileriyle birlikte çalışıyor. Şu anda liderlikte en büyük potansiyeli görüyor; hiyerarşik seviyeden bağımsız olarak Bazı yön değişiklikleriyle bir kariyer yolunun ardından bu potansiyelden yararlanmayı kendine görev edindi. Birkaç yıllık danışmanlık deneyimine sahip bir BT geçmişinden gelen, başlangıçta kendi yazılım geliştirme şirketini kurdu. Liderliğin öğrenilmesi gerektiğini ve iyi rol modellerinin nadir olduğunu buldu. Müşterilerinin yazılım geliştirmede en büyük desteğe ihtiyacının kod üretiminde değil liderlik olduğu ortaya çıktı. Dolayısıyla Kutura şirketinin nereye doğru gittiği onun için açıktı: ürünleri geliştiren insanların gelişip büyüyebilmesi için liderliği geliştirmek. Stefan, 1994'ten bu yana iX'te uzun süredir serbest çalışan olarak Haberler için yazıyor.
Bugün aslında hangi kişilerin veya rollerin bir takıma ait olduğunu yazmak istiyorum.
Scrum Kılavuzuna göre bir Scrum takımı şu kişilerden oluşur:
- Ürün sahibi
- Scrum Master e
- Geliştiriciler
Bana göre bu iki nokta uyumlu değil. Takım tanımının Scrum tasarımında bir kusur olduğunu düşünüyorum. Nasıl olur?
Her işbirliğinde bazen sürtüşme veya çatışma ortaya çıkar. Birlikte çalışan insanların daha da gelişmesinin bir kısmı da sürtüşmeleri ve çatışmaları yönetmeyi öğrenmeleridir.
Scrum'da retrospektif, bir takımın işbirliğini geliştirdiği önemli bir etkinliktir. Çevik manifestoya sadık geliştiriciler girişimcilerle günlük olarak çalışırsa, bu iki grup arasındaki işbirliğinin ne ölçüde geliştirilmesi gerektiği sorusu ortaya çıkıyor. Geriye dönük olarak değil çünkü Scrum takımına ayrılmıştır.
Scrum takımının tanımını göz ardı edip, ürün üzerinde birlikte çalışan tüm insanlardan oluşan takımı kastediyorsanız, iş adamlarının da retrospektifte yer aldığı sonucu çıkar.
Belki bu ekibin anlaşılmasıyla grup çok büyük olacaktır. Dolayısıyla benim görüşüme göre, Scrum takımıyla retro yapmak ve daha büyük bir katılımcı grubuyla takımlar arası retro yapmakta yanlış bir şey yok. İlginç bir şekilde, bu anlayışla tek takımlı Scrum diye bir şey olmazdı.
Bu geliştiriciler için ne anlama geliyor?
Bazı geliştiriciler için bunun en önemli sonucu ürün sahibinin arkasına saklanamamaktır. Özellikle geliştiricilerin ürün sahibini “dışa dönük” bir arayüz olarak gördüklerinde saklandıklarını gözlemledim. Burada sunulan anlayışla “dışarıdakiler”, geliştiricilerin çalıştığı ekibin bir parçasıdır; ancak bu durumda ürün sahibinin devralabileceği bir arayüz işlevi yoktur.
Sonuçlar çok geniş kapsamlı ve ben bunun bir sonucu olduğuna inanıyorum: Çeviklik gelişti.
Scrum Rehberinin Scrum Master'ın silo zihniyetiyle mücadele etmesi gerektiğini çok açık bir şekilde ifade ettiğine itiraz eden herkes haklıdır. Kelimenin tam anlamıyla “Paydaşlar ve Scrum Takımları arasındaki engelleri kaldırın” diyor. Ancak aynı zamanda retrospektifin bir Scrum Takımı etkinliği olduğunu da söylüyor. İşin içinde yabancı yok. Ben buna engel derim.
Ayrıca bu blog Scrum Master'lara değil, yazılım geliştiricilere yöneliktir. Onların girdisi olmadan çeviklik işe yaramaz ve bunun yerine geliştiricilerin yalnızca silolarına dışarıdan beslenen biletleri işlediği bir özellik fabrikasına yol açar.
İşte bu yüzden özellik fabrikasından kaçmak isteyen yazılım geliştiricilere, iş adamlarını ve diğer paydaşları ekiplerinin bir parçası olarak görmelerini ve onlara bu şekilde davranmalarını öneriyorum.
MERHABA. Stephen
(kendim)
Haberin Sonu