Güncelleme Raporu: Basecamp'ın 'Şekillendirme' Metodolojisini Denemek

Geçen yıl ürün ekibimi klasik SCRUM yaklaşımından Basecamp'ın Shape Up metodolojisine taşımaya çalıştım. İnanılmaz bir deneyimdi; Ondan çok şey öğrendim ve bulgularımdan bazılarını sizinle paylaşacağımı düşündüm.

Eğer bunu kendiniz denediyseniz, nasıl gittiğini duymak isterim. Eğer yapmadıysanız neden uzak durduğunuzu duymak isterim.

Bölüm 1: Neden Şekillendirmelisiniz?

Ekibim ezelden beri SCRUM üzerinde çalışıyordu. Başlangıç günlerimizde klasik teknoloji döngülerini yaşıyorduk: hızlı çalışın, sevk edin ve süreçler hakkında çok fazla düşünmeyin. Daha sonra satın alındık.

Ürün metodolojisi seçeneklerimizi değerlendirmek için biraz daha zamanım olduğunda Shape Up'ı denemeye karar verdim. Birkaç nedeni vardı:

1. O zamana kadar 2 haftalık sprintler denemeye çalışıyorduk ve onları bitirme konusunda sürekli olarak başarısız oluyorduk. Her hafta, asla bitiremeyeceğimiz biletlerin taşıma bandı gibi geliyordu.

   
   

2. Ekip kendini kod maymunları gibi hissetti. Bilet seç. İş bileti. Bileti teslim et.

   
   

3. Sprint'i hiç bitirmediğimiz için görevler her zaman bir sonrakine aktarılırdı. Sonunda baraj yıkılır.

   
   

4. Hepimizin odaklanma sorunu vardı. Her sprint, tüm kod tabanı boyunca üzerinde çalışılacak şeylerin bir seçimi ve karışımıydı.

   
   

5. Çok az takım çalışması. Her geliştirici pastadan kendine düşen küçük parça üzerinde çalışacak ve birbirlerinden bir şeyler öğrenmeye ve açıkçası topluluk duygusuna çok az yer bırakacaktı.

   
   

6. Neredeyse hiç müşteri anlayışı yok. Geliştiriciler atanan biletleri alır, halleder ve neden/kim/ne hakkında hiçbir fikri olmaz.

Tekrar okuduktan sonra Basecamp'ın Şekillenmesi , bu sorunların çoğunu çözdüğünü iddia ettiği için deneyeceğimi düşündüm.

Bölüm 2: Dahili Satış Konuşması

Shape Up'a geçmenin en zor kısımlarından biri fikri şirket içinde ortaya koymaktı.

Her türlü soruya hazır olduğumdan emin olmak için Shape Up'ın konseptlerinin çoğunu içselleştirmek için ekstra zaman harcadım. Şaşırtıcı olmayan bir şekilde, geliştiriciler bu yeni yaklaşım fikrini sevdiler (daha fazla zaman, daha fazla odaklanma, daha fazla işbirliği; neden olmasınlar!).

Ayrıca hiyerarşinin daha ketum olması da şaşırtıcı değildi. Sonunda onları şu şekilde ikna etmeyi başardım:

1. Bunun sadece bir deneme olduğundan emin olmak. Eğer işler yolunda gitmezse 'normale' dönerdik.

   
   

2. Onlara yardım etmek için her zamanki gibi hazır kalacağımdan emin oldum. Geliştiriciler odaklanmış ve kesintisiz olurdu ama ben değildim.

   
   

3. Shape Up'ın vurgulanması daha büyük sorunları çözmemize olanak tanır, bu da daha büyük fırsatlar anlamına gelir.

   
   

4. Şu anda yaşanan acı ürününde ve bunun her takımı nasıl etkilediğinde ısrar etmek.

Çok net bir slayt gösterisi hazırladım ve her departman başkanını (müşteri hizmetleri, satış ve üst düzey yöneticiler) bunun üzerinden yönettim.

Bölüm 3: Korkular ve Endişeler

Kurucu, pazarlamacı ve ürün yöneticisi olarak deneyimlerim bana, bir denemeye başlamadan önce endişeleri not etmenin her zaman faydalı olduğunu öğretti. Shape Up'ta birkaç tane vardı:

• Dikkatimizi dağıtan şeylerle nasıl baş ederiz? 'Hayır' demem gerektiğini biliyorum. 'Meşguldü.' 'Bir sonraki döngüde buna bakabiliriz.' Teori bu ve eğer tüm şirket bu metodolojiye inanırsa işe yarar. İlk döngü denemem sırasında acil bir durumun ortaya çıkmasından endişelendim.

• Birikmiş işler mi? Shape Up, birikmiş işlerin olmamasını tavsiye eder (bölüm 7). Bunu henüz denediğimiz için açıkçası gidip cmd+a+birikimimizi silmedim ama yine de. Eğer bu metodolojiyi benimseseydik, birikmiş işler olmadan kendimi biraz kaybolmuş hissederdim.

• 'Neredeyse bitti.' Bu beni gerçekten korkuttu. 6 haftalık döngünün sonuna ulaşırsak ve geçici olarak orada olsak da tam olarak orada olmasak ne olur? Basecamp 'yeniden başla' diyor (eğer çok yakın değilseniz). Can sıkıcı %20-30 aralığını kaçıracağımızdan endişeliydim.

Sonuçta bu korkuların/endişelerin hiçbiri beni davaya devam etmekten alıkoyamadı. Yine de bunları akılda tutmakta yarar vardı.

Bölüm 4: Döngü

Ve biz yola çıktık!

İlk döngüye bir Pazartesi sabahı, altı haftalık yoğun odaklanma ve ekip çalışmasına bakarak başladım. İşte her hafta yaşananların özeti:

• 1. Hafta : Başlama vuruşu ve... sessizlik. Ekibi kendi haline bırakmak, araştırma yapmalarına izin vermek ve kendi zamanlarında koda dalmak bu metodolojinin önemli bir parçasıdır. İlk hafta boyunca bunu bırakıp güncelleme istememek benim için inanılmaz derecede zordu. Güçlü durdum!

• 2. Hafta : Ekip sonunda kabuğundan çıktı. İletişim sağlandı. İşin tasarımı ortaya çıkmaya başladı, biraz geri bildirimde bulunmalı ve birlikte çalışmalıyız.

• 3. Hafta : Teorik olarak 3. hafta döngü eğrisinin en üst noktası olmalıdır. Sonunda ekip, inşa edilmesi gereken şeyi nasıl inşa edecekleri konusunda çok iyi bir fikre sahip olmalıdır. İletişim düzgün bir şekilde artmaya başladıkça döngüye özel bir Slack kanalı oluşturduk. O haftanın sonunda prototipleri, tasarımları, kod parçacıklarını ve daha fazlasını gördük. Biz doğru yoldaydık!

• 4. Hafta : Tekrar sessizlik. 3. haftanın tüm gidiş-gelişleri, herkes işini uygularken odaklanmış bir 4. hafta üretti. Cuma günü 'göster ve anlat' etkinliğine başladık.

• 5. Hafta : Curveball haftası. Kapsamlardan biri oldukça fazla sohbete yol açmaya başladı. Kapsamın yeterince açık olmadığı kısa sürede anlaşıldı. Gereksinimlerimi yeterince net belirtmemiştim ve başlangıçta güzel ve basit görünen şeylerin karmaşık olduğu ortaya çıktı. Bu kapsamı daraltmak için zor bir karar vermek zorunda kaldım.

• 6. Hafta : Geriye kalan kapsamlar güzel bir şekilde ilerlemeye devam ediyordu. 6. haftada her yerde QA'lar yaptığım ve geliştiriciler geri bildirimlerimi inanılmaz hızlı bir şekilde yineledikleri için yoğunluk büyük ölçüde arttı; hepimiz hedefe ulaşmak için bir araya geliyorduk.

  
  

Sonunda hedefe ulaştık. Başardık! Çok yoğundu ve dürbünlerden birini kesmek zorunda kaldığımız için yıkılmıştım ama başardık.

Ertesi Pazartesi sabah 10'da üretime geçtik.

Bölüm 5: Birkaç Ders

Belirli bir sıraya göre değil, burada birkaç ders ve tavsiye var:

1. Şekil vermek zordur . Döngünün korkutucu kısımlarının çoğunu şekillendirerek iyi bir iş çıkardığımı düşündüm. Neredeyse tüm döngüyü raydan çıkaran bariz bir şeyi kaçırdığım ortaya çıktı.

   
   

2. Şekillendirme sırasında ekibinizi de dahil edin . Bunu çoğunlukla kendi başıma ve bazen de geliştirme ekibimin liderliğiyle şekillendirdim. Diğer geliştiricileri de dahil etmek benim için değerli olurdu.

   
   

3. Kendinizi döngünün ortasında tartışırken veya şekillendirirken bulursanız, bir şeyler ters gitti . Her şeyi durdurun. Önceliğiniz, her şeyi tamamen rayından çıkarmadan önce bu şeyi çözmek.

   
   

4. Yoğunluk eşit olarak dağılmamıştır . İster ekip üyeleri arasında ister döngü boyunca olsun, iş yoğunluğu büyük ölçüde değişecektir. Başbakan olarak bu yoğunluk alanlarını tespit etmek ve bu alanlardan geçen kişilere özel ilgi göstermek sizin görevinizdir.

   
   

5. Ayrı bir Slack kanalı oluşturun . İletişimi çok daha kolay ama aynı zamanda çok daha eğlenceli hale getirdi. Bisiklet ekibi hızla ortak bir dil, üzerinde çalıştığımız işle ilgili memler vb. geliştirdi. Temelde ekip içinde bir startup gibi hissettim.

   
   

6. Göster ve anlat toplantılarını 1. haftadan itibaren uygulayın . Bunu yapmak için çok bekledik. 1. haftanın sonundan itibaren gösterecek veya tartışacak yeterli şey olmalıdır. Bu aynı zamanda buluşma, tartışma, öğrenme vb. için de bir fırsattır.

   
   

7. Bekleme süresinin döngünün kendisinden çok daha zor olduğu ortaya çıktı . Tüm 'diğer işler' 6 hafta boyunca birikmişti; sanki SCRUM'a geri dönüyormuşum gibi hissettim. Bu hâlâ geliştirmeye çalıştığım bir şey.

Muhtemelen anlayabileceğiniz gibi, bu deneme beni sattı.

Shape Up'ı uygulamak ve tuhaflıklarını benimsemek kesinlikle bir gecede olacak bir şey değil. Bunun uzun bir öğrenme süreci olacağını düşünüyorum. Bu deneyin bize sağladığı zihniyet değişikliğini özellikle takdir ediyorum. Biz (ve umarım diğer takımlar) işin ne olduğunu görmeyi öğrendik: birlikte üstesinden geleceğimiz heyecan verici bir zorluk.

Bunu denediyseniz (veya denemediyseniz), bazı hikayeleri veya geri bildirimleri okumayı çok isterim!

Bu yazıyı beğendiyseniz, bültenimi de beğenebilirsiniz. Ürün yönetimi hakkında yazıyorum, uygulanabilir içgörüleri paylaşıyorum ve eğlence için gerçek hayattaki ürün zorluklarını üstleniyorum (biliyorum, değil mi?).