5 Kerangka Penskalaan Agile Dibandingkan: Mana Yang Harus Anda Gunakan?

Bayangkan ini: Pada awal sebuah proyek, Anda membentuk satu tim individu yang efektif dan lintas fungsi yang berkomitmen untuk mencapai tujuan produk. Untuk meningkatkan kinerja, Anda memastikan tim mahir dalam Agile. Permintaan untuk produk tumbuh, meningkatkan persyaratan dan memperluas backlog. Anda dan pemangku kepentingan lainnya menyadari bahwa tim perlu ditingkatkan. Terdengar akrab?

Penskalaan memungkinkan beberapa tim bekerja sama untuk mempertahankan kelincahan mereka. Jika ada lebih banyak pekerjaan yang harus diselesaikan daripada yang dapat ditangani tim Anda dalam jangka waktu yang wajar, inilah saatnya untuk mengukur. Namun, untuk melakukannya, Anda harus memilih kerangka kerja yang tepat, dan ada beberapa yang bisa dipilih. Memilih dengan buruk dan implementasi bisa gagal, mengganggu produktivitas dan mengakibatkan dampak finansial yang signifikan.

Kerangka kerja yang paling cocok untuk tim Anda akan bervariasi, tergantung pada faktor-faktor seperti pendanaan yang tersedia, pendekatan organisasi, dan kompleksitas produk.

Kapan Anda Harus Menskalakan?

Ada sejumlah kriteria utama yang harus dipenuhi sebelum Anda harus mempertimbangkan penskalaan:

Bisakah Anda mengelola pengembangan hanya dengan satu tim?

Menerapkan kerangka kerja Agile yang diskalakan bisa jadi rumit dan memakan waktu, jadi jangan lakukan penskalaan jika tidak perlu. Ketika beban kerja tim Anda melebihi kemampuannya, maka penskalaan diperlukan.

Apakah tim Anda Agile?

Mungkin kriteria yang paling penting adalah kemampuan tim Anda dalam pendekatan Agile. Jika tim Anda tidak berpengalaman di Agile, maka penskalaan akan menciptakan lebih banyak masalah.

Apakah praktik pengembangan tim Anda perlu ditingkatkan?

Jika praktik teknik tim Anda tidak efisien, penskalaan mungkin tidak memberikan hasil yang diinginkan. Praktik seperti implementasi DevOps yang tepat dan pipeline CI/CD sangat penting untuk konsistensi di seluruh tim. Selain itu, tanpa jaminan kualitas standar, mungkin sulit untuk menguji fitur baru.

Apakah tim Anda memberikan peningkatan terintegrasi?

Penskalaan melibatkan pengintegrasian beberapa tim yang berkolaborasi pada produk yang sama, di mana setiap tim menghasilkan fitur yang bekerja bersama. Tabel berikut merinci empat kemungkinan konfigurasi tim dan produk. Perhatikan bahwa hanya satu yang memerlukan penskalaan.

Memilih Kerangka Penskalaan

Ada banyak kerangka kerja penskalaan Agile untuk dipilih, tetapi kami akan fokus pada lima solusi yang paling banyak digunakan: Kerangka Kerja Agile Berskala (SAFe), Nexus, Scrum Skala Besar (LeSS), Scrum@Scale, dan Disiplin Agile (DA) . Saya telah menemukan ini sebagai kerangka kerja yang paling efektif, dan mereka dapat diterapkan pada berbagai skenario dan organisasi. Bagian berikut akan membekali Anda dengan informasi yang Anda butuhkan untuk membuat pilihan terbaik untuk konteks penskalaan unik Anda.

1. Kerangka Agile Berskala (SAFe)

SAFe adalah kerangka kerja paling populer untuk penskalaan Agile. Sebuah survei tahun 2021 menemukan bahwa 37% praktisi Agile menggunakannya, sebagian besar karena beberapa konfigurasinya, yang semuanya fokus pada aliran nilai dan memiliki panduan dan prosedur yang terdefinisi dengan baik.

Karena SAFe digunakan untuk memberikan solusi kompleks yang membutuhkan lebih dari 50 orang, SAFe mengatur tim ke dalam agile release trains (ARTs). Untuk menyinkronkan tim dalam ART, SAFe menggunakan iterasi peningkatan program—mirip dengan sprint Scrum—dan setiap iterasi biasanya berlangsung selama delapan hingga 12 minggu. Pendekatan ini memungkinkan manajer produk untuk tetap fokus pada tujuan keseluruhan dan mengawasi peta jalan produk yang kompleks secara efisien tanpa memperkenalkan perubahan yang berlebihan.

SAFe didasarkan pada kerangka kerja Scrum tetapi dengan beberapa perbedaan utama: adopsi SAFe terjadi di tingkat perusahaan daripada di tingkat tim; dan sementara Scrum memberi pemilik produk otoritas tunggal atas prioritas, SAFe mendorong pendekatan yang lebih demokratis.

SAFe memiliki empat tingkat implementasi:

AMAN Esensial

Essential SAFe adalah dasar dari SAFe dan harus dikuasai sebelum beralih ke konfigurasi berikutnya. Ini menggunakan peran Scrum yang sudah mapan seperti master Scrum, manajer produk, dan pemilik produk, dan juga memperkenalkan peran baru: insinyur kereta rilis. Orang ini bertindak sebagai pelayan-pemimpin dan pelatih ART, membimbing tim untuk menyelaraskan tujuan mereka. Mungkin ada antara lima dan 12 tim dalam satu ART, dengan masing-masing ART mampu memberikan solusi lengkap.

Solusi Besar

Konfigurasi ini berada di atas Essential SAFe dan memperkenalkan konsep yang disebut “kereta solusi.” Ini digunakan ketika membangun solusi besar dan kompleks yang memerlukan koordinasi beberapa ART—berpotensi ratusan atau bahkan ribuan orang—bekerja pada aliran nilai yang sama. Misalnya, jika Anda bekerja di Microsoft dan memiliki tiga tim terpisah yang memprogram Excel, Word, dan PowerPoint, mereka semua berkontribusi pada aliran nilai yang sama: Microsoft Office.

Portofolio

Portofolio terdiri dari beberapa ART yang bekerja pada aliran nilai yang berbeda. Melanjutkan dengan contoh Microsoft: tim terpisah yang mengerjakan produk Office, Skype, atau Xbox perusahaan.

Penuh AMAN

Konfigurasi ini menggabungkan semua lapisan—Essential, Large Solution, dan Portfolio—untuk mengoordinasikan manajemen tim di seluruh perusahaan.

2. Nexus

Kerangka kerja Nexus juga didasarkan pada Scrum tetapi lebih ringan daripada SAFe, hanya memerlukan sedikit penyesuaian yang memfasilitasi kolaborasi antara tiga hingga sembilan tim. Menerapkan Nexus tidak memerlukan peran tambahan apa pun. Sebaliknya, satu perwakilan dari setiap tim bergabung dengan tim integrasi pusat yang menyelaraskan pekerjaan menuju satu tujuan. Mirip dengan Scrum, semua tim berkumpul untuk sesi perencanaan sprint, yang hasilnya membentuk backlog produk bersama. Untuk memeriksa kemajuan, setiap tim mengadakan pertemuan harian yang mirip dengan stand-up, dan tim integrasi juga bertemu untuk melaporkan kemajuan tim mereka.

Selama sprint, tim berpartisipasi dalam sesi perbaikan untuk memprioritaskan dan memperkirakan backlog. Karena kompleksitas pengelolaan backlog meningkat seiring dengan jumlah tim, Nexus mengamanatkan sesi penyempurnaan. Tim berkumpul untuk tinjauan dan retrospektif setelah setiap sprint.

3. Scrum Skala Besar (LeSS)

LeSS hampir identik dengan Nexus, tetapi memiliki perbedaan kecil, seperti konvensi penamaan dan sesi perencanaan sprint khusus tim tambahan. Ini juga berbeda dalam kemampuannya untuk diperpanjang dengan konfigurasi kedua, LeSS Huge, yang mendukung kolaborasi lebih dari delapan tim.

LeSS Huge mengambil pendekatan yang berpusat pada pelanggan untuk mengorganisir pengembangan. Untuk mengelola pekerjaan secara efektif, pemilik produk harus membagi simpanan produk tingkat tinggi menjadi "penumpukan area" yang lebih kecil dari item yang lebih terperinci dan kemudian menyortirnya lebih jauh—menjadi area persyaratan.

Area persyaratan ini dikelola oleh pemilik produk area (APO). APO berspesialisasi dalam bidang yang terkait dengan setiap area dan bekerja dengan beberapa tim untuk mencari solusi untuk area mereka. Setiap kebutuhan yang disimpan dalam backlog hanya dimiliki oleh satu area kebutuhan, dan setiap area hanya dikelola oleh satu APO. Bersama-sama, pemilik produk dan APO membentuk tim yang bertanggung jawab untuk memprioritaskan dengan pandangan seluruh produk.

4. Scrum@Skala

Scrum@Scale adalah perpanjangan dari Scrum dan kemungkinan merupakan kerangka kerja termudah untuk dipelajari dan dipahami. Ini skala dari satu tim ke tim tim.

Komponen inti dari kerangka kerja adalah Scrum of Scrums (SoS). Setiap tim memilih seorang individu untuk mewakili mereka dalam pertemuan SoS, yang biasanya berlangsung setiap hari setelah tim individu berdiri. Tujuan dari pertemuan SoS setiap hari adalah untuk membantu koordinasi dan komunikasi antar tim, dan memfasilitasi pengelolaan yang mudah dari ketergantungan atau tumpang tindih.

Peran unik dalam kerangka kerja ini termasuk master SoS, yang pada dasarnya merupakan versi skala dari master Scrum, dan pemilik produk utama, yang bekerja dengan pemilik produk tim untuk membentuk backlog bersama untuk SoS.

Scrum@Scale kurang preskriptif daripada kerangka kerja lain, memungkinkan organisasi untuk mengukur dengan kecepatan mereka sendiri. Jika jumlah tim terus bertambah dan pertemuan SoS menjadi terlalu besar, organisasi dapat meningkatkan kerangka kerja menjadi Scrum of Scrum of Scrums (SoSoS).

5. Disiplin Agile (DA)

DA berbeda dari kerangka kerja lain dalam hal itu bertindak lebih sebagai kotak peralatan dari mana Anda dapat memilih strategi penskalaan yang paling tepat, daripada kerangka kaku dengan aturan yang harus Anda patuhi. Ini adalah hibrida berbasis konteks dari berbagai kerangka kerja, termasuk Scrum dan Kanban, yang dapat disesuaikan dengan kebutuhan setiap proyek, berpusat pada prinsip "Pilihan itu baik." DA dibangun di atas gagasan bahwa setiap tim dan organisasi unik dalam ukuran, distribusi, dan domainnya, dan setiap anggota tim juga unik, dengan keterampilan dan pengalaman mereka sendiri.

Ini dapat diterapkan di tingkat tim pengembangan perangkat lunak atau di seluruh perusahaan. Untuk yang terakhir, toolkit DA mengidentifikasi apa yang harus ditangani oleh berbagai fungsi bisnis—seperti keuangan, operasi TI, dan manajemen vendor, dan menyajikan berbagai opsi untuk melakukannya.

DA membedakan tiga fase proyek—Inception, Construction, dan Transition—dan masing-masing terdiri dari tujuan proses yang berorientasi pada penyampaian. Karena kerangka kerja ini berfokus pada siklus hidup pengiriman penuh, bukan hanya pembuatannya, kerangka kerja ini memperkenalkan lebih banyak peran daripada kerangka kerja lainnya. Peran utama, ditemukan di setiap tim DA, adalah pemangku kepentingan, anggota tim, pemimpin tim, pemilik produk, dan pemilik arsitektur. Ada juga lima peran pendukung, yang sering digunakan secara sementara untuk membantu penskalaan: spesialis, pakar domain, pakar teknis, penguji independen, dan integrator.

DA dapat digunakan di atas kerangka kerja lain untuk meningkatkan skala lebih jauh.

Pilih dengan Hati-hati dan Skala Perlahan

Menskalakan tim Agile dan mengintegrasikan pekerjaan mereka dengan mulus memang sulit, tetapi dapat dibuat lebih mudah dengan memilih kerangka kerja terbaik. Gunakan diagram alur di bawah ini sebagai langkah pertama untuk memandu proses pengambilan keputusan Anda.

Saya yakin Anda akan menemukan kerangka penskalaan yang sesuai dengan pengalaman, pendekatan, anggaran, dan produk organisasi Anda di antara yang disajikan di sini. Kerangka kerja mana pun yang Anda pilih, sangat penting untuk tidak terburu-buru—skalakan secara bertahap untuk meminimalkan gangguan dan merencanakan perubahan jauh sebelumnya.

Sudahkah Anda menggunakan kerangka kerja ini dalam aktivitas penskalaan Anda? Beritahu kami tentang pengalaman Anda di bagian komentar.