Yalın Altı Sigma Yaklaşımlarının Çevik Retrospektiflere Uygulanması Engin Çallı1, Gökhan Turan1 1 Turkcell Teknoloji, İstanbul, Türkiye {calli.engin, gokhan.turan}@turkcell.com.tr Özet. Çevik manifesto, bireyler ve etkileşimleri kullanılan süreç ve araçlardan daha değerli görmektedir. 100 bireyden oluşan bir oragnizasyonda olası ilişki adedi 4950 iken, 1000 bireyden oluşan bir organizasyonda olası ilişki adedi 499500’dür. Yani organizasyon 10 kat büyüdüğünde ilişki adedi 100 kattan fazla büyümektedir. Bu kadar yüksek sayıda ilişkiden doğan etkileşimin, süreç ve araçlardan katma değeri daha yüksek sonuçlara yol açması ve süreçlerin getirdiği öngörülebilir düzenin bir kaosa dönüşmesi riskinin giderilebilmesi için farklı bir çevik perspektif gerekmektedir. Çeviklik, organizasyonun kendisini sürekli iyileştirmesine bağlı olup, bunun en temel pratiği retrospektif çalışma- larıdır. Çevik çalışma biçiminin önemli pratiklerinden biri olan retrospektif çalışmaları organizasyonun büyüklüğü ile yakından ilişkilidir. Çevik çalışan ekiplerin bağımlılık ilişkileri büyük ölçekli organizasyonlarda artmakta, bu bağımlılık ilişkileri retrospektif çıktılarında yer alan Kai-Zen (iyileştirme) faali- yetlerinin yapılmasını zorlaştırmaktadır. Oysa retrospektif çalışmasının temel motivasyonu maliyeti düşük ve faydası yüksek iyileştirmeler yapmaktır. Bu çalışmada, büyük ölçekli çevik organizasyonlar için bir retrospektif yöntemi önerilmektedir. Yöntem, birey etkileşimlerinin süreçleri sürekli iyileştirmesine ve sürekli iyileşen süreçlerin birey etkileşimlerini katma değeri daha yüksek bir sonuca odaklamasına dayanmaktadır. Yöntemin uygulandığı çevik bir organizasyonda ortaya çıkan deneyim, çalışma kapsamında analiz edilmektedir. Anahtar Kelimeler: Çeviklik, Kaizen, Retrospektif, Altı Sigma,Yalın Applying Lean Six Sigma Concepts to Agile Restrospectives Engin Çallı1, Gökhan Turan1 1 Turkcell Teknoloji, İstanbul, Türkiye {calli.engin, gokhan.turan}@turkcell.com.tr Abstract. The agile manifesto sees "individuals and interactions" as more val- uable than the "processes and tools" used. The number of possible relationships in an organization consisting of 100 individuals is 4950, while possible rela- tionships in an organization consisting of 1000 individuals increase to 499500. So when the organization grows 10 times, the relationship grows more than 100 times. A different agile perspective is needed in order to eliminate the risk that the predictable order brought by the processes becomes a chaos. Agility de- pends on the organization’s constantly improving itself and the most basic method of continous improvement is retrospective meetings. Retrospective meetings, one of the most important practices of agile work, are closely related to the size of the organization. The dependencies of agile teams are increasing in large-scale organizations, making it difficult to carry out Kai-Zen (improve- ment) activities in retrospective outputs. However, the main motivation for a retrospective meeting is to make low cost and high benefit improvements. In this study, a retrospective method is proposed for large-scale agile organi- zations. The method is based on the interactions that constantly improve pro- cesses and the processes that canalize interactions to a result with higher value added. The experience emerging in the agile organisation where the method is applied is analyzed within the context of the study. Keywords: Agile, Kaizen, Retrospective, Six Sigma, Lean 1 Tarihsel Süreç ve Çalışmayı Ortaya Çıkaran Zorlayıcı Koşullar 20. yüzyılın başlarından itibaren Japonya’da gelişme göstermeye başlayan yalın yak- laşım iki temel üzerine inşa edilmiştir[1,2]: 1. Jidoka (Otonomasyon) 2. JIT (Tam zamanlı üretim) Jidoka bir organizasyonda yer alan çalışanların otonomi çerçevesinde bağımsız kararlar alabilmesine olanak sağlayan ve çalışanın üretim sistemindeki sorumluluğunu her an hissetmesini hedefleyen bir yaklaşımdır [2]. Organizasyondaki karar alma sü- resi, alınacak kararın büyüklüğüyle yakından ilişkilidir. Stratejik seviyedeki büyük kararların alınması, taktik seviyedeki küçük kararların alınmasından daha zordur. Jidoka büyük kararların küçük kararlara bölünmesini, bu karar parçalarının taktik seviyede ele alınabilmesini sağlamakta ve Çevik Manifesto[19]’nun dayandığı “kendi kendine organize olma” prensibinin tarihsel esin kaynağını oluşturmaktadır. Organi- zasyondaki insan sayısı artıkça merkezi karar alma mekanizmalarının veriminin aynı kalmadığı, alınmış kararların orgnizasyonun bütününde hissedilmesinin zorlaştığı düşünülebilir. Buna karşılık organizasyonun çevikliği, karar alma süreçlerinin hızlanmasıyla doğrudan ilişkilidir. Çünkü hızlı karar alamayan bir organizasyonun anlık değişimlere cevap vermesi -dolayısıyla çevikleşmesi- zorlaşır. JIT, bir organizasyonun ihtiyaç duyulan ürün veya hizmeti, ihtiyaç duyulduğu kadar ve ihtiyaç duyulduğu anda üretmesidir [1,2]. Yazılım geliştiren organziasyon- larda JIT yaklaşımı, çapraz fonksiyonlu ve kendi kendine yetebilen üretim bi- rimlerinin kurulması, yazılımın takip ettiği gelişim sürecinde yer alan adımlar arasın- da beklemelerin yok edilmesi, üretim birimlerinde yer alan bireylerin kendi bireysel hedeflerine değil; üretim biriminin yapacağı nihai üretim hedefine odaklanmaları şeklinde ortaya çıkar. JIT, bu perspektifi sağlamak için değer akışı haritalama, görselleştime, yapılan işi limitleme, çekme sistemi kullanma gibi somut bazı pratik- lerden faydalanır. Çevik Manifesto’nun dayandığı birçok prensibin [19] arka planında JIT yaklaşımına ait bu pratiklerin izleri bulunmaktadır. 1970’li yıllardan sonra Japonya’nın yalın tecrübesi Avrupa ve Kuzey Ameri- ka’ya yayılmaya başlamış ve hem sanayide hem de yazılım geliştirme meto- dolojilerinde yeni pencereler açmaya başlamıştır[13]. Günümüzde dünyanın en yaygın çevik çerçevesi durumundaki Scrum[13,14,17] başta olmak üzere pekçok çevik çerçeve ve çevik çalışmaya başlayan organizasyonlar yalın yaklaşımdan esinlenerek çevikliğe ulaşmayı hedeflemişlerdir. Çevik çerçevelerin ilk örnekleri çoğunlukla küçük üretim birimlerini (çevik takım) hedeflemiş ve bu ölçekteki organi- zasyonlarda çoğunlukla başarılı olmuşlardır. ‘Büyük ölçekte çeviklik’ ise oluşan başarısızlık örnekleri ile ivmelenmeye başlamıştır. XP[20], Scrum, FDD[21] gibi pek çok çevik çerçevenin büyük ölçekli organizasyonlarda başarı şansı azalmaktadır[18]. Küçük ölçekli çevik çerçevelerde ekiplerdeki insan sayısı sınırlandırılır. Örneğin Scrum ve onun dayandığı deneysel süreç kontrolü [22], 9 kişiyi aşmayan geliştirme ekiplerini önermektedir. Üretilecek yazılımın zorluğu ve büyüklüğü 9 kişinin altından kalkamayacağı kadar büyük olduğunda aşağıdaki olasılıklar ortaya çıkmaktadır: 1. Geliştirme ekibindeki kişi sayısı sınır konulmaksızın artırıldığında ekibin iletişim maliyeti artmakta, çerçeveye ait aktiviteleri zamanında tamamlama olasılığı za- yıflamakta, çevik çalışmadan elde edilen kazanç ortadan kaybolmaktadır. 2. Yazılım, birden fazla ekipte ele alınacak şekilde geliştiridiğinde ekipler arası bağımlılık ve bu bağımlılıktan kaynaklanan entegrasyon sorunları ortaya çıkmak- tadır. 3. Çevik çalışma yerine geleneksel çalışma yöntemleri uygulamak veya bilinen çerçevelerin dışına çıkıp kurum özelinde geliştirilmiş çerçeveler kullanmak gerek- mektedir. Görüleceği gibi, büyük ölçekte çevik çalışma modelinin inşası o kadar kolay olamamaktadır. Bu nedenle son yıllarda Nexus[15], Less[23], Safe[24] gibi büyük ölçekte çeviklik çerçeveleri oluşmaya başlamıştır. Bu çerçeveler, büyük bir organi- zasyonda çevikliğe bakış konusunda perspektifler sunmakta, ancak bu perspektifler bazı risklerin doğmasına sebep olmaktadır. Örneğin Nexus çerçevesi, Scrum çerçevesini yapı taşı kabul eden ölçekli bir çevik çerçevedir. 9 çevik ekibin aynı anda aynı yazılım üzerinde çalışmasını destekleyebilmektedir. Ancak çerçevede, bu yazılımın yol haritasına karar veren bir ürün sahibi bulunmaktadır. Yani organi- zasyondaki tek bir kişinin, geliştirmesini 9 farklı ekibin yaptığı bir yazılıma ait tüm paydaş iletişimini tek başına yapabileceği varsayılmaktadır. Scrum çerçevesinde ortaya çıkan iletişim maliyeti yok edilmemekte, sadece organizasyondaki tek bir kişinin sorumluluğu haline getirilmektedir. Dolayısıyla çerçevenin başarısı bu olağanüstü maliyeti karşılayacak kişinin bireysel yetkinliğine dayanmaktadır. Litera- türde büyük ölçekli çevik yaklaşımlar, daha çok mevcut organizasyonun çevik orga- nizasyona evrilmesi ile ilgili olup [18], çevik çalışmayı zaten başarmış büyük ölçekli organizasyonların kendilerini nasıl daha olgun bir organizasyon haline getire- bileceklerine dair yeterli veri sunmamaktadırlar. Oysa çevik çalışmadan maksat, değişime daima cevap verebilen, üretilen değeri artırmaya odaklı, yüksek performanslı, esnek ve sürekli kendisini iyileştiren bir or- ganizasyona ulaşmaktır. Çevik çerçevelerin mevcut olgunluk durumu düşünüldüğün- de, büyük organizasyonlarda bu amaca ulaşılabilmesi için organizasyon özelinde deneysel çalışmalara yönelmek kaçınılmaz gözükmektedir. Çevik çalışma tarihsel olarak önce küçük ölçekli organizasyonlarda uygulanmaya başlanmış olmasına ragmen, esin kaynağı olan yalın yaklaşım büyük ölçekli organi- zasyonlarda en iyi pratiklerini ortaya çıkarmıştır. Bu çelişkinin kaynağında yatan sebepler büyük oragnizasyonlar için yol gösterici olabilirler. Büyük oragnizasyonlar, yalın yaklaşıma ait pratikleri çevikleşmek için doğrudan alıp kullanma yoluna da gidebilirler [3,5]. Bu çalışmada, çevik çalışmanın temel amaçlarından biri olan “organizasyonun kendisini iyileştirmesi” üzerine yapılan deneysel bir yaklaşım yer almaktadır. Bu yaklaşım bundan sonraki bölümlerde “deney” olarak isimlendirilecektir. Deney büyük ölçekli bir organizasyonda yapılmış olup, deney sırasında yalın ve çevik yaklaşıma ait çok sayıda yöntem, çerçeve ve pratik bir arada kullanılmaktadır. 2 Yalın ve Çevik Yaklaşımda İyileştirme Faaliyetleri: Farklılıklar ve Benzerlikler İyileştirme (KaiZen [4]) faaliyetleri yalın bir organizasyonda [6] çoğunlukla yalın altı sigma süreç iyileştirme çalışmaları ile disipline edilir [7]. Bu çalışmalar kapsamında organizasyonun kullandığı araç, teknoloji ve süreç sürekli olarak iyileştirilir ve/veya izlenir. İyileştirmenin ortaya çıkması için daima bir problemin ortaya çıkmasına ih- tiyaç yoktur; organizasyon daima daha iyiye doğru gitme eğilimindedir. Yalın Altı Sigma istatistik veriye dayalı bir yaklaşıma sahiptir; verinin analiz edilmesiyle israfın yok edilmesine, üretim veya tedarikte ihtiyaç duyulan çevrim süresinin kısaltılmasına, problem alanlarının tespit edilip yok edilmesine odaklanır [8,9]. İyileştirme faaliyetleri çevik bir organizasyonda ise çoğunlukla retrospektif çalışmalarıyla disipline edilir. İteratif (döngüsel) olarak yazılım geliştiren çevik takımlar çoğunlukla her iterasyon (döngü) bitiminde retrospektif toplantısı yaparlar. Bu toplantının amacı tamamlanan iterasyonda öğrenilen derslerin neler olduğunu bulmak ve bu sayede sürekli iyleşmenin kapısını açmaktır [16]. Çevik takımlar, kullandıkları çevik çerçeveye bağlı olarak geliştirdikleri yazılım başta olmak üzere tüm ürün, araç ve süreçleri daima iyileştirme eğilimindedirler. İyileştirmenin ortaya çıkması için daima bir problemin ortya çıkmasına ihtiyaç yoktur; retrospektif top- lantısı her iterasyon bitiminde tekrarlanır. Retrsopektif toplantısı sırasında veri toplanır veya önceden toplanmış veriler analiz edilir. Toplanan veri, yalın altı sigma’da olduğu gibi istatistik temelli bir veri olmak zorunda değildir. Toplantı katılımcılarının duygu durumları, geçen iterasyonda ortaya çıkan bir gerilim veya elde edilen güzel bir başarı bile veri kabul edilebilir. Verinin analiz edilmesi sırasında yalın altı sigma daha metodolojik bir yol takip ederken; ret- rospektif çalışmasında standart bir metodoloji kullanılmaz; ekip kendi kendisine or- ganize olmasının bir getirisi olarak veriyi analiz edecek yöntem ve araçlara kendisi karar verebilir. Organizasyonun ölçeği büyüdükçe yalın alti sigmada kullanılan istatistik temelli yöntemler bir zaafa uğramamakta sadece uğraşılacak veri kümesi büyümektedir. Or- ganizasyon ölçeği büyüdüğünde retrospektif toplantılarının etkinliğine ait belirsizlik artmaktadır: 1. Ekip seviyesinde toplanan veri ekibin yaşadığı problemlere ışık tutmaya yetme- yebilir. Büyük organizasyonlarda ekipleri bağımlı kılan, onları bekleten veya verimsiz kılan çok sayıda etken ortaya çıkabilir. Dolayısıyla ekibin kendi iç dina- miklerinin yanı sıra onu kuşatan çevre koşulllarına da hakim olması gerekir. 2. Büyük ölçekte Kaizen faaliyetlerini tek bir ekibin tetiklemesi oldukça güçtür. Örneğin tek bir ekibin kullandığı yazılım yaşam döngüsünün iyileştirilmesi ile on- larca ekip tarafından kullanılan yazılım yaşam döngüsünün iyileştirilmesi aynı se- viyede kolay değildir. Üstelik tüm ekiplere hitap eden böylesi süreçlerin iyileştirilmesi kararını tek bir ekibin vermesi mümkün değildir. Öte yandan istatistik veriler iyileştirmenin tek tetikleyicisi olamazlar. Retrsopektif toplantıları bazı iyileştirme türlerinde yalın altı sigma’ya göre daha etkin olabilir: 1. Kişiler arası iletişimin kalitesine ait doğrudan bir istatistik veri oluşturmak im- kansızdır; ancak “iletişimin iyileştirilmesi” olgusu bir gerçektir ve çevik çalışan bir ekip bu konuda iyileştirme faaliyeti yapmaya karar verebilir. 2. Bireylerin motivasyonu, mutlu olup olmadıkları, psikolojik güvenlik durumları, takım ve organizasyon aidiyetleri gibi pek çok olgu anlık olarak sayısal verilere dönüştürülemezler. Ancak bu olgulardan hareketle organizasyonun mikro seviyede (ekip ve bireyler seviyesinde) kendisini gözlemlemesi ve iyileştirmeler yapması retrospektif toplantılarıyla mümkündür. 3 Yöntem Bu bölümde çevik çalışan bir organizasyonda yapılan deney hakkında bilgiler sunulmuştur. Deneyin amacı büyük ölçekli bir organizasyonda sürekli iyileşme faali- yetlerinin etkinliğini artırmaktır. Çevik çalışan bu organizasyon uluslararası bir teknoloji ve telekomünikasyon şirketindeki birimlerden biridir. 3.1 Mevcut Çevik Organizasyon Yapısı Çevik organizasyon, firmanın servis, tarife ve kampanya kurgularına ait talepleri hayata geçiren, ele aldığı talepleri ortalama 10 gün altı sürede teslim edebilen 9 çevik takımdan oluşmaktadır. Bu 9 takım aşağıdaki çevik çerçeveyi takip etmektedirler: 1. Her ekip Kanban çekme sistemini işletmekte, değer akışını bir pano üzerinde görselleştirmektedir. 2. Değer akışları yazılım yaşam döngüsüne ait belli başlı tüm adımları (olgunlaştırma, kurulum, analiz, test…vs) bünyesinde taşımaktadırlar. 3. Ekipler Scrum çerçevesine ait aktiviteleri (planlama toplantısı, günlük toplantı, ret- rospektif toplantısı…vs) 1 aylık iterasyon süresinde gerçekleştirmektedirler. 4. Ekipler Scrum çerçevesine ait rollere sahiptirler. (Master, ürün sahibi ve geliştirme ekibi) 5. Ekipler birbirleri arasında ortaya çıkan küçük bağımlılıkları Kanban iş kartlarını ilgili panoya taşıma yoluyla çözmektedirler. 6. Ekipler büyük çaplı bağımlılıklarından kaynaklanan sorunları idari birim yönetici- lerinin çözmesini beklemektedirler. 7. Ekipler bir araç vasıtasıyla organizasyondaki değer akışlarına ait tüm istatistik ve- riyi toplayabilmekte; israf noktalarını istatistik veri üzerinden açığa çıkararak verimlilik hesapları yapabilmektedirler. 8. Ekip üyelerinin tamamı aynı fiziksel ortamda bulunmakta ve rahatlıkla yüz yüze iletişim kurabilmektedirler. 9. Retrospektif toplantıları sırasında çoğunlukla “deniz yıldızı”, “üzgün-kızgın- mutlu” gibi geleneksel retrospektif yöntemleri kullanılmaktadır. Yukarıdaki çerçevenin bir yıl süreyle organizasyon tarafından takip edilmesi so- nunda, ekiplerin retrospektif çıktılarında yer alan iyileştime önerileri ile ilgili olarak 3 temel sorun şekillenmiştir: 1. İyileştirme önerilerinin çok azı hayata geçebilmektedir. Hayata geçenlerin organi- zasyonun bütününe sağladığı fayda belirsizdir. 2. Ekipler aynı iyileştirme önerilerini birbirlerinden habersiz ve mükerrer şekilde farklı zaman dilimlerinde yapabilmekte, birbirlerinin deneyimlerinden fayda- lanmakta zayıf kalmaktadırlar. 3. Bazı ekiplerin iyileştirme kapsamında yaptığı çalışmalar, başka bazı ekiplerin değer akışlarında israfa sebep olup rahatsızlık oluşturabilmektedir. 3.2 Deney Çerçevesi Yukarıda sayılan problem alanlarının iyileştirilmesi maksadıyla diğer tüm para- metreler sabit kalmak şartıyla orgnaizasyonun iyileştirme faaliyetlerini yapma biçimi aşağıdaki şekilde düzenlenmiştir: İterasyon süresince yapılan retrospektif toplantılarının sayısı 2’ye çıkarılmıştır. İletişimde kolaylık sağlaması için isimleri “Retrospektif” ve “Kaizen” toplantısı olacak şekilde değiştirilmiştir. Yalın altı sigma yaklaşımlarından DMAIC [10,11,12] , bu toplantıların girdi ve çıktılarını belirlemek için kullanılmıştır. Şekil 1. Altı Sigma DMAIC metodolojisi Şekil 1’de görüldüğü gibi DMAIC metodoloijsi iyileşme veya bir problem alanının tanımlanması, ölçülmesi, analiz edilerek geliştirme aksiyonlarının belirlenmesi ve bu aksiyonların oluşturduğu etkinin kontrolünü esas alır. Organizasyondaki 9 çevik ekip DMAIC kullandıkları toplantılarını en fazla birkaç gün farkla aynı hafta içerisinde yapmakta, ortaya çıkan iyileştirme önerilerini ortak bir havuzda toplamaktadırlar. 9 çevik ekibin gönüllü temsilcilerinden bir komite oluşturulmuştur. Bu komite havuzda toplanan iyileştirme önerilerinin organizasyonun geneline katkısını ölçmekte, katkısı yetersiz bulunan önerileri ilgili ekibe iletmektedir. Oluşturulan bu komite, kurgulanan sürecin garantörüdür ve iyileştirme önerilerinin seçimini yapan otorite durumundadır. İyileştirmelerin hayata geçmesi konusunda sponsorluk yapar. Bu açıdan bakıldığında yalın altı sigma içerisindeki roller (‘Şampiyon’, ‘Siyah Kuşak’ …vs)’e ait bazı işlevlere sahiptir. Şekil 2. İyileştirme döngüsünde aktif iterasyon anı Şekil 2’de görüldüğü üzere retrospektif çalışması, kendinden önceki Kaizen çalışmasına ait iyileştirmelerin kontrol edilmesinden ve bu kontrol sonucunda oluşan veriye dayalı olarak yeni iyileşme alanlarının tanımlanmasından sorumludur. Kaizen çalışması, kendinden önceki retrospektif çalışmasında tanımlanmış iyileşme alanının ölçülmesi, analiz edilmesi ve iyileştirme aksiyonlarının belirlen- mesinden sorumludur. İyileştirmelerin iterasyon süresince ekip tarafından sürekli olarak hayata geçirilmesi ve ilgili komite ile istişare edilmesi gerekmektedir. Aksi halde kontrol adımı icra edilemeyeceğinden tanımlama adımı hiç oluşmayacaktır. Kurgulanan yapı, az sayıda iyileştirmenin hayata geçmesini, hayata geçmeyen çok sayıda öneri oluşturmaktan kıymetli görmektedir. Kaizen çalışmasında belirlenen aksiyonların tamamının hayata geçmesi ve kontrolleri sırasında yeni iyileşme alanlarının ortaya çıkmaması halinde çevik ekibin yeni bir iyileşme alanı tanımlaması gerekecektir. İyileşme alanlarının tanımlanması sırasında bu aşamada sadece DMAIC kapsamındaki istatistiksel veri değil; sayısal olmayan veriler de ekip seviyesinde kullanılabilmektedir. Ancak Kaizen çalışması sırasında bu verinin ölçülebilir hale gelmesi gerekir ki iyileşme aksiyonlarına karar verilebilsin. Dolayısıyla Kaizen çalışması sırasında ilgili ekibin gelişim alanlarını subjektif şekilde değil veriyle tarif etmesi gerekmektedir. Örnek: Ekibin iş bazında teslimat hızı sürekli düşmektedir ve son iterasyonda teslimat süresi12 güne çıkmıştır. Oysa deney koşullarında ifade edildiği gibi beklenti 10 gün altıdır. Retrospektif sırasında bu ekibin iyileşme alanı “ekibin yavaş olması” şeklinde tanımlanabilir. Kaizen çalışması sırasında bu iyileşme alanı “ekibin birim üretim hızının beklentinin 2 gün altında olması” şeklinde ifade edilebilir. Aynı çalışma kapsamında oluşturulan iyileştirme aksiyonları da benzer şekilde “ekip üretim hızının %18 seviyesinde artırılması” gibi sayısal net hedeflerle ifade edilmektedir. Çünkü ancak o şekilde bir sonraki retrospektif çalışmasında ortaya ko- nan iyileşme kontrol edilebilir. 3.3 Bulgular ve Tartışma Yeni retrospektif modeline 9 ekibin aynı anda uyumu zorluk oluşturmaktadır. “Kendi kendine organize olma” prensibi daha çok ekip içi faaliyetler söz konusu olduğunda geçerlidir. Oysa yeni yapıda tüm çevik organizasyonun birlikte hareket etmesi ve organize olması gerekmektedir. Zaman zaman faaliyet takvimlerinde sarkmalar oluşmakta, ortaya çıkan iyileştirme önerilerinin değerlendirildiği komite çalışmaları gecikebilmektedir. Bireyler ekiplerinde gördükleri gelişim alanlarını ölçülebilir net hedeflerle ifade etme konusunda destek ihtiyacı hissetmektedirler. DMAIC için gerekli olan verinin kaliteli ve sürdürülebilir şekilde sağlanması en büyük zorluğu oluşturmaktadır. Değer akışlarına ait ölçüm verisini toplayan araç, akışı işleten bireylerin şeffaf ve titiz bir şekilde veri girişi yapmasına bağımlıdır. Veri kalitesinin artırılması için zaman zaman organizasyonda denetim faaliyetleri ve özendirici oyunlaştırma faaliyetleri de yapılmak zorunda kalınmıştır. 4 Sonuçlar ve Gelecek Çalışmaları Deney sonuçları 1 yıldan uzun bir süre gözlemlenmiştir. Deneyin yapılmasına sebep olan problem alanlarında bazı iyileşmeler olmuşur: 1. Hayata geçen iyileştirme aksiyonlarının sayısı halen çok azdır (Önerilerin %10’undan azı). Ancak organizasyon hayata geçen iyileştirme aksiyonlarının getirdiği faydanın net olarak farkındadır. Bu nedenle maliyet-fayda ilişkisi üzerin- den ilerleyerek düşük maliyetli ve yüksek seviyede fayda oluşturan aksiyonlara yönelmenin önemi organizasyon tarafından öğrenilmiştir. 2. Ekiplerin aynı iyileştirme önerilerini farklı zamanlarda tekrar tekrar yapmalarının tamamen önüne geçilmiştir. Ekipler bazı iyileştirme önerileri için birlikte çalışmak- ta veya birbirlerinin önerilerini zenginleştirme çabası gösterebilmektedirler. 3. İyileştrme önerilerinin bazı takımları değil; tüm organizasyonu iyileştirmesi ge- rektiği konusunda konsensüs oluşmuştur. Ancak bu noktada halen organizasyonun bazı gelişim alanları bulunmaktadır. Organizasyondaki bireylerin etkileşimlerinde açığa çıkan değişim gözle görülür seviyededir. Takımlar kendi çevikliklerinin organizasyonun çevikliğine hizmet eden bir alt küme olduğunu farketmişlerdir. Bu nedenle rahatsızlık duydukları konularda “suçlamak ve şikayet etmek” yerine “konuşmak, verilerle destekleyerek uzlaşma sağlamak” daha değerli bir yol olarak görülmektedir. Bireyler kendi seslerini retros- pektif toplantılarında ekiplerine, ekipler ise kendi seslerini komite toplantıları sayesinde tüm organizasyona duyurabilmektedirler. Takımları kuşatan bir ahenk oluşmuştur ve bu ahenk bir birey veya yöneticinin sorumluluğundan kaynaklanan bir denetim faaliyetiyle değil; tamamen “etkileşimlerin kendisini sürekli iyileştirmesi” ile sağlanmıştır. DMAIC ile desteklenen bu yapının en zayıf yanı, DMAIC’yi besleyen istatistik ve- rilerin kaliteli ve sürdürülebilir şekilde sağlanmasıdır. Gelecek dönemde organizasyon bu zafiyeti ortadan kaldırmak için bazı araçlar geliştirme ve özendirici faaliyetler ortaya koyma düşüncesindedir. Kaynaklar 1. Y. Sugimori , K. Kusunoki , F. Cho & S. Uchikawa: Toyota production system and kanban system materialization of just-in-time and respect-for-human system. The International Journal of Production Research, 15:6, 553-564 (1977) 2. T. Ohno: Toyota Production System: Beyond Large-Scale Production. CRC Press, USA (1988) 3. Danovaro, Emanuele & Janes, Andrea & Succi, Giancarlo: Jidoka in software develop- ment. OOPSLA Companion '08, 827-830. Nashville, TN, USA (2008) 4. García, J.L., Maldonado, A.A., Alvarado, A. :Human critical success factors for kaizen and its impacts in industrial performance. The International Journal of Advanced Manufactur- ing Technology 70: 2187-2198 (2014) 5. Poppendieck, Mary: Lean software development. In: Companion to the proceedings of the 29th International Conference on Software Engineering. IEEE Computer Society, p. 165- 166 (2007) 6. Tortorella G.L., de Castro Fettermann D., Marodin G.A., Fogliatto F.S.: Lean Product De- velopment (LPD) Enablers for Product Development Process Improvement. In: Davim J. (eds) Research Advances in Industrial Engineering. Management and Industrial Engineer- ing. 31-57 Springer, Cham (2015) 7. Pyzdek, Thomas, Paul A. Keller : The six sigma handbook. Vol. 4. McGraw-Hill Educa- tion, New York (2014) 8. Jacobs, Brian W., Morgan Swink, and Kevin Linderman.: "Performance effects of early and late Six Sigma adoptions." Journal of Operations Management 36:244-257 (2015) 9. Tjahjono, Benny & Ball, Peter & Vitanov, V.I. & Scorzafave, C & Nogueira, J & Calleja, J & Minguet, M & Narasimha, L & Rivas, A & Srivastava, A & Srivastava, S & Yadav, A. :Six Sigma: a literature review. International Journal of Lean Six Sigma. 1. 216-233.(2010) 10. Pyzdek, Thomas: The six sigma project planner: a step-by-step guide to leading a six sig- ma project through DMAIC. McGraw-Hill, New York (2003) 11. Fornari, A., & Maszle, G. :Lean six sigma leads Xerox. In Six Sigma Forum Magazine Vol. 3, No. 4, pp. 11-16 (2004) 12. Tonini, Antonio Carlos; Spinola, Mauro De Mesquita; Laurindo, Fernando Jose Barbin: Six Sigma and software development process: DMAIC improvements. In: Technology Man- agement for the Global Future, 2006. PICMET 2006. IEEE, 2006. p. 2815-2823 (2006) 13. Takeuchi, Hirotaka & Nonaka, Ikujiro.:“The New New Product Development Game.” Harvard Business Review DOI: 10.1225/86116 (1986) 14. Schwaber, Ken.: Scrum development process. In: Business object design and implementa- tion. Springer, London, p. 117-134 (1997) 15. Bittner, K., Kong, P., Naiburg, E., & West, D. :The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams. Addison- Wesley Professional,Boston (2017) 16. Derby, Esther, Diana Larsen, Ken Schwaber: Agile retrospectives: Making good teams great. Pragmatic Bookshelf,USA (2006) 17. State of Agile, http://stateofagile.versionone.com/, erişim Haziran 2018 18. Dikert, Kim, Maria Paasivaara, Casper Lassenius: "Challenges and success factors for large-scale agile transformations: A systematic literature review." Journal of Systems and Software 119:87-108 (2016) 19. Çevik Manifesto, http://agilemanifesto.org/iso/tr/manifesto.html, erişim Haziran 2018 20. Xtreme Programming , http://www.extremeprogramming.org/, erişim Haziran 2018 21. Feature Driven Development, http://www.featuredrivendevelopment.com/,erişim Haziran 2018 22. Dybå, Tore, Torgeir Dingsøyr :"Empirical studies of agile software development: A sys- tematic review." Information and software technology 50.9-10, 833-859 (2008) 23. Large Scale Scrum, https://less.works/,erişim Haziran 2018 24. Scaled Agile Framework, https://www.scaledagileframework.com/, erişim Haziran 2018