Scrum - Retrospektif Toplantısı (Sprint Sonunda Yapılır)

Giriş
Her sprint sonunda geriye yönelik işlerin gözden geçirildiği bir toplantı yapılabilir. Buna eskiden "Lessons Learnt" denilirdi. Açıklaması şöyle.

The sprint retrospective is at the heart of Scrum. This is where the entire team comes together and looks at what worked and didn’t work in sprints, projects, people, tools, and even these very events and ceremonies that makeup Scrum. This is the time for the team to focus on what needs to be improved, changed, thrown out, and kept.

Bu toplantı bir sonraki Sprint Planlama Toplantısından önce gerçekleştirilir.

Bu toplantıda İyi yapılan, İyileştirilmesi Gereken konular görüşülür deniliyor. İyileştirilmesi gereken şeylerde amaç yıkıcı eleştiri değil. Açıklaması şöyle.

Instead of writing down "what didn't go well", they were reminded that no process is perfect and to write down "what they would do differently the next time". This simple re-wording of the phrases is powerful.

Blameless Retrospective

Yapılan hatalarda kişilerin isimleri verilmeyebilir. Buna blameless restrospective deniliyor. Bir örnek şöyle

Why don't you just acknowledge that you found the problem and fixed it? Why do you need to name names?
..
Naming Bob is not going to make the mistake any less concerning ...

Bir başka açıklama şöyle.

One of the most important elements of a retrospective, and of SRE as a whole, is the notion of blamelessness. To learn from retrospectives, there needs to be total transparency. Opening up about mistakes can often be frightening, and requires a psychologically safe space to do so. Positive intent should always be assumed in order to foster the trust that allows for true openness. Blaming team members or defining people as the root cause for failure will only lead to more insecurity, covering up the important truths that retrospectives are meant to uncover.

Eğer parmak gösterme durumu ortaya çıkarsa, insanlar hatalarını gizlemek için gayret sarfetmeye başlarlar. Açıklaması şöyle.

The moment people realize that there is blame being handed out they will obfuscate and hide their mistakes as best they can, scapegoating others and generally making it impossible to learn anything useful.

A much better idea is to do a no-blame post-mortem of the project. The goal is to go over the entire project from start to finish, examining at each stage what worked well and what went wrong. At no point should any blame be assigned to any member of the team. Instead the focus should be on identifying failures and putting procedures in place to make sure they don't happen again.

To err is human which is why we have checks and procedures in place. Therefore if a mistake goes uncorrected or unnoticed it is a problem with the procedures, not the individual (except in extreme circumstances such as gross negligence or misconduct).

In fact having a no-blame culture is a great way to prevent these things happening in the first place because people will feel able to come forward with issues when they happen, not long after they have caused a huge problem.

Hazırlık
Scrum için olmayan ancak ilgili olduğu için alıntıladığım bir başka açıklama şöyle.

To craft great retrospectives, there are four other best practices that will ensure your incidents are being used to their full advantage:

1. Use visuals in your retrospectives: As Steve McGhee says, “A ‘what happened’ narrative with graphs is the best textbook-let for teaching other engineers how to get better at progressing through future incidents.” Graphs provide an engineer with a quickly readable yet in-depth explanation for what was happening during the incident days, weeks, or even years later.

2. Be a historian: Timelines can be invaluable for parsing through a particularly dense incident. Chat logs can be cluttered, and it’s difficult to quickly find what you’re looking for. Thus, it’s important to have a centralized timeline that gives a clean, clear summary of the events. This also provides the context that helps relevant team members analyze what happened.

3. Tell a story: An incident is a story. To tell a story well, many components must work together.

  - Without sufficient background knowledge, this story loses depth and context.

  - Without a timeline dictating what happened during an incident, the story loses its plot.

  - Without a plan to rectify outstanding action items, the story loses a resolution.

4. Publish promptly: Promptness has two main benefits: first, it allows the authors of the retrospective to report on the incident with a clear mind, and second, it soothes affected customers. Best-in-class companies like Google, Uber, and others have internal SLOs around publishing their retrospectives within 48 hours.

Günlük Toplantılar İle Farkı
Bu toplantıdaki biraz daha resmidir. Açıklaması şöyle.

Retrospective is more formal because not everyone is comfortable raising issues during the sprint, some people need a dedicated time for this. Also some problems are deep and complicated and require a long discussion.

Spring Review is about demonstrating the progress, more like a demo. Its purpose is to inspect the Increment and adapt the Product Backlog if needed. So Retro is about the team and process, Review is about Backlog and product.

İyileştirilmesi Gereken Genel Konular
Örneğin yazılımdaki hatalar kimseyi suçlamadan konuşulabilir.

Spend some time examining and classifying the types of bugs they fix to understand patterns behind how they happen.

İyileştirilmesi Gereken Süreçle İlgili Konular

Bazen iyileştirilmesi gereken şey yazılım değil de süreç olabiliyor. Bazı süreç maddeleri şöyle olabilir.

- Updates to the Definition of Done.

- Changes to the way Sprint Backlog Items are handled.

- Modifications of the team's information radiators (e.g. Kanban board or story cards).

- Other adaptations to the Scrum Team's processes, artifacts, and events.

Bu tür kararları hemen uygulamakta fayda var. Açıklaması şöyle

As a practical matter, items from a Sprint Retrospective tend to fall into a few broad categories. Process changes should be implemented as soon as possible through the appropriate team process or artifact. 

Definition of Done Tanımını Değiştirme

Açıklaması şöyle. Mevcut standartlarla çelişmemesine dikkat etmek gerekir.

During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of "Done", if appropriate and not in conflict with product or organizational standards.

Değişik Toplantı Tecrübelerim
- Toplantıya isteksiz katılan tuhaf bir ekiple çalışmıştım. İsteksizlik bence Scrum'ı öldürdü.

- Her şeyi olumlu gören bir başka ekiple de çalışmıştım. Bu insanlar çok yapmacık geliyor. İşler yetişmemiş ancak çok başarılıydık diyor. Bu durumda da bence Scrum girişimini öldürdü.

Bu Toplantı Mutlaka Yapılmalı
Açıklaması şöyle.

One of the twelve principles behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.  Unfortunately the Sprint Retrospective is often treated like an add-on or a luxury, and performed only “if there’s time”.  The fact is, Agile is all about adjustments here and there, fine tuning and responding to change.  It’s really hard to adjust and fine tune if we don’t pause to find out where adjustments are needed.  The status quo is not Agile; continual improvement is.