Bir verimsel scrum ekibi ile nasıl başa çıkabilirim?

Backstory:
Son üç yıldır bu ekibin bir parçası olarak çalışıyorum ve bu süre zarfında, her şeyi farklı şekilde yöneten üç farklı Scrum Master'ımız vardı.

Scrum Masters'daki bu değişiklik ve gösteriyi yürütme biçimleri nedeniyle, ekibim uyuşmazlığı bıraktı çünkü ilkeler tutarlı bir şekilde uygulanmadı ve Scrum Masters'dan biri çevikliğe inanmayan bir insandı. gelişimi ve sadece tutulan olayları ve eserleri şirket kararlarına uymak için acemi olarak tuttu.

Şimdi Scrum etkinlikleri yaptığımız zaman ekip üyelerim rahatsız ve sıkılıyor ve bu konuda özellikle bir kişi çok sözlü.

Şimdiki:
İki ay önce şirket, çalışma çevikliğine ve ilkelerine olan bağlılığım nedeniyle beni takımımın Scrum Ustası'na atadı.

Takım üyelerimin Scrum'a isteksiz olmalarının atmosferik baskısı altında çok acı çekiyorum.

Daha önce de belirtildiği gibi, benim için çok zorlaştıran tüm süreç hakkında endişeleniyorlar çünkü Planlama, Retrospektif ve Günlük Scrum'ı etkin hale getirmek için gereken gerekli konuşmaları yapmıyorlar.

Onlara göre, Planlama sadece zaman kaybıdır, çünkü biz sadece yeni Sprint'e taşınıyoruz ve işi zaten tamamlamıyoruz, neden rahatsız ediyor.

Retrospektif sırasında sadece "Scrum yapmayı bırak" demek istediklerini hissedebiliyorum. Bir kişi var, ama diğerleri sessiz ve bununla her zaman başa çıkmak zorundayım.

Günlük Scrum yine onlar için bir zaman kaybı çünkü hiçbiri günü konuşmayı ve planlamayı zorlaştırmıyor. Sadece "Dün X görevinde çalıştım ve bugün tekrar üzerinde çalışacağım" diyorlar. Ve çoğu zaman sertleşene kadar şakalaşıyorlar.

Bu olaylar sırasında zamanlarını nasıl harcadıklarına gelince çok büyüdüm. Ama ben içimde ölüyorum çünkü buna tutkum var ve artık umursamıyorlar.

Bugün bana her zaman karşı olan kişi bana "Bu Sprint için yaptıklarını söylediler" demekten vazgeçmemi söyledi çünkü onun sözleriyle, "Bir Sprint'i asla tamamlamıyoruz. Sonraki Sprint kotayı doldurmak için. Gerçekte KanBan yapıyoruz. Öyleyse şunu söylemeyi kes. "

Neden bunu söylediğini anlıyorum, ama onun ve takımdaki herkesin umrunda olmadığı için bunun böyle olduğunu anlamıyor gibi görünüyor. Sadece engellerle uğraşmak yerine iş yapıyorlar. Engeller hakkında şikayet ediyorlar, ancak onlar hakkında hiçbir şey yapma. Ve yardım etmeye çalıştığım zaman silkiyorlar.

Lanet olsunlardı, ama son iki yılda istekli olmaları az ya da çok kayaların dibine inmeye başladı.

Bu toplantılar sırasında şaka yapıp vakit kaybetmenin şirkete çok para kazandırdığını nasıl görebilirim?

Başarısız yazılım projeleri hakkında çok fazla istatistik duymuş olabilirsiniz ve hatanın teknik nitelikte olmadığı sonucuna varmış olabilirsiniz. Teknolojik problemler yüzlerce teknik çözümle çözülebilir, ancak işyeri atmosferinizdeki sorunları Scrum kullanarak çözmek işe yaramaz.

Buradaki önerim, buna teknik bir konu olarak bakmaktan tamamen vazgeçmektir. Bu Scrum ile ilgili değil, günlük standuplar, sprintler, retrospektifler veya bunun gibi bir şeyle ilgili değil. Ekibinizle temasa geçmeniz ve kendiniz ve üstlerinizin yanı sıra onları tatmin eden etkili bir çalışma yöntemi bulmanız gerekir.

Günlük işlerin kötü bir fikir olduğunu düşünüyorlarsa, günlük iş yapmalarını söylememelisiniz ve nedenlerini kendilerine atmaya çalışmamalısınız. Günlüklerin size sunduğu şeyleri kendiniz için düşünün. Takımınıza bu avantajlara değer verip vermediklerini kontrol edin. Anlayışınızı neden paylaşmadıklarını öğrenin - bakış açılarını anlamada olduğu gibi, onları hiçbir şeye ikna etmediğiniz gibi. Daha sonra günlüklerin ekibinize gerçekten yardım edip etmediğini veya başka bir mekanizma ile daha fazlasını başarabileceğinizi kontrol edin. Scrum ustaları ile ilgili komik olan şey, ekiplerine hizmet eden insanlar olmalarıdır - Scrum'u tamamen kaldırarak onlara en iyi şekilde hizmet edebilirsiniz.

Özetle, Scrum'a odaklanmayı bırakın ve bunun yerine çevikliğin temellerine geri dönün. En baştan çevik manifesto ile başlamak isteyebilirsiniz : Bireylere ve süreçler ve araçlar üzerindeki etkileşimlere değer verin.

Tecrübelerime göre, hayal kırıklığına uğramış ekiplerin etkili retrospektiflere sahip olmaları gerekir. Bu nedenle, bana göre retrospektifler çevik bir sürecin tek zorunlu kısmı. Geriye kalan her şey geriye dönük olarak değişebilir.

Etkili retrospektiflerde, yalnızca sorunlarınızdan şikayetçi değilsiniz, bu sorunlardan en az birini seçip olası çözümleri belirlersiniz, sonra bir sonraki yinelemede bu çözümü deneyin. Bir sonraki retrospektifte, bu çözümün nasıl çalıştığı veya işe yaramadığı hakkında konuşuyorsunuz, gerekirse daha fazla ayarlama yapıyorsunuz veya üzerinde çalışmak için başka bir konu seçiyorsunuz.

Ekip üyeleri süreçlerindeki gerçek değişikliği etkileme gücüne sahip olduklarını gördüklerinde, daha istekli olmaya başlarlar.

Geçmişe dönük süreç, çevikliği iyi olan bir şirketteki tüm takımları ziyaret ederseniz, hepsinin biraz farklı şekilde yapmasıdır. Kanban, bazılarında XP, bazılarında ise sadece Pazartesi Çarşamba, standup yapan takımlarımız var.

Ekibiniz akşamdan kalmalarla nasıl başa çıkacağınızı sevmiyorsa, farklı yaklaşımlar hakkında beyin fırtınası yapın. Çok isteksiz geliştiriciler kazandım, ancak geriye dönük olarak sürekli dinleyerek ve çözümler deneyerek kazandım .

Tamam, pürüzlü başlayalım - sorunun büyük kısmı seninle - Duydun, ama dinlemiyorsun. Ekibiniz size sorunların ne olduğunu açıkça söylüyor. Takımını suçlamak yerine onlara hitap etmelisin.

Planlama

Onlara göre, Planlama sadece zaman kaybıdır, çünkü biz sadece yeni Sprint'e taşınıyoruz ve işi zaten tamamlamıyoruz, neden rahatsız ediyor.

Kesinlikle. Görevlere sürekli olarak doğru zaman ayıramazsanız ve tutarlı bir şekilde hafife alınırsa, bunun çok olumsuz etkileri olur:

• Geliştiriciler sürekli baskı altında olduklarını hissediyorlar.
• "Zamanında hiçbir şey yapamam".
• İşlem işe yaramadığından haklı olarak bunu zaman kaybı olarak görüyorlar.

Çözüm : Tahminlerinizi aşağıdakileri kullanarak düzeltin:

• Öykü Puanları (Zaman ve Riskin bir birleşimi olarak).
• Görevlerin> 55 SP
• Karşılaştırmalı Tahminler
• Kanıta Dayalı Planlama

Bunun için bir üs olarak, kesinlikle bu zaman tam gereken aslında önceki görevleri bitirmek için aldı bu test, yazı belgeleri, yazma testleri, son kullanıcı eğitimi, entegrasyon çabalarını, dağıtım içerir. vb.

Belirli bir görev için toplam süreniz olduğunda, beklenen süreyi önceki görevlere dayandırabilirsiniz.

Her üyeye, kendisine verilen görevin, önceki görevlerin seçiminden daha karmaşık veya kolay olduğunu hissetmediğini sorun, buna göre ayrılmış görevlerin sayısını ayarlayın.

Daha önce SP kullanmadıysanız, tavsiyem, kılavuz olarak 5SP = Tanrı işine dürüst olmak gerekirse = 5SP. Her zamanki geliştirme ortamında, günde belki 6 tane olabileceğini, bu yüzden de maksimum 30SP olduğunu unutmayın . Asla 2 günden uzun süren bir göreve tahtaya binme izni vermeyin. İdeal olarak, benim deneyimlerime göre günde 2 işin olmalı.

Doğru planlama yapmazsanız, Scrum faaliyetlerinizin geri kalanı zaman kaybı gibi görünecektir (Planlama dahil).

geçmişe yönelik

Retrospektif sırasında sadece "Scrum yapmayı bırak" demek istediklerini hissedebiliyorum. Bir kişi var, ama diğerleri sessiz ve bununla her zaman başa çıkmak zorundayım.

Bana Daily beatings will continue until morale improves!geçmişteki işleri ve ikisini hatırlatıyor . Eğer engelleri kaldırmazsanız, bunun zaman kaybı olduğu doğrudur.

Yine, insanların gerçekte söylediklerini dinleyin. Geçmişe dönük olarak ortaya çıkan şikayetler ele alınmıyorsa, neden bunları hiç rahatsız etmiyorsunuz?

Yani:

• İletişimi geliştirmek için Altı Düşünce Şapkası tekniğini düşünün.
• Retrospektifte harcanan zamanı en fazla 30 dakika azaltın.
• Retrospektif sırasında ortaya çıkan şikayetlerin bir sonrakinden önce ele alındığından emin olun.

Günlük SCRUM'lar

Günlük Scrum yine onlar için bir zaman kaybı çünkü hiçbiri günü konuşmayı ve planlamayı zorlaştırmıyor. Sadece "Dün X görevinde çalıştım ve bugün tekrar üzerinde çalışacağım" diyorlar. Ve çoğu zaman sertleşene kadar şakalaşıyorlar.

Burada iki sorunun var gibi geliyor: SCRUM toplantıları çok uzun ve planlama ve görev oluşturma berbat.

Her ikisi de bir scrum toplantısı gibi ses çıkarabilir zaman kaybıdır.

SCRUM uzunluğu için:

• En fazla 15 dakika deneyin.
• Ayağa kalkmayı dene.
• Sabit formül:
  • Dün ne yaptın?
  • Bugün ne planlıyorsun?
  • Ekip üyelerinin (siz değil!) Görev hakkında bilmeleri gerekenler, onları nasıl etkileyeceği.
• Onları ele almayacaksanız engellerle uğraşmayın.

Bu, planlamanızın durumunuzu olumsuz etkilediğinin ikinci bir kanıtıdır - eğer rapor edecek özel bir şeyiniz yoksa, bu genellikle işin çok büyük olduğu ve söyleyebileceğiniz tek şey oldu: üzerinde çalışıyordum.

• Görevleri kurşun noktalarına ayırın.
• Görevlerin bir günden az sürecek kadar küçük olduğundan emin olun. İdeal olarak, IMO, görev ~ 3 saat sürmeli ve yaklaşık 13 SP'ye eşit olmalıdır, bu nedenle çoğu durumda günde 2 yapabilirsiniz.

Takımla başa çıkmak

Bugün bana her zaman karşı olan kişi bana "Bu Sprint için yaptıklarını söylediler" demekten vazgeçmemi söyledi çünkü onun sözleriyle, "Bir Sprint'i asla tamamlamıyoruz. Sonraki Sprint kotayı doldurmak için. Gerçekte KanBan yapıyoruz. Öyleyse şunu söylemeyi kes. "

O haklı. Hatalısınız. Kanban'da bastarize SCRUM ve / veya varyasyon yapıyorsunuz. Onların suçu değil.

Neden bunu söylediğini anlıyorum, ama onun ve takımdaki herkesin umrunda olmadığı için bunun böyle olduğunu anlamıyor gibi görünüyor.

Anladığını hiç sanmıyorum. Eskiden olduğundan daha az umursayabilirler, ancak onları suçlamak yalnızca bir şeyi iyileştirmekle kalmaz, bir durumu daha da kötüleştirir. Kaya dibi olsaydı, aslında kazmaya başlayabilirlerdi.

Sadece engellerle uğraşmak yerine iş yapıyorlar.

Ve burada iş yapmanın işlerinin neyle ilgili olduğunu düşündüm. Kimin engeller ile başa çıkması gerektiğini merak ediyorum .... oh doğru. Bir Scrum Ustası. Bu senin işin. Size neyin yanlış olduğunu söylüyorlar. Düzelt. Diğer yoldan değil.

Muhtemelen bu yüzden Retrospektifte bu kadar probleminiz var.

Bu toplantılar sırasında şaka yapmanın ve etrafa sarsılmanın şirkete çok para getirdiğini nasıl görebilirim?

İşe yaramaz toplantıları durdurun, bunun yerine su soğutucusu etrafında şaka yapacaklar. Ayrıca moral iyileştirme dayak ile ilgili paragrafa bakın. Eğer mizahı savunma mekanizması olarak kullanıyorlarsa, bazı ciddi problemleriniz var efendim!

Şakaya atıl - ekibinle olduğu gibi, buna karşı değil. (Fuuuuuuck şirketin parasını kim umursar? Şu anda bir hissedar mısınız?)

Özetlemek

Kötü planlamanız SCRUM'un diğer bölümlerini başarısız kılıyor ve katılan herkes perişan oluyor. Hiçbir şeyin değişmediğini, hiçbir şeyin ele alınmadığını ve şikayetlerinin duyulmadığını görüyorlar.

Planlamanızı geliştirin; akışı ve morali iyileştirin.

İşinizi engelleri kaldırarak yapın ve ekibiniz daha hızlı ilerler. Onlara yardım etmek için ne yapmaları gerektiğini düşündüklerini sorun .

En önemlisi: İnsanlarını dinle. Size (ve bana) sorunun ne olduğunu zaten söylediler.

İyi şanslar!

Başlıca çevik prensiplerden biri geri dönüp yanlış olanı düzeltmektir. Bu sadece kod yeniden düzenleme ve hata düzeltmelerini içermez, aynı zamanda geliştirme sürecini de düzeltir.

Öyleyse neden ekibinizle bir toplantı yapmıyorsunuz ve gelişim sürecini nasıl iyileştirebileceğinizi görüyorsunuz? Bu demektir ki, hiçbir scrum veya standup toplantıları, o zaman olsun.

Ayrıca çevik manifestodaki ilkelerden birini çiğniyorsunuz : "Bireyler ve süreçler ve araçlar üzerindeki etkileşimler".

Öte yandan, eğer ekibiniz yinelemeli gelişimin kötü olduğunu düşünüyorsa, belki de yanlış yapıyorsunuz demektir. Bir yineleme için planladığınız her şeyi bitirmemeniz önemli değil - her zaman bir sonraki yinelemeye taşıyabilirsiniz. Bu nedenle “şeyleri içermek zorunda”, “sahip olmak güzel”, vb. Gibi şeyleri işaretlemenizin nedeni de budur.

Sadece küçük bir rant: önceki ve şu anki şirketimde yaptık ve hala standup toplantılar gerçekleştirdik. Tecrübelerime göre, onlar büyük zaman kaybı, çünkü her zaman 30+ dakika statü raporu toplantılarına dönüyorlar ve bana hiçbir bilgi vermeyecek kadar az veri sağlıyorlar. İnsanlar dürüstçe umrumda değil, sorunları hakkında konuşurlar.
Önceki şirketimde akıllıydılar, bu sorunu standuplarla tanıdılar ve insanlar şikayet etmeye başladıktan hemen sonra onları durdurdular.

Eğer scrum hakkında gerçekten iyi bir video izlemek istiyorsanız, bkz. " Robert C. Martin - Scrum'ın Unuttuğu Toprak ".

Öncelikli olarak, üstlenmeye devam eden görevlere bakardım. Hedeflere ulaşmamak, son derece moral bozucu. Çok mu bağlısın? Yıkılması gereken fatloglar var mı? Kontrolünüz dışında darboğazlar var mı? "Yapılmış" olarak net bir tanımınız var mı? Gereksinimler açık mı? Geliştiricinin başına düşen saatler makul (örn. Yönetici, standuplar, planlama, retrospektifler, klavye molaları, proje dışı çalışmalar).

Ardından, çalışmayanı çıkarın. Değersiz süreç sadece bir zaman hırsızıdır. Stand-up odaklı değil ve takıma değer sağlamazsa standuplar çok fazla zaman harcayabilir. Saatler başka bir yerde daha iyi harcanabilir. Belki de çok büyükse takımı bölmeyi de düşünebilirsiniz.

Ekibi neyin moralini bozanla ilgili bir şeyler yapmaya çalışın. Retrospektifleri alın ve daha da önemlisi, çıktıya göre hareket edin. Başarısızlıklara bakmak kadar başarıları kutlamak da aynı derecede önemlidir.

Son olarak, markayı zedelemek için daha önce zarar vermiş olan scrum ustalarının yaklaşımlarını değerlendirmek isteyebilirsiniz. Bilinen veya bilmeseniz de, ortaya çıkan her sorunun iş yükünüze eklenmesinden önce toksik bir scrum ustası altında çalıştım. Sonuç: sorunlar göz ardı edildi ve herkes çok az ekip çalışmasıyla kendi küçük alanlarında çalıştı.

Takımınızın sprintinizi etkili bir şekilde kapatmasını sağlamak (en azından hikayelerin% 80'ini kapatın) sprint üzerinden sprint yapmak bence yapabileceğiniz en önemli şey. Ekibiniz sürekli olarak eksikse, tahminlerinizi ayarlamanız gerektiğinin açık bir göstergesi budur.

Ekip bu konuda açık olmalı, geliştiricilerin tahminler konusunda daha gerçekçi olmalarını sağlamak çok zor olabilir - bir yıl boyunca bir sprint kapanmayan bir takım üzerinde çalıştım (sprintin% 50'sinden daha azını kapatarak) (her zaman tahmini altında ve her planlama / retrospektifte, tahminlerinizin berbat olduğunu söyleyen yalnız bir sestim, aptalca fazla güvende oluyorsunuz, tahmin yapmanıza engel olan şey için mazeret bırakmayı bırakıp yerine gerçeği yansıtacak şekilde tahminde bulunmayı bıraktım ( belki de ondan daha diplomatik olarak ama bu temel bir duyarlılıktı.) - Bu pozisyondayken, sürecin zaman kaybı olduğunu söyleyen ekibinizdeki curmudgeon ile tamamen aynı fikirdeyim, çünkü aslında ne olursa olsun KonBon yapıyorsunuz. sen buna ne diyorsun. Belli bir noktada, görüşü şartlar tarafından onaylandı. O'

Bir noktada işleri sıfırlamak zorundasınız, ekibin sadece sistemi harekete geçirmek için tahminlerini büyük ölçüde telafi etmesini sağlamalısınız. Bir ekip tutarlı bir şekilde hikayeleri kapatmaya başladığında, Çevik sürecin temelde sağduyulu olduğunu ve bunu bir şekilde gerçekleştirememenin verimliliğiniz için zararlı olduğunu anlamalıdır. Ancak, “taahhüt” ve “sprint hedefleri” ciddiye alınmadığı sürece, bunlar tutarlı bir şekilde elde edilmediğinde olur, o zaman her şey utanç vericidir ve ekiplerin üretkenliğini yitirir.

İnsanları önemli ölçüde farklı bir sprint üzerinden satın almak (tahminler, planlama, taahhüt vb. Bakımından) zordur, o takımda sonunda iki faktörden dolayı başardım. Biri sadece JIRA'dan veri topluyordu ve "bunun için hiçbir mazeret yok, sayılar kapalı, her zaman tek bir yöne gidiyorlar, düzeltmemiz gerekiyor, retro olarak mazeretler istemiyorum" diyordum. Eklenecek rakamlar "- ve diğeri sonunda onlara anlattığım gibi yönetimde yükseklerden gelen baskıydı ..." Bu sürecin amacı, geliştirme zaman çizelgemizi öngörülebilir hale getirmektir. gayet iyi olan sprint, bundan bağımsız olarak, yönetim kurulumuzun yaptıklarımızı doğru bir şekilde yansıtması gerekiyor. Yönetim, başarımıza olan bağlılığımıza bağlılığımızın daha farkındadır; kendi iyiliğiniz için, projeksiyonun çıktısını sıraya sokmasını sağlayın, böylece her sprintin yarısını harcamak yerine işinizi tamamlarsınız. hiçbir şey yapmamak. Daha sonra kaldırılan insanlar bu zamandan itibaren, sizi daha fazla başarısız görüyorlar, retro olarak yaptığınız bahaneler kendi görüşlerinde bile bir şey değil, sadece başarısız olduklarını görüyorlar. ”

Sonunda ekibimiz çekişmeye başladı ve işler daha yumuşak ve düşük olmaya başladı ve ilerledi; süreç gerçekten çalışmaya başladıktan sonra daha yüksek verim almaya başladık. Öyleyse, dr - nispeten yüksek bir başarı derecesiyle sprint'leri kapatmaya başlamak için ne gerekiyorsa yapın. Bunu yapmazsanız, ekibinizdeki curmudgeon, Scrum'a karşı direncini sonuçlar tarafından doğrulamaya devam edecek ve sonuçta sürecinizin aslında sadece zamanların bir yalancı ve israfı olduğu doğru olacaktır.

Bir Scrum Master olarak, daha üretken olmaları için takıma koçluk yapar ve rehberlik yaparsınız. Scrum çerçevesi oraya ulaşmak için güçlü bir araçtır, ancak Scrum çerçevesi kesinlikle tek başına hedef olmamalı - aksi halde Kargo Kültü'nü yapıyorsunuz .

Görünüşe göre 3 yıldır Kargo Kültü yapıyorsun ve insanlar bunun korkunç bir proje yönetimi metodolojisi olduğunu anladılar. İyi haber şu ki, akıllı insanlarınız var, doğru anladılar. Maalesef, şirketinizdeki bazı insanlar buna Scrum diyor, ancak yine de akıllı insanlar var , hatta ekibin yaptığı işin Scrum olmadığını söylediler.

Planlama sadece zaman kaybıdır, çünkü taşmayı yeni Sprint'e taşıyoruz ve işi zaten tamamlamıyoruz, o yüzden neden rahatsız etmiyoruz.

Kesinlikle. Neden rahatsız ediyorsun? Bir cevap bulmanız gerekiyor ya da planlama ve sprintin kendisini değiştirmeniz gerekiyor, böylece planlama için bir nokta var. Öyle ya da anlamsız bir Sprint Planlama ile herkesin zamanını boşa harcama. Şirketten sizi Scrum Master eğitimine göndermesini isteyebilirsiniz, çünkü harika bir Sprint Planlaması yapmak önemsiz değildir.

Retrospektif sırasında [...] diğerleri sessizdir ve bununla her zaman başa çıkmak zorundayım.

Her Retrospektifte aynı konuyla uğraşıyorsanız, insanlar Retrospektif sırasında konuşmak için (artık?) Bile uğraşmazlar, bu sadece zaman kaybıdır. Siz veya takım bir şekilde Retrospektifte ortaya çıkan sorunları ele alamazsa, toplantı sadece ekibin moralini bozuyor. Retrospektifte ortaya konan konular ele alınmalı ve bir sonraki Retrospektifte ilerleme kaydedilmelidir.

Günlük Scrum yine onlar için bir zaman kaybı çünkü hiçbiri günü konuşmayı ve planlamayı zorlaştırmıyor. Sadece "Dün X görevinde çalıştım ve bugün tekrar üzerinde çalışacağım" diyorlar.

Aslında, sadece birkaç gün aynı görevlerde çalışıyorlarsa neden herkesin zamanını boşa harcıyorsunuz? Kesinlikle haklılar, Daily Standup gerçekten anlamsız. Standup, her biri yarım gün veya daha kısa sürede tamamlanabilecek birçok görevde yakın işbirliğini kolaylaştırır. Görevleriniz bu şekilde bozulamıyorsa (Sprint Planlamasının kırılması nedeniyle veya görevleriniz Scrum'a tam olarak uymadığından), 5 dakikalık Günlük Standup Toplantısı toplantısının bir anlamı yoktur. 5 dakikadan fazla değil, doğru mu?

“Bir Sprint'i asla tamamlamayız. Sadece kota doldurmak için bir sonraki Sprint'te görevlere devam eder ve yenilerini alırız. Gerçekte KanBan yaparız. Öyleyse şunu söylemeyi kes.”

Neden bunu söylediğini anlıyorum, ama onun ve takımdaki herkesin umrunda olmadığı için bunun böyle olduğunu anlamıyor gibi görünüyor.

Hayır, neden bunu söylediğini kesinlikle anlamıyorsun . Engelin temel sebebini - çözmeniz gereken - yanlış anladınız. Umursamıyorlar çünkü ekibin proje yönetimi uygulamaları berbat. Cargo Cult yapmayı ve Cargo Cult'u daha sert yapmayı önemsemek, var olan en kötü proje yönetimi metodolojilerinden biri olan Cargo Cult olmasını engellemez (savunmanızda: ayrıca en çok kullanılan).

Bununla ilgili ne yapabilirsin?

1. Endişelerini dinleyin. Yine, akıllı insanlara sahip olduğun için kutsanmışsın .

2. Engelleri çözmelerine yardımcı olun.

Ve işte bu, gerçekten. Takım için değerli olmalarını sağlamak için Sprint Planlama, Günlük Scrum ve Retrospektiflerin nasıl değiştirileceğini denemeniz gerekir - Scrum etiketini bırakmak isteseniz bile, yine de bu 3 toplantıyı benzer sıklıkta ve benzer amaçlarla gerçekleştiriyorsunuz. orada proje yönetimi metodolojisi. Nasıl deneyeceğinize gelince (sıklık, içerik, toplantıya ev sahipliği yapan kişi, süre, süre vb.) Şaşırtıcı derecede kolaydır: Ekibe sorun. Fikirlerinizi üzerinizde zorlamalarına izin vermeniz gereken bir şey varsa (bazılarında hemfikir olduklarını varsayarak) fikirlerinizi zorlamayın.

Eğer korkuyorsanız kontrolünü kaybedeceksiniz, önceden bazı sınırları ayarlayın, örneğin:

• Toplantıların etiketleri aynı kalır.
• Toplantılar halen devam etmektedir ve toplantıların sıklığı 2 katından daha fazla değişemez.
• Şu anda deneme yapıyorsunuz, bu nedenle herhangi bir değişiklik yalnızca 2 sprint için sürüyor, ardından eski kalıba geri dönüyorsunuz (sprint süresini iki katına çıkarmak istediğinizde belirsizliği önlemek için haftalar içinde zaman verin).

Bence herkes aynı çizgiyi Çevik Manifesto'dan alıntı yapıyor . Ben de aynısını yapacağım: "Süreçler ve araçlar üzerindeki bireyler ve etkileşimler."

SCRUM yöneticisi olarak, işi yapmak için SCRUM kullanmak istiyorsanız, bunlarla bir başkasıyla etkileşime giren bir birey olarak yaklaşmalısınız. Sürecin daha iyi hale getirilmesi için beyin fırtınasına başlayın. Belki onları SCRUM'u sevmeye ikna edebilirsin. Belki de sizi farklı bir süreç kullanmaya ikna edebilirler. Hadi bulalım!

Takımın halihazırda mevcut sistemin işi yapmadığını anladığı anlaşılıyor. Onları işi yapabileceğine inanmalarına teşvik edebilir misin? Birkaç örnekten bahsediyorsun. Sprint'i fazla dolduruyorsanız, daima sızıntı yapsın ... durun. Bu senin SCRUM ekibin. Aşırı bağlılıklarını durdurmalarına yardımcı olun. Biraz nefes almak için yönetime tekrar başla. Ne için iyi olduğunu SCRUM kullanın. Verileri yönetime, süreçlerindeki değeri kaybedecek kadar zorladıklarını göstermek için kullanın. Yönetim, SCRUM'u bir süreç olarak istiyorsa, düzeltmek için ihtiyaç duyduğunuz alanı ve enerjiyi inşa etmelerine yardımcı olun. SCRUM master olarak, işiniz takım üretken olabilmesi için problemleri çözmek.

Yararlı bir başka yaklaşım da eski içinde yeni bir süreç oluşturmak olabilir. SCRUM'u aynı işe yaramaz şekilde çalıştırmaya devam edin, ancak programın küçük bir bölümünü kordon altına alın ve "programımızın bu bölümünde araçların nasıl doğru kullanılacağını bulacağız" deyin. Orada aşırıya kaçma. Metriklerinizi kullanın. Oradaki tüm toplantılarına odaklan. “SCRUM” projenizin sadece geri kalan kısmı, siz ve ekibiniz varken yönetimi mutlu tutmak için bir kalkan olarak kalkanı oluşturuyor ”. Zamanla, bu kovaya daha fazla değerli görevlerinizi koymak isteyeceksiniz ve eski kova yavaş yavaş ölecek. Yakında, canlı bir yazılım geliştirme ortamınız var ve kimse bilge değil.

Ya da karıştırın ve eşleştirin. Anti-scrum olan bir program üzerinde çalıştım. Müşteriler, işlem sırasında herhangi bir noktada yeni görevler ekleyebilmeyi ve derhal harekete geçmemizi istedi. (Bu aslında aklı başında bir istekti: çalışmaları oldukça değişkendi ve sıklıkla hızlı desteğe ihtiyaçları vardı ... bunun için para aldık). Tabii ki, "neden sprintte söz verdiğinde X yapılmadı" meseleleriyle nasıl başa çıkacaklarını bulmak zorunda kaldık. Bizim çözümümüz aslında iki aşamalı bir süreç oluşturmaktı. Doğru önceliklendirme için uzun vadeli görevler SCRUM'a verildi. Kısa vadeli görevler, müşteri ile geliştirici arasındaki sıkı etkileşime odaklanan, evsiz bir sürece konuldu. Müşterilerimizin bu kısa vadeli süreci kullanarak bizi itmeye davet ettikleri anlaşıldı, ancak bunun Sprint'e itildiğini anladılar ' Zaman çizelgesi ve aynı anda duydukları ve neden oldukları zamanlama konularına değinmeden istek eklemeleri yasaklandı. Sonuç? İşe yaradı. Çoğu görev, olması gerektiği gibi SCRUM sürecine dahil edildi ve acil durumlar onlarla sorunsuz bir şekilde etkileşime girdi. Tutum, "Müşteri olmak istiyorsanız, bir SCRUM hikayesi için sıraya girin. Eğer bir ortak olmak istiyorsanız, gelip bizimle çalışmaktan çekinmeyin ve bu ürünün çalışmasını sağlayın. !"

Bunu söylüyorum çünkü gerçekten biliyorum. Üst yönetimde aşırı planlama, öncelikleri belirleyememe ve daha fazla öğe eklemeye istekli olmak, ancak çıkış tarihlerini geri itmek konusunda istekli olmamanızda bir sorun var.

Bu şekilde işleyebilecek bir metodoloji olmadığını söylerdim, ama şimdi Kanban'ı gördüm, bunu söyleyebilirim, ama sadece Kanban'ın ilgilenmesi gerekmediği için. Aşırı tamamlandığında çalışmaya devam eder. Daha hızlı sonuç getirmeyecek ancak sıralardaki yedeklemenin herhangi bir bireye atılmasına izin verilmiyor ve bu nedenle yönetim sorunu yönetime aittir. Geri bildirim raporları aşırı yükü gösteriyor ki bu doğru.

Scrum Masters'taki bu değişiklik ve gösteriyi yönetme biçimleri nedeniyle

Oh, bu senin problemin olabilir. Bir Scrum ustası gösteri yapmak için orada değil, proje lideri değil. Tüm paydaşların iletişimde olduğundan ve operasyonun şeffaf olduğundan emin olmak için orada.

Takımın nereden geldiğini merak ediyorum. Onlara Scrum (kaçınılmaz Scrum ustası dahil) düşürülmeden önce az çok özerk olabilirler mi? Scrum neden ilk olarak tanıtıldı? Neyi çözmesi gerekiyordu?

Scrum'ın rehberlik etmesi gerekiyor ve ekibiniz bunu hiçbir şekilde yararlı bulmadıklarını açıkça ortaya koyuyor. Rehberlik umursamıyorlar, uygunsuz bir zaman kaybı olduğunu düşünüyorlar. Görünüşe göre en az bir karar verici yine de yönlendirilmeleri gerektiğini düşünüyor. Kim? Neden? Bir noktaları var mı?

Bu, yazılımla sınırlı olmayan bir sorundur.

Herhangi bir çalışma ortamında, farklı kişilikleri ve yetenekleri olan farklı insanlar olacaktır. Scrum mükemmel bir yöntem olsa bile, kişilikleri ve yetenekleri nedeniyle buna karşı insanlar olacaktır.

Geliştiriciler zor işleri rasyonel bir şekilde gerçekleştirir. Bunu yapabilmek için, her geliştirici Scrum gibi şeylere isteksizlik gibi görünen şeyleri ele alma yoluna sahip olacaktır. Eğer tüm geliştiriciler tamamen aynı şekilde sıfırdan eğitildiyse, bir modeli kullanmak çok daha kolay olabilir, ancak geliştirici tarafında veya yönetim tarafında adapte olmak gerekir.

Ek olarak, bağımsız düşünürler (geliştiriciler ve diğer uzmanlar) çoğu zaman işlerin nasıl yapıldığını söylemekten hoşlanmazlar çünkü bu onların işidir ve çatışmaların gerçekleşmesi kolaydır. Scrum, genellikle eldeki her bir konuya göre analiz edip davranan mantıklı bir düşünür için anlamsız bir ritüel gibi görünebilir.

Aşağıdaki problemin nerede olduğunu değil, nerede olduğunu gösteriyor gibi görünmektedir. Bundan kesinlikle daha fazlası var. Yalnızca geliştiricilerin denediklerini ancak önlendiklerini (deneyimsiz) varsayabilirim. Geliştiricilerin bir şeyi düzeltmek istediği ancak sistematik bir şey (yönetim, şirket politikası, vb.) İmkansız hale getirdiği için vazgeçmeleri için birçok kez gördüm. Gerçekten umursamıyorlar mı yoksa sadece yardımcı olamayacağına inandıkları bir şeyi yapmayı umursamıyorlar mı (muhtemelen deneyimsiz).

Neden bunu söylediğini anlıyorum, ama onun ve takımdaki herkesin umrunda olmadığı için bunun böyle olduğunu anlamıyor gibi görünüyor. Sadece engellerle uğraşmak yerine iş yapıyorlar. Engeller hakkında şikayet ediyorlar, ancak onlar hakkında hiçbir şey yapma. Ve yardım etmeye çalıştığım zaman silkiyorlar.

Lanet olsunlardı, ama son iki yılda istekli olmaları az ya da çok kayaların dibine inmeye başladı.

Bu toplantılar sırasında şaka yapmanın ve etrafa sarsılmanın şirkete çok para getirdiğini nasıl görebilirim?

Bir şey diğer insanlara zorlanıyorsa, bu yöntemi onları faydalara ikna etmeye zorlayan insanlara kalmıştır. Her ne kadar, insanları bir şeyler yapmaya zorlamadığına inanmıyorum, ancak herhangi bir durumda olduğu gibi herkesi dinliyor ve mevcut ortam için çalışan bir yöntem geliştiriyorum.

Scrum, zayıf yönleri olmadan değildir. Elbette kendim için konuşabilirim, ancak geliştiricilerin iyi bir sebepten nefret ettiğini düşünüyorum . Dürüst olmam, denenmemesi gerektiği kanısındayım .

Nedenini anlamak için, her scrum ustasının scrum hakkında ne bilmesi gerektiğini okuyun . Benim tarafımdan yazılmadı, ama benim her şey benim tecrübelerimi temsil ediyor, ki bunlar sadece dehşet olarak özetleyebiliyorum .

Benim durumumda, özellikle 5. maddeden muzdarip oldum. Temel olarak, scrum bana bir çocuk ve bir kaybeden olarak davrandı. Şimdi, meslektaşlarıma yardım eden becerikli bir ortak geliştiriciyim… ne tercih edeceğime şaşmamalı!

Şimdi etrafta dolanan ve insanlarla konuşan yeni bir patronum var ve bunun için çok müteşekkirim ! Bunun işe yaramasının bir nedeni de, geliştiriciler arası iletişim için bir sohbet odamızın (en önemlisi kullanıyoruz) olmasıdır. Herhangi birinin bir gündemi varsa, oraya götürürüz. Toplantılar, yalnızca geçici geliştirici tartışmaları içindir, kendilerine yapay günlük son tarihler getirmek için değildir.

Çok fazla mükemmel cevap aldın. İşte size yardımcı olabilecek birkaç nokta daha:

Değişen Metodoloji Zor

Bir çalışma alanında çok büyük bir zorluk, çünkü “bu şekilde işler yapıyoruz” eylemsizliği altında ve son başvuru tarihlerinin ve iş gereksinimlerinin baskısına karşı çalışıyorsunuz.

Takımınızın planlama için daha fazla zaman harcamak zorunda kaldığı sonucuna varmak oldukça doğru ; bu planlama şu anda vaktinizin iyi olmadığı ve iyileştirilmesi gereken bir şey. Sorun şu ki, yeni kurallar dikte ederek oraya ulaşamazsınız. Yeni kurallar büyük bir yardım olmadan önce yeni bir yük. Ve derhal büyük bir değer sağlamazlarsa , işbirliği yapmaktan kaçınacaksınız.

Bu konuda Roy Osherove'yi tavsiye ederim. Şirketinizde değişimi nasıl planlayacağınız ve etkileyeceğinizin kısa bir özeti var ve bu videoda konuya daha derinlemesine bakıyor .

Osherove'nin temel gözlemi aşağıdaki tüm zorlukların aşılması gerektiğidir:

Kişisel Motivasyon: Neden kimse belirli bir şekilde davranmaya dikkat etmelidir?
Kişisel Yetenek: Kelimenin tam anlamıyla yapabilirler mi?
Sosyal Motivasyon: Bu davranış için akran baskısı var mı?
Sosyal Yetenek: Etrafımdaki insanlar benim davranışlarımı destekliyor ve yardıma ihtiyacım olduğunda bana yardım ediyor mu?
Yapısal Motivasyon: İyi \ kötü davranış için ödüller \ cezalar var mı?
Yapısal Yetenek: Fiziksel çevre bu davranışı destekliyor mu?

Görevleri Kırmayı Öğrenmeniz Gerekiyor

Ekibiniz "Dün X görevinde çalıştım ve bugün tekrar çalışacağım" diye düşünüyor ve görevlerin bir hafta geri çekilmeye devam etmesi anlamında haklı görünüyorlar.

Burada gerçekten yardımcı olan, görevleri nasıl küçük parçalara ayıracağınızı öğrenmek. Aradığın şey, "Tamam, X görevinde çalışıyorsun, ama bugün özellikle X görevinde ne iş üstünde çalışıyorsun ?" Sorusunun cevabı.

Bazı cevaplar şunlar olabilir:

• Bu eski miras sınıfını öğreniyorum.
• Belirtileri olan bir hatayı düzeltiyorum (BELİRTİLER).
  • Bu biraz zaman alan bazı hatalar varsa: "Bugün deneyeceğim şey ... (PLAN)"
• Bu arayüzü değiştirmem gerekiyor.
• Testler yazıyorum.
• Ben denenmemiş kodu entegre ediyorum.

... ve benzerleri. Bir günde veya bir hafta içinde gerçekten neler yapabileceğinizi gözlemleyebilmek, Çevik'in en büyük yararlarından biridir. Ancak bu, aslında ne zaman Hazır Olsa Hazır olacak bazı yekpare Görev X'e değil, bireysel günlerin çözünürlüğüne bakmanız gerektiği anlamına gelir.

Tamamlandı, Teslim Edildi

Sık karşılaşılan bir sorun (genel olarak Çevik ve işyeri planlaması ile), son tarihlerin geliştiriciden değil yönetimden gelme eğilimindedir. Bu son tarih, yapılacak fiili işten boşaltılabilir - ve özellikle, işlerin mümkün olduğunca çabuk teslim edilmesini istemek olasıdır.

Sorun şu ki, "asap teslim" çok kaotik bir süreçtir. Köşeleri kesmeyi teşvik eder; "hızlı ve kirli" kodlama; yönergeleri dikkate almamak; kendinden sonra temizlik yapmamak. "Denemek, işe yarayıp yaramadığına bakın. Evet ise teslim et. Eğer hayırsa, başka bir şeyi dene" zihniyetini cesaretlendirir ve böyle bir ifadeyle, neden kimsenin bir şeyin ne kadar süreceğini tahmin edemediğini görebilirsiniz.

Oysa ki düzenli olarak çalışıyorsanız, planlama ve test etme konusunda titizseniz, bir sürü tabela ve güvenlik ağı kurdunuz. Daha uzun sürebilir - acil teslimatı ilerletmeyen şeylere çok fazla zaman ayırıyorsunuz ve bu tür bir iş akışında henüz çok iyi değilsiniz - ama çok daha az değişken olacak.

Bu yüzden kendinize sormanız gereken bir şey var: Geliştiriciler aslında gördükleri ihtiyaç ve ihtiyaçlara göre sprint hedeflerini belirliyor mu? Yoksa, geliştiricilerin sprint benzeri bir programa taahhütlerini denemelerini ve ayırmalarını bırakarak yönetim son başvuru tarihlerini belirliyor mu?

Geliştiricilere bir şeyleri planlamak veya güvenilir bir plana göre çalışmak için zaman tanınmıyorsa, yararlı tahminler yapamayacakları şaşırtıcı değildir. :)

Bu popüler olmayan bir fikir olabilir, ancak bu konuda hiçbir şey yapamayabilirsiniz.

Yıllarca, takımın varlığı ve liderlerin akılarının, takımdan gerçekten memnun olmayan kişilerin ayrıldığını hayal edebiliyorum. Sahip olduğunuz şey, şikayette bulunabilecek ancak durumun iyileştirilmesi için çaba sarf etmekle ilgilenmeyen insan kalıntılarıdır. Sadece 8 saatlik hack kodlarını harcamak istiyorlar, kimsenin rahatsız etmemesi ve günün sonunda eve gitmesi gerekiyor. Burada sahip olduğunuz ciddi bir motivasyon sorunu gibi görünüyor. Ve bu sorunu çözmek için scrum master'ın işi değildir. Bu insanlara para ödeyenlerin sorunu.

Bu gerçekten doğruysa, o zaman sadece asıl seçenek mevcut takımdan kurtulmak ve sıfırdan başlamaktır. Belki de takımda en iyisi olduğunu düşündüğünüz bir veya iki kişiyi terk edin ve gerisini ateşleyin veya diğer ekiplere taşıyın. En azından bu olasılığı amirlerinle tartışmalısın.