Çevik (Agile) İnovasyonun Kısa Tarihi
Çevik Metodolojilerin Doğuşu
Bu günlerde muhtemelen “çevik inovasyon” hakkında çok şey duyuyorsunuzdur. Çevik metotlar kullanan ekipler işleri, geleneksel metotları kullanan ekiplerden daha hızlı şekilde hallediyorlar. Müşterilerini daha memnun ve daha mutlu etmeyi başarıyorlar. Çalışmaktan daha çok zevk alıyorlar. Çevik yaklaşım tartışılmaz bir biçimde yazılım sektörünü geliştirmeyi başardı ve birçok uzman çevik yaklaşımın Bilgi Teknolojilerinin çok ötesine geçmeye hazır olduğuna inanıyor. İronik bir şekilde aslında bu yaklaşım, Bilgi Teknolojileri alanının dışında başladı.
Çeviklikten Yalınlığa
Bazıları çevik metodolojileri, Francis Bacon’un bilimsel yöntem üzerine 1620'deki ifadesine kadar götürmektedir. Ancak daha makul bir başlangıç noktası, Bell Labs’teki fizikçi ve istatistikçi Walter Shewhart’ın ürünlerin ve süreçlerin iyileştirilmesi için Plan-Do-Study-Act (PDSA) döngü metodolojisini uygulamaya başladığı 1930'lar olarak düşünülebilir. Shewhart bu yineleyici ve aşamalı geliştirme metodolojisini öğrencisi W. Edwards Deming’e öğretti ve Deming bunu İkinci Dünya Savaşı’ndan sonraki yıllarda Japonya’da yaygın şekilde kullandı. Toyota, yüzlerce şirket yöneticisini yetiştirmek için Deming ile çalıştı ve sonunda bugünkü “yalın” düşüncenin birincil kaynağı olan ünlü Toyota Üretim Sistemini geliştirdi. Yinelemeli ve artımlı geliştirme yöntemleri, 1950'lerde X-15 hipersonik jetin de başarılı bir şekilde oluşturulmasına önemli bir katkı sağladı.
Çeviklikten Yeniliğe
1986'da, Hirotaka Takeuchi (Harvard Business School Öğretim Üyesi) ve İkujiro Nonaka tarafından, “Yeni Yeni Ürün Geliştirme Oyunu” adlı Harvard Business Review’da bir makale yayınlandı. Yazarlar, başarılı inovasyonları rakiplerinden çok daha hızlı bir şekilde yapan firmaları araştırarak ekip odaklı bir yaklaşım belirlediler. Bu yaklaşım Fuji-Xerox’daki fotokopi makineleri, Honda’daki otomobil motorları ve Canon’daki kameralar gibi ürünlerin tasarım ve geliştirme sürecini etkileyip değiştirdi. Bu şirketler, geleneksel “bayrak yarışı” ürün geliştirme yöntemlerini izlemekten ziyade (ki bu bir grup uzmanın çalışma aşamalarını tamamladıktan sonra süreci bir sonraki işlevsel aşamaya geçirmeleri şeklinde tarif edilebilir), Takeuchi ve Nonaka’nın “rugby” yaklaşımı dediği şeyi kullanıyordu ve burada, “ekip mesafenin tümünü hep beraber bir birim halinde topu ileri geri atarak kat eder.”
1993’de (Scrum’in kurucularından biri) Jeff Sutherland’a zor bir görev verildi: Bir yazılım şirketi olan Easel Corporation, altı aydan daha kısa bir sürede eski ürünlerini tamamen yenilemek istiyordu. Sutherland zaten, hızlı uygulama geliştirme, nesne dayalı tasarım, PDSA döngüleri ve “skunkworks” gibi yöntemlerde güçlü bir geçmişe sahipti. Kurumda, hem örgütsel ayrımın hem de entegrasyonun faydalarını harmanlayan skunkworks benzeri bir kültür oluşturmaya çalıştı. İşe örgütsel verimliliği en üst düzeye çıkarmak için elinden gelen her şeyi öğrenerek başladı. Yüzlerce makale okuyup ürün yönetimi uzmanlarıyla mülakatlar yaptı ve bu süreçte birçok geleneksel olmayan fikir üretti.
Scrum’ın Ortaya Çıkışı
Bunlardan bir tanesi, kısa günlük ekip toplantılarının grup verimliliğini önemli ölçüde artırdığı şeklindeydi. Sutherland’ın temel yaklaşımı, yazılımdan ziyade üretim üzerinde yoğunlaşsa da, Takeuchi’nin ve Nonaka’nın keşfettiği rugby yaklaşımıydı. Takeuchi ve Nonaka’nın temel fikirlerinden birçoğunu ödünç alıp spesifik operasyonel uygulamaları dahil ederek Sutherland, yazılım geliştirmenin yeni bir yolunu yarattı; rugby oyununa atıf yaparak adını “scrum” (hamle, saldırı) koydu. Scrum yöntemleri, görünüşte bitmesi imkânsız görünen projesini zamanında, az bütçeyle ve daha önceki herhangi bir sürümden daha az hatayla tamamlamasını sağladı. Daha sonra, yaklaşımı ayrıntılandırmak için uzun süreli meslektaşı Ken Schwaber ile işbirliği yaptı ve 1995'te ikisi ilk defa scrum’ı kamuoyuna sundu.
Sutherland ve Schwaber, yenilikçi yöntemler arama konusunda yalnız değillerdi. Bilgi Çağı patlamıştı ve yıkıcı teknolojiler yavaş davranan işletmeleri sahneden hızla siliyordu. Startuplar ve piyasada mevcut oyuncular, bu yeni ve çalkantılı çevreye uyum sağlamanın daha iyi yollarını aradılar. Yazılım neredeyse her işin ayrılmaz bir parçası haline geliyordu ve birçok yaratıcı yazılım geliştiricisi uyumluluğu artırmak için daha iyi programlama yöntemleri üzerinde yoğun çalışıyordu.
Çevik Metotlar Oluşmaya Başlıyor
2001'de, kendilerini “örgütsel anarşist” olarak adlandıran 17 yazılım geliştirici, fikirlerini paylaşmak için Utah’daki Snowbird’de bir araya geldi. Sutherland ve diğer scrum savunucuları da bu gruptaydı. Ancak grup, birçok rekabetçi yaklaşımın savunucularını da içeriyordu: extreme programming (XP); crystal; adaptive software development (ASD); feature-driven development (FDD); ve dynamic-systems-development method (DSDM). Hızla değişen ortama daha hızlı adapte olabilmeye imkân vermek için daha az ve daha basit kurallar uygulandığından, tüm bu yaklaşımlar genellikle “hafif-lightweight” çerçeveler-frameworks olarak biliniyor ancak bu katılımcıların çoğu bu terminolojiyi beğenmiyorlar.
Çevik İttifak Doğuyor
Her ne kadar birçok konuda anlaşamasalar da, grup sonunda bu hareket için yeni bir ad buldu: Agile/Çevik. Katılımcılar, herkesin mutabık kaldığı dört temel değeri tarif eden ve “Çevik Yazılım Geliştirme Bildirgesi” olarak adlandırılan metodoloji üzerinde fikir birliği sağladı. Toplantı sonrasında ve sonraki birkaç ay boyunca devam ederek “Çevik Bildirgenin Ardındaki İlkeler” adlı 12 ilke geliştirdiler. 2001'den itibaren bu değerler ve ilkelerle uyumlu tüm gelişim çerçeveleri çevik teknikler olarak anılmaya başlandı. Bu toplantıdan sonra çevik hareket hızla yayıldı. İmza verenler ve daha birçok kişi daha sonra kalıcı bir çalışma grubu oluşturmak istedi ve hareketi desteklemek için Çevik İttifak adlı kar amacı gütmeyen bir organizasyon kurdu. Bugün, Çevik İttifak’ın yaklaşık 30.000 üyesi ve abonesi bulunuyor.
Çevik mi? Yalın mı?
Bu arada çevik metodolojiler gelişmeye devam etti. 1980'lerin sonu ve 1990'ların başında, MIT’li araştırmacılar Japon üretim sistemlerini, özellikle de Toyota üretim sistemini incelemeye başladı. Düzensiz iş akışlarındaki (“mura”) ve tahrip edici aşırı yüklemenin (“muri”) azaltılması yoluyla atıkların (“muda”) ortadan kaldırılarak sistemin üretkenliğini artırma yöntemlerini tanımlamak için “yalın/lean” terimini yarattılar. Yalın metodolojiler çevik çerçeveler olarak sunulmamakla birlikte, 2000'li yıllarda resmi yalın ve kanban yazılım geliştirme sistemleri ortaya çıktı. Başlangıçta, çevik metodolojiyi benimseyen bazı kişiler bu yaklaşımları çevik metodolojiler olarak tanımayı reddetti. Ancak yalın yaklaşımın savunucuları odaklarını müşteri işbirliğine yoğunlaştırdı ve bu yaklaşımlar ve hibritleri de daha çok çevik değerlerin ve ilkelerin meşru uygulamaları olarak kabul edilmeye başlandı.
Başarının birçok sahibi var ve çevik inovasyon renkli bir mirasa sahip. Çevik yaklaşımın karmaşık aile ağacı, yaklaşımın uygulayıcıları arasında bazen tartışmalara neden olsa da, iki konu çok açıktır: İlki, çevik yaklaşımın kökenleri bilgi teknolojisinin çok ötesindedir ve ikincisi, çevik yaklaşım her sektörün neredeyse her işlevinde inovasyon süreçlerini iyileştirmek için yaygınlaşmaya devam edecektir.
