Ne demek sadece takım üyesi?

Agile ve Scrum kavramlarıyla ilk tanıştığım zaman, bir İş Analisti olarak çalışıyordum. Eğer ki bir İş Analistiyseniz, en iyi iş akışları çıkartmak, etki analizini her koşulda her detayına kadar ön görmek, sayfalarca doküman yazmak, tüm fonksiyonların açıklamalarını yapmak, gereksinimleri ve kapsamı belirlemek sizin mesleki uzmanlık alanınızdı. Firmanızdaki iş tanımınızdan iş ilanlarına bu böyleydi. İş analisti bir meslek, geliştirme süreci içerisindeki bir roldü.

Agile yaklaşım içerisindeki Scrum çerçevesinin iş hayatıma yıldırım gibi inişini dün gibi hatırlıyorum. Yıldırım tam olarak şöyle bir şeydi;

“İş analisti, developer, tester sadece birer yetkinliktir. Rol değildir!. Scrum içerisinde bu insanlar sadece takım üyesidir”

Ne demek sadece takım üyesi? Sadece mi takım üyesi? Sen ben kimim biliyor musun?

Neyse ki göz tansiyonum çıkmadan eye roll konusu son buldu. Bu Scrum ne yapmaya çalışıyordu? Development team, cross-functional ve self-organized olacak, tek rol takım üyesi olacak, geri kalan her şey yetkinlik olacak ve ekip içerisindeki takım üyelerinin yetkinlikleri toplamı, anlamlı bir ürün üretebilecekti.

2020 yılında güncellenen Scrum Guide ile birlikte Development Team Developers, self-organized ise self-managed olacak şekilde değiştirilmiştir.

Böylesine devrimsel bir bilgi karşısında, insanoğlunun direniş göstermesi kadar doğal bir şey yoktur. İnsanoğlu, bir koloni içerisinde yaşamayı, kendini bir gruba ait hissetmeyi ve o grubun savunuculuğunu yapmayı DNA’sına çok uzun yıllar önce işlemişti. Bu zamana kadar gelen öğretilerimiz ise bize İş Analisti, Tester, Back-End Developer, Front-End Developer, iOs Developer gibi mesleki — rol grupların içerisinde yaşamayı güvenli göstermişti.

Toyota Üretim Sistemi’nin yani Toyota Ruhu’nun yaratıcısı Taiichi Ohno, 1947 yılında devrimsel bir hareketle bir işçiye birden fazla makine emanet etme kararı aldı. Amacı, üretimi akışkanlaştırmak, Amerika ile Japonya arasındaki üretim farkını kapatmaktı.

Sizce sonuç ne oldu?

O yıllarda Amerikadaki üretim bölümleri ve sendikalar arasında paralel bir bağ vardı. Her profesyonel iş koluna ait bir özel sendika vardı ve bu sendikaların felsefesi, tornacıların sadece tornada, frezecilerin sadece frezede çalışması yönündeydi. Birbirlerinin atölyelerine girmeleri bile yasaktı. Bu yaklaşımın sonucu elbette bir direnişti. Ne yazık ki Taiichi Ohno, hayal ettiği şeyi gerçekleştirmek için bir süre daha beklemek zorunda kaldı. Japonlar, petrol krizi ile birlikte bu sistemin kendilerine hiç uygun olmadığını anlayacaklardı.

Yukarıdaki örgütlenme biçimi, eski yazılım geliştirme dünyası için size de tanıdık geliyor mu?

Bu rol bazlı örgütlenme biçimi, yazılım dünyasındaki çalışanlara;

• Bol bol bürokrasi
• Kullanılmayan birçok ürün
• Sayısız mesai
• Çok sayıda bug/defect

ve asla zamanında bitemeyen projeler olarak geri dönüyordu.

Çünkü;

Torna tezgahında üretimini tamamlayan tornacının ( iş analistinin), freze tezgahındaki işi (developmentı) görme ihtimali yoktu. Parçaları kontrol eden kalite ustasının (Tester) bu ürünün neye göre üretildiği, ne beklendiği hakkında da hiçbir bilgisi yoktu. Ne münasebetti!

Çıktının hiç revize edilemediği, her yetkinlik sahibinin kendi yetkinliğine göre üretimini yapıp bir sonraki adımı kaderine bıraktığı, iş akışının tek yönlü olduğu, bir yetkinliğin işini bitirmesinin hiçbir anlam ifade etmediği — çünkü müşterimize hala bir ürün sunamıyorduk — zamanlar şu an bana hayal gibi gelse de bunlar yaşandı ve bir yerlerde hala yaşanmaya devam ediyor.

Bu yazıyı, bu hikayeyi bir yerden hatırlayan, kendinden bir parça bulan herkese biraz olsun dokunabilmek için yazdım. Yorumlarınızı ve tecrübelerinizi dinlemeyi, okumayı çok isterim :)

Peki ya Cross-Functional takım olmak, bir yapbozun parçaları gibi birleşip yapbozu tamamlamak bize neler kazandırdı? Takımlardan rolleri kaldırmak ne anlam ifade ediyor? Bir sonraki yazımda size bunları anlatacağım.

Keyifli okumalar….

P.S: Devam yazısına buradan ulaşabilirsiniz.