Startup’larda Agile — I

Türkiye’de ve hatta dünyada bütün şirketler ve ekipler Agile yaşıyor, şirketlerde Agile’dan geçilmiyor, Agile Danışmanlık şirketleri gelip sihirli değnekleriyle şirketleri bir değişime sokuyor ve herkes birden anlamını bile bilemedikleri ama süper uyguladıkları AGILE oluveriyorlar. Neyse sektördeki ‘Agile’ durumunu başka bir yazıya bırakalım, background’da çalması için tatlı bir müzik hazırladıktan sonra startup’larda Agile nasıl olmalı diye atıp tuttuğum konumuza girelim yavaştan.

Agile? I live in Agile. It’s not a development process to me. It’s totally best way of expressing my own. You know, sometimes I’m dreaming of a world, all people do the development perfectly.

Startup, ileride ne olacağı belli olmayan, her dakika değişikliğe maruz kalabilen, yaşamak için elinden geleni en hızlı bir şekilde yapmak zorunda kalan bir yaşam formu. Startup’ı ıssız bir ormanda tek başına olan bir insana benzetiyorum. Yanında gerekli araçları olan ( yatırım almış v.b. ) bazı şanslı startup’lar bile o koca ormanda tek başlarına. Onlarca hatta yüzlerce tehlike ile karşı karşıyalar ve hayatta kalmak için hızlı karar vermeli, değişik şeyler denemeli ve her türlü şanslarını kullanmak zorundalar. Yanlış en ufak bir hareket bile onları öldürebilir ya da 10 dakka sonra nasıl bir durumla karşılaşacaklarını bilmezken, nasıl bir plan yapıp hayatta kalabilirler ki?

Şimdiye kadar n11'un ilk geliştirilme zamanlarında, Dolap’ın ilk 2 yıllık hikayesinde, n11 mobile uygulamalarının geliştirilmesinde, Turkcell AdInAction projesinde gördüğüm, deneyimlediğim, Agile ve XP’yi TR’de ilk uygulayanlardan / uygulatmaya çalışanlardan biri olan olan Cenk sayesinde ögrendiğim kadarıyla; belirsiz ve sonuç odaklı bir ortamda en verimli ve uygun proje yönetim yöntemi olan Agile, Manifestosuna göre,

• Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
• Kapsamlı dökümantasyondan ziyade çalışan yazılıma
• Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine
• Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye

önem vermekte. Bu değerleri Startup için düşünürsek ve farklı Agile metodolojileri bir kenara koyarsak, Startup’larda Agile süreçleri Team(ekip), Product(ürün), Process(süreç) ve Development( yazılım) olarak 4 bölüme ayırabiliriz. Bu bölümleri ayrı ayrı inceleyelim.

1. Team

Bir Startup’ın en değerli varlığı, ekibin kendisi. Dolap ekibinde de, daha önce beraber çalıştığımız n11 ekibinde de hep konuştuğumuz ve daha önemlisi yaşadığımız şey, o ekibin o anda yaptığı iş yerine başka bir iş de yapsa gene başarılı olacağı idi. Bugun Dolap ekibi olarak, daha öncelerinde n11 ekibi olarak hep hissettiğim, startup ruhunu koruyan, bir aile olan ekibin her zaman başarılı olacağı.

Birbirine yardım eden, sonuç odaklı, araya Slack, email v.b. gibi aracı iletişim araçları yerine birebir iletişimi tercih eden, birbirini seven ve sayan bir ekibin her sorunun üzerinden gelebiliyor. Startup, doğası gereği, ekip üyelerinin ailelerinden çok birbirlerini gördükleri bir ortam olduğu için, kendi aralarında hiyerarşi, title v.b. ayrımı olmadan, farklı parçaları olan tek bir makine gibi birbirine uyumlu şekilde çalışması gerekiyor. O makine ilk başlarda rodaj süresini geçiriyor, o süreçte çok hızlanmamak gerekiyor belki ama bir süre sonra kusursuz bir şekilde birbirine uyumlu parçaları ile yol almaya başlayabiliyor. Ekibin alışma sürecinde dikkatli olup, ekibin hızına, uyumuna göre ekibe destek olmak, bu kültürdeki insanları işe yavaş yavaş almak çok önemli. Şirket kültürünün ortaya çıktığı ve oturmaya başladığı ilk iki yıl çok kritik . Ekibin kültürünün ne olduğuna göre şirketin geleceği değişiyor. Barbaros Özbugutu’nun Şirket Kültürü Stratejiyi döver ! yazısı bu konuyu çok güzel özetliyor diyebilirim.

Şirket 10–12 kişiye kadar tek masa çevresinde oturması, birbirinden haberdar olması çok önemli. Herkes her konudan haberdar olduğu, kararların ortak alındığı bir süreçte ekibin verimi ve bağlılı maksimum oluyor. 10–12 kişiye kadar açık ofis modeli çok gerekiyor bence. Agile’ın takım konusundaki yansımasının, bireyler ve etkileşimlerinin güçlü olması, güven içinde olması ve özverili şekilde bu ilişkinin devam etmesi şeklinde olduğunu gördüm.

2. Product

Ürün ve ürünün çözdüğü sorun, bir startup’ın varoluş amacı. Bu sorun ve çözüm de Müşteri ile yakın ilişkiyle paralel bir şekilde gitmeli aslında. İlk 10, 100, 1000 hatta 100000 müşteri ile yakın ilişki kurmak, onları dinlemek, takip etmek çok kritik. Bunun için Dolap’ta çok kullandığımız, kullanıcılar ile whatsapp grupları, periyodik olarak farklı profildeki ( sistemi çok aktif kullanan, kullanmayı bırakan v.b. ) müşterileri aramak, belki kısa anketler yapmak ( google docs ile süper kolay ) ve istedikleri değişikliklere ya da geri bildirimlere hızlı bir şekilde karşılık verebiliyor olmak çok önemli. Kullanıcıların geri bildirimleri startup’ın ilk zamanlarında çok etkili oluyor ve şirketin nereye pivot etmesi gerektiğini gösterebiliyor. Gerekirse onlara anlık demo yapmak bile aslında geri bildirimlere hemen ulaşmamızı sağlıyor.

Şu anda çalıştığım Dolap özelinde baktığımızda, Günün İndirimli Dolapları projesini ‘bi deneyelim’ diye başlayıp kullanıcılardan gelen geri bildirimler ile daha efektif bir hale getirdik. Kullanıcıların son online olma tarihleri, kullanıcı bloklama, festivaller ve daha bir çok şey hem kullanıcılarımızın bize direk ilettiği hem de onlarla ara ara yaptığımız konuşmalarda beraberce ortaya çıkardığımız fikirler ile ortaya çıktı ve büyüdü.

Product tarafında çözülmeye çalışan sorunun kullanıcılar için en kolay ve basit halde çözümü ve onların geri bildirimleri ile değişiklikler yapmak Agile’ın bir Startup’taki yansıması diyebiliriz. 12 ay bekleyip, müşterilerden geri bildirim almadan projeyi uzatmak yerine, 3–4 ay içinde gerekirse hataları, eksiklikleri ile de olsa canlı’ya çıkıp, kullanıcıların deneyimlemelerini yakından incelemek, startup’ın onların sorunlarını çözüp çözemediğini anında görmek gerektiğini düşünüyorum.

Konuyla çok alakalı olmasa da ben 10–12 kişiden az olan bir startup’ın, ilk 1 1.5 yılında çok istisnai bir kişi ya da bir durum olmadığı sürece bir analist / product owner v.b. ihtiyacı olmadığını düşünüyorum. Ekibin zaten kendi kendine karar alabilmesi, denemekten korkmaması, birbirinden haberdar olarak işleri yapması aradaki karar verici sürecini v.b. ortadan kaldırmalı bence. Bugün denk geldiğim ve her hafta takip ettiğim Erman Taylan’ın haftalık bülteninde bu konuyla az biraz ilgili yorumsuz iki yazı ( Good Product Manager/Bad Product Manager ve You Are Not the CEO of Anything ) mevcut idi.

Yazının ikinci kısmında süreç ve yazılım tarafında bir kaç fikir atıp tutmaya çalışacağım…