#antipattern

Learn by frustration. A guide on what not to do and remember to avoid it :P

7 Anti-Pattern Umum dalam Scrum: Sebuah Analisis

Scrum, sebagai salah satu kerangka kerja Agile yang populer, memberikan struktur bagi tim untuk menghasilkan nilai secara iteratif dan inkremental. Namun, meskipun memiliki keunggulan, sering kali tim terjebak dalam anti-pattern, yaitu kebiasaan atau praktik yang terlihat bermanfaat tetapi justru merusak prinsip dasar Scrum. Visual yang diberikan menggambarkan tujuh anti-pattern umum dalam Scrum, yang menunjukkan kesalahpahaman terhadap peran, ritual, dan tujuan Scrum. Berikut adalah analisis setiap anti-pattern beserta dampaknya terhadap efektivitas Scrum:

1. Scrum Master sebagai Project Manager

Salah satu anti-pattern yang paling sering terjadi adalah memperlakukan Scrum Master seperti Project Manager tradisional. Pemahaman ini bertentangan dengan inti peran Scrum Master, yaitu sebagai fasilitator, pelatih, dan penjaga praktik Scrum. Ketika Scrum Master mengambil alih tugas manajemen proyek, seperti pembagian tugas dan penegakan tenggat waktu, hal ini merampas otonomi tim dan merusak prinsip self-organizing dalam Scrum.

2. Scrum Goals sebagai Project Mister

Anti-pattern ini menggambarkan penyalahgunaan sprint goals sebagai deliverable proyek yang kaku. Alih-alih menjadi tujuan yang memberikan makna, sprint goals sering kali direduksi menjadi sekadar daftar tugas tanpa konteks. Padahal, sprint goals seharusnya mencerminkan nilai yang ingin dicapai tim, bukan hanya daftar hasil keluaran. Ketika tujuan tidak selaras dengan visi yang lebih besar, fokus tim dalam memberikan nilai kepada pemangku kepentingan menjadi kabur.

3. Three Sprint Goals sebagai Wish List

Membebani sprint dengan terlalu banyak tujuan mengaburkan fokus dan prioritas tim. Anti-pattern ini mencerminkan kurangnya pemahaman akan pentingnya menetapkan tujuan yang ringkas dan dapat dicapai untuk membimbing tim. Pendekatan seperti “wish list” melemahkan kejelasan sprint, yang pada akhirnya menyebabkan pekerjaan tidak selesai dan menimbulkan rasa frustrasi dalam tim.

4. Sprint Goals sebagai Wish List

Mirip dengan anti-pattern sebelumnya, ini terjadi ketika sprint goals ditetapkan secara tidak realistis atau terlalu abstrak. Sprint goals bertujuan memberikan arahan dan nilai yang dapat diukur. Ketika tujuan hanya bersifat aspiratif alih-alih dapat dieksekusi, tim kehilangan kriteria keberhasilan yang jelas, sehingga retrospektif menjadi tidak efektif dan upaya perbaikan berkelanjutan terhambat.

5. Daily Standup sebagai Swish List

Daily standups adalah elemen penting dalam Scrum, dirancang untuk meningkatkan keselarasan tim dan mengidentifikasi hambatan. Namun, anti-pattern ini muncul ketika standup berubah menjadi daftar keinginan atau laporan status, sehingga kehilangan fokus utamanya untuk menyelesaikan masalah. Standup yang efektif harus singkat, kolaboratif, dan berpusat pada tiga pertanyaan inti: Apa yang dikerjakan kemarin? Apa yang akan dikerjakan hari ini? Hambatan apa yang ada?

6. Daily Standup sebagai Status Debt

Dalam anti-pattern ini, daily standup hanya menjadi ritual formal tanpa diskusi bermakna. Anggota tim mungkin hanya melaporkan progres tanpa membahas kendala atau mencari solusi. Pendekatan yang dangkal seperti ini menghasilkan status debt, di mana masalah yang tidak terselesaikan terus menumpuk, menghambat progres sprint secara keseluruhan.

7. Technical Debt sebagai Irnositechnal Debt

Anti-pattern terakhir ini menyoroti kegagalan dalam mengelola technical debt, yaitu akumulasi kompromi teknis dalam desain atau kode yang menghambat pengembangan di masa depan. Mengabaikan atau salah mengelola technical debt merusak skalabilitas, performa, dan maintainability produk. Tim Scrum harus secara aktif memasukkan resolusi technical debt ke dalam backlog untuk memastikan kesehatan produk dalam jangka panjang.

Kesimpulan

So I have now seen a specific type of horrible code from several programmers at my internship who really should know better. The code will look something like this:

And when I ask how on earth they managed to overcomplicate "calling a function" I get the answer "I am calling by reference!" Which... no... no you are not. So, there are two ways to feed arguments to a function. Known as calling by value, and calling by reference. When you call by value, the compiler takes a COPY of whatever you send in, and your function works on that copy. (By the way, that is faster than calling by reference when you need to send in small primitive variables, since playing with a 64bit address is harder than moving the 16 bits an int often is ) What is happening in the... abomination of a function call here, is that they use a shared pointer. And shared pointers are a great tool! It gives you all the safety and easy of use of working in a single thread environment with a statically allocated variable (IE, a variable allocated on the stack) when you are working with dynamically allocated memory in a multi-threaded environment. But when you use it on a statically allocated variable in a single threaded environment... then.... it gives you all the safety and easy of use... that you already had... When I asked why on earth they were doing this to that poor poor pointer, I got told that it was because using raw pointers was bad... Ok... first of all, yes, raw pointers are bad. Not really in of themselves, but because c++ have better tools than them for 99% of use cases... But that is not a reason to use a pointer at all! When I told him he was calling this function by value... just in a really weird complicated way, he disagreed. He was using a pointer! Yes... you are putting in a pointer... which gets copied... And together with the work on creating the pointer and the more complicated syntax of using a pointer... it is just bad. You know how you call by reference? You do it... by calling... with a reference... Not a pointer, a REFERENCE. The hint is in the name! This is the refactored code: