LeSS: Rangka Kerja Large-Scale Scrum Dijelaskan

Setiap organisasi yang melepasi satu pasukan Scrum akhirnya bertanya soalan yang sama: bagaimana anda menyelaras sepuluh, tiga puluh atau lapan puluh pasukan tanpa kehilangan apa yang menjadikan Scrum berkesan pada mulanya? SAFe menjawabnya dengan menambah struktur: lebih banyak peranan, lebih banyak upacara, lebih banyak lapisan untuk memastikan semua orang sejajar. Large-Scale Scrum (LeSS) menjawabnya dengan melakukan sebaliknya.

LeSS ialah Scrum yang diterapkan pada banyak pasukan yang membina satu produk bersama, dan ia mencapainya dengan descaling organisasi, bukan dengan melapiskan sesuatu yang baharu di atasnya. Daripada bertanya bagaimana melaksanakan agile pada skala besar, ia bermula daripada soalan yang lebih kecil dan lebih sukar: sejauh mana organisasi boleh dimudahkan sambil kekal benar-benar agile.

Fakta Utama

• Large-Scale Scrum dibentuk oleh Craig Larman dan Bas Vodde, yang bekerjasama menskalakan Scrum sejak 2005.
• less.works mentakrifkan dua rangka kerja: LeSS untuk 2 hingga 8 pasukan, dan LeSS Huge untuk lebih daripada 8, dengan had lapan pasukan itu digambarkan sebagai "sekadar pemerhatian empirikal had atas," bukan peraturan tegar.
• less.works menamakan sepuluh prinsip LeSS, bukan sembilan, bilangan yang disalah nyatakan oleh beberapa ringkasan sekunder.
• Dalam LeSS Huge, sebuah Requirement Area menempatkan 4 hingga 8 pasukan secara reka bentuk, tidak pernah kurang.

Apa itu LeSS (Large-Scale Scrum)?

Large-Scale Scrum (LeSS) ialah Scrum yang diterapkan pada beberapa pasukan yang membina satu produk bersama, dan ia mencapainya dengan descaling organisasi dan bukan menambah lapisan penyelarasan di atasnya. Sementara banyak rangka kerja penskalaan bertanya bagaimana melaksanakan agile pada skala besar, less.works membingkai soalan LeSS secara berbeza: bagaimana kita boleh memudahkan organisasi, dan menjadi agile, bukan sekadar menjalankan gerak langkahnya.

Craig Larman dan Bas Vodde membina rangka kerja ini daripada kerja klien yang bermula pada tahun 2005. Bertahun-tahun menskalakan Scrum bersama organisasi sebenar menjadi peraturan LeSS yang diterbitkan rangka kerja ini hari ini. Dua rangka kerja lahir daripada kerja itu. LeSS biasa merangkumi 2 hingga 8 pasukan. LeSS Huge mengambil alih dari situ untuk lebih daripada 8. less.works berterus terang bahawa had lapan pasukan itu bukan peraturan tegar, menyebutnya "sekadar pemerhatian empirikal had atas," iaitu titik di mana mereka melihat struktur yang lebih kecil mula memerlukan bantuan, bukan nombor yang terbina dalam logik rangka kerja.

Kedua-dua rangka kerja mengekalkan perkara tidak boleh dirunding yang sama: satu Product Backlog, satu Definition of Done, satu Sprint, satu Product Owner dan satu Product Increment yang berpotensi untuk dihantar, tidak kira berapa banyak pasukan yang menyumbang kepadanya.

Sepuluh prinsip LeSS

less.works jelas tentang bilangannya: sepuluh prinsip, bukan sembilan. Itu mengelirukan kerana sebilangan besar ringkasan sekunder membundarkannya kepada sembilan, dengan menggugurkan satu. Perbezaan itu penting bukan sebagai remeh-temeh, tetapi kerana inilah idea yang menjadi punca peraturan LeSS yang sebenar. less.works menyatakan prinsip-prinsip itu "membimbing kami dalam mencipta LeSS," dan ia patut membimbing pelaksanaan dengan cara yang sama: ia adalah apa yang anda rujuk apabila muncul situasi yang tidak dilindungi oleh peraturan.

Prinsip terakhir itu patut direnungkan jika anda pernah bekerja dalam SAFe atau rangka kerja lain yang bergantung pada aliran kerja selari: teori baris gilir menyatakan bahawa menambah lebih banyak kerja dalam proses melambatkan segala-galanya, walaupun terasa seolah-olah lebih banyak usaha selari sepatutnya mempercepatkan. LeSS menerapkan logik itu kepada seluruh organisasi, bukan hanya papan satu pasukan.

LeSS berbanding LeSS Huge: apa yang sebenarnya berubah selepas lapan pasukan

Dua hingga lapan pasukan ialah tempat LeSS biasa berada, dan dalam julat itu tiada apa yang berubah secara struktur dari segi penyelarasan: satu Product Backlog, satu Product Owner yang bekerja terus dengan setiap pasukan, satu Sprint. Selepas lapan pasukan, LeSS Huge menambah mekanisme yang diperlukan untuk mengekalkan pandangan keseluruhan produk apabila tiada satu Product Owner pun yang munasabah boleh menjejaki kerja harian setiap pasukan seorang diri.

Area Product Owner mengkhusus dalam kawasan mereka dan bertindak seperti Product Owner kepada pasukan di dalamnya, tetapi Product Owner keseluruhan mengekalkan keputusan akhir mengenai backlog dan visi seluruh produk. Kedua-duanya sentiasa menyelaras, khususnya sebelum Perancangan Sprint, supaya keutamaan tempatan seorang Area PO tidak menyimpang jauh daripada apa yang sebenarnya telah diputuskan oleh Product Owner keseluruhan sebagai paling penting. Titik penyelarasan itulah yang menjadikan kerumitan tambahan LeSS Huge berbaloi: ia wujud untuk melindungi fokus keseluruhan produk apabila bilangan pasukan melebihi apa yang mampu dijejaki oleh seorang.

Sprint LeSS: satu Sprint, banyak pasukan

Secara konsep, LeSS menjalankan satu Sprint peringkat produk untuk seluruh produk, bukan satu Sprint bagi setiap pasukan pada jamnya sendiri. Setiap pasukan bermula dan berakhir bersama, dan hasilnya ialah satu Increment produk bersepadu yang berpotensi untuk dihantar, bukan longgokan increment peringkat pasukan yang perlu didamaikan kemudian. Perancangan Sprint untuk setiap pasukan berlaku serentak, begitu juga Semakan Sprint dan retrospektif. Yang tidak perlu sejajar ialah penghalusan backlog: pasukan boleh menghalusi mengikut jadual sendiri selagi item sedia apabila Perancangan Sprint bermula.

Perancangan Sprint itu sendiri terbahagi kepada dua bahagian, sama seperti pada peringkat satu pasukan, cuma dengan lebih ramai orang dalam bilik untuk separuh pertama.

Penghalusan ialah tempat LeSS menuntut disiplin paling tinggi, kerana mudah membiarkannya terabai apabila tiada apa yang memaksanya masuk kalendar seperti Perancangan Sprint. less.works menyebut versi multi-pasukan sebagai "boleh dikatakan acara paling penting dalam LeSS," dan pasukan lazimnya menghabiskan kira-kira sepersepuluh kapasiti Sprint mereka padanya. Langkau ia, dan Perancangan Sprint One menjadi mesyuarat yang dihabiskan untuk menjelaskan dan bukan memilih, iaitu bertentangan dengan tujuannya.

Semakan Sprint wajar disebut tersendiri, kerana mudah untuk menjalankannya seperti demo satu pasukan yang dibentangkan kepada lebih ramai orang. LeSS menganggapnya sebagai titik periksa-dan-adaptasi sebenar pada seluruh produk, bukan pintu kelulusan Product Owner, satu perbezaan yang lebih halus daripada bunyinya. Demo yang sebenarnya ialah pusat semakan kelulusan melatih pasukan untuk membuat persembahan kepada PO. Bazar yang membenarkan pihak berkepentingan merayau, bertanya dan membentuk apa yang berlaku seterusnya melatih organisasi untuk benar-benar melihat produk yang dibinanya.

Satu Product Owner untuk seluruh produk (bahagian yang diragui semua orang)

Inilah butiran yang menghentikan kebanyakan orang pada kali pertama mereka mendengarnya: satu Product Owner, untuk seluruh produk, merentas setiap pasukan, tidak kira berapa banyak pasukan itu. Bunyinya seperti kesesakan yang menunggu untuk berlaku. Dalam amalan, LeSS menjadikan pengiraannya berfungsi dengan tepat tentang apa yang sebenarnya perlu dilakukan Product Owner.

Itu meninggalkan Product Owner sepenuhnya di luar Perancangan Sprint Two, Daily Scrum dan retrospektif peringkat pasukan. Mesyuarat-mesyuarat itu milik pasukan, bukan PO. LeSS mencapainya dengan memisahkan dua tugas yang digabungkan oleh banyak organisasi menjadi satu peranan: pengutamaan dan penjelasan. Product Owner memiliki pengutamaan, memutuskan apa yang paling penting dan mengapa. Penjelasan, iaitu bual bicara tentang bagaimana tepatnya sesuatu item patut berfungsi, berlaku terus antara pasukan dengan pelanggan atau pihak berkepentingan, dengan PO tersedia tetapi tidak diwajibkan sebagai pengantara. less.works menerangkan peranan yang dimaksudkan sebagai "penyambung, bukan pengantara," satu tugas yang jauh berbeza daripada menjadi saluran tunggal yang diluluskan untuk setiap soalan yang dimiliki pasukan.

Bentuknya juga berbeza daripada apa yang disangka ramai pembaca pada awalnya. Ini bukan Product Manager yang duduk di atas beberapa Product Owner, menyelaras pasukan penyelaras. Ia ialah seorang yang melakukan tugas Product Owner Scrum, pada skala produk, dengan bahagian tugas yang tidak boleh diskalakan diserahkan kepada pasukan.

Pembahagian itu juga melindungi autonomi pasukan dengan cara yang mudah terlepas pandang. Jika setiap soalan penjelasan perlu melalui seorang sahaja, LeSS akan mencipta semula kesesakan yang dianggap wujud oleh pengkritik. Sebaliknya, pasukan yang boleh bercakap terus dengan pelanggan bergerak lebih pantas pada butiran, dan Product Owner menggunakan masa yang terluang untuk perkara yang hanya seorang boleh lakukan untuk seluruh produk: memutuskan apa yang dibina seterusnya. Jika anda menimbang peranan ini berbanding tugas penyelarasan yang dikendalikan Scrum Master pada peringkat pasukan, pembahagiannya sama seperti yang sudah wujud dalam Scrum satu pasukan, cuma diterapkan merentas lebih banyak pasukan dan bukan di dalam satu.

LeSS berbanding SAFe: descaling lawan menambah struktur

Pembaca biasanya tiba di halaman ini selepas membaca tentang SAFe, dan cara yang adil untuk membandingkannya ialah menyatakan apa yang sebenarnya dioptimumkan oleh setiap satu. SAFe mengekalkan pasukan lebih kurang seperti sedia ada dan menambah lapisan, peranan serta rentak perancangan berskala untuk menyelaraskannya. LeSS pergi ke arah lain: ia meminta organisasi menyusun semula di sekeliling pasukan ciri, membuang peranan tambahan, dan menyelaras melalui satu Sprint dan satu Backlog dan bukan timbunan acara perancangan.

Tiada satu pun sisi jadual itu salah, dan tiada rangka kerja yang lebih agile daripada yang lain mengikut ukuran objektif. Kedua-duanya menyelesaikan masalah penyelarasan yang sama dengan gerak hati yang bertentangan: SAFe menganggap penyelarasan memerlukan lebih banyak perancah, dan LeSS menganggap kebanyakan perancah itulah masalah yang cuba diselesaikannya. Di mana SAFe menggunakan PI Planning sebagai acara penyegerakannya, LeSS menggunakan Perancangan Sprint One, acara yang sama yang sudah dijalankan oleh satu pasukan, cuma dengan setiap pasukan berada dalam bilik. Itulah jurang falsafah dalam satu perbandingan: satu rangka kerja membina acara baharu untuk mengendalikan skala, yang lain menskalakan acara yang sedia ada.

LeSS berbanding model Spotify berbanding Scrum multi-pasukan biasa

Dua lagi perbandingan sering timbul sehingga wajar dibincangkan secara ringkas. Tiada satu pun benar-benar pesaing LeSS seperti SAFe, kerana kedua-duanya menyelesaikan masalah yang sedikit berbeza.

Model Spotify tidak pernah dimaksudkan untuk disalin sepenuhnya, dan Spotify sendiri telah melangkaui struktur asal itu bertahun-tahun lalu. Ia sesuai sebagai perbendaharaan kata (squad, chapter, guild) tetapi kurang sesuai sebagai buku peraturan, kerana ia tidak pernah menerbitkannya. Scrum multi-pasukan biasa, beberapa pasukan yang masing-masing menjalankan Scrum piawai tanpa rangka kerja bersama dilapiskan di atasnya, ialah apa yang kebanyakan organisasi lakukan secara lalai sebelum mengguna pakai apa-apa yang lain, dan biasanya itulah yang rosak dahulu: tiada apa menghalang Product Owner dua pasukan daripada mengutamakan ke arah bertentangan, kerana pada mulanya tiada apa yang mengikat backlog mereka. LeSS, dalam erti kata sebenar, ialah apa yang anda dapat apabila mengambil persediaan lalai itu dan membetulkan perkara khusus yang merosakkannya: satu Backlog, satu Pemilik, satu Sprint. Ada jawapan yang lebih lama untuk soalan yang sama dan berbaloi diketahui: Crystal berskala dengan menukar kepada ahli keluarga metodologi yang lebih berat apabila pasukan membesar, bukannya mengekalkan satu rangka kerja dan membentuk semula organisasi di sekelilingnya.

Realiti penerimaan: apa yang sebenarnya dituntut oleh penerimaan LeSS

SAFe lebih mudah dijual, dan wajar dinyatakan dengan jelas sebabnya. Pelancaran SAFe menambah sesuatu: peranan baharu, kurikulum latihan, pensijilan, acara bernama dalam kalendar. Ia kelihatan seperti kemajuan pada carta organisasi, walaupun sebelum menghantar apa-apa. Penerimaan LeSS membuang sesuatu, dan pembuangan ialah cerita yang jauh lebih sukar diceritakan kepada bilik penuh pengurus yang kerja semasanya mungkin salah satu yang akan hilang.

Tiada satu pun daripada itu halus. Menyusun semula di sekeliling pasukan ciri biasanya bermakna kerja sesetengah orang berubah bentuk, dan menyatukan Product Ownership menjadi satu peranan biasanya bermakna jawatan orang lain hilang atau ditakrifkan semula. Itu permintaan yang benar-benar berbeza daripada SAFe, yang kebanyakannya melatih orang ke dalam peranan baharu dan bukan membuang peranan yang sedia ada. Ia juga sebahagian sebab penerimaan LeSS cenderung lebih kecil dan lebih perlahan tersebar berbanding pelancaran SAFe. Lebih sedikit organisasi sanggup mengadakan perbualan itu dengan struktur pengurusan mereka sendiri, walaupun asas kes untuk descaling adalah kukuh.

LeSS cenderung sesuai untuk organisasi yang sudah menjalankan Scrum satu pasukan dengan baik dan mempunyai backlog sebenar sebagai bukti, bukan yang masih belajar apa maksud Sprint atau Definition of Done dari hari ke hari. Ia juga sesuai untuk organisasi yang sanggup melantik seorang Product Owner dengan kuasa sebenar ke atas seluruh produk, dan sanggup menyusun semula di sekeliling pasukan ciri dan bukan mempertahankan struktur pasukan komponen yang sedia ada. Ia tidak sesuai untuk organisasi yang memerlukan struktur pelaporan dan peranan yang dituntut oleh persekitaran terkawal selia atau berkontrak berat, atau yang menguruskan beberapa produk yang benar-benar berasingan dan tidak berkongsi satu backlog sejak awal. Kes-kes itu biasanya lebih sesuai di bawah lapisan portfolio SAFe atau model lain sepenuhnya.

Bila tidak patut menggunakan LeSS

Tiada satu pun daripada ini sebab LeSS rangka kerja yang buruk. Ia adalah sebab sesebuah organisasi tertentu, pada saat tertentu, mungkin belum bersedia untuk apa yang dituntutnya. Versi jujur ayat itu juga terpakai untuk SAFe, atau mana-mana pendekatan penskalaan: rangka kerja bukan bahagian yang sukar. Mengubah cara organisasi sebenarnya distruktur ialah bahagian yang sukar, dan itu benar sama ada rangka kerja menambah perancah atau membuangnya.

LeSS bukan jualan yang lebih mudah, dan ia tidak pernah cuba menjadi begitu. Jika organisasi anda sudah menjalankan Scrum satu pasukan dengan baik dan bersedia menyusun semula di sekeliling pasukan ciri dan seorang Product Owner, descaling ialah pilihan sebenar, bukan sekadar pendirian falsafah. Jika ia belum bersedia melakukannya, SAFe atau pendekatan yang lebih ringan mungkin akan pergi lebih jauh dan lebih pantas, dan itu juga jawapan yang sah. Pilihannya bukan tentang rangka kerja mana yang lebih agile. Ia tentang arah perubahan mana yang benar-benar mampu dibuat oleh organisasi anda.