Studi Kasus SAFe: Catatan Transformasi Dari Lapangan

Artikel ini adalah bagian ketiga dari seri penskalaan Agile Toptal, yang dirancang untuk memandu manajer proyek dalam upaya ekspansi tim mereka. Pastikan untuk membaca bagian pertama, “5 Kerangka Penskalaan Agile Dibandingkan: Mana yang Harus Anda Gunakan?” dan bagian dua, “Penskalaan Agile: Praktik Terbaik AMAN untuk Scrum Masters.”

Kelincahan dipraktikkan dalam beberapa cara oleh 94% perusahaan, menurut Laporan Tahunan Negara Agile ke-15 . Tetapi penelitian juga menunjukkan bahwa 90% organisasi berjuang dengan implementasi Agile di seluruh perusahaan. Biasanya, ini adalah pekerjaan pelatih Agile, master Scrum, dan profesional manajemen proyek lainnya untuk memimpin dan mengatur upaya ini. Seringkali, mereka bekerja dengan tim atau departemen yang tahan terhadap perubahan, dalam budaya perusahaan yang sulit dipahami.

Dalam meja bundar ini, tiga manajer proyek Toptal membahas tantangan memimpin transformasi Agile. Karena solusi mereka sesuai dengan Scaled Agile Framework (SAFe), kami juga berbicara dengan Dean Leffingwell, pencipta SAFe. Wawasan kolektif mereka menggambarkan perlunya praktisi SAFe untuk mempersiapkan visi yang jelas tentang apa itu kelincahan dan rencana kepemimpinan yang dapat membawa tim yang bandel.

Berbicara AMAN Dengan Pembuat Kerangka

SAFe, kerangka kerja yang diformalkan oleh Scaled Agile, baru ada pada tahun 2014. Namun bagi Leffingwell, pekerjaannya dimulai saat ia pertama kali bertemu tim Agile di awal tahun 2000-an. Sebagai ahli metodologi pengembangan perangkat lunak, dia terkesan dengan hasil praktik Agile di tim pengembang, dan dia segera mulai mengeksplorasi bagaimana pola pikir dapat diterapkan di seluruh perusahaan. Jika tim Agile dapat menghasilkan hasil, apa yang dapat dihasilkan oleh tim dari tim Agile yang selaras? Bagaimana praktik Agile dapat digunakan untuk proyek transformasi skala penuh di perusahaan nasional atau internasional? Seperti yang dikatakan Leffingwell, “Saya suka pengembangan perangkat lunak. Saya suka Agile. Aku hanya ingin yang besar .”

Pada tahun-tahun sejak itu, perusahaan telah mengakui manfaat SAFe, termasuk pengiriman yang lebih singkat, kualitas produk yang lebih tinggi, efisiensi yang lebih besar, dan karyawan yang lebih terlibat. Pada tahun 2021, lebih dari sepertiga organisasi di seluruh dunia menggunakan SAFe, dan di antara aspek terpentingnya adalah proses bersama dan bahasa terpadu yang disediakannya. Misalnya, jika satu tim berpikir sprint adalah dua minggu dan yang lain berpikir itu 30 hari, itu menciptakan apa yang Leffingwell gambarkan sebagai "masalah Menara Babel." Sulit bagi tim untuk mendiskusikan fitur apa yang akan ditambahkan jika mereka bahkan tidak dapat menyetujui apa arti "fitur". “Anda [membutuhkan] orang yang bekerja dengan cara yang sama jika Anda ingin membangun solusi besar,” katanya. “Tidak ada istilah di industri kami yang tidak kelebihan beban, seperti 'iterasi' atau 'sprint' atau 'backlog'. Itu tidak membantu jika Anda mencoba bekerja melintasi batas tim dan regional.”

Kisah Sukses Agile

Membuat semua orang di perusahaan mengadopsi cara berbicara dan melakukan pekerjaan yang terpadu adalah tugas yang menakutkan bahkan ketika ada urgensi yang luar biasa untuk perubahan. Di perusahaan mapan, itu bisa lebih sulit. Leffingwell menjelaskan: “Anda sedang melihat perusahaan terbesar di dunia yang menghasilkan banyak uang dan bekerja dengan sangat baik serta bersaing—dan mereka harus berubah. Nah, pertanyaan bagi mereka adalah mengapa mereka harus melakukannya?” Manajer proyek Toptal yang ditampilkan di sini masing-masing menghadapi pertanyaan seperti ini selama aktivitas penskalaan mereka sendiri, dan masing-masing menemukan cara mereka sendiri untuk bekerja melalui transformasi Agile mereka menggunakan SAFe.

Menunjukkan Nilai

Alvaro Villena, manajer proyek Toptal di Santiago, Chili, baru-baru ini menyelesaikan transisi SAFe untuk portofolio yang mengembangkan platform lintas bisnis. “Tonggak pertama dalam transisi saya adalah mengadakan lokakarya aliran nilai,” katanya. Secara sederhana, lokakarya value stream adalah pertemuan awal untuk mengidentifikasi seluruh proses bisnis mulai dari konsep hingga pengiriman dan semua langkah, pengguna, sistem, dan titik nyeri di antaranya.

Mendapatkan perwakilan dari seluruh perusahaan ke dalam lokakarya membantu Villena memahami budaya perusahaan dan apa hambatannya. “Sebelum kami mengimplementasikan lokakarya, ada struktur di mana satu bisnis memiliki tim mereka, bisnis lain memiliki tim mereka, dan bisnis berikutnya memiliki tim mereka — ketiganya tidak berbicara satu sama lain.”

Villena menemukan bahwa meskipun semua tim berbagi poin rasa sakit yang sama, tidak ada kolaborasi dalam solusi. Misalnya, meskipun setiap bisnis dalam portofolio mengirimkan produk, hanya satu yang telah mengembangkan sistem pelacakan. Tidak ada alasan mereka semua tidak bisa menggunakannya, kecuali bahwa tidak ada yang berbagi pengetahuan. Setelah lokakarya membuat mereka berbicara, pengetahuan mulai mengalir di antara tim, bisnis, dan pemilik produk. “Pembicaraan semacam itu sangat, sangat kuat untuk program ini. Itu adalah titik awal yang bagus,” kata Villena. Ketika DevOps, desain, dan produk mengetahui apa yang dilakukan tim lain, mereka melihat bahwa ada solusi di perusahaan yang dapat mereka gunakan. “Mereka mulai bertanya, 'Bagaimana saya bisa memilikinya?' Dan di situlah Anda masuk dan berkata, 'Ikuti proses ini.'”

“Tidak ada yang menginginkan perubahan sampai mereka tahu alasannya. Jadi, Anda mulai dengan alasan dan memberi mereka masa depan yang lebih baik.” Dean Leffingwell, pencipta SAFe

Leffingwell tahu bahwa tim terkadang melawan. “Tidak ada yang menginginkan perubahan sampai mereka tahu alasannya,” katanya kepada Toptal. “Jadi, Anda mulai dengan alasan dan memberi mereka masa depan yang lebih baik.” Memberi tim gambaran tentang seberapa efisien mereka dapat menjadi alat yang ampuh untuk kepemimpinan perubahan.

Bahkan ketika semua orang antusias, Anda tetap harus mengharapkan awal yang sulit. Tim yang terbiasa dengan pengembangan Waterfall tradisional dan rilis besar, misalnya, mungkin mengalami kesulitan untuk beralih ke proses pengembangan yang lebih berulang dan gesit, bahkan jika mereka melihat nilai di dalamnya. “Peningkatan program pertama yang kami lakukan adalah semacam bencana bagi tim,” kata Villena. “Dan kami tahu itu akan terjadi; kami mengatakan kepada klien untuk memperkirakan bahwa tiga bulan pertama mungkin sulit.” Untuk mengimbangi hal ini, ia membangun iterasi satu kali selama seminggu di akhir program increment (PI) pertama di mana tim dapat mengevaluasi kemajuan mereka. Dia mengorganisir sprint yang ditujukan semata-mata untuk proses perbaikan dan evaluasi yang akan melampaui inspeksi dan adaptasi biasa. Dia merasa berguna untuk menerapkan pola pikir Agile tidak hanya pada produk tetapi juga transisi bisnis, meluangkan waktu untuk mundur, melihat apa yang berhasil dan apa yang tidak, dan menyesuaikannya.

Menciptakan Kemenangan Kecil

Sangat penting untuk bersiap menghadapi hambatan tak terduga dalam adopsi SAFe Anda. Beberapa tahun yang lalu, manajer proyek Toptal Miroslav Anicin di Beograd, Serbia, sedang mentransisikan perusahaan telekomunikasi ke SAFe. Perusahaan telah mengalihdayakan semua pengembangan perangkat lunaknya. Menggabungkan tim di luar lokasi bukanlah tugas yang terlalu berat—masalah yang terlibat sebagian besar adalah logistik. Namun upaya tersebut menciptakan tantangan tak terduga dalam transisi perusahaan itu sendiri. “Saya sedang mencari kompetensi yang kami butuhkan di kereta rilis,” katanya. “Dan semua orang yang harus saya pilih berasal dari pemasaran, dari hukum, dari produk, dari keuangan — sama sekali tidak memiliki pola pikir Agile atau bahkan pengalaman apa pun di Agile.”

Menjadi jelas bahwa manajemen tidak memiliki pengalaman menangani tim Agile. Pengambilan keputusan yang terdistribusi mengharuskan manajer untuk melepaskan beberapa kendali, sebuah fakta yang dapat ditolak oleh para pemimpin jika mereka tidak berpengalaman dengan kerangka kerja Agile. Untuk mengatasi hal ini, Anicin harus berlatih dari bawah ke atas dan dari atas ke bawah, melatih para pemimpin bersama timnya.

Perpindahan ke pengambilan keputusan yang lebih terdesentralisasi membutuhkan “perubahan cara kerja dari komando dan kontrol, melalui kepemimpinan yang melayani, ke budaya pembelajaran dan budaya Agile yang memberdayakan ini—dan kemampuan untuk menoleransi kesalahan,” kata Leffingwell.

Anicin memulai proses penskalaan secara bertahap—dengan proyek Agile kecil yang dilakukan dalam tim tunggal, bukan dalam kerangka SAFe—sehingga tim individu dapat mengembangkan beberapa pengalaman langsung. Proyek-proyek ini harus tidak penting dan cukup kecil sehingga perusahaan tidak akan dirugikan jika terjadi kesalahan pada percobaan pertama, tetapi cukup berguna untuk menunjukkan kepada tim apa yang dapat dicapai dengan pendekatan tersebut. Misalnya, tim pemasaran membuat kampanye pemasaran internal, di mana Anicin mengajari mereka dasar-dasar Scrum. Mirip dengan lokakarya Villena, proyek yang lebih kecil ini menunjukkan nilai Agile secara nyata, sehingga anggota tim dan kepemimpinan dapat melihat manfaat dari rilis singkat dan peningkatan berkelanjutan sebelum transisi skala penuh.

Memenuhi Kebutuhan Tim Anda

Ketika Imane Marouane, seorang manajer proyek Toptal yang berbasis di Paris, memimpin transformasi untuk sebuah lembaga keuangan multinasional yang besar, dia melangkah ke lingkungan yang kacau di mana tim individu menghasilkan pekerjaan yang solid tetapi tidak memiliki visi yang sama di seluruh perusahaan. “Setiap tim punya prioritas masing-masing. Setiap manajer produk ingin produk mereka dikirim terlebih dahulu.”

Solusi SAFe untuk masalah ini dapat ditemukan pada model weighted shortest job first (WSJF). WSJF memberikan standar untuk memprioritaskan pekerjaan sehingga ketika tiba saatnya untuk memutuskan apa tugas selanjutnya, langkah pertama tidak melibatkan perselisihan tentang bagaimana menentukan peringkat kepentingan. Dalam sistem Agile berbasis aliran, Anda tidak perlu khawatir untuk mengirimkan semuanya sekaligus karena, seperti yang dikatakan Leffingwell, “yang terpenting adalah pekerjaan apa yang harus dilakukan selanjutnya. Dan itu pertanyaan yang jauh lebih mudah dijawab daripada pekerjaan apa yang paling berharga.” SAFe menyediakan cara untuk menyelesaikan ketergantungan antar tim—pengurutan tugas sangat penting untuk hasil ini.

Jalan Marouane menuju resolusi ketergantungan menjadi tidak pasti: “Setelah dua sprint, sebelum inspeksi dan adaptasi pertama, kami melihat bahwa beberapa tim tidak mengikuti rencana PI kami.” Dependensi yang ditentukan dalam rencana PI tidak diikuti, sehingga pekerjaan satu tim tidak dapat dimulai karena kontribusi dari tim lain belum siap.

“Karena ini adalah iterasi pertama, dan tim tidak terbiasa dengan pekerjaan seperti ini, kami memutuskan untuk mengadakan upacara tambahan—pertemuan mingguan untuk membahas kemajuan pada dependensi,” kata Marouane. “Satu orang dari setiap tim datang untuk memperbarui kemajuan kontribusi mereka.” Dengan cara ini, jika Tim A mengatakan bahwa mereka tidak dapat melakukannya, Tim B dapat mengetahui sebelumnya dan merencanakan dengan tepat, daripada menunggu kontribusi yang tidak akan terwujud di awal sprint mereka.

Leffingwell mengajarkan kehati-hatian saat membuat penyesuaian semacam ini pada SAFe: “SAFe adalah sistem tanggung jawab. … Anda dapat menyesuaikannya, tetapi Anda harus benar-benar berhati-hati.” Meskipun kerangka kerja dimaksudkan untuk dapat beradaptasi, perubahan cenderung terjadi jika tidak ditinjau ulang. Konfigurasi Essential SAFe ada untuk memastikan bahwa setiap perubahan memenuhi kriteria dasar.

Upacara tambahan Marouane dimasukkan lagi dalam PI kedua, dan pada yang ketiga telah dihapus. Tim tidak memiliki apa pun untuk dilaporkan yang belum dikomunikasikan. Sedikit fleksibilitas ekstra memungkinkan Marouane membawa tim kembali ke jalur proses yang lebih tradisional. Dia menemukan bahwa transisi itu sendiri membutuhkan pola pikir Agile untuk mendapatkan hasil maksimal dari tim lembaga keuangan. Dan yang terpenting, perubahan yang dia buat, melalui komitmennya terhadap peningkatan berkelanjutan, pada akhirnya memenuhi prinsip-prinsip Lean-Agile yang merupakan dasar dari Essential SAFe. Solusinya memberi perusahaan visi terpadu yang tidak dimiliki dan memungkinkan tim untuk bekerja sama menuju prioritas yang sama.

Beradaptasi untuk Masa Depan

Kerangka kerja apa pun yang beroperasi pada skala akan datang dengan tantangan. Jumlah bagian yang bergerak dan kepentingan yang bersaing sangat besar. Tetapi imbalannya sama besar, dan transisi yang dijalankan dengan baik akan memberi tim alat yang mereka butuhkan untuk bekerja menuju tujuan bersama. Hambatan yang Anda hadapi dalam implementasi skala besar seperti itu tidak dapat diprediksi, dan pola pikir Agile membantu Villena, Anicin, dan Marouane beradaptasi dengan tantangan yang tidak terduga. Lagi pula, untuk itulah pengiriman berkelanjutan: memberdayakan proses Anda dengan alat untuk beradaptasi dengan yang tak terduga.

Scaled Agile juga beradaptasi dengan teknologi baru dan standar industri yang berkembang, memperkenalkan alat dan kemampuan baru jika diperlukan. Setiap orang harus tetap gesit dan bersiap untuk hal yang tidak terduga. “Kami tidak memiliki bola kristal,” kata Leffingwell. “Kami hanya berlari cepat, memimpin dengan keras, dan mengikuti dengan keras—dan menulis secepat yang kami bisa.”