Tag Archives: scrum

PROFESSIONAL SCRUM MASTER I – PSM I SERTİFİKASI HAKKINDA

20 Haz

AGILE & SCRUM; yazılım dünyasının yeni trendi. Aslında bu yazımda bu trend ile ilgili bilgiler vermeyeceğim; çünkü ilgili bilgileri internette bulmak oldukça kolay; fakat sertifikasyon süreci ve özellikle sertifikasyon sınavları ile ilgili kaynak bulmak biraz daha zor. Ben de bu yüzden sınavını yeni geçtiğim PSM I sertifikası assessment süreci hakkındaki bir yazının sizlere daha faydalı olabileceğini düşünerek bu konu üzerine eğilmek istedim.

 

Nedir Bu PSM I?

Öncelikle PSM I sertifikasının dünyada oldukça popüler olduğunu ve Türkiye’de de saygınlığının giderek arttığını belirtmek isterim. Scrum sertifikasyonu, Scrum.org ve ScrumAlliance.org adlı iki organizasyon tarafından gerçekleştirilmektedir. Aslına bakarsanız ikisi de benzer sertifikasyonları sağlamaktalar. Ancak şu an için ScrumAlliance.org daki üye sayısının Scrum.org a göre çok daha fazla olduğunu belirtmek isterim. Ben bu yazımda Scrum.org sertifikasyon sürecinin nasıl olacağından bahsedeceğim. Scrum.org sertifikasyonları, Scrum rollerine göre isimlendirilmiştir. Örneğin Scrum Master sertifikasyonu aldığınızda, “Professional Scrum Master” olursunuz. Belirli ücretler karşılığında, Scrum.org‘un sağladığı sınavlara online olarak katılabilir ve sertifikanızı alabilirsiniz. Scrum.org‘un sağlamış olduğu sertifikaları şöyle sıralayabiliriz:

  • Professional Scrum Master I ve II (PSM)
  • Professional Scrum Product Owner I ve II (PSPO)
  • Professional Scrum Developer (Java ve .NET) (PSD Java ve PSD .NET)
  • Professional Scrum Developer Java Trainer (PSDT Java)
  • Professional Scrum Developer .NET Trainer (PSDT .NET)
  • Professional Scrum Master Trainer (PSMT)

Scrum.org sertifikaları arasında bağlantılarda bulunmaktadır. Örneğin PSM II alabilmek için, önce PSM I almış olmanız gerekmektedir.

 

Gelelim PSM 1 Sınavının Özelliklerine

PSM 1 sınavı çoktan seçmeli 80 sorudan oluşmakta. Başarılı olabilmeniz için 80 sorudan %85 başarı, yani en az 68 doğru yapmanız gerekiyor. Sınava internete bağlı herhangi bir bilgisayardan girebiliyorsunuz. Yapmanız gereken tek şey http://www.scrum.org a üye olmak ve herhangi bir eğitim programı almadıysanız 150 dolarlık sınav giriş ücretini ödemeniz. Eğer bir eğitim almış iseniz -genellikle bu eğitim programına 150 $ lık sınav ücreti dahil edilmiş olur- evinizden, iş yerinizden ya da dilediğiniz farklı bir ortamdan sınava kendi başınıza girebilirsiniz. Size sınava giriş için bir şifre maili gelecek ve bu şifre ile PSM I sınavına giriyor olacaksınız.

 

AMAN DİKKAT !

Sınav süresi yalnızca 60 dakika. İnternet bağlantınız koptuğu anda sınav için süreniz devam edecek. Dolayısıyla internet bağlantınıza güvenebileceğiniz bir lokasyonda sınava girmeniz çok önemli.

 

Sınava Nasıl Hazırlanmalı ?

İnternette yaptığınız araştırmalarda birçok farklı yöntem ve sınav için okumanız gereken birçok kitap önerileri görebilirsiniz. Bu kitapların hepsi scrum felsefesini anlayabilmek için çok önemli ve kesinlikle okunması gereken kitaplar. Ben bu yazımda sertifika konusunda aceleci olanlar içinAGILE bir sınav hazırlık programı yayınlayacağım 🙂 Ama zamanı olanlar sınavdan önce bu kitapları tabiki okuyabilir; kesinlikle faydalı olacaktır. Gelelim AGILE hazırlık programımıza. Yaklaşık 2 hafta süren aşağıdaki programı uygulamanız durumunda sınavı geçmeniz oldukça kolaylaşacak.

  1. Agile metodolojisi ile ilgili bir eğitim alınması: Eğitim almadan da sınava girebilirsiniz; ama şahsi fikrim en az 2 günlük bir eğitimi mutlaka ama mutlaka alın, işiniz çok daha kolaylaşacak.
  1. Scrum guide ı ingilizce ve türkçe olarak en az 3’er kez okuyun. (2 gün)

İng:        http://www.scrumguides.org/scrum-guide.html Türkçe:  http://www.scrumguides.org/download.html

  1. Scrum.org da yer alan open assessment da 5 kez ardarda %100 yapana kadar tekrar tekrar çözün. Bu soruların bazıları birebir olarak gerçek sınavda karşınıza çıkıyor. (3 gün)

https://www.scrum.org/Assessments/Open-Assessments/Scrum-Open-Assessment

  1. İnternette bulabileceğiniz gerçeğe yakın deneme sınavlarını en az 3 kez aklınıza iyice işlenene kadar çözün. (3 gün)
  1. Scrum.org daki forumların okunması: Sınavda en çok işinize yarayacak ama çalışma süresinde size en çok zaman kaybettirecek bölüm burası. Forumda yapılan yorumları okumak çok önemli. Sorular ve yapılan yorumların nedenlerinin iyice irdelenmesi gerekiyor; çünkü sınavda forumda yer alan soruların çok benzerleri de çıkabilmekte. O yüzden forum, forum, forum ! (3 gün)
  1. https://www.scrum.org/Assessments/Open-Assessments/Scrum-Practitioner-Open-Assessment

da yer alan 15 soruluk sınavdan 3 kez üstüste en az 14/15 yapabilmek (5. Maddedeki sorulara iyi çalışırsanız bu soruları yapmak oldukça basit gelecek). (2  gün)

ve bir not; bir “Agile Bilgi Bankası” haline gelen all4agile.com blogunu mutlaka inceleyin. Hem agile kavramı, hem de scrum ile ilgili birbirinden faydalı birçok blog yazısını okuyarak konuya çok daha hakim olabilirsiniz.

Kaynak: https://erkancinko.wordpress.com/2015/04/20/professional-scrum-master-i-psm-i-sertifikasi-hakkinda/

Reklamlar

PMSummit 2015-ANKARA Videoları Yayında!

16 Ara

Yoğun katılımla 27 Ekim 2015 tarihinde TOBB Ekonomi ve Teknoloji Üniversitesi Sosyal Tesislerinde gerçekleştirdiğimiz Proje Yönetim Zirvesinin tüm oturumlarının videoları PMI Türkiye Youtube kanalında yayınlandı. Bu videoları izleyerek neleri canlı takip etme fırsatını kaçırdığınızı görebilirsiniz.

Şimdi sıra 2016 Proje Yönetim Zirvesinde Mayıs ayında yapmayı planladığımız zirve ile ilgili gönüllülük,sponsorluk ve konuşmacı konularında bana ulaşabilirsiniz.

Nice güzel etkinliklerde bir arada olmak dileğiyle…

Hepsi ve daha fazlası için: https://www.youtube.com/user/PmiTurkeyChapter/videos

 

 

Sprint Burndown Chart Nedir?

25 Tem

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.

Sprint-Burndown-Chart-OrnekAş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-Brundown-Chart-225x300

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?

29 Oca

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

26 Oca

​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?