LeSS: Penjelasan Framework Large-Scale Scrum

Setiap organisasi yang tumbuh melampaui satu tim Scrum akhirnya mengajukan pertanyaan yang sama: bagaimana mengoordinasikan sepuluh, tiga puluh, atau delapan puluh tim tanpa kehilangan hal yang membuat Scrum berhasil sejak awal? SAFe menjawabnya dengan menambah struktur: lebih banyak peran, lebih banyak seremoni, lebih banyak lapisan untuk menjaga semua orang tetap selaras. Large-Scale Scrum (LeSS) menjawabnya dengan melakukan kebalikannya.

LeSS adalah Scrum yang diterapkan pada banyak tim yang membangun satu produk bersama, dan ia sampai ke sana dengan menyederhanakan organisasi (descaling) alih-alih menumpuk sesuatu yang baru di atasnya. Alih-alih bertanya bagaimana menjalankan agile dalam skala besar, ia berangkat dari pertanyaan yang lebih kecil dan lebih sulit: seberapa sederhana organisasi bisa menjadi sambil tetap benar-benar agile.

Fakta Utama

• Large-Scale Scrum dibentuk oleh Craig Larman dan Bas Vodde, yang bekerja sama menskalakan Scrum sejak 2005.
• less.works mendefinisikan dua framework: LeSS untuk 2 hingga 8 tim, dan LeSS Huge untuk lebih dari 8, dengan batas delapan tim digambarkan sebagai "sekadar pengamatan empiris batas atas," bukan aturan baku.
• less.works menyebut sepuluh prinsip LeSS, bukan sembilan, jumlah yang salah dikutip beberapa ringkasan sekunder.
• Dalam LeSS Huge, sebuah Requirement Area berisi 4 hingga 8 tim secara desain, tidak pernah kurang.

Apa itu LeSS (Large-Scale Scrum)?

Large-Scale Scrum (LeSS) adalah Scrum yang diterapkan pada beberapa tim yang membangun satu produk bersama, dan ia sampai ke sana dengan menyederhanakan organisasi alih-alih menambahkan lapisan koordinasi di atasnya. Sementara banyak framework penskalaan bertanya bagaimana menjalankan agile dalam skala besar, less.works membingkai pertanyaan LeSS secara berbeda: bagaimana kita bisa menyederhanakan organisasi, dan menjadi agile, bukan sekadar menjalankan gerakannya.

Craig Larman dan Bas Vodde membangun framework ini dari pekerjaan klien yang dimulai pada 2005. Bertahun-tahun menskalakan Scrum bersama organisasi nyata menjadi aturan LeSS yang diterbitkan framework ini saat ini. Dua framework lahir dari pekerjaan itu. LeSS biasa mencakup 2 hingga 8 tim. LeSS Huge mengambil alih dari sana untuk lebih dari 8. less.works terbuka bahwa batas delapan tim bukan aturan baku, menyebutnya "sekadar pengamatan empiris batas atas," titik di mana mereka melihat struktur yang lebih kecil mulai membutuhkan bantuan, bukan angka yang tertanam dalam logika framework.

Kedua framework mempertahankan hal-hal tak tertawar yang sama: satu Product Backlog, satu Definition of Done, satu Sprint, satu Product Owner, dan satu Potentially Shippable Product Increment, berapa pun jumlah tim yang berkontribusi.

Sepuluh prinsip LeSS

less.works eksplisit soal jumlahnya: sepuluh prinsip, bukan sembilan. Itu menjebak orang karena cukup banyak ringkasan sekunder yang membulatkan ke sembilan, menghilangkan satu di tengah jalan. Perbedaan ini kurang penting sebagai trivia dan lebih penting karena inilah gagasan tempat aturan LeSS sebenarnya berasal. less.works mengatakan prinsip-prinsip itu "membimbing kami dalam menciptakan LeSS," dan seharusnya membimbing implementasi dengan cara yang sama: itulah yang Anda andalkan ketika muncul situasi yang tidak dicakup aturan.

Prinsip terakhir itu layak direnungkan jika Anda pernah berurusan dengan SAFe atau framework lain yang bertumpu pada alur kerja paralel: teori antrean mengatakan menambah work in progress memperlambat segalanya, meski terasa seolah lebih banyak upaya paralel seharusnya mempercepat. LeSS menerapkan logika itu pada seluruh organisasi, bukan hanya board satu tim.

LeSS vs LeSS Huge: apa yang benar-benar berubah setelah delapan tim

Dua hingga delapan tim adalah wilayah LeSS biasa, dan dalam rentang itu tidak ada yang berubah secara struktural dalam koordinasi: satu Product Backlog, satu Product Owner yang bekerja langsung dengan setiap tim, satu Sprint. Setelah delapan tim, LeSS Huge menambahkan mekanisme yang diperlukan untuk menjaga pandangan seluruh produk ketika tak ada Product Owner tunggal yang masuk akal bisa memantau pekerjaan harian setiap tim sendirian.

Area Product Owner mengkhususkan diri pada area mereka dan bertindak seperti Product Owner bagi tim di dalamnya, tetapi Product Owner keseluruhan memegang keputusan akhir atas backlog dan visi seluruh produk. Keduanya selalu bersinkronisasi, khususnya sebelum Sprint Planning, sehingga prioritas lokal Area PO tidak pernah jauh menyimpang dari apa yang telah diputuskan Product Owner keseluruhan sebagai yang terpenting. Titik koordinasi itulah tempat LeSS Huge membenarkan kompleksitas tambahannya: ia ada untuk melindungi fokus seluruh produk ketika jumlah tim melampaui yang bisa dipantau satu orang sendirian.

Sprint LeSS: satu Sprint, banyak tim

Secara konseptual, LeSS menjalankan satu Sprint level produk untuk seluruh produk, bukan satu Sprint per tim dengan jamnya sendiri. Setiap tim memulai dan mengakhiri bersama, dan hasilnya adalah satu Increment produk terintegrasi yang berpotensi dirilis, bukan tumpukan increment level tim yang harus direkonsiliasi kemudian. Sprint Planning untuk setiap tim berlangsung bersamaan, begitu pula Sprint Review dan retrospective. Yang tidak harus sejajar adalah backlog refinement: tim dapat melakukan refinement sesuai jadwal sendiri selama item siap saat Sprint Planning dimulai.

Sprint Planning sendiri terbagi menjadi dua bagian, sama seperti di level satu tim, hanya dengan lebih banyak orang di ruangan pada paruh pertama.

Refinement adalah tempat LeSS menuntut disiplin paling besar, karena mudah dibiarkan lolos ketika tak ada yang memaksanya masuk kalender seperti Sprint Planning. less.works menyebut versi multi-tim itu "bisa dibilang event terpenting dalam LeSS," dan tim biasanya menghabiskan sekitar sepersepuluh kapasitas Sprint untuknya. Lewatkan, dan Sprint Planning One berubah menjadi rapat untuk memperjelas alih-alih memilih, kebalikan dari tujuannya.

Sprint Review layak mendapat sebutan tersendiri, karena mudah menjalankannya seperti demo satu tim yang sekadar diperlebar untuk lebih banyak orang. LeSS memperlakukannya sebagai titik inspect-and-adapt yang sungguhan atas seluruh produk, bukan gerbang persetujuan Product Owner, perbedaan yang lebih halus daripada kedengarannya. Demo yang sebenarnya adalah pos pemeriksaan persetujuan melatih tim untuk tampil di hadapan PO. Bazar yang membiarkan pemangku kepentingan berkeliling, bertanya, dan membentuk apa yang terjadi berikutnya melatih organisasi untuk benar-benar melihat produk yang dibangunnya.

Satu Product Owner untuk seluruh produk (bagian yang diragukan semua orang)

Ini detail yang membuat kebanyakan orang tertegun saat pertama kali mendengarnya: satu Product Owner, untuk seluruh produk, di semua tim, berapa pun jumlah tim itu. Kedengarannya seperti bottleneck yang menunggu terjadi. Dalam praktik, LeSS membuat hitungannya masuk akal dengan bersikap presisi tentang apa yang sebenarnya harus dilakukan Product Owner.

Itu membuat Product Owner sepenuhnya tidak terlibat dalam Sprint Planning Two, Daily Scrum, dan retrospective level tim. Rapat-rapat itu milik tim, bukan PO. LeSS mewujudkannya dengan memisahkan dua pekerjaan yang digabungkan banyak organisasi dalam satu peran: prioritisasi dan klarifikasi. Product Owner memegang prioritisasi, memutuskan apa yang terpenting dan mengapa. Klarifikasi, bolak-balik tentang persis bagaimana sebuah item harus berperilaku, terjadi langsung antara tim dan pelanggan atau pemangku kepentingan, dengan PO tersedia tetapi tidak wajib sebagai perantara. less.works menggambarkan peran yang dimaksud sebagai "penghubung, bukan perantara," pekerjaan yang berbeda secara berarti dari menjadi satu-satunya kanal resmi untuk setiap pertanyaan tim.

Bentuknya juga berbeda dari yang banyak diasumsikan pembaca di awal. Ini bukan Product Manager yang duduk di atas beberapa Product Owner, mengoordinasikan tim para koordinator. Ini satu orang yang menjalankan pekerjaan Scrum Product Owner, pada skala produk, dengan bagian pekerjaan yang tak bisa diskalakan diserahkan kepada tim.

Pemisahan itu juga melindungi otonomi tim dengan cara yang mudah terlewat. Jika setiap pertanyaan klarifikasi harus melewati satu orang, LeSS akan menciptakan kembali bottleneck persis seperti yang diasumsikan para pengkritik. Sebaliknya, tim yang bisa berbicara langsung dengan pelanggan bergerak lebih cepat pada detail, dan Product Owner menghabiskan waktu yang dibebaskan untuk hal yang hanya bisa dilakukan satu orang untuk seluruh produk: memutuskan apa yang dibangun berikutnya. Jika Anda menimbang peran ini terhadap pekerjaan koordinasi yang ditangani Scrum Master di level tim, pemisahannya sama dengan yang sudah ada di Scrum satu tim, hanya diterapkan di lebih banyak tim, bukan di dalam satu.

LeSS vs SAFe: descaling vs menambah struktur

Pembaca biasanya tiba di halaman ini setelah membaca tentang SAFe, dan cara adil membandingkannya adalah dengan menyebut apa yang sebenarnya dioptimalkan masing-masing. SAFe mempertahankan tim kurang lebih seperti adanya dan menambahkan lapisan, peran, dan ritme perencanaan berskala untuk mengoordinasikannya. LeSS menuju arah lain: ia meminta organisasi menata ulang di sekitar feature team, menyingkirkan peran ekstra, dan berkoordinasi lewat satu Sprint dan satu Backlog alih-alih setumpuk event perencanaan.

Tak satu pun sisi tabel itu salah, dan tak ada framework yang lebih agile daripada yang lain menurut ukuran objektif. Keduanya memecahkan masalah koordinasi yang sama dengan naluri berlawanan: SAFe mengasumsikan koordinasi butuh lebih banyak perancah, dan LeSS mengasumsikan sebagian besar perancah itulah masalah yang ingin dipecahkannya. Di mana SAFe memakai PI Planning sebagai event sinkronisasinya, LeSS memakai Sprint Planning One, event yang sama yang sudah dijalankan satu tim, hanya dengan setiap tim di ruangan. Itulah kesenjangan filosofis dalam satu perbandingan: satu framework membangun event baru untuk menangani skala, yang lain menskalakan event yang sudah dimilikinya.

LeSS vs model Spotify vs Scrum multi-tim biasa

Dua perbandingan lagi cukup sering muncul untuk dibahas singkat. Tak satu pun benar-benar pesaing LeSS seperti SAFe, karena keduanya memecahkan masalah yang sedikit berbeda.

Model Spotify tidak pernah dimaksudkan untuk disalin mentah-mentah, dan Spotify sendiri telah melampaui struktur aslinya bertahun-tahun lalu. Ia berguna sebagai kosakata (squad, chapter, guild) tetapi buruk sebagai buku aturan, karena tak pernah menerbitkannya. Scrum multi-tim biasa, beberapa tim yang masing-masing menjalankan Scrum standar tanpa framework bersama di atasnya, adalah yang dilakukan kebanyakan organisasi secara default sebelum mengadopsi apa pun, dan biasanya itulah yang pertama patah: tak ada yang mencegah Product Owner dua tim memprioritaskan ke arah berlawanan, karena tak ada yang mengikat backlog mereka sejak awal. LeSS, dalam arti nyata, adalah hasil jika Anda mengambil setup default itu dan memperbaiki hal spesifik yang mematahkannya: satu Backlog, satu Owner, satu Sprint. Ada jawaban lebih tua atas pertanyaan yang sama yang layak diketahui: Crystal berskala dengan mengganti anggota keluarga metodologi yang lebih berat seiring tim membesar, alih-alih mempertahankan satu framework dan menata ulang organisasi di sekitarnya.

Realitas adopsi: apa yang sebenarnya diminta adopsi LeSS

SAFe lebih mudah dijual, dan perlu dikatakan terus terang mengapa. Rollout SAFe menambahkan hal-hal: peran baru, kurikulum pelatihan, sertifikasi, event bernama di kalender. Ia terlihat seperti kemajuan di bagan organisasi, bahkan sebelum menghasilkan apa pun. Adopsi LeSS menghapus hal-hal, dan penghapusan adalah cerita yang jauh lebih sulit disampaikan kepada ruangan penuh manajer yang pekerjaannya saat ini mungkin salah satu yang akan hilang.

Tak satu pun dari itu halus. Menata ulang di sekitar feature team biasanya berarti pekerjaan sebagian orang berubah bentuk, dan menggabungkan Product Ownership menjadi satu peran biasanya berarti jabatan orang lain hilang atau didefinisikan ulang. Itu permintaan yang benar-benar berbeda dari SAFe, yang kebanyakan melatih orang ke peran baru alih-alih menghapus peran yang sudah ada. Itu juga bagian dari alasan adopsi LeSS cenderung lebih kecil dan lebih lambat menyebar dibanding rollout SAFe. Lebih sedikit organisasi yang bersedia membahas hal itu dengan struktur manajemennya sendiri, bahkan ketika argumen dasar untuk descaling itu kuat.

LeSS cenderung cocok untuk organisasi yang sudah menjalankan Scrum satu tim dengan baik dan memiliki backlog nyata untuk dibuktikan, bukan yang masih mempelajari apa arti Sprint atau Definition of Done sehari-hari. Ia juga cocok untuk organisasi yang bersedia menunjuk satu Product Owner dengan otoritas nyata atas seluruh produk, dan bersedia menata ulang di sekitar feature team alih-alih mempertahankan struktur tim komponen yang sudah ada. Ia tidak cocok untuk organisasi yang membutuhkan struktur pelaporan dan peran yang dituntut lingkungan teregulasi atau berkontrak berat, atau yang mengelola beberapa produk yang benar-benar terpisah dan sejak awal tidak berbagi satu backlog. Kasus-kasus itu biasanya lebih cocok di bawah lapisan portfolio SAFe atau model lain sama sekali.

Kapan tidak memakai LeSS

Tak satu pun dari ini alasan bahwa LeSS framework yang buruk. Itu alasan mengapa organisasi tertentu, pada saat tertentu, mungkin belum siap untuk apa yang diminta. Versi jujur dari kalimat itu juga berlaku untuk SAFe, atau pendekatan penskalaan apa pun: framework bukan bagian yang sulit. Mengubah cara organisasi sebenarnya distrukturkan itulah yang sulit, dan itu benar baik framework menambah perancah maupun mengambilnya.

LeSS bukan jualan yang lebih mudah, dan ia tak pernah berusaha menjadi demikian. Jika organisasi Anda sudah menjalankan Scrum satu tim dengan baik dan bersedia menata ulang di sekitar feature team dan satu Product Owner, descaling adalah opsi nyata, bukan sekadar sikap filosofis. Jika belum bersedia melakukannya, SAFe atau pendekatan yang lebih ringan kemungkinan akan membawa Anda lebih jauh, lebih cepat, dan itu juga jawaban yang sah. Pilihannya bukan soal framework mana yang lebih agile. Ini soal arah perubahan mana yang benar-benar bisa dilakukan organisasi Anda.