Bir Ekipte 150 Kişi Bulunabilir mi? FAST Agile Evet Diyor

FAST çevik , bir süredir öğrendiğim en ilginç organizasyonel uygulamadır. Bugün FAST Agile'ın ne olduğunu paylaşıyorum ve denemeye değer olup olmadığını araştırıyorum. TL;DR? Oldukça ilgi çekici ama yine de deneysel.

FAST Agile nedir?

1. FAST Agile, çevik bir yazılım çeşididir. FAST, çok büyük ekipler içinde kendi kendini organize etmeye odaklanır. Bu büyük takımlara Kolektif denir. Birkaç kişiden 150 kişiye kadar olabilirler [1].

Kolektif haftada iki kez toplanır. Toplantıda:

• Ekip üyeleri ne kadar ilerleme kaydettiklerini gösterir ve anlatır .
• Ürün lideri vizyonu yineler ve yönü belirler . En iyi projelerle ilgili bağlam sağlarlar. İş tamamlandıkça veya öncelikler değiştikçe yeni öncelikler ortaya koyarlar. Ve genellikle öncelikleri görsel bir şekilde, bir duvarda veya sanal bir eşdeğerde gösterirler.
• Kolektif içindeki kişiler, en öncelikli işi teslim etmek için kendi kendini organize eder ve daha küçük ekiplere ayrılır.

FAST agile'ın en ilginç kısmı bu kendi kendini organize eden ekiplerdir, o yüzden onları biraz daha ayrıntılı olarak açıklayalım.

Her toplantıda insanlar ekiplere liderlik etmek için gönüllü olur ve insanlar da bu ekiplere katılmak için gönüllü olur. Birisi bir ekibi yönetmeye gönüllü olduğunda öne çıkıp şöyle der: "[En iyi projelerden biri] üzerinde çalışacağım". İnsanlar daha sonra oluşturulan ekiplere katılarak o alanda çalışırlar. Minimum takım büyüklüğü ikidir, bu nedenle ekibi oluşturmak için insanların "ayaklarıyla oy vermeleri" gerekir.

Oluşturulan ekipler Olumsuz ürünün ortaya koyduğu öncelikler etrafında olmalıdır. Örneğin, dağıtım hattının iyileştirilmesi veya bazı kesintili hizmetlerin izlenmesinin iyileştirilmesi etrafında bir ekip oluşturulabilir.

Haftada bir saat toplantı dışında insanlar zamanlarının çoğunu kendi seçtikleri, kendi organize ettikleri ekiplerde geçiriyorlar. Teorik olarak haftada iki kez takım değiştirebilirsiniz. Ancak pratikte insanlar kiminle çalışmaktan hoşlandıklarını buluyorlar ve ekipler ilk aydan sonra yerleşmeye başlıyor.

İnsanların iş ihtiyaçları değiştikçe veya farklı alanlarda uzmanlığa ihtiyaç duyulduğunda hareket edebilecekleri kadar akışkan kalırlar. Ekiplerin taşınması beklenen ve az çaba gerektiren bir değişikliktir. Yani bu, Kolektif toplantılar sırasında, insanların kendi takımlarını yeniden oluşturduğu bir kalıp olduğu, ancak kompozisyonun hayal edebileceğiniz kadar değişmediği anlamına geliyor.

Hataların ve çağrının nasıl ele alındığı gibi birçok başka ayrıntı var. Bu konuların bir kısmını daha sonra ele alacağım. Ancak FAST Agile'ın temel özü, projeler üzerinde daha büyük bir Kolektif içinde çalışan, kendi kendini seçen ekiplerdir. Toplu toplantılar yapılandırılmıştır ve işin ihtiyaçları hakkında bağlam sağlamaya ve bu önceliklere göre ilerlemeyi aktarmaya odaklanmıştır.

Farklılıkların özeti

FAST, günümüzde çoğu çevik yazılım kuruluşunun çalışma biçiminden çok farklıdır. Benim gördüğüm farklar şöyle:

Gördüğünüz gibi FAST, günümüzde çoğu şirketin yaptığından çok farklı bir yaklaşım.

Peki takaslar nelerdir?

Gördüğüm kadarıyla bunlar FAST Agile'ın ödünleşimleri:

• FAST daha iyi organizasyonel ölçeklenebilirlik sunabilir
• FAST artımlı olarak denenebilir
• FAST daha az yeniden düzenlemeyle sonuçlanacaktır
• FAST, değişen önceliklere yanıt vermeyi kolaylaştırır
• FAST, içsel motivasyon ve elde tutma açısından daha iyi olabilir

Ancak…

• Birçok ortam FAST ile uyumlu değildir
• Öz yönetimi yönetmeniz gerekebilir
• HIZLI çok çalışma gerektirir
• FAST materyalleri jargonla doludur

Bunların her birini sırasıyla tartışacağız.

FAST daha iyi organizasyonel ölçeklenebilirlik sunabilir

Kuruluşları ölçeklendirdiğinizde bunu genellikle onları "yatay olarak" ölçeklendirerek yaparsınız. Organizasyonu birer birer ekip olarak büyütürsünüz. Bu ekiplerin her biri ürünün bir dilimine sahiptir ve çoğu zaman ürün ekiplerini daha etkili hale getiren bir platform organizasyonuna sahip olursunuz.

Kişi sayısı arttıkça organizasyonun karmaşıklığı da artar. Mühendislikte on kişiniz varsa hepsi birbiriyle iletişim kurabilir. Mühendislikteki yüz kişinin hepsi birbiriyle konuşamaz. Ve kod temeli hiçbir bireyin kafasına sığmaz. Yani bu karmaşıklığı ekiplere ayırırsınız ve her ekibin odaklanabileceği bir alan olur.

FAST ilginçtir çünkü organizasyonları “dikey” olarak ölçeklendirme girişimidir. FAST, daha fazla takım eklemek yerine Kolektifler adı verilen daha büyük takımlar oluşturmaya çalışır. Kolektifler hala koda sahiptir ancak Kolektif içindeki kendi kendini organize eden ekipler bu koda sahip değildir. Ve yine de iletişimi bölümlere ayırmanız gerekiyor. Ancak ekipler daha dinamik ve sürekli gelişiyor. Ekipleri yeniden yapılanma yoluyla yeniden şekillendirmek yerine, çalışma şeklinizin sürekli ve beklenen bir parçasıdır.

Ekip büyüklüğü birçok mühendislik başkanı için tanıdık bir konudur. Ekipler ne kadar büyük olmalı? FAST iddialarının nasıl daha iyi ölçeklendiğini anlamamıza yardımcı olması için bu konuyu biraz daha derinlemesine inceleyelim.

Ekipler ne kadar büyük olmalı?

Mühendislikten Sorumlu Başkan Yardımcısı'nın yanında zaman geçirdiğinizde, ara sıra mühendislik ekibinin büyüklüğü konusu gündeme gelecektir. Küçük takımlar için argümanlar ve büyük takımlar için argümanlar duyacaksınız. Her iki tarafın da haklı yönleri var.

Küçük ekiplerin avantajları

• Ekip içinde daha az koordinasyon ve iletişim yükü.
• Sonuç olarak hızlı hareket edebilir.
• Daha az iş akışı, odaklanmanın ve sonuç üretmenin daha kolay olmasını sağlar.
• Yönetilmesi daha kolay.

Büyük ekiplerin avantajları

• Daha düz organizasyon. 150 mühendisin yer aldığı bir mühendislik organizasyonunda 3-4 yönetici ve 10 kişilik ekipler bulunacaktır. Beş kişilik ekiplerle 6-8 direktör ve 1-2 Başkan Yardımcısı olacak. Bir organizasyondaki karışıklık nereden geliyor? Muhtemelen liderlik, yani büyük ekipler kafa karışıklığını azaltabilir.
• Daha fazla dayanıklılık. Birisi tatile çıkabilir ve ekip gayet iyi bir şekilde yoluna devam edebilir.

Yani küçük ekipler kendi ekipleri içinde harikadır, ancak daha az idealdir çünkü onlardan çok sayıda vardır ve bu da organizasyonel karmaşıklığı artırır. Daha büyük ekipler genel organizasyonel karmaşıklık açısından daha iyidir, ancak her ekibin içindeki performans açısından daha az idealdir.

Birçok liderin benimsediği yaklaşım, daha az iş akışına odaklanan büyük ekipler oluşturmaktır. Bu, dahili ekibin karmaşıklığını azaltır ve aynı zamanda organizasyonel karmaşıklığı da azaltır.

FAST'ı, gülünç derecede büyük ekipler aracılığıyla daha da büyük organizasyonel basitliğe ulaşmaya çalışan bir yaklaşım olarak görebilirsiniz. Kendi kendine toplanan küçük ekiplere sahip olmanın avantajlarından da yararlanmaya çalıştı.

Organizasyonları ölçeklendirmek zorlu bir iştir

Danışmanlık işimin büyük bir kısmı kuruluşların ölçekle başa çıkmasına yardımcı oluyor. Organizasyonların karşılaştığı ölçeklendirme zorluklarının çeşitli aşamaları vardır.

İlk bariyer tipik olarak 15-25 mühendis işaretindedir. Bu, amipinizin çok büyüdüğü ve bölünmesi gerektiği zamandır. Bu tür sorunları görüyorsunuz:

• İletişim kanalları etkisiz hale gelir.
• Mühendislik, teslimat ve/veya kalite sorunları yaşamaya başlar.
• Yöneticiler veya liderler bunalmış hissediyorlar. Daha fazla insan eklemek durumu iyileştirmek yerine daha da kötüleştirecektir.

Ve ikinci bir engel de altmış mühendis civarında. Bu noktada çok daha fazla koordinasyon sorunu görmeye başlarsınız:

• Ekipler arası projeler nadiren başarılı olur.
• Ürün çalışması platform ekiplerini batırır veya tam tersi.
• Büyük girişimleri tamamlayamama.

Zeki insanların organizasyonel karmaşıklıktaki bu adım adım değişiklikleri yönlendirmede defalarca başarısız olduklarını gördüm. Benim önsezim, karmaşıklıktaki bu adım sırası artışlarının, ek bir yönetim katmanı eklediğinizde karşılık geldiği yönündedir.

Büyüyen mühendislik organizasyonları gerçek bir beceridir. Organizasyonların ve insanların nasıl çalıştığına dair derinlemesine bir anlayış gerektirir. Şunun gibi şeyler öğrenirsiniz:

• İnsan gruplarının birlikte çalışmasını sağlayacak koordinasyon modelleri .
• Akış uyumlu ekipler ile işlevsel olarak tasarlanmış ekipler.
• İş öncelikleri değiştikçe insanları değiştireceğiniz ve kod yazacağınız yeniden düzenlemelerin nasıl yapılacağı.
• Ürünlerin, ürün yatırımıyla örtüşen teknik sorumluluk alanlarına nasıl bölüneceği.
• Ekipler etrafında iletişim kanallarının kurulması.
• Ürününüzü etkili bir şekilde desteklemek için çağrı ve güvenilirlik programlarının kurulması.
• Karmaşıklıkla mücadele etmek için platform organizasyonları ve geliştirici deneyimi girişimleri kurmak.
• Vesaire.

Bu uzmanlığa sahip kişileriniz olsa bile, yönetim ekibinizin ölçeklendirmeyle baş etmesi çok fazla çaba gerektirir. Dolayısıyla, FAST daha iyi ölçeklenebilirse, yönetim ekibinizin başka bir şeye odaklanma potansiyelinin büyük bir kısmını açığa çıkaracaksınız. Ayrıca, adım sırası değişiklikleriniz çok daha az sıklıkta gerçekleştiğinden, kuruluşunuzun yönetimini çok daha kolay hale getirme potansiyeline sahip olabilirsiniz.

FAST çevikliği etrafında bir düşünce deneyi

Ekip boyutunu ölçeklendirebileceğinizi hayal edin. Beş ya da on kişiden oluşan ekipler yerine, etkili yirmi kişilik ekipleriniz olsa nasıl olurdu? Yoksa altmış kişilik ekipler mi?

Görünüşte bu gülünç bir teklif. Bu kadar büyük takımlar etkili olmuyor. On iki kişilik ekipler bile zorlayıcıdır. Bazen yirmi veya otuz kişiye rapor veren kişilerin özgeçmişlerini görüyorum. İlk tepkim onların berbat bir şirkette çalıştıklarını düşünmek oldu. Bu kadar çok sayıda doğrudan rapora sahip olmak “organizasyonel bir koku”dur.

FAST Agile'ın temel önermesi, bu daha büyük Kolektif içerisine kendi kendini organize etmeyi ve kendi kendini seçen ekipleri eklerseniz, ekiplerinizi daha yatay olarak ölçeklendirebilmenizdir. Her takım (FAST onları Kolektif olarak adlandırır) çok daha büyük olabilir. Ve daha sonra insanların her gün birlikte çalıştığı ekipler bu Kolektifler içerisinde kendiliğinden bir araya gelir.

Eğer daha büyük Kolektifler etkili olsaydı, organizasyonel karmaşıklığı önemli ölçüde azaltırlardı. Tipik bir yazılım başlangıcı, sorumluluk alanlarına bölünmek zorunda kalmadan yıllar sürebilir. Kod tabanının her ekibin sahip olduğu alanlara titizlikle bölünmesine gerek yoktur. Bu, yöneticilerin ürüne ve ekiplere odaklanmak için kullanabileceği yönetim süresinden önemli ölçüde tasarruf sağlayacaktır.

Yani test etmemiz gereken temel şey şu: Kendi kendine toplanma ve kendi kendini organize etme, daha küçük, tasarlanmış ekipler kadar etkili bir çalışma yolu sunuyor mu?

Eğer öyleyse, organizasyonları ölçeklendirmede potansiyel olarak çok daha iyi olan organizasyonları ölçeklendirmenin bir yolunu sunacaktır. Neden bu kadar? Altı kişilik ekiplerle büyüyen bir organizasyonu, altmış kişilik "ekipler/Kolektifler" ile ölçeklenen bir organizasyonla karşılaştıralım.

Bu argümanın içine yerleştirilmiş pek çok varsayım var ve siz de bu varsayımda bazı boşluklar açabilirsiniz. Ancak bunu yapsanız bile FAST, esasen daha büyük bir organizasyon biriminin ürün ve kod tabanı alanına sahip olmasına izin verir.

FAST yeni olduğundan şu anda FAST ekiplerinin geleneksel çevik ekipler kadar etkili çalışıp çalışmadığına dair çok fazla kanıt yok. Ama bu sorunun cevabının evet olduğundan şüpheleniyorum. Buna inanmak için birkaç nedenim var. Her şeyden önce Jim Shore'un bu konudaki ilk deneyimi oldukça olumluydu ve kendisi güvendiğim biri.

FAST konusunda iyimser olmamın ikinci nedeni, kendi kendini organize eden büyük insan gruplarıyla bazı deneyimlerim olması. Ve ne kadar iyi çalıştığına şaşırdım.

Küçük şirketlerde elbette çok fazla kendi kendine örgütlenme görürsünüz. Ancak şirketler büyüdükçe her şeyi standartlaştırıyorsunuz ve ekipler dışında kendi kendini organize etmeyi ortadan kaldırıyorsunuz. Ancak parçası olduğum en ilginç deneylerden biri New Relic'teki büyük ölçekli bir öz-örgütlenme etkinliğiydi. Tüm ekiplerimizi yeniden tasarladık ve elli yazılım ekibindeki herkesten hangi ekibin parçası olmak istediklerini seçmelerini istedik. Her takımın ihtiyaç duyduğu beceriler konusunda kısıtlamalarımız vardı ve herkesin sahip olması gereken becerileri tanımlamıştık. Herkesin, hatta biz organizatörlerin bile beklediğinden çok daha başarılı oldu.

Her ne kadar jüri bu konuda görüş belirtmese de benim önsezim bu uygulamanın doğru bağlamlarda çok fazla potansiyele sahip olduğu yönünde.

FAST artımlı olarak denenebilir

FAST materyallerinde bundan bahsedilmiyor, ancak FAST ile ilgili ilginç olarak dikkatimi çeken şey, onu aşamalı olarak deneyebilmenizdir.

FAST Agile'ı bir deneme olarak bir takıma uygulayabilir ve ardından zamanla ek takımları yutacağınız bir blob yaklaşımını kullanabilirsiniz. Eğer işler yolunda giderse ilave takımları yutmaya devam edin. Olmazsa deneyi iptal edin.

FAST daha az yeniden düzenlemeyle sonuçlanacaktır

Değişim organizasyonlarda olur. Öncelikler değişiyor, insanlar ayrılıyor, ürünün alanları beklenmedik bir şekilde büyüyor. Önceki teknik kararlar sizi ısırır ve ek iş yapmanız gerekir. Yatırım gerektiren yeni fırsatlar ortaya çıkıyor.

Bütün bunların kuruluşunuzun yapısı üzerinde etkisi vardır. Her birinin kendi sahiplik alanları olan bir takım ekipleriniz var. Bu değişiklik meydana geldikçe, elinizden gelenin en iyisini yapmak için zaman içinde organizasyonunuzu yeniden düzenlersiniz. Bu yeniden düzenleme işlemleri "yeniden yapılanmalardır" ve büyüyen organizasyonlarda sıklıkla gerçekleşebilir!

FAST ile yeniden düzenlemelerin çok daha az sıklıkta olması gerekir. Yeniden düzenleme birimi o kadar büyüktür ki, bunu o kadar sık yapmanıza gerek yoktur.

Bunun potansiyel bir dezavantajı, tanımlanmış sorumluluk alanlarına sahip ekiplerinizin olmamasıdır. Dolayısıyla sorumluluğun dağılmasına ve kötü korunan ortak kodlara sahip olabilirsiniz. (Bu konuya biraz sonra değineceğiz)

FAST, değişen önceliklere yanıt vermeyi kolaylaştırır

Geleneksel olarak yapılandırılmış ekiplerde öncelikler değiştiğinde, işi yapacak ekipleriniz olur. Bu ekip yapısı yeni öncelikleri desteklemiyorsa organizasyonunuzu yeniden düzenlemeniz gerekir.

FAST için öncelikteki değişiklikler daha akıcı ve süreklidir. Sorumluluklar Kolektifin içinde olduğu sürece ekipler kendilerini iş etrafında organize ederler ve bu sanki başka bir gün gibidir.

Toplu toplantı yapısı aynı zamanda değişen öncelikleri daha az dramatik hale getiriyor. Esasen haftada iki kez yerleşik Tüm Eller'e sahipsiniz. Toplu toplantılarda sürekli olarak bağlamı paylaşabilir ve ekibinizi müşterileriniz ve pazar hakkında eğitebilirsiniz. Bu, ekibinizin daha iyi uyum içinde kalmasına yardımcı olacaktır.

Bu yaklaşımı Üç Aylık OKR'ler gibi bir şeyle karşılaştırdığımda, daha akıcı görünüyor ve insanları hizalamada daha iyi bir iş çıkaracakmış gibi görünüyor. Ürün liderinin sürekli olarak bağlamı ve öncelikleri paylaşması için kararlı bir çaba göstermesi gerekir. Ancak parçası olduğum en iyi takımların bazılarında bu şekilde hareket eden bir ürün lideri vardı, bu yüzden bunun iyi harcanmış bir zaman olduğundan şüpheleniyorum.

FAST, içsel motivasyon ve elde tutma açısından daha iyi olabilir

Pek çok ekip, süreçlerinin insanları kontrol etmeye yönelik araçlar olarak tasarlandığını hissedebilir. Ve sanki bir montaj hattında çalışıyormuş gibi hissedebilirsiniz.

FAST, kendi kendini organize etmeyi tasarımının temel bir bileşeni olarak benimser. Bu o kadar temel ki, kendi kendine örgütlenme olmadan işe yaramaz. Yönetim için tamamen farklı bir araç seti gerektirir ve çoğunlukla (tamamen olmasa da) yukarıdan aşağıya, hiyerarşik yaklaşımlarla uyumsuzdur.

Daniel Pink, içsel motivasyonun üç yönünü ünlü bir şekilde özetledi:

• Özerklik – Uyum yerine bağlılığı artıran, kendi kendini yönetme arzusu.
• Ustalık – Daha iyi becerilere sahip olma dürtüsü.
• Amaç – Anlamı olan ve önemli olan bir şeyi yapma arzusu. Amaca değer vermeden yalnızca kâra odaklanan işletmeler, kötü müşteri hizmetleri ve mutsuz çalışanlarla sonuçlanacaktır.

FAST ile işinizi kendi başınıza yönetebilir ve özerklik hissetmenize yardımcı olabilirsiniz. Becerilerinizi geliştiren, ustalık duygusuna ulaşan çalışmalara odaklanmayı seçebilirsiniz. Ayrıca, işinizin iş için önemli olan şeylerle nasıl bağlantılı olduğu size sürekli olarak hatırlatılır ve bu da bir amaç duygusu hissetmenize yardımcı olur. Bu nedenle garanti edilmese de, FAST uygulayan kuruluşların yüksek elde tutma oranları elde etme potansiyelini görüyorum.

Kendi kendine örgütlenme aynı zamanda insanlardan oluşan bir topluluğun birlikte daha iyi çalışmasını sağlayacak bazı kullanışlı sinyaller de sağlar. "Pislik yöneticisi" tipindeki kişi, davranışlarının hoş karşılanmadığına dair bir sinyal alır. Nasıl? Bir ekibe liderlik etmek için öne çıkarlar ve yapmak istedikleri işi söylerler. Eğer ekibine kimse katılmazsa iş gerçekleşmez ve ekip oluşmaz (Takımlarda en az iki veya üç kişi bulunur veya oluşmaz).

Kendi kendini organize etme aynı zamanda insanların, diğer şirketlerde dikkat çekmeyen, işin acı verici yönleriyle başa çıkmalarına da olanak tanır. Örneğin, test paketi berbatsa, birisi öne çıkıp bu sorunu çözen bir ekibe liderlik edebilir. Açıkça iş önceliği olmayan işleri yapmak son derece mantıklıdır. Ama bu ortada ve gerçekleşmesi için başkalarının da katılması gerekiyor. Bu, sanki bir özellik fabrikasındaymışsınız gibi hissetmenizi önlemeye yardımcı olabilir.

Son olarak, her gün birlikte çalıştığınız kişileri seçebiliyorsunuz. Geçmişte kendi kendini organize eden ekipleri gördüğümde bu beklenmedik bir faydaydı: İnsanlar birlikte çalışmak istedikleri insanlarla çalışmayı seçtiler. Ve bu takımlar beklediğimden çok daha güçlüydü.

Tüm bunların dengeleneceği şey, insanların FAST ile deneyimleyeceği yeni acılardır. Zorluklardan biri resmi olmayan güç dinamikleri veya potansiyel politikalarla ilgili olabilir.

Birçok ortam FAST ile uyumlu değildir

FAST çok yeni olduğundan uygulanması daha risklidir. HIZLI her durumda mantıklı olmayacaktır. Ve daha pek çok bilinmeyen var. Bunu deneysel bir yaklaşım olarak düşünmek en iyisidir.

FAST'ı denemek için en uygun ortamlar hangileridir? Peki FAST'tan nerede kaçınmalısınız?

Şirketinizin bu listedeki nitelikleri ne kadar fazlaysa, FAST'a o kadar uygun olur:

• Yönetim yeniliği ve denemelerine ilgi.
• Yüksek güven, düşük korku ortamları. Ya da en azından liderlikte komuta ve kontrolden kaçınma arzusu.
• Sürecin iyi bir rehberi veya kolaylaştırıcısı. Etkili bir Toplu toplantıyı yürütebilecek, süreci kurabilecek, değerlendirebilecek ve aktif olarak yönetebilecek biri. Örgütsel dinamikleri ve gruplar halindeki insanların birlikte nasıl çalıştığını anlayan biri. (Bunun için beni işe alabilirsin).
• Önceliklerde orta ila yüksek oranda değişim. Öncelikler değişmiyorsa HIZLI daha az kullanışlıdır.
• İşbirlikçi, kendi kendini yöneten, yüksek performanslı ve sürekli öğrenen bir ekip.
• Önceliklerini belirleyebilen bir liderlik ekibi.
• Her Toplu toplantıda öncelikler ve iş bağlamı hakkında konuşabilecek bir ürün lideriniz var. Ve etkili bir şekilde iletişim kurabilirler.

Bu özellikler ne kadar az doğruysa, FAST'ta o kadar çok ters rüzgarla karşılaşırsınız. Bunun için mükemmel bir ortamda olmanıza gerek olduğunu düşünmüyorum. Bazı açılardan, bu şeyler olmayı istemenin aslında bu şeyler olmaktan daha önemli olduğunu düşünüyorum. Belki de en önemli başarı faktörü, liderliğin buna yer açma konusunda kararlı olmasıdır.

Öz yönetimi yönetmeniz gerekebilir

Kendi kendini organize eden sistemler etkili bir şekilde çalışabilir. Ama özgür değiller. Daha çok bir topluluğu yönetmeye benziyorlar.

Doğru davranışı teşvik etmek için kısıtlamalar ve araçlar oluşturmanız gerekecektir. Ve işlerin yolunda gitmediğinden emin olmak için dikkatlice izlemeniz ve yönetmeniz gerekecek.

Herhangi bir kuruluşun kötü aktörleri veya o topluluğun çıkarlarıyla uyumlu olmayan kişileri olabilir. Bir keresinde bir mühendisle konuştuğumu ve bana (şaka yapmıyorum) işverenleri için değer üretme zorunlulukları olmadığını düşündüklerini söylediğini hatırlıyorum. Bazı mühendisler, kendilerini çalıştıran şirket için iyi olan şeylerden ziyade, becerilerini geliştirecek veya onları daha değerli bir çalışan haline getirecek şeylere odaklanmak isteyebilir.

FAST ile bir insan topluluğunu yönetmek için kayıt oluyorsunuz.

Geleneksel durumlarda hiyerarşi bundan kimin sorumlu olduğunu açıkça ortaya koyar. FAST'ta çatışmayı önlemenin ve "üyelerin bunu çözmesine izin vermenin" kolay olacağından şüpheleniyorum. Bu, gayri resmi güç ağlarının bir tür yapısızlık zulmüne hakim olmasına neden olabilir. Eğer FAST kullanıyorsanız, bu benim korunacağım bir şeydir.

Diğer uç nokta ise, grubun sorunları çözmesine izin vermemek ve yönetimin bu sorunu tamamen halletmesini sağlamaktır. Bu aynı zamanda zararlı da olabilir.

Dolayısıyla FAST, iyi bir kolaylaştırma, dikkatli gözlem ve ara sıra müdahale gerektirecektir.

HIZLI çok çalışma gerektirir

FAST ile deneme yapmak istememenizin en büyük nedeni, FAST'ta çok fazla gizli işin bulunmasıdır. Alışılmadık bir çalışma şekline doğru, kuruluşunuzda çok fazla değişiklik yapılmasını gerektirir.

FAST'ı yeni bir bilgisayar programlama dilinde çalışmaya benzetebilirsiniz. Yeni dil umut verici görünüyor çünkü o kadar çok yeni ergonomik özelliğe sahip ki, daha önce gördüğünüz her şeyden çok daha iyi görünüyor. Ancak bu yeni dilde yazılmış çerçeveleriniz ve kitaplıklarınız yok. Bu yüzden çoğunu kendiniz inşa etmeniz gerekecek.

Yani FAST'ın en büyük dezavantajı köklü bir uygulama olmamasıdır. FAST'ın çalışma şekli ile geleneksel uygulamalar arasındaki uyumsuzluklarla başa çıkmak için birçok şeyi telafi etmeniz gerekecek. İşte bazı örnekler:

Performans yönetimi nasıl çalışır?

Geleneksel takımlarda, işi denetleyen ve bireylere koçluk yapan bir yöneticiniz vardır. Performans değerlendirmeleriniz var ve birisi uygun değilse yönetici müdahale edebilir. Performans değerlendirmelerinde sorunlar olsa da çoğu insan bunların nasıl çalıştığını ve organizasyonda bir amaca hizmet ettiğini anlıyor.

FAST takımlarında performans incelemesi yapmanın aslında belirgin bir yolu yoktur. Kişinin yöneticisi onun ne yaptığını veya nasıl çalıştığını biliyor mu? “Takımları” bile değerlendiremezsiniz çünkü bunlar geçicidir.

Bu nedenle performans yönetimi kavramının yeniden keşfedilmesi gerekiyor. Bu her ne kadar iyi bir fikir olsa da, düşünmeyi ve icat etmeyi gerektiren bir şeydir.

FAST'ta mühendislik yöneticilerinin rolü nedir?

Bir mühendislik yöneticisi rolünü yapılandırmanın birçok yolu vardır. Genel olarak proje yönetiminden sorumlu mühendislik yöneticisinin bulunmasını öneriyorum çünkü bu onları güç farkının sorun yaratacağı bir alana koymadan ekibiyle yan yana çalışmalarını sağlar. Mühendislik yöneticisi rolünü tanımlamanın pek çok geçerli yolu vardır, ancak ben buna yönelme eğilimindeyim.

FAST'ta mühendislik yöneticisinin rolü daha az açıktır. Uzun ömürlü ekipleriniz yok, dolayısıyla mühendislik yöneticisinin kendilerine doğrudan bağlı olanlarla yan yana çalışması daha zor.

Kendi kendine oluşturulan ekiplere mühendislik yöneticilerinin liderlik etmesini sağlayabilirsiniz. Veya onların saf insan yöneticileri olmalarını sağlayabilirsiniz. Ya da onların oyuncu-antrenör olmalarını sağlayabilirsiniz.

Bunların hepsinin değiş tokuşları ve oldukça büyük dezavantajları var. FAST, mühendislik yönetimine olan ihtiyacı azaltıyor gibi görünüyor. Hala işe alacak, performans yönetimi yapacak ve süreci denetleyecek insanlara ihtiyacınız var. Ama belki geleneksel bir organizasyondaki kadar değil?

Bir disiplin olarak yönetime değer vermedikleri için birçok kuruluşun acı çektiğini gördüm. Ancak FAST organizasyonlarının daha az yönetime ihtiyaç duyduğunu tahmin ediyorum.

Bunun işe yarayıp yaramayacağını gerçekten merak ediyorum ve FAST'ı deneyen kuruluşlardan bilgi almak istiyorum. Yönetim konusunda ne yapıyorsunuz?

Sahiplik alanları olmadan kod kalitesini nasıl sağlayacaksınız?

Kod sahipliği, kod kalitesini yüksek tutmak için doğal teşvikler sağlar. Bu sizin çıkarınızadır, çünkü gelecekteki benliğiniz mevcut kodunuz üzerinde çalışmak zorundadır.

Paylaşılan kod sahipliği durumunda, kod kalitesini sağlamak için daha fazla çaba harcamanız gerekir. Benim tavsiyem gerekli bir uygulama olarak eşleştirme veya mobbing olacaktır.

Kod kalıpları için daha güçlü standartlara da ihtiyacınız olacak. Kod astarına ihtiyacınız olacak. Ve bir çeşit mimari karar almaya ihtiyacınız olacak. Ön uç kodunuzun durumu nasıl ele aldığına ilişkin yirmi modele sahip olmak istemezsiniz. Bunlar çoğu yazılım kuruluşunda karşılaşacağınız sorunlardır, ancak FAST kullanan bir kuruluşta çok daha acil olacaktır.

Pek çok kuruluşun gereğinden az yatırım yaptığı şeylerden biri de etkili yazılım tasarım modelleriyle ilgili eğitim ve iletişimdir. Ve herkesin hangi yaklaşımların ne zaman kullanılacağı konusunda aynı fikirde olmasını sağlayacak konuşmalar. Bunlar muhtemelen bir FAST organizasyonunda daha da önemlidir.

Paylaşılan kod sahipliği, bazı emsalleri olan bir uygulamadır. HIZLI ile devam ederseniz, bu konuda nasıl başarılı olabileceğinizi araştırmak için zaman harcamaya değer.

Birden fazla Kolektifte ve Kolektif sınırlarının aşılmasında ne olur?

Kolektif sınırları aşan işler esasen FAST'ta tanımsızdır. Yüksek derecede koordinasyon gerektiren büyük girişimler de FAST tarafından yeterince belirtilmemiştir. Dolayısıyla bu durumlara çözüm bulmanız gerekir.

FAST kullanan birden fazla Kolektife sahip olacak kadar büyük herhangi bir kuruluş, Kolektifler arası projelerle karşılaşacaktır. Bu sorunları ele alma kalıpları, daha küçük ölçekte çözümleme şeklinize benzer veya benzer olacaktır. Ancak bildiğim kadarıyla burası büyük ölçüde keşfedilmemiş bir bölge. Bu nedenle, ortaya çıktıklarında bu sorunları çözmek için bazı koordinasyon modellerini kullanmanız gerekecek. Bu bir icat eylemi olacak.

FAST çağrı üzerine nasıl davranır?

Çağrı sırasında FAST kılavuzunda özel olarak bahsedilmiyor. Bu yüzden bununla başa çıkmak için bir plan icat etmeniz gerekecek.

Geleneksel ekiplerde çağrı üzerine standart tavsiye, her ekibin kendi operasyonlarından sorumlu olmasıdır. Ve ekipteki herkesin görev başında olmasını sağlamak. Bu, yükün çok kötü olmaması için en az dört kişiden oluşan ekiplerinizin olması gerektiği anlamına gelir. Buradaki düşünce, ekiplerin iş ürünleri için çağrıda bulunmasının onları güvenilirliği artırmaya teşvik etmesidir. Bu, iyi bir çağrı programlarına sahip olmalarına yardımcı olur.

FAST ile katmanları olan bir çağrı üzerine rotasyon oluşturabilirsiniz (bu runbook'u takip edin ve sorunu çözmezse üst kademeye iletin). Ve kimin neyi destekleyebileceğinin bir haritasını açıkça saklamanız gerekecek. Bu, takımlarınızla eşleşmeyecektir.

Bunu yapmak çok zor olmasa da geleneksel çağrı uygulamalarına göre daha az yaygındır ve yönetimin dikkatini gerektirir.

Hataları düzeltmeye ve üst kademelere destek sağlamaya ne dersiniz?

FAST'ın "Özellik Sorumlusu" adı verilen isteğe bağlı bir rolü vardır. Belirli bir özellik konusunda bir nevi uzmandırlar ve paydaşlar için bu özellik etrafında iletişim noktasıdırlar. Bu özellik üzerinde sürekli çalışmaları gerekmemektedir ancak bu özelliği sürekli olarak anlamaları gerekmektedir.

Çağrı sırasında olduğu gibi, özelliklerin bu özellikler konusunda uzmanlığa sahip kişilerle eşleştirilmesine ihtiyacınız olacak. Bu hem hatalar hem de destek yükseltmeleri açısından önemli olacaktır. Ayrıca bunu çağrı üzerine de birleştirebilirsiniz. Sorunları doğru kişilere önceliklendirmenin bir yoluna ihtiyacınız olacak.

Ayrıca uzmanlığın bir veya iki kişiyle sınırlandırıldığı durumlarda bilgi boşluklarını dolduracak bir mekanizmaya sahip olduğunuzdan da emin olmanız gerekir.

Karar vermeniz gereken şeylerden biri, hataları düzeltme politikanızdır. Diğer özelliklerin çalışmasını yavaşlatarak bunların her zaman düzeltilmesini mi istiyorsunuz? Hatalar, onları tanıtan kişi tarafından mı düzeltildi, yoksa başka bir plan mı istiyorsunuz? Peki hataların tetiklenmesinden kimin sorumlu olduğunu nasıl belirleyeceksiniz? Muhtemelen bir çeşit rotasyon mu?

Destek yükseltmeleri de biraz çaba gerektirecektir. İrtibat noktası, bir bölgenin Özellik Sorumlusu'dur. Peki ya Özellik Komiseri tatildeyse? Muhtemelen her alan hakkında birden fazla kişinin bilgi sahibi olmasını istersiniz. Peki ya destek sorusu çalışma gerektirmeye başlarsa? İşi sadece siz mi yapıyorsunuz yoksa merkezi önceliklere mi aktarıyorsunuz?

Bunların hiçbiri çözülmesi zor sorunlar değil, ancak bunlar yönetim işidir. Ve yaptığınız her şeyde odaklanma ve tepki verme arasında dengeler olacaktır.

Güvenilirlik olayları ve geçmişe dönük olay incelemeleri ne olacak?

FAST olayların nasıl ele alınacağını tanımlamaz. Çağrı düzeniniz büyük ölçüde olayların nasıl ele alınacağını belirleyecek ve muhtemelen durumu düzeltmek için nasıl düzeltileceğini bilen kişileri de içerecektir.

FAST, olayların geriye dönük olarak nasıl ele alınacağını açıklamaz. Aşağıdakine benzer bir şey yapmanızı tavsiye ederim: Bir sonraki Kolektif toplantıdan önce meydana gelecek bir olayı geriye dönük olarak planlayın. Retrospektifin amaçlarından biri, olaya neden olan şeyin olasılığını veya ciddiyetini azaltacak yapılabilecek birkaç çalışmayı belirlemek olacaktır. Bir diğeri ise olaydan öğrenebileceğiniz her şeyi öğrenmek olacaktır.

Olayın hemen ardından yapılan Toplu toplantıda öğrendiklerimizi paylaşacak ve ayrıca bir sonraki döngü için retrospektifte belirlenen bazı işlerin yapılmasını otomatik olarak önceliklendirecektim.

New Relic'te FAST kullanmıyorduk ancak benzer bir politikamız vardı. Biz buna “Olayları Tekrarlamayın” (DRI) adını verdik. Güvenilirlik açısından şimdiye kadar yaptığımız en iyi şeylerden biriydi. Kural, DRI çalışmasının otomatik olarak diğer önceliklerden daha önemli olmasıydı. Bu nedenle, bir olay her zaman ya kapsamın azalmasına ya da son teslim tarihinin ertelenmesine neden oluyordu.

Tasarımcılar FAST'ta nasıl çalışır?

Birçok tasarımcının karşılaştığı zorluk, mühendislik ekibiyle çalışmaya veya mühendislik ekibinin önünde iş yapmaya odaklanmaktır. Veya her iki yönde de çalışmasını sağlayın. Her iki çalışma şekli için de güçlü argümanlar duyacaksınız.

FAST bunun nasıl çalışması gerektiğini belirtmez, dolayısıyla kendiniz karar vermeniz gerekir. Tasarımcılar üzerinde çalışacak ekiplere kaydoluyor mu? Yoksa önceden çalışan ve insanların kendilerinden bir şeye ihtiyacı olduğunda danışman olarak hareket eden bir hizmet kuruluşu mu? Karar vermeniz gerekecek. Muhtemelen tasarımcıların kaydolmasını ve ekiplerin bir parçası olmasını isterim, ancak yine bu, FAST'ı benimserken vermeniz gereken karar türlerinin bir örneğidir.

Ürün yöneticileri FAST'ta nasıl çalışır?

FAST'taki ürün rolü çoğunlukla öncelikleri belirlemek ve öncelikleri iletmektir. Bunun dışındaki çalışmalar hakkında FAST kılavuzunda gerçekten açıklanmayan pek çok şey var.

FAST kılavuzundaki varsayım, ürün yöneticilerinin ilham verip iletişim kurduğu ve ardından mühendislerin özellikler üzerinde çalıştığı yönünde görünüyor.

Yapabildiğiniz ölçüde mühendislerin müşterilerle konuşmasını ve çalıştıkları ürün alanında uzmanlık kazanmalarını sağlarım. İdeal olarak işi onlar yapar, müşterilere gösterir ve onlardan geri bildirim alırlar. . Ürün yöneticilerinin bunu kolaylaştırmasını sağlamak ve mühendislerin bunu etkili bir şekilde yapma becerilerini geliştirmek, işlerinin değerli bir parçası olabilir.

Bu modelde çok fazla esneklik var. Tipik ürün-mühendislik aktarımını gerçekleştirebilir veya müşterilerinizle birlikte alanı keşfetmelerini ve problem çözmelerini sağlayabilirsiniz.

Gördüğünüz gibi FAST'ta birçok boşluk var. Gerisini problem çözmeniz gerekecek.

FAST materyalleri jargonla doludur

FAST web sitesini ve kılavuzunu kafa karıştırıcı bulabilirsiniz. FAST Agile'ın altınına ulaşmak için birçok jargon ve sinir bozucu terminolojide gezinmeniz gerekecek. Örnek olarak, FAST Kılavuzunun 2.12 versiyonundaki uygulamayı tanımlamaya çalışan FAST Agile'ın berbat tanımı aşağıda verilmiştir:

“Akışkan Ölçekleme Teknolojisi Nedir? Akışkan Ölçeklendirme Teknolojisi, insanları iş çevresinde organize etmek için hafif, anlaşılması kolay ve ustalaşması basit bir yöntem oluşturmak için Açık Alan Teknolojisi ile Açık Tahsis'i birleştirir; bu ölçeklenir. FAST, Fluid Scaling Technology'nin kısaltmasıdır. Çevik için Akışkan Ölçeklendirme Teknolojisi HIZLI Çeviktir.”

Bu yüzden. Kötü. Ve bu oldukça temsili bir durum. Kolektiflere, Değer Döngülerine, Açık Teknolojiye, Deniz Mavisi dönüşümüne, Y Teorisine vs. pek çok referans göreceksiniz. Bunların hepsi hiçbir açıklama olmadan sunuluyor ve açıklansa bile aslında faydası olmayacak. Çevik teorisyenlerden oluşan niş bir kitleye hitap ediyorlar ve kullanışlılıktan ziyade ilişkilendirmeye odaklanıyorlar.

Çözüm

Peki bu bizi nereye bırakıyor? FAST çevikliği denemeye değer mi?

Bunun cevabının evet olduğuna inanıyorum, ancak dikkatli ve doğru bağlamlarda. Bireysel takımlar içinde bununla oynayabilirsiniz. Ve eğer liderlik desteğiniz varsa, bunu daha büyük organizasyonlarda yavaş yavaş deneyin.

Eğer deneme yaparsanız lütfen benimle paylaşın. Kuruluşunuzda bunu yaygınlaştırma konusunda yardıma ihtiyacınız varsa benimle iletişime geçin. Size ya doğrudan yardım edeceğim ya da sizi yardım edebilecek diğer kişilerle buluşturacağım.

Teşekkür ederim

Bu yazının ilk versiyonları… gerçekten kötüydü. Eleştirileri için Seth Falcon ve Davy Stevenson'a teşekkür etmek istiyorum. Her ikisi de gönderiyle ilgili bazı önemli sorunlara dikkat çekti ve bu da beni geri adım atmaya ve yaklaşımımı yeniden düşünmeye yöneltti. Ve yazının kendi bölümlerine dahil ettiğim bazı mükemmel noktalara değindiler. Sonunda yazının çoğunu yeniden yazdım ve sonuçtan çok daha mutlu oldum. Teşekkür ederim! Seth'in mühendislik liderliği üzerine göz atmaya değer bir haber bülteni var ve Davy (benim gibi) startup danışmanlığı ve koçluk yapıyor.

Jim Shore beni FAST agile ile tanıştırdı. Bununla ilgili deneyimleri hakkında bazı mükemmel konuşmaları var. Birkaç kez buluştuk ve FAST'ın sonuçlarını ve uygulanmasını tartıştık. Jim , Çevik Gelişim Sanatı kitabının yazarıdır.

Resim Kanenori tarafından Pixabay'a yüklendi

Dipnotlar

1. 150 kişinin bir Kolektif için muhtemelen hantal olduğuna inanıyorum. Altmış kişinin daha iyi bir maksimum boyut olduğundan şüpheleniyorum.