<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Yalın Altı Sigma Yaklaşımlarının Çevik Retrospektiflere Uygulanması</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Engin Çallı</string-name>
          <email>calli.engin@turkcell.com.tr</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Gökhan Turan</string-name>
          <email>gokhan.turan@turkcell.com.tr</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Anahtar Kelimeler: Çeviklik</institution>
          ,
          <addr-line>Kaizen, Retrospektif, Altı Sigma,Yalın</addr-line>
        </aff>
      </contrib-group>
      <abstract>
        <p>Ö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ışmaları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) faaliyetlerinin 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.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Abstract. The agile manifesto sees "individuals and interactions" as more
valuable than the "processes and tools" used. The number of possible relationships
in an organization consisting of 100 individuals is 4950, while possible
relationships 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
depends 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
(improvement) activities in retrospective outputs. However, the main motivation for a
retrospective meeting is to make low cost and high benefit improvements.</p>
      <p>
        In this study, a retrospective method is proposed for large-scale agile
organizations. The method is based on the interactions that constantly improve
processes 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.
1
20. yüzyılın başlarından itibaren Japonya’da gelişme göstermeye başlayan yalın
yaklaşım iki temel üzerine inşa edilmiştir[
        <xref ref-type="bibr" rid="ref1 ref2">1,2</xref>
        ]:
1. Jidoka (Otonomasyon)
2. JIT (Tam zamanlı üretim)
      </p>
      <p>
        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 [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. 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[
        <xref ref-type="bibr" rid="ref19">19</xref>
        ]’nun dayandığı “kendi
kendine organize olma” prensibinin tarihsel esin kaynağını oluşturmaktadır.
Organizasyondaki 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.
      </p>
      <p>
        JIT, bir organizasyonun ihtiyaç duyulan ürün veya hizmeti, ihtiyaç duyulduğu
kadar ve ihtiyaç duyulduğu anda üretmesidir [
        <xref ref-type="bibr" rid="ref1 ref2">1,2</xref>
        ]. Yazılım geliştiren
organziasyonlarda JIT yaklaşımı, çapraz fonksiyonlu ve kendi kendine yetebilen üretim
birimlerinin kurulması, yazılımın takip ettiği gelişim sürecinde yer alan adımlar
arasında 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ı
pratiklerden faydalanır. Çevik Manifesto’nun dayandığı birçok prensibin [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] arka planında
JIT yaklaşımına ait bu pratiklerin izleri bulunmaktadır.
      </p>
      <p>
        1970’li yıllardan sonra Japonya’nın yalın tecrübesi Avrupa ve Kuzey
Amerika’ya yayılmaya başlamış ve hem sanayide hem de yazılım geliştirme
metodolojilerinde yeni pencereler açmaya başlamıştır[
        <xref ref-type="bibr" rid="ref13">13</xref>
        ]. Günümüzde dünyanın en
yaygın çevik çerçevesi durumundaki Scrum[
        <xref ref-type="bibr" rid="ref13 ref14 ref17">13,14,17</xref>
        ] 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
organizasyonlarda ç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[
        <xref ref-type="bibr" rid="ref20">20</xref>
        ], Scrum, FDD[
        <xref ref-type="bibr" rid="ref21">21</xref>
        ] gibi pek
çok çevik çerçevenin büyük ölçekli organizasyonlarda başarı şansı azalmaktadır[
        <xref ref-type="bibr" rid="ref18">18</xref>
        ].
      </p>
      <p>
        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ü [
        <xref ref-type="bibr" rid="ref22">22</xref>
        ], 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ığı
zayı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
çıkmaktadı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
gerekmektedir.
      </p>
      <p>
        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[
        <xref ref-type="bibr" rid="ref15">15</xref>
        ], Less[
        <xref ref-type="bibr" rid="ref23">23</xref>
        ], Safe[
        <xref ref-type="bibr" rid="ref24">24</xref>
        ] gibi büyük
ölçekte çeviklik çerçeveleri oluşmaya başlamıştır. Bu çerçeveler, büyük bir
organizasyonda ç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
organizasyondaki 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.
Literatürde büyük ölçekli çevik yaklaşımlar, daha çok mevcut organizasyonun çevik
organizasyona evrilmesi ile ilgili olup [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ], çevik çalışmayı zaten başarmış büyük ölçekli
organizasyonların kendilerini nasıl daha olgun bir organizasyon haline
getirebileceklerine dair yeterli veri sunmamaktadırlar.
      </p>
      <p>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
organizasyona ulaşmaktır. Çevik çerçevelerin mevcut olgunluk durumu
düşünüldüğünde, büyük organizasyonlarda bu amaca ulaşılabilmesi için organizasyon özelinde
deneysel çalışmalara yönelmek kaçınılmaz gözükmektedir.</p>
      <p>
        Ç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
organizasyonlarda 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 [
        <xref ref-type="bibr" rid="ref3 ref5">3,5</xref>
        ].
      </p>
      <p>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</p>
    </sec>
    <sec id="sec-2">
      <title>Yalın ve Çevik Yaklaşımda İyileştirme Faaliyetleri:</title>
      <p>
        Farklılıklar ve Benzerlikler
İyileştirme (KaiZen [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]) faaliyetleri yalın bir organizasyonda [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] çoğunlukla yalın altı
sigma süreç iyileştirme çalışmaları ile disipline edilir [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. 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
ihtiyaç 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 [
        <xref ref-type="bibr" rid="ref8 ref9">8,9</xref>
        ].
      </p>
      <p>
        İ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 [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ]. Ç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
toplantısı her iterasyon bitiminde tekrarlanır.
      </p>
      <p>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;
retrospektif çalışmasında standart bir metodoloji kullanılmaz; ekip kendi kendisine
organize olmasının bir getirisi olarak veriyi analiz edecek yöntem ve araçlara kendisi
karar verebilir.</p>
      <p>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.
Organizasyon ö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
yetmeyebilir. 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ç
dinamiklerinin 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
onlarca ekip tarafından kullanılan yazılım yaşam döngüsünün iyileştirilmesi aynı
seviyede 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.</p>
      <p>Ö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
imkansı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</p>
      <sec id="sec-2-1">
        <title>Yöntem</title>
        <p>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
faaliyetlerinin etkinliğini artırmaktır. Çevik çalışan bu organizasyon uluslararası bir
teknoloji ve telekomünikasyon şirketindeki birimlerden biridir.
3.1</p>
        <p>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ı,
retrospektif 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öneticilerinin çözmesini beklemektedirler.
7. Ekipler bir araç vasıtasıyla organizasyondaki değer akışlarına ait tüm istatistik
veriyi 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ınmutlu” gibi geleneksel retrospektif yöntemleri kullanılmaktadır.</p>
        <p>Yukarıdaki çerçevenin bir yıl süreyle organizasyon tarafından takip edilmesi
sonunda, 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
organizasyonun 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
faydalanmakta 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</p>
        <p>Deney Çerçevesi
Yukarıda sayılan problem alanlarının iyileştirilmesi maksadıyla diğer tüm
parametreler sabit kalmak şartıyla orgnaizasyonun iyileştirme faaliyetlerini yapma biçimi
aşağıdaki şekilde düzenlenmiştir:</p>
        <p>
          İ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 [
          <xref ref-type="bibr" rid="ref10 ref11 ref12">10,11,12</xref>
          ] ,
bu toplantıların girdi ve çıktılarını belirlemek için kullanılmıştır.
        </p>
        <p>Ş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.</p>
        <p>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.</p>
        <p>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.</p>
        <p>Ş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.</p>
        <p>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
belirlenmesinden sorumludur.</p>
        <p>İ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.</p>
        <p>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.</p>
        <p>İ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.</p>
        <p>Ö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
konan iyileşme kontrol edilebilir.
3.3</p>
        <p>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.</p>
        <p>Bireyler ekiplerinde gördükleri gelişim alanlarını ölçülebilir net hedeflerle ifade
etme konusunda destek ihtiyacı hissetmektedirler.</p>
        <p>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</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Sonuçlar ve Gelecek Çalışmaları</title>
      <p>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
üzerinden 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ışmakta veya birbirlerinin önerilerini zenginleştirme çabası gösterebilmektedirler.
3. İyileştrme önerilerinin bazı takımları değil; tüm organizasyonu iyileştirmesi
gerektiği konusunda konsensüs oluşmuştur. Ancak bu noktada halen organizasyonun
bazı gelişim alanları bulunmaktadır.</p>
      <p>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
retrospektif 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.</p>
      <p>DMAIC ile desteklenen bu yapının en zayıf yanı, DMAIC’yi besleyen istatistik
verilerin 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.</p>
      <sec id="sec-3-1">
        <title>Kaynaklar</title>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <given-names>Y.</given-names>
            <surname>Sugimori</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Kusunoki</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Cho</surname>
          </string-name>
          &amp; S. Uchikawa:
          <article-title>Toyota production system and kanban system materialization of just-in-time and respect-for-human system</article-title>
          .
          <source>The International Journal of Production Research</source>
          ,
          <volume>15</volume>
          :
          <fpage>6</fpage>
          ,
          <fpage>553</fpage>
          -
          <lpage>564</lpage>
          (
          <year>1977</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2. T. Ohno:
          <article-title>Toyota Production System: Beyond Large-Scale Production</article-title>
          . CRC Press, USA (
          <year>1988</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Danovaro</surname>
            , Emanuele &amp; Janes, Andrea &amp; Succi,
            <given-names>Giancarlo:</given-names>
          </string-name>
          <article-title>Jidoka in software development</article-title>
          .
          <source>OOPSLA Companion</source>
          '
          <volume>08</volume>
          ,
          <fpage>827</fpage>
          -
          <lpage>830</lpage>
          . Nashville,
          <string-name>
            <surname>TN</surname>
          </string-name>
          , USA (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>García</surname>
            ,
            <given-names>J.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Maldonado</surname>
            ,
            <given-names>A.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Alvarado</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Human critical success factors for kaizen and its impacts in industrial performance</article-title>
          .
          <source>The International Journal of Advanced Manufacturing Technology</source>
          <volume>70</volume>
          :
          <fpage>2187</fpage>
          -
          <lpage>2198</lpage>
          (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Poppendieck</surname>
          </string-name>
          , Mary:
          <article-title>Lean software development</article-title>
          .
          <source>In: Companion to the proceedings of the 29th International Conference on Software Engineering. IEEE Computer Society</source>
          , p.
          <fpage>165</fpage>
          -
          <lpage>166</lpage>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Tortorella</surname>
            <given-names>G.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>de Castro</surname>
          </string-name>
          Fettermann D.,
          <string-name>
            <surname>Marodin</surname>
            <given-names>G.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fogliatto</surname>
            <given-names>F.S.</given-names>
          </string-name>
          :
          <article-title>Lean Product Development (LPD) Enablers for Product Development Process Improvement</article-title>
          . In: Davim J. (eds) Research Advances in Industrial Engineering. Management and
          <string-name>
            <given-names>Industrial</given-names>
            <surname>Engineering</surname>
          </string-name>
          .
          <fpage>31</fpage>
          -57 Springer, Cham (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Pyzdek</surname>
          </string-name>
          , Thomas, Paul A. Keller :
          <article-title>The six sigma handbook</article-title>
          . Vol.
          <volume>4</volume>
          .
          <string-name>
            <surname>McGraw-Hill</surname>
            <given-names>Education</given-names>
          </string-name>
          , New York (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Jacobs</surname>
          </string-name>
          , Brian W., Morgan Swink, and Kevin Linderman.:
          <article-title>"Performance effects of early and late Six Sigma adoptions</article-title>
          .
          <source>" Journal of Operations Management</source>
          <volume>36</volume>
          :
          <fpage>244</fpage>
          -
          <lpage>257</lpage>
          (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Tjahjono</surname>
          </string-name>
          , Benny &amp; Ball, Peter &amp;
          <string-name>
            <surname>Vitanov</surname>
            ,
            <given-names>V.I.</given-names>
          </string-name>
          &amp;
          <string-name>
            <surname>Scorzafave</surname>
            ,
            <given-names>C</given-names>
          </string-name>
          &amp; Nogueira,
          <string-name>
            <given-names>J</given-names>
            &amp;
            <surname>Calleja</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J</given-names>
            &amp;
            <surname>Minguet</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M</given-names>
            &amp;
            <surname>Narasimha</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L</given-names>
            &amp;
            <surname>Rivas</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A</given-names>
            &amp;
            <surname>Srivastava</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A</given-names>
            &amp;
            <surname>Srivastava</surname>
          </string-name>
          ,
          <string-name>
            <surname>S</surname>
          </string-name>
          &amp; Yadav,
          <string-name>
            <surname>A.</surname>
          </string-name>
          :
          <article-title>Six Sigma: a literature review</article-title>
          .
          <source>International Journal of Lean Six Sigma</source>
          .
          <volume>1</volume>
          .
          <fpage>216</fpage>
          -
          <lpage>233</lpage>
          .(
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Pyzdek</surname>
          </string-name>
          , Thomas:
          <article-title>The six sigma project planner: a step-by-step guide to leading a six sigma project through DMAIC</article-title>
          .
          <string-name>
            <surname>McGraw-Hill</surname>
          </string-name>
          , New York (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Fornari</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          , &amp;
          <string-name>
            <surname>Maszle</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          :
          <article-title>Lean six sigma leads Xerox</article-title>
          .
          <source>In Six Sigma Forum Magazine</source>
          Vol.
          <volume>3</volume>
          , No.
          <issue>4</issue>
          , pp.
          <fpage>11</fpage>
          -
          <lpage>16</lpage>
          (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Tonini</surname>
          </string-name>
          , Antonio Carlos; Spinola, Mauro De Mesquita; Laurindo, Fernando Jose Barbin:
          <article-title>Six Sigma and software development process: DMAIC improvements</article-title>
          .
          <source>In: Technology Management for the Global Future</source>
          ,
          <year>2006</year>
          .
          <article-title>PICMET 2006</article-title>
          . IEEE,
          <year>2006</year>
          . p.
          <fpage>2815</fpage>
          -
          <lpage>2823</lpage>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Takeuchi</surname>
          </string-name>
          , Hirotaka &amp; Nonaka, Ikujiro.:“
          <source>The New New Product Development Game.” Harvard Business Review DOI: 10.1225/86116</source>
          (
          <year>1986</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Schwaber</surname>
          </string-name>
          , Ken.:
          <article-title>Scrum development process</article-title>
          .
          <source>In: Business object design and implementation</source>
          . Springer, London, p.
          <fpage>117</fpage>
          -
          <lpage>134</lpage>
          (
          <year>1997</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Bittner</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kong</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Naiburg</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          , &amp;
          <string-name>
            <surname>West</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams</article-title>
          .
          <source>AddisonWesley Professional</source>
          ,Boston (
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Derby</surname>
          </string-name>
          , Esther, Diana Larsen, Ken Schwaber:
          <article-title>Agile retrospectives: Making good teams great</article-title>
          .
          <source>Pragmatic Bookshelf</source>
          ,USA (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>17. State of Agile, http://stateofagile.versionone.com/, erişim Haziran 2018</mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Dikert</surname>
          </string-name>
          , Kim, Maria Paasivaara, Casper Lassenius:
          <article-title>"Challenges and success factors for large-scale agile transformations: A systematic literature review</article-title>
          .
          <source>" Journal of Systems and Software</source>
          <volume>119</volume>
          :
          <fpage>87</fpage>
          -
          <lpage>108</lpage>
          (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>19. Çevik Manifesto, http://agilemanifesto.org/iso/tr/manifesto.html, erişim Haziran 2018</mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          20.
          <string-name>
            <surname>Xtreme</surname>
            <given-names>Programming</given-names>
          </string-name>
          , http://www.extremeprogramming.org/, erişim Haziran 2018
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>21. Feature Driven Development, http://www.featuredrivendevelopment.com/,erişim Haziran 2018</mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          22.
          <string-name>
            <surname>Dybå</surname>
          </string-name>
          , Tore, Torgeir Dingsøyr :
          <article-title>"Empirical studies of agile software development: A systematic review</article-title>
          .
          <source>" Information and software technology 50</source>
          .
          <fpage>9</fpage>
          -
          <issue>10</issue>
          ,
          <fpage>833</fpage>
          -
          <lpage>859</lpage>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>23. Large Scale Scrum, https://less.works/,erişim Haziran 2018</mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>24. Scaled Agile Framework, https://www.scaledagileframework.com/, erişim Haziran 2018</mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>