Ücretsiz sunduğum bu çalışma karşılığında sizlerden tek bir ricam var. Karşılaştığınız yazım hatalarını, anlatım bozukluklarını veya herhangi bir yorumunuzu uygarboynudelik@gmail.com adresine eposta atarak paylaşırsanız sevinirim.
Kitabin icindekiler kısmını aşağıda aynen paylaşıyorum:
2019 yili bu blogun 10. yili olacak! Ilk yazimin yayinlandigi Eylul 2009 uzerinden neredeyse 10 yil gecti, dile kolay.
Bu sure zarfında birçok farkli sirkette calistim. Evlendim, 1 kızım, 1 oğlum oldu. Sektörel olarak Once SD -> HD donusumunu, hatta sonra HD -> 4K Ultra HD dosunumunu yaşadık. Turkiye’deki TV sektoru maalesef büyümek yerine yerinde saydı, hatta kuculdu. Digiturk güç bela satildi, son donemde statükocu bir yol izliyorlar, D-Smart neredeyse dondu kaldi. Kablo TV bir kamu kurulusu olarak bir turlu büyüme atağı yapamadı. TV sektörüne yeni giren telco’lardan Turk Telekom’un Tivibu’su birçok stratejik hata sonucunda guclu bir TV teklifi olmaktan ziyade mobil müşteri kazanımı icin kullanilan bir “araç” haline geldi. Milenicom’un baslarda heyecan yaratan TV servisi Dopingbox’in ömrü kısa oldu. Sektöre sonradan giren Filbox saman alevi gibi parladı , sonra sondu, yakin zamanda da tamamen kapilarini kapattı. 3. buyuk mobil operator Vodafone’un uzun sure TV servisi cikartacagi söylendi ama o cephede de hiç ses soluk cikmadi, bu saatten sonra da cikacaga benzemiyor. Dijital karasal donusum bir turlu tamamlanamadı, yakin zamanda bir gelişme olacak gibi de degil zaten. (Sahiden dünyada halen analog karasal yayın yapan nadir ülkelerden biri olabiliriz.) Bana kalırsa bu oyuncular arasında basarili denebilecek durumda olan nadir orneklerden bir tanesi Turkcell’in TV+ servisi oldu. Neredeyse son 6 yildir o isin icinde yer aldigim icin tarafsiz olamiyor olabilirim 🙂 Hem Sagemcom ile geliştirdiğimiz YouTube TV erişimi de saglayan kullanıcı deneyimi yüksek 4K Ultra HD set-top-box hem de mobil datası icinde TV+ Android, iOS ve Apple TV uygulamaları ile genel olarak bir memnuniyet seviyesini yakalamayı başardı. IP baglantisi da olan Hibrit bir uydu alicisi ve herhangi bir internet altyapısında da calisabilen bir OTT Box benim icimde kalan, “keske” hayata geçirebilseydik dedigim isler oldu. Bu isler gerek feasibility’si tutmadigi icin gerekse o donemde halen yururlukte olan AKK uygulaması nedeniyle ust yönetimden onay alamadigimiz isler oldu. Bunlarin disinda Netflix, PuhuTV, BluTV gibi yeni ve populer OTT servisleri de sektöre girdiler ama surdurulebilir bir büyüme yakaladiklarini söylemek güç, daha çok yeni iceriklerin duyurulması ile iliskili anlık ivmeler yakalayabiliyorlar.
Goruldugu gibi bu blogda yazmaya basladigimdan beri geride kalan neredeyse 10 yillik zamanda odemeli-TV (pay-TV) sektöründe yasanan gelişmelere bakildiginda pek de ic acici bir donem geride kalmadı. Bunun arkasında yatan sebepleri analiz etmek istersek bambaşka bir blog yazısı olur ama burada kısaca 3 temel konuya değinmek isterim:
Turk futbolunun azalan, kötülesen marka degeri, futbola ilginin giderek azalması : 3 Temmuz sureci, futbola siyasetin bulaşması, kluplerin ekonomik sikintilari vs. Dunyanin her yerinde pay-TV sektorunun lokomotifi futboldur, futbola ilgi ile sektörün dinamikleri arasında pozitif korelasyon vardır.
Turk parasinin deger kaybı, hanehalkinin alim gucunun artmaması: TV teknolojileri doviz ile ithal edildigi icin ve abonelik ücretlerine dovizdeki deger artısı kadar zam yapilamadigi icin yıllar geçtikçe operatörler ucuz ve kalitesiz donanım ve yazılım cozumleri tercih edilmek zorunda kaldı, bu da müşteri memnuniyetsizliği, abonelik iptalleri olarak geri dondu)
Ozellikle sektore ilk giren olan Digiturk ve sonrasinda D-Smart’in yaptigi musterilerini degersizlestiren, onlari kaba tabirle yolunacak kaz olarak gören hatalı yaklasimlari: Sadece birkaç ornek vermek gerekirse Digiturk’un iptal süreçlerini zorlastirmasi, aboneye gore fiyatlandırma politikasi, yagmur yagdiginda kesilen yayin, D-Smart’in baslangicta ucretsiz olacagini soyledigi kanallar icin sonradan para istemesi vs. Sektore sonradan katılanlar da maalesef büyük oranda benzer hataları yaptilar.
Uzun lafın kısası, benim kisisel olara tutku ile bağlı oldugum, okuyup araştırmaktan zevk aldigim TV teknolojileri ile ilgili icinde bulunduğumuz sektör 2010 yıllarda altın cagini yasadi diyemeyiz. Zaten son yıllarda yeni gelen OTT oyuncuları ile pazar çok daha fragmante oldu ve yakin zamanda da konsolide olabileceğini söylemek güç. Diğer bir ifade ile sektorun onumuzdeki yıllarda daha iyiye gideceğini, yeni yatırımlar yapilacagini, yeni is imkanlari doguracagini hayal etmekte zorlaniyorum.
Bunlari soyledikten sonra baska bir not daha paylasmak istiyorum. Bu blogdan baska gorece duzenli olarak yazilar yazdigim 2 farkli platformum daha vardi. Bunlardan bir tanesi www.turkishtvmarket.info idi. Burasi basitce Turkiye’de TV tekno ve pay-TV dunyasinda olup bitenleri Ingilizce olarak yazdigim 5 yasinda bir blog idi. Artik Almanya’da yasadigim ve Turkiye pazarini takip edemeyecegim icin bu blogu canli tutamayacaktim, bu sebeple kapatmaya karar verdim ve oradaki yazilarimi da bu ortama tasidim, dileyenler bu baglantidan turkishtvmarket.info’daki yazilarimin arsivine ulasabilirler.
Bu yil bolca zaman ve enerji harcadigim blog sayfam ise www.productowner.info oldu. Turkcell’de yasanan cevik donusum surecinin bir parcasi olarak yeni kurulan Scrum takiminda almis oldugum Product Owner rolu ile ilgili yazilar yazdigim bu blogumdaki icerikleri de buraya tasidim ve orayi da kapattim. Buradan www.productowner.info arsivine ulasabilirsiniz.
Uzun lafin kisasi 3 tane farkli blog yerine 2019 itibariyle tek adresten (www.uygarboynudelik.com) seslenmeye devam edecegim. Oyle zannediyorum ki TV sektorune odaklanmis olan gecmisteki yazilarimin biraz daha disina cikip Almanya’da calisma hayati, entegrasyon konulari, Avrupa/Almanya’da dijital servisler ve daha kisisel konular hakkinda paylasim yapabilirim, belki de diger mesguliyetlerden dolayi artik cok daha nadir yazabilirim, bilemiyorum. Ama suna eminim ki bu blog benim tek yazma ortamim oldugu icin kapilarini acik tutmaya devam edecek.
Herkese harika bir 2019 diliyorum! Umarim saglikli, huzurlu, neseli, hedeflerimize ulasacagimiz, guzel hatirlayacagimiz bir yil olur.
Ideally, before performing the Sprint Planning session as a team, the Product Backlog Items those will be potentially included in the next Sprint are supposed to be estimated in Story Points. The higher the priority of any Product Backlog Item, the higher is the expected maturity level of that particular PBI. Then, based on the average velocity data i.e. the average completed story points in the past, together with the expected capacity of the team for the next Sprint, the development team decides which PBIs should be included into the scope of the following Sprint. We, as the product owners are supposed to provide the right level of priorization and the overall direction to achieve a Sprint Goal before the planning session. This is basically how Sprint Planning works.
Nevertheless, Scrum teams may face scenarios where there may be strict deadline for a new feature or a solution. In other words, teams could face circumstances where the typical release planning could be not be applicable. To make it more concrete, let’s assume that the total amount of Story Points for a new to-be-developed solution is 100 SPs. Moreover, assuming that based on the proper planning done by PO according to the velocity of the team while preserving the projected capacity , it seems feasible that the team would require 4 Sprints in order to ship the solution. There are chances that, due to a certain reason ( Top Management expectation, natural deadlines such as Christmas, back-to-school season etc.) it may not be feasible to run 4 Sprints as the strict deadline does not allow such a period of time. Let’s imagine that for this example the deadline is just 3 Sprints away. Than the big question is how should a PO react if she/he encounters such a case ?
I’ve just finished reading the book called “Agile Product Management with Scrum” by Roman Pichler. I had really enjoyed it. It provides valuable insight regarding not only about the Agile Product Management but also tips and tricks to become a great product owner.
At the last part of the book, there was a section that I found very interesting and insightful. It’s the following table that has been referenced to Lyssa Adkins, author of “Coaching Agile Teams”.
When I’ve came across this table, I’ve openly criticized myself and think about if I’m having attitudes of items in the “Don’t” part. My sincere feedback to myself was there are times I might fail to “protect the team from outside noise” and instead of “incorporating change between Sprints” there are Sprints in which I allow change to jump in to. I thought I’m doing not bad at the other items. I’ve decided to ask openly to the development team their feedback by commenting for which item they think my overall attitude is on the “Do” part and for which in the “Don’t” part.
Generally speaking, they agreed with me regarding my improvement areas that I’ve found out by doing self-criticism. Almost all of them thought that it’s very positive and bold move that I’m asking their feedback in this way. On of my colleagues told that he is aware of the pressure I’m carrying on my shoulders and he is ready to support me as much as he can. It made me feel better that they are sensible to the challenge of my position and do empathize. What I’ve done later on upon receiving their feedback is I’m no longer including the development team to the email exchanges I’ve been doing with the shareholders in order to isolate them. Earlier I was keeping them in the loop so that we can be aligned as a whole team. Besides, I’m putting more effort not play to much with the SBL and keep the ground as stable as possible.
In a nutshell, as product owners we are the ones who are carrying the biggest responsibility to maximize the value delivered my the development team. As a result, we are the ones who are under fire most of time. In order to become great Product Owners we have to improve our expertise and acquire the know-how required for the domain while being kind, patient, empathetic, open-minded and also cool 🙂
Agile transformation starts by individuals followed by teams and at last gets completed by organisation level. This is potentially a long-lasting process with a lot of turbulance. Majority of the people like status quo particularly people who are above a certain level of age. They are quite comfortable in their comfort zone and are not very willing to leave it. I think it’s completely understandable.
On the other hand, Agility is a totaly different mindset. It embraces early and frequent delivery in an iterative and incremental manner. It’s extremely critical that the agile transformation is well understood throughout the whole company not only in technology teams or in part of the organisation. If this is not the case, agile teams will have face many significant impediments and at the end may probably fail. Let’s imagine a case where the product marketing teams are not familiar with agile principles or Scrum framework and in the Sprint review meeting they’ve been made a demonstration of the iteration to be shipped. It’s quite likely that there is a struggle between the Marketing teams and PO regarding the deployment decision of the iteration. PO will very likely to push the deployment so that customer feedback is received and following iterations are improved based on that while marketing guys don’t think the iteration is mature enough to present to customers and might damage the overall image of the product. On such instances, it’s key that decisions that has been made by the PO should be respected by the whole organization. POs those are supposedly selected by the management team, should be empowered enough to have the right level of authority. Without sufficient sponsorship support, POs will be underpowered and lack authority. On those cases it is very likely that they feel overwhelmed and will struggle with the major decision makers.
One of the many new practices for organizations going through agile transformation is the move from requirement documents to user stories. I’m quoting from Mike Cohn *:
“User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.”
In the classical approach, there is a requirement document that has been agreed by development and business groups after multiple time-consuming iterations. Even if both parties agree on a document after significant time and start developing the new feature, chances are part of the original scope gets obsolete or changes and things need to be reiterated and perhaps portion of the development efforts have been wasted. This approach is obviously not suitable particularly for time-critical projects. On the other hand, user stories are mutually understandable both for customers and developers and increase the communications between team members and stakeholders. User stories also allow the development team do the practical planning. As Roman Pinchler nicely puts it **:
“User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possible;not to impose any overhead.”
Scrum framework doesn’t mention about how the software is developed i.e. which development techniques have been used. It lets the team to decide which techniques and practices will be used. I think it’s a good idea to share the practices we benefit as a Scrum team thanks to the leadership of the Scrum Master. (A tailor-made adaptation of XP practices)
Pair Programming: All production code is written by two people at one screen/keyboard/mouse. This helps us to ship software with superior quality, less bugs, less iteration and as a result greater efficiency.
Test Driven Development: TDD is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests. Chances are the test coverage percentage of our software stack decreases due to other priorities. In any case, we focus to keep it above a certain threshold.
Unit testing: It's a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. Unit testing is key for the team to level less buggy software.
Continuous Integration: New code is integrated with the current system after no more than a few hours. When integrating, the system is built from scratch and all tests must pass or changes are discarded. This eliminates manual work and saves time and efforts.
Refactoring: The design of the system is evolved through transformations of the existing design that keep all the tests running. In the lack of refactoring, the quality of software decreases and the probability of major bugs increases.
One of key definitions of the Scrum framework is “Definition of Done”(DoD). In order to be able to decide when an activity from the Sprint Backlog is completed, the Definition of Done (DoD) is used. This bring all the team members to the same level of understanding about the conditions when a task is completed. The definition of done for our team is as follows:
Any issue in the Sprint Backlog is considered to be “Done” if the analysis, development and validation stages have been completed successfully and the acceptance criteria has been met. The deployment is not a prerequisite for the issue to be considered as “Done”.
One of key metrics of a Scrum team is Velocity. Even though it’s not mentioned in the Scrum guide, it is still very useful for the Product Owner while planning the Scope of the next Sprint and defining a concrete Sprint Goal.
As the name implies Velocity (consider the team as a vehicle) is a metric calculated by averaging the total amount of Story Points completed over the number of Sprints within the same period. In practice, the velocity of the teams gets stabilized after a certain number Sprints are left behind. As the number of Sprints increases, the velocity starts oscillating in a regular rhythm.
Reference
Source