Agile Leaders Etkinliği - Episode 7

Agile Leaders etkinliğinin 7. bölümü ile sizlerleyiz. Etkinliğimizin 7. bölümünde 4 Şubat 2014 Çarşamba günü, saat 17.00'da Thunderhead.com'dan Volkan Doğan bizlerle olacak. Bu bölümümüzde "Yurt Dışında Agile Uygulamaları" başlıklı bir sohbet gerçekleştireceğiz. Ülkemizde gittikçe yaygınlaşan Agile metodolojilerin, yurt dışında pratik olarak nasıl uygulandığı hakkında bilgi sahibi olacağınız bu keyifli sohbeti kaçırmayın!
 
 
Yayın öncesinde veya canlı yayın sırasında Volkan Doğan'a yöneltmemizi istediğiniz soruları #AgileLeadersST etiketi ile Twitter üzerinden paylaşabilirsiniz.

 
 
Volkan Doğan Kimdir?
 
 
Volkan Doğan, Dokuz Eylül Üniversitesi Bilgisayar Mühendisliği bölümünden 2006 yılında mezun oldu. Mezuniyet sonrası İstanbul’da IBTech firmasında 14 ay kadar çalıştıktan sonra, Amsterdam’a taşındı. 7 yıldır Amsterdamda çalışmaktadır. Şimdilerde 3 yıl önce Senior Developer olarak çalışmaya başladığı Thunderhead.com şirketinde, Amsterdam R&D ofisinin yöneticisi olarak görev yapmaktadır. 3 ayrı ekibin yazilim takımlarından sorumludur. Jeff Sutherland tarafından verilen Certified Scrum Master eğitimi sonrasında aldığı Certifed Scrum Master (CSM) sertifikası bulunmaktadır.

Dağıtık Takım Modelleri

Agile Leaders etkinliklerini takip edenlerin hatırlayacağı üzere 6. bölümde VNGRS'dan Birge Elif Basık ile birlikte Dağıtık Takımlarda Agile Uygulamaları başlıklı bir sohbet gerçekleştirdik. Birge'nin anlattığı bazı konuların literatürdeki karşılıklarını da merak edenler için derli toplu bir yerde bulunması adına bu yazıyı kaleme aldım.
 

Dağıtık takımların ortak çalışma kültürünün oluşturulması adına bir çok farklı yöntem bulunuyor. Bu yöntemlere genel olarak, "Distributed Team Patterns" ismi veriliyor. Türkçe karşılığı olarak "Dağıtık Takım Modelleri" tanımını kullanabiliriz. Dağıtık takımlardaki en büyük zorlukları iletişim problemleri, kültür farklılıkları, dil farklılıkları ve saat dilimi farklılıkları olarak tanımlayabiliriz. Bu tür problemlerin mümkün olduğunca ortadan kaldırılması için, bir çok farklı şirket tarafından denenmiş ve kabul görmüş bazı modeller oluşturulmuş. Bu modellerin önemli gördüğüm 4 tanesini sizlerle paylaşmak istiyorum.

Boot Camp
Boot Camp yöntemi temelde, farklı lokasyonlarda çalışan tüm takım üyelerinin aynı lokasyonda bir araya gelmesi olarak tanımlanabilir. Bir araya gelme nedeni bir projenin başlangıcı olabildiği gibi, bir yaygınlaştırma planlaması da olabilir. Tüm takımların bir araya getirilmesi imkansız ise, takımların önemli üyeleri bir araya gelerek bir süre birlikte çalışır. Boot Camp yöntemi takımlara, müşterinin istekleri ile ilgili ortak bir anlayış oluşturulması, kullanılacak ortak araçların seçilmesi, ilk mimari kararların oluşturulması, Tamamlandı Kriterinin belirlenmesi vb. konularında fayda sağlar. Bu yöntemin en önemli faydaları olarak, farklı lokasyonlardaki takım üyelerinin paylaşımını arttırması ve takımlar arasında güven ortamının oluşmasını söyleyebiliriz.
 

Rotating Guru
Boot Camp yöntemi ile başlangıçta oluşturulan ortak anlayış, zamanla azalabilir. Bu nedenle ekip üyeleri arasındaki güven ortamının da azalması beklenebilir. Takım üyelerinden birisinin, diğer takımları düzenli olarak ziyaret etmesi bu problemlerin ortadan kaldırılması için bir yöntem olarak kullanılabilir. Ziyareti gerçekleştiren kişi "Rotating Guru" olarak adlandırılır. Bu kişi ziyaret ettiği lokasyonda, oradaki takımın düzenli bir üyesi gibi çalışır. Eşli kodlama yöntemi kullanılarak, bu kişinin o lokasyondaki takımın geliştirme stilini öğrenmesi, iletişimi ve ortak anlayışı geliştirmesi ve takım ile "Rotating Guru" arasındaki güvenin oluşturulması sağlanır. Her rotasyonda farklı bir kişi "Rotating Guru" olarak seçilerek, yöntemden tüm takım üyelerinin faydalanması sağlanır. 

Ambassador
Ambassador (Türkçe: Elçi) modeli, uzak lokasyonda çalışan takımın, lokal takımdaki elçisi olarak yer alan bir takım üyesinin bulunması olarak tanımlanabilir. Bu yöntem, "Rotating Guru" yönteminin tamamlayıcısı olarak değerlendirilebilir. "Rotating Guru" olan takım üyesi, kendi lokasyonuna döndüğünde, ziyareti gerçekleştirdiği lokasyondaki takımın elçisi olarak kabul edilir. "Rotating Guru" yöntemi kullanılmadığı durumlarda, Elçi ile uzak lokasyondaki takımı bir araya getirecek farklı yöntemler geliştirilmelidir. 

Shared Community
Paylaşılan Topluluk modeli, tüm takımlar arasında oluşturulan "sanal topluluk" olarak adlandırılabilir. Bu model ile bilginin tek kaynakta toplanarak tüm takımların ulaşabilmesi sağlanır. Bu modelin kullanılmadığı durumlarda, detaylı bilgiler farklı lokasyonlardaki takımlarda bulunur ve bu durum büyük karışıklıklara neden olabilir. Bu nedenle senkronizasyon problemleri ortaya çıkabilir ve bu nedenle çok ciddi zaman kayıpları yaşanabilir. Ekiplerin kullanımında olacak Facebook benzeri bir sosyal paylaşım platformu, Wiki ve blog sayfaları, ortak e-posta listeleri ve online proje yönetim araçları vb. yöntemler ile bu model hayata geçirilir.
Bu yöntemlerin haricinde High Communication Modes, Remote Pairing vb. isimli  modeller de bulunmaktadır. Bu konulara da ilerleyen dönemlerde detaylı olarak değinmeye çalışacağım.
Not: Bu yazıda kullanılan resimler http://agilekata.co/ sitesinden alınmıştır.

Agile Leaders 6. Bölümü Gerçekleştirildi

Agile Leaders etkinliğinin 6. bölümü gerçekleştirildi. Bu bölümdeki konuğumuz Birge Elif Basık'tı. Kendisine keyifli sohbeti ve katkıları için çok teşekkür ediyoruz.
 
 
Sizlerin geri bildirimleri bizim için çok önemli. Etkinlikle ilgili düşüncelerinizi, etkinlikte görmek istediğiniz konukları, sorularınızı vb. bize Twitter üzerinden #AgileLeadersST etiketiyle iletebilirsiniz.

Agile Leaders 7. bölümünü sürpriz konuğumuz ile 4 Şubat 2015 tarihinde gerçekleştireceğiz. Etkinlik detaylarını önümüzdeki günlerde yayınlayacağız. Görüşmek üzere.

Secret Powers of Story Points

Our dear friend Soner Altın has written a blog post about Story Points. You can read his up-to-date posts on his personal blog. In this post, he is pointing a grey area in Scrum teams: Performance Measurement. He discusses to use Story Points for performance evaluations of individual and team performances. Thank you Soner for your great contribution and valuable discussions!
We, developers hate performance management and to be monitored but at the same time we want to be rewarded due to our performance. We want to earn much if we work harder, finish projects on time, and fix critical problems. We want to work with awesome colleagues and be a part of an awesome team. It is usual to face some problems in teams whose members have significant performance difference in team members. Team members can lose their motivation when there are people having bad performance in the group. Nobody wants to be a part of a team which the performance is not homogeneous. And if managers don't try to fix this issue, other team members need to work harder to avoid the related delays which means overtime and less social life.

And the question is how to measure performance of a developer? Some companies tried to measure it by using SLOC, number of bugs, number of completed stories/use cases, number of bugs fixed. I am sure there are a lot of different other measurement methods used to evaluate developer performance. But all developers say that these metrics cannot be used to measure their performance. Every 5 lines of code cannot be counted as the same contribution. At this point we have to think about the complexity of the contribution. At this point Scrum helps us with its magical tool: Story Points! In Scrum, team estimates the complexity of the stories by Planning Poker and assigns the related points to stories which mean team members define the complexity by themselves. If team assigns 5 points to Story X and 8 points to Story Y, it is easy to monitor the individual performance by using story points.
How to use Story Points to detect the problems?
Assume that there is a Scrum team consists of four developers who have very similar technical level (Team members named A, B, C, D). They have a social media project with well-defined requirements, they selected JIRA project tracking tool, they have an amazing office, and they don't have strict working hours. By using JIRA, it is very easy to monitor both individual and team performance sprint by sprint. They start to analyse all the backlog items, they assigned Story Points to stories by playing Scrum Poker and they created sprints by prioritizing the stories. After several sprints, let’s assume team's Story Point performance like this:


First of all, according to Wikipedia Scrum promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change.
At this point, we can make some observations from individual performance:
  • Developer A made the most contribution to the project (28%), but related performance decreased after sprint 4
  • Developer B made the promised contribution and increased contribution in every sprint
  • Developer C didn't make promised contribution almost in every sprint and made the least contribution (20 %)
  • Developer D made tried the promised contribution like Developer B with constant contribution
Team Performance
Firstly let's take a look at the team performance. Their average burn down point is 93; individually they tried not to take extra work to their responsibility. But from first sprint to last sprint their burn down point decreased from 99 to 87. This is a very powerful bad signal for team's structure. Their incomplete story points were increased 1 to 10; team didn't go well in estimation. This is another bad signal. Team is very good at adaptive planning, after each sprint every team member increased or decreased next estimated story point for the sprint. All team members tried to increase their performance which shows they are very open to continuous improvement. We can say that they are good at applying Scrum to their project.
Individual Performances
Now let's look at the individual performance of the team members. We can say Developer C was not motivated to the project since story points tell us Developer C has the most incomplete story points in the project, he has 50 % of the incomplete points (See the graph below).


There can be a lot of different reasons for this situation and by using this metric; managers shall discuss this performance with developer. So we can easily say that Developer C didn't show good performance at this team. Developer C has 26 incomplete story points after 7 sprints where Developer D has 4. I am sure Developer D is not very happy with this metric since Developer D also wants to work with the stunning colleagues like all of us.

And we can say that after Sprint 4, Developer A has very significant loss on his completed story points where this can be because of Developer C's low performance. It's very important to solve the bottleneck problems in the projects, when you don't solve the problems on time, you can lose your good workers.


Individual performance can affect other member's performance dramatically, it is not easy to deal with poor performance and keeping bad performance players in your team can cause a lot of problems. In the upper graphic we can easily say that Developer C and D were not affected negatively from Developer B's performance but Developer A was affected. Monitoring the decreasing performance will give us very useful feedbacks about the team structure.
Performance Measurement vs Team Structure Design
In theory you can easily use story points to measure the individual and team performance. By focusing on story points, you can see unforeseen problems easily and you can solve them before the breakdown. I believe using story points for performance measurement would be very fair, easy and acceptable method. But you can gain more. It is obvious that story points tell us very important and priceless information about the team. These metrics will change the way you manage your projects and company.

We discussed this model in my Executive MBA class with various executives from different industries who do not know anything about story points. They all said it would be super easy to make performance management in their business if they have story points. So I think your business can have significant improvements if you are ready to change the way you use story points.

Agile Leaders Etkinliği - Episode 6

Yeni yılın ilk Agile Leaders etkinliği ile sizlerleyiz. Etkinliğimizin 6. bölümünde 7 Ocak 2014 Çarşamba günü, saat 17.00'da VNGRS'den Birge Elif Basık bizlerle olacak. Bu bölümümüzde "Dağıtık Takımlarda Agile Uygulamaları" başlıklı bir sohbet gerçekleştireceğiz. Bu keyifli sohbeti kaçırmayın!
 
 
Yayın öncesinde veya canlı yayın sırasında Birge Elif Basık'a yöneltmemizi istediğiniz soruları #AgileLeadersST etiketi ile Twitter üzerinden paylaşabilirsiniz.
 
 
Birge Elif Basık Kimdir?
 
 
2009 yılında Koç Üniversitesi Kimya Biyoloji Mühendisliği bölümünden mezun oldu. 2009-2011 yılları arasında reklam sektöründe dijital projelerde çalıştıktan sonra 2011'den beri İletken Teknoloji'de Proje Yöneticisi - Agile Coach olarak çalışmaktadır. Hem Türkiye'de hem de dünya üzerinde dağıtık bulunan takımlarla beraber çalışmaktadır. 2 kedi, 30 developer annesidir.