Agile Sertifikasyon

Agile Sertifikasyon

Dünya üzerinde bir çok farklı kurum Agile ve Agile yöntemlerin an yaygını olan Scrum için sertifikasyon programı sunmaktadır. Bunların arasında en popüler olanları şu şekilde listeleyebiliriz.

 

• Proje Yönetimi Enstitüsü (PMI),
• Scrum.org
• Scrum Alliance

 

Bu üç kurumun sağladığı sertifikasyonların hangisinin daha önemli ve geçerli olduğu konusunda kesin bir şey söylemek çok doğru olmayacaktır.

 

Agile Proje Yönetimi ve Agile bazlı yöntemlerin en yaygını olan Scrum için sağlanan sertifikaları aşağıdaki tablodaki gibi özetleyebiliriz.

Kurum	Sertifika	Sertifikasyon Bilgileri
PMI	ACP – Agile Certified Practitioner	PMI-ACP sertifikası Agile yöntemler ile ilgili bilgilerin pekiştirilmesi ve ölçülmesi için hazırlanmış bir sertifikasyondur. PMI-ACP  sertifikası için sınav başvuru şartlarından birisi REP statüsünde bir eğitim kurumundan 21 saatlik eğitim alınmasıdır. Diğer şartlar:·         Son 5 yıl içinde 2000 saatlik genel proje tecrübesi
Scrum		BT (yazılım geliştirme) sektörüne özel  sertifikasyonlar
	Professional Scrum Master (PSM) – PSM I, PSM IIProfessional Scrum Product Owner (PSPO)- PSPO I, PSPO II	Belirli ücretler karşılığında, Scrum.org’un sağladığı sınavlara online olarak katılabilir ve sertifika alabilirsiniz.
Scrum Alliance		Scrum prensip ve pratiklerinin BT (yazılım geliştirme) dışında da kullanımını sağlayan ve destekleyen sertifikasyonlar
	Certified Scrum Master (CSM)Certified Scrum Product Owner (CSPO) Certified Scrum Developer (CSD) Certified Scrum Professional (CSP) Certified Scrum Coach (CSC)	Belirli ücretler karşılığında, bu sertifikalar için düzenlenen sınavlara online olarak katılabilir ve sertifika alabilirsiniz.ScrumAlliance.orgsınavlara girmeden önceonaylı bir Scrum eğitimine katılmanızı şart koşmaktadır.

 

 

 

 

 

Scrum Sertifikasyonu

Scrum sertifikasyonu Scrum.org ve ScrumAlliance.org adlı iki organizasyon tarafından gerçekleştirilmektedir.

Bu organizasyonlar Scrum ile ilgilenen kişilere şu imkanları sunmaktadır:

• Scrum ile ilgili kaynaklara erişim
• Fikir ve düşüncelerinizi diğer kişilerle paylaşılabilmesi
• Scrum eğitimleri ile ilgili bilgilere erişim
• Scrum sertifikasyonu ile ilgili bilgilere erişim

Her iki organizasyon tarafından sağlanan sertifikalar ve karşılaştırmalarına yönelik detayları özetlemeye çalışalım.

 

Scrum.org – Scrum Alliance Sertifika Karşılaştırması

• Scrum.org yazılım geliştirme odaklı eğitim ve kurslar düzenlemektedir, Scrum Alliance ise Scrum prensip ve pratiklerinin yazılım dışında da kullanımını zorlamaktadır.
• Scrum.org sınav/sertifika süreçleri daha net tanımlıdır ve kurs ve eğitim materyalleri daha ileri seviyededir.
• Scrum.org eğer Scrum konusunda gerekli bilgi ve tecrübeye sahipseniz, sınavlardan önce eğitim almayı zorunlu kılmaz.
• Scrum.org sınavlarının geçme başarı %’si daha yüksek ve sınavlar seçenekli ve makale yazmaya dayalı sorular içerdiği için daha zordur

Scrum.org – Scrum Guide :  Scrum uygulayan ve eğitim veren profesyonellerin yazılım geliştirme alanında iyileşme sağlamaları için oluşturulan global yapı

• Vizyon : Yazılım geliştirme alanında profesyonelliğin geliştirilmesi 

Scrum Alliance – Scrum Core : Scrum prensip ve pratiklerinin anlaşılması ve kullanımını destekleyen, kar amacı olmayan, profesyonel üyeliklerden oluşan bir organizasyon

 

• Vizyon : İş dünyasının dönüştürülmesi – Transforming the world of work

Kaynak: http://www.projeegitimmerkezi.com/bdetail-d-281-agile-sertifikasyon

Reklam

PMSummit 2015 Ankara – “Kalkınma ve Proje Yönetimi”

PMI (Project Management Institute, www.pmi.org), dünya üzerinde Proje Yönetimi alanında standartları belirleyen lider ve kar amacı gütmeyen küresel bir kurumdur. Dünya üzerinde 700 bini aşkın üyesi ve 204 ülkede 274 yerel dernek (Chapter) ile faaliyetlerde bulunmaktadır.

PMI Türkiye (www.pmi.org.tr), PMI’ın belirlediği standartları ülkemizde yaymak, Proje Yönetimi konusunda farkındalık yaratmak, Türkiye üzerinde yetkin ve yetişmiş Proje Yöneticilerinin sayısını fazlalaştırmak ve rekabet kabiliyetimizi artırabilmek için 600’ün üzerinde üyesiyle Profesyonel Gelişim Faaliyetleri yürüten bir Sivil Toplum Kurumudur.

 

PMI Türkiye, proje yönetimi alanındaki sertifikaların yaygınlaştırılmasını da kendine amaç edinmiştir. PMI tarafından verilen ve dünya çapında 650 binden fazla kişinin sahip olduğu PMP (Project Management Professional) Sertifikasına ait sınav sorularının Türkçeleştirilmesi ve bu sınava baz olan PMBOK^® Kılavuzu’nun (Project Management Body of Knowledge – Proje Yönetimi Bilgi Birikimi Kılavuzu) yerelleştirilmesi yine PMI Türkiye tarafından gerçekleştirilmektedir. Bu sayede Türkiye, PMI tarafından proje yönetimi alanında dünyanın 9’uncu en büyük pazarı olarak belirlenmiştir.

 

PMI Türkiye geleneksel olarak her yıl “PM Summit” markası altında geniş katılımlı Proje Yönetimi Zirvesi düzenlemektedir. Bu yıl 27 Ekim 2015 tarihinde Ankara TOBB ETÜ Sosyal Tesisleri’nde düzenlenecek olan 8’inci Zirvenin teması “Kalkınma ve Proje Yönetimi  (Development of Country and Project Management)” olarak belirlenmiştir.

 

Zirvede Ulaştırma, Finans, Sağlık, Bilişim, Savunma, İnşaat ve Enerji Sektörlerinden değerli konuşmacılar aşağıdaki tema alt başlıklarında sunumlar gerçekleştirecek olup, bunun yanı sıra Bilgi Teknolojileri Proje Yönetiminde Trend bir konu olan Agile Scrum ve Etkili İletişim konularında ana salon oturumlarıyla eş zamanlı workshop oturumları gerçekleştirilecektir. Tüm gün sürecek zirve PMP sertifikalı Proje Yöneticileri için 7 PDU değerindedir.

 

Zirve Tema Alt Başlıkları:

• Kalkınma Programı ve Sürdürülebilir Büyüme
• Paydaş İş Birliği (PPP Projeleri)
• Proje Program Portföy Yönetimi
• Çevresel, Sosyal, Ekonomik ve Kültürel Faktörler
• İnsan Kaynağı Yönetimi
• Proje Başarı Hikayeleri-Öğrenilmiş Dersler
• İletişim ve Problem Yönetimi

 

Bu kapsamda, Ankara’da gerçekleşecek “Kalkınma ve Proje Yönetimi (Development of Country and Project Management)” temalı Proje Yönetim Zirvesi etkinliğimize katılımınız bizi sevindirecektir.

 

Zirve Hakkındaki Detaylı Bilgiye aşağıdaki Adresten ulaşabilirsiniz.

http://pmiturkey.org/summit/ankara/

Zirveye Kayıt Olmak ve Erken Kayıt Fiyat avantajlarından yararlanmak için

Aşağıdaki bağlantıyı kullanabilirsiniz. (Erken Kayıt için Son Gün 31 Ağustos)

Kayıt Olmak için Tıklayın!

Sprint Burndown Chart Nedir?

Sprint Burndown Chart
Scrum’da her Sprint kendi başına bir proje gibi. Kısa zaman dilimleri olan Sprint’lerin her birisinde bir amaca doğru koşuluyor. Sprint Golü de dediğimiz bu amaç aslında Scrum Takımı’nın Sprint’e aldığı işlerin birleşiminden oluşan takımın ana doğrultusu. Takımın her gün Daily Scrum toplantısında yaptığı şey ise sadece 3 soruya cevap vermek olmamalı. “Takım olarak bu Sprint Golü’ne ulaşabilmek için ne durumdayız, nasıl gidiyoruz?” asıl cevaplanması gereken soru.

 

Bu bilgiyi en güzel şekilde gösterebilen görsel araçlardan birisi de Sprint Burndown Grafiği. Bu oldukça basit bir grafik aslında: yatay ekseninde Sprint’in günlerini, düşey ekseninde ise Sprint’te kalan işi gösteren basit bir grafik. Raporlama kültürü yerine bilgiyi yayma kültürünün, komuta kontrol yerine kendi kendini yönetme kültürünün hakim olduğu Scrum Takım’larında çokça da kullanılan bir grafik.

Bu aynı zamanda Scrum çerçevesinin Sprint Backlog (Sprint İş Listesi) ile ilgili olarak söylediği şu özelliğe de uyuyor.
“Sprint İş Listesindeki toplam kalan iş Sprintin herhangi bir anında hesaplanabilir. Geliştirme Takımı, Sprint Hedefini gerçekleştirmeye ne derece yakın olduğunu görebilmesi için en azından her Günlük Scrumda toplam kalan işi izler. Geliştirme Takımı, Sprint boyunca kalan işi izleyerek ilerlemesini yönetebilir.”

Daily Scrum’larda bu “kalan iş” veya “kalan saat” bilgisine odaklanmak önemli. Yapılan önemli yanlışlardan bir tanesi, bir iş üzerinde ne kadar çalışıldığı bilgisini takım arkadaşlarına söylemek. Bu tip durumlarda Scrum Master’ın bir işle ne kadar uğraşıldığı bilgisinin önemli olmadığı, önemli olan bilginin tahminen ne kadar kaldığı olduğunu hatırlatması ve bu yönde koçluk yapması da çok değerli.

Aşağıda kalan işi Sprint boyunca “kalan saat toplamı” cinsinden izleyen bir takımın Sprint Burndown Grafiği görülüyor. Bu takım aynı A3 boyutundaki grafik üzerine her Sprint’i farklı renklerle çizerek takımın genel olarak oturmuş olan temposunu ve kapasitesini de açık bir şekilde gösterebilmiş. Takımın 3 haftalık Sprint’ler koştuğu, Sprint’in her gününde Daily Scrum sonrası kalan işin saat toplamının ne olduğu grafikte açıkça görünüyor. Aynı kağıt üzerinde ardışık Sprint’lerin gösterilmesi sayesinde bu grafiğe bakarak şu yorumu yapmak da oldukça kolay. Takım ilk Sprint’in sonunda hedeflediği işleri bitirebilmenin oldukça uzağında kalmış, ikinci Sprint’te belki fazla temkinli davranmış ve bu sefer de Sprint’e aldıkları işi hızlı eritip Sprint’in beşinci gününde Sprint Golü’nden sapmadan ve elbette Product Owner’ın geçerli öncelikleri doğrultusunda ek iş almışlar. Sprint-3’ten itibaren ise takımın kapasitesi ve eritme hızı ortaya çıkmış. Şeffaflık o kadar yüksek ki, bu üst üste çizilen Sprint Burndown Grafikleri sayesinde, bir takımın Tuckman Modeli’ndeki doğal adımlardan bu takımın da geçip sonunda iyi işleyen takım haline geldiği bile açıkça görülüyor. Bu tam da Scrum takımlarında yaratılmasını istediğimiz şeffaflığa güzel bir örnek oluşturuyor.

Sprint Burndown Chart
Sprint Burndown Grafikleri’nde kalan saat toplamının gösterimi çok yaygın olmakla birlikte, koçluk yaptığım takımlardan bazılarında kullanılan diğer bir pratiğe de değinmek isterim. Saat bir gösterge olabilir doğru. Ancak eğer Sprint İş Listesi’ndeki işlerinizin her biri ufak farklarla yaklaşık aynı sürelerde tamamlanan işler ise – ki her bir işin idealde bir gün veya daha kısa zamanda tamamlanacak küçük parçalar halinde olması sürekli akışı görebilmeyi sağlar – sadece kalan görev sayısının toplamı yani Yapılacak ve Yapılıyor tahtalarımızda kalan post-it’lerin sayısı da bir gösterge olabilir. Bu aynı zamanda bazı takımlarda gelişen yukarıda bahsetmiş olduğum “bir işle ne kadar uğraştım” bilgisini rapor verir gibi Daily Scrum’da söylemek alışkanlığını değiştirmeye de yarayan bir yaklaşım.

Scrum bize “burndown grafiği tutun”, “saatleri kullanın” gibi bir talimat vermez. Ancak önemli olanın Sprint’te kalan işi hızlıca görünür kılmak ve bunu gözlemlemek olduğunu bilen iyi Scrum takımları için en kolay ve kullanışlı pratiklerden birisi olarak Sprint Burndown Grafikleri duvarlardan Sprint’in gidişat bilgisini yayarak şeffaflığı maximize etmeye devam etmektedir.

Tolga Kombak-Agile Consultant

Kaynak: http://www.acm-software.com/acmblog/sprint-burndown-chart-nedir/

Agile mı Olur acaba Banka PMO?

Agile konusunda yaptığım araştırmalar, okuduğum kaynaklar ve dinlediğim uzmanlar sonucunda artık olaya kendi etki ve ilgi alanım çerçevesinden bakmaya başladım.
​Agile’ın söylemlerinin isabet ettiği güven, kalite, hız ve çeviklik kavramları gerçek anlamda mevcut banka proje yönetim süreçlerinde sorun olarak zaten karşımıza çıkıyor. ​Fakat burada sorunlara çözüm gözüyle bakarak yeni söylemler geliştirmenin dışında mevcut duruma, ihtiyaçlara, zorunluklara ve stratejiye uygun agile yöntemi uygulamak gerektiği yaşanılan tecrübeler incelendiğinde görülebiliyor.
​
​Agile’ın sunduğu süreç modeli, kuralları ve kültürü gerekli imkanların sağlanması durumunda uygulanabilir ve karşılığı da alınabilir görülüyor. Bankalardaki proje yönetim süreci düşünüldüğünde projelerin planlanmasının, risklerinin belirlenmesinin ve tedariklerle ilgili planlamanın yapılmasının ve tüm bunların belirli bir disiplin içinde yönetilerek raporlanmasının çok önemli olduğu görülüyor. Bu hem yaşanan tecrübelerle hem de yaşanmış tecrübelerle oluşturulmuş dış mevzuat düzenlemeleriyle zorunlu olarak uygulanmaktadır. ​Bu nedenle Yorumlarla farklılaşmamış bir scrum iş modeli uygulanmaya çalışıldığı zaman bir banka içerisinde proje yönetim sürecinde çözümüne ihtiyaç duyulacak konular aşağıdaki gibidir:
​
​Agile portföy yönetimi:

Konu ile ilgili olarak bazı yazılı ve farklı çalışmalar olsa da agile çalışma yöntemi tüm projelere çok kısa zamanda uygulanamayacağından mevcut portföy yönetiminin devam etmesi gerektiği önerilmektedir. Bu durum planlama ile gerçekleşen arasındaki farkı göze almayı gerektiriyor.

​Risk, tedarik ve maliyet yönetimi konusu:

Agile yöntemler geliştirme çalışmalarına odaklandığından alışılmış proje yönetim uzmanlık alanlarını kapsamına almamaktadır. Kurulacak yeni düzende bu çalışmaların yapılması için bu tür sorumlulukları üstlenecek pasif bir proje yöneticisine ihtiyaç duyulmaktadır. Disiplin olarak da pmbok gibi bir kılavuz rehber alınmaya devam edilecektir.

​SDLC süreci aşamaları olarak dokümantasyona çok ağırlık verilmemesi konusu:

Agile, geliştirme ve üretim odaklı olduğu için yapılacak çalışmalarda iş planı ve zorunlu ve yararlı dokümantasyon için ekip üyelerine telkinde bulunmak gerekmektedir. Geliştirme sonrası da olsa yaşanan örneklerde bu işlerin eski süreçlerde olduğu gibi hazırlandığı görülmektedir.

​Dış kaynak ağırlıklı proje yönetim konusu:

Agile, başarı için tüm ekip üyelerinin öngördüğü süreç modelinde hep bir arada ve aynı disiplinde çalışması gerektiğini vurguluyor. Bu nedenle uzmanlar, dış kaynaklı işlerin ya paket iş teslim alma modeliyle yürütülmesini ya da outsource firmanın personelinin agile takım içinde çalışması gerektiğini vurguluyorlar. Yine bu doğrultuda teslim edilecek ürünün kapsamı net olmadığından anahtar teslim çalışma modelinin agile sürecine uymayacağı da dile getiriliyor.

​Dedike kaynak kullanım konusu:

Başarı için uzmanlar, takım üyelerinin dedike olarak tüm mesailerini o proje için harcamaları gerektiğini söylüyorlar. Ekip üyelerinin günlük mesaileri oranlara ayrılarak da bu çalışma gerçekleştirilebilse de başarı için riskli bir çözüm olduğu ifade ediliyor.
​
​Öğrendiğimiz ve duyduğumuz kadarıyla Akbank, ING, AVEA, TURKCELL gibi kurumlar uygun gördükleri bazı projelerinde agile yöntemleri bir süredir uyguluyormuş. ​Zaten yukardaki detaylar ve alternatif çözümler de bu kurumlarda geliştirilmiş süreçlerin sonucu olarak anlatılmaktadır.
​
​Daha detaylı ve sağlıklı bir analiz yapabilmek için 2 günlük bir agile scrum foundation eğitimi almak gerektiğini de düşünerek bir bankada özellikle kapsamı belirsiz yeni ürün projelerinde uygulanabilecek bir agile için görüşlerimse şu şekilde:
​
​-Scrum Masterlar ya pyo kadrosundan ya da bt içerisindeki tecrübeli personel arasından olmalıdır.

-​Product Owner mevcut proje müşterisi rolü olarak görülse bile bu kişilerin hızlı karar alabilmesi için yetkilerinin artırılması veya yöneticiler arasından seçilmesi gerekmektedir.

​-Agile yöntem en az %80 seviyelerinde iç kaynakla geliştirilecek ve dış kaynak kullanımı agile yöntemlere uygun olabilecek projelerde uygulanmalıdır.

​-Proje süresi tahmini veya hedef bitiş tarihine göre projenin süresi 6 ay ile 8 ay arasında olmalıdır.

​-Yukarda belirttiğim gibi diğer proje yönetim faliyetlerini gerçekleştirecek kişi; scrum master pyo içindense yine scrum master olur veya scrum master pyo içinden değilse iş yükü açısından pyo py içerisinden atanmalıdır.

​-Agile eğitimini tüm ilgililerin alması ve kültürün oturması için bu hareketin üst yönetim tarafından desteklenmesi gerekmektedir.

​-Yapılacak projelerde agile uygulanmasını hem bt biriminin hem de iş biriminin kabul etmesi, tarafların bir birine güvenmesi ve bu işe dedike olmayı kabul etmesi gerekmektedir.
​
​Sonuç olarak şimdilik agile bir banka pmo biraz uzak görünse de agile’ın uygulanarak projelerde başarı yüzdesinin artırılabileceğini düşünmek çok da yanlış görünmüyor.

Agile Scrum Hakkında Notlarım

​Bir yazılım geliştirme projesi yaklaşımı olarak Agile Savunucularının mevcutta uygulanan sistemler hakkındaki görüşleri:
​İstenildiği ve planlandığı gibi yürümeyen ve geç biten projelere bir çözüm olarak düşünülüyor.
​Asıl sorunu bulmaya çalışırken mevcut sistemlerin gecikmeler ve aksaklıklara yol açtığını ve proje yöneticilerinin arada kalan taraf olduğunu tesbit ediyorlar.
​İş biriminin bt’yi suçlaması ve sıkıştırması ve yine iş biriminin pyo’yu yeterli bulmaması çıkarımının yanı sıra yine bt’nin de pyo’nun baskı uyguladığını söylediği şuan yaşanan sistemlerin sonucu olduğu vurgulanıyor.
​Bu sıkıntıların yaşandığı sistemlerde proje yönetim ofisinin hep arada kaldığı ve yıprandığı agile savunucuları tarafından dile getiriliyor.
​Agile SCRUM:
​Scrum, Agile yöntemlerinden biri ve kompleks problemleri çözümleyerek üretken ve yaratıcı bir şekilde olası en yüksek değerde ürünler üretilmesini sağlayan bir altyapı olarak tanımlanıyor.
​Scrum, yönetimsel bir alt yapı olarak tanıtılıyor ve bütünü itibariyle sürecin kapsamında proje yönetim tekniği dışında öğretiler olduğu vurgulanıyor.
​Scrum Master, scrum değer,pratik ve kurallarının uygulanmasını sağlayarak scrum takımının üretkenliğine destek olmaktan sorumlu olan kişi olarak tanımlanıyor.Bu pozisyon ilk bakışta proje yöneticisine denk geliyor gibi görünse de proje yöneticsinin donanımlı görev tanımından uzak bir görev tanımıyla yönlendirici, çözüm üretici olarak ekibi yönlendiriyor.
​Dönüşüm Hakkında:
​Agile scrum uygulamak için organizasyonların dedike personelin çalışacağı, süresinin ve paydaşlarının uygun olduğu pilot projelerle değişim aksiyon planlarının uygulanması gerektiği belirtiliyor.
​Bu değişim aksiyon planında dikkat edilecek en önemli noktanın bt’nin potansiyel görüşleri olduğu belirtiliyor. Bt’nin agile konusunu dokümansız ve kuralsız bir proje yönetim tekniği olarak algılaması ve proje yöneticisine yer olmadığı için pyo gibi birimlerin bu dönüşümü istemeyeceğini düşünüyor olması muhtemel görünüyor.
​Buna paralel bt’nin scrum masterları kendi içinden çıkararak geliştirme süreçlerini kendi içinde yürütmek agile’ın şeffaflık ilkesinden dolayı riskli görülüyor.
​Bu görüşler doğrultusunda organizasyonun agile altyapı sistemini kurabilmesi için proje yönetim ofisi gibi güçlü bağlantıları olan bir birimin desteğinin olması çok önemli görülmektedir.
​Scrum Süreci:
​Scrum takımının önemli üyelerinden Product Owner, üretilecek olan ürünün değerini optimize etmekten sorumlu kişi olarak görülüyor ve bu diğer yaşayan sistemlerdeki müşteri kavramına benzer şekilde ürünün gereksinimleri ve işleyişi hakkında bilgi vermesi gereken kişi olarak görünüyor fakat burda farklı olan aradaki bilgi alışverişinin çoğunun sözlü ve yüzyüze olması gereltiği ve yapılacak işin bitti kapsamı denen kabul kriterleriyle tarif edilmesi bekleniyor.
​Product Owner’dan specleri alan scrum geliştirme takımının çalışır durumdaki yazılım parçacığını geliştirmek için çalıştığı süre  Sprint olarak tanımlanıyor. Bu yapı yaşayan diğer sistemlerdeki aktiviteler bütününe denk geliyor olsa da farklı olan kısmı çalışan takımda geliştirici, analyst ve tester birlikte çalışıyor ve kullanıcıya gösterilen kısım tamamlanmış çalışır bir parça oluyor.
​Yaşayan diğer sistemlerde olduğu gibi scrum süreci de bir kick off toplantısıyla hazırlıklar yapılarak başlanıyor.
​Süreç başlangıcında takımın product backlog denen ürünün şekillenmesini sağlayacak her türlü isteğin üretilecek değeri optimize edecek şekilde önceliklendirilmiş olarak belirtildiği listenin çıkarılması ve bu listedeki öncelikli işlere sprint süresi tanımlanmasıyla başlıyor.
​Bu planlama çalışmasına sprint planlama toplantısı deniyor ve sprint sonlarında sprint review toplantısıyla ortaya çıkan yazılım değerlendiriliyor. Sprint sonlarında kaizen çalışma prensibi amacıyla retrospective toplantısı yapılarak sprint dahilindeki işlerin değerlendirilmesi ve iyileştirmeye yönelik adımlar konuşulabiliyor.
​Günlük kısa scrum toplantılarıyla, scrum geliştirme takımının bir araya gelerek senkronize olması ve sprint hedefine doğru ilerleyişin değerlendirilmesi isteniyor.
​Agile’ın yapılmasını istediği toplantılar mevcut sistemlerdeki durum değerlendirme toplantılarına benzetilebilir fakat mevcut sistemlerdeki diğer yönetim gereksinimleri ve dokümanları (risk, kalite, performans, tedarik yönetimi) üzerinde uzun konuşulacak ve zaman harcanacak çalışmalar olarak görülmüyor.
​Buradaki kapsamın çerçevesinin yazılım geliştirme projesi olduğu düşünüldüğünde  bu klasik dokümanlar ve çalışmalar gerekli görülmeyebilir fakat yaşanılan tecrübelere göre bu tür sorunlara scrum masterın çözüm bulması bekleniyor. Scrum master’ın zaten başarılı bir şekilde ekibi yönetebilmesi için geliştirici takımını tamamen bu işe ayrılmış kaynaklardan oluşturması gerektiği söyleniyor.
​Yine detaylardan bir diğeri de müşteri ve paydaş tarafının sürece aktif olarak dahil edilmesi gerektiği ve product owner denen kişinin bu sürece yeterince zaman ayırarak geliştirmelere bilgi sağlaması gerektiği. Scrum sürecinde yapılan her toplantının tüm katılımcılarının bir takım olma bilinciyle çalışmayı öğrenmesi gerektiği ve yaşanılan sorunlara takımın birlikte çözüm bulmayı öğrenmesi gerektiği vurgulanıyor.
​
​Bu sistemdeki diğer kavramlar ve işleyişlerde şu şekilde;

​Scrum Studio:İçerisinde sadece scrum uygulayan kişi ve ekiplerin bulunduğu, şirket organizasyonundan bağımsız, özerk bir yazılım geliştirme birimi.
​
​Grooming toplantısı:Scrum takımı tarafından product backlogun güncel bir şekilde varlığını sürdürmesi amacıyla yapılan çeki düzen toplantısı.
​
​Scrum Tahtası:Sprint ile ilgili yapılması gereken işlerin bulunduğu yer.
​
​Timebox:Bir işin yapılması için tanımlanmış belirli uzunluktaki maksimum zaman periyodu.(Klasik yöntemlerde aktivite süresi diyebiliriz fakat buradaki iş paketleri aktiviteler bütünü olabilir ve ayrıca proje planı olmadan projeler son tarihe kadar sürekli değişen belirsiz bir zaman planlamasıyla yürütülür.)
​
​Sprint Burn Down Chart: Sprint ile ilgili yapılması gereken kalan işlerin büyüklüğünün zamanla değişimini gösteren grafik.
​
​Agile altyapı sistemleri ve kullanımı ile ilgili araştırılabilecek ve detayları öğrenilmesi gereken konu başlıkları:
​
-​Agile portföy yönetim altyapısı nasıl çalışır?
-​Proje yönetim süreci olarak risk, tedarik , maliyet yönetimi nasıl yapılabilir?
-​Sdlc ile ilişkisi düşünüldüğünde analiz,tasarım,geliştirme ve geçiş sürecinin cobit gibi düzenlemelere uyumu nasıl yönetilebilir?
-​Özellikle dış kaynak ağırlıklı çalışılan projelerde agile yaklaşımı kendi içinde farklılaşabilir mi?
-​Dedike olmayan kaynaklarla agile süreç nasıl planlanır, nasıl yönetilir?