SAFe adalah kebalikan dari apa yang akan digunakan oleh perusahaan produk yang kuat. Ini disebut 'Agile dalam skala besar'. Ini bukan Agile. Itu hanya Pemasaran.
“Begitu banyak perusahaan besar yang kecanduan proses, dan mereka berpikir jawabannya adalah proses… Meskipun mereka menggunakan kata agile, mereka sering menggunakan proses konyol seperti SAFe atau LeSS. Ini adalah kebalikan dari apa yang akan digunakan oleh perusahaan produk yang baik. Faktanya, saya tidak dapat menyebutkan satu pun perusahaan produk kuat yang menggunakan produk-produk tersebut. Mereka disebut Agile at Scale. Mereka sama sekali bukan Agile. Itu hanya pemasaran, dan semua orang ini tertarik pada bidang pemasaran
— Marty Cagan, 2022
Marty Cagan adalah Pendiri dan Mitra dari Silicon Valley product Group (SPVG) dan penulis buku terlaris INSPIRED dan EMPOWERED. Marty — yang memiliki pengalaman industri selama 20 tahun sebagai pemimpin produk — kini bekerja dengan perusahaan teknologi dari seluruh dunia untuk membantu mereka mendorong transformasi produk dengan inovasi, kecepatan, dan ketangkasan. Dia sering disebut sebagai 'orang paling berpengaruh di bidang produk'.
TLDR;
Metodologi tangkas modern menghadirkan sistem yang kompleks untuk melacak apakah sebuah tim menyelesaikan pekerjaan yang menjadi komitmen mereka di tingkat PI. Tanpa strategi manajemen produk yang tepat (karena hal ini tidak dapat terjadi beberapa hari per kuartal), para insinyur menghabiskan banyak waktu untuk berbohong tentang perkiraan mereka, memberikan janji yang terlalu rendah, dan mencoba melakukan gamifikasi pada metrik umum. Hal ini menyebabkan masalah motivasi yang besar bagi para insinyur. Self Efficacy yang merupakan bagian dari model kesejahteraan psikologis yang mapan (“model Zimmerman” yang menjelaskan “pengaturan diri”) adalah keyakinan bahwa Anda dapat melakukan sesuatu dan motivasi di sekitarnya. Jika jadwal dan perkiraan Anda tidak masuk akal dan Anda menghabiskan waktu terlalu lama untuk berbohong tentang hal tersebut, maka Anda tidak dapat membangun struktur keyakinan atau motivasi untuk melakukannya, yang kemudian memengaruhi minat Anda untuk mencoba dan melakukannya.
Apa itu SAFe?
Scaled Agile Framework® (SAFe®) adalah serangkaian pola organisasi dan alur kerja untuk menerapkan praktik tangkas pada skala perusahaan. Kerangka kerja ini merupakan sekumpulan pengetahuan yang mencakup panduan terstruktur mengenai peran dan tanggung jawab, cara merencanakan dan mengelola pekerjaan, serta nilai-nilai yang harus dijunjung tinggi.
SAFe klaim ada lebih dari 1.000.000 profesional yang dilatih di SAFe di 110+ negara. Jadi pasti ada sesuatu di dalamnya kan?
Implementasi SAFe
Langkah pertama “seperti yang dikutip oleh kerangka SAFe” adalah memilih sekelompok karyawan untuk menjadi Konsultan Program Aman.
“Latih agen perubahan Lean-Agile sebagai Konsultan Program SAFe® Bersertifikat (SPC).”
Biaya sertifikasinya sekitar $3.000 per SPC dan ini belum termasuk biaya pengiriman pemimpin dan staf umum Anda untuk mengikuti sertifikasi lain yang SAFe rekomendasikan untuk diikuti oleh organisasi Anda.
Hasil yang diharapkan? Anda kini memiliki karyawan yang berdedikasi untuk menghayati dan menghidupkan SAFe serta mendorong agenda SAFe di seluruh organisasi Anda. Ini sebenarnya adalah skema piramida yang sedang beraksi.
Bermerek Agile
Ekstrak “branded agile” berikut diambil dari “Understanding Fake Agile” oleh Steve Denning, 2019
Bentuk yang sangat disayangkan dari “branded agile” berkaitan dengan kerangka penskalaan. Ini adalah skema yang ditujukan untuk membantu perusahaan yang memiliki beberapa tim yang menerapkan praktik Agile dan ingin menyelesaikan ketegangan antara tim Agile dan sistem back-office organisasi (seperti strategi, perencanaan, anggaran, SDM, Keuangan) yang biasanya bersifat monolitik. dan birokratis.
Tantangannya biasanya disajikan sebagai salah satu “peningkatan tangkas”. Persoalannya di sini adalah jika perusahaan berpikir untuk “meningkatkan skala secara tangkas”, maka perusahaan tersebut sudah berada di jalur yang salah. Tantangan dari agile sejati adalah bagaimana mengubah skala sistem besar yang monolitik dan berfokus secara internal menjadi tugas-tugas yang dapat dijalankan oleh tim kecil yang berfokus pada pelanggan dan mengelola dirinya sendiri.
Varian yang sangat mengkhawatirkan adalah Scaled Agile Framework atau SAFe. Pada dasarnya ini adalah birokrasi yang terkodifikasi, dimana pelanggan hampir tidak ada sama sekali. Hal ini sekarang menyebar luas di perusahaan-perusahaan besar karena memberikan mandat kepada manajemen untuk menyebut diri mereka tangkas dan terus melakukan apa yang selalu mereka lakukan. Pada dasarnya, hal ini menundukkan tim-tim tangkas kepada birokrasi, dibandingkan melakukan hal-hal yang diperlukan untuk mencapai ketangkasan bisnis, misalnya, mentransformasikan sistem-sistem besar yang berfokus secara internal ke dalam pengaturan dimana anggaran, SDM, Keuangan dan sebagainya bersifat fleksibel dan fokus secara eksternal dalam memberikan dukungan. tim Agile dalam operasi. Peran pelanggan yang tidak signifikan pada grafik di atas merupakan indikasi adanya masalah.
Ada risiko SAFe mendiskreditkan Agile asli. Ini adalah ilustrasi Hukum Gresham: uang yang buruk mengusir uang yang baik. Jika hal ini terjadi, SAFe adalah lambang dari “Agile palsu”. Ada kemungkinan bahwa ketika SAFe diterapkan oleh manajer dengan pola pikir Agile yang sejati, efek samping negatifnya dapat dikurangi. Pertanyaan saya adalah: mengapa orang dengan pola pikir Agile yang asli menggunakan SAFe?
Kritikus SAFe Umum
Di bawah ini adalah kumpulan poin-poin kecil yang tidak layak mendapat bagian tersendiri dalam artikel ini:
- SAFe menggambarkan tim pengembangan terdiri dari “pengembang dan penguji”, bukan berfungsi penuh
- SAFe mencoba menerapkan praktik kualitas kode yang diadaptasi dari XP.
- SAFe mengatakan “Kembangkan Sesuai Irama, Kirim Sesuai Permintaan” tetapi juga menggunakan “Kereta Rilis”. Kereta Rilis adalah peningkatan besar yang dapat dikirimkan. Ini tidak sesuai permintaan. Ini dikirimkan setiap 10 minggu sesuai jadwal.
- SAFe menyarankan agar Sprint ke-6 ditujukan untuk “Pengerasan, Inovasi, dan Perencanaan”. Ini adalah model mulai & berhenti. Setiap kali ada perhentian, selalu ada pemborosan yang tidak perlu. Bisnis dan pelanggan tidak tidur selama 2 minggu setiap 3 bulan dan ini tidak sesuai dengan model DevOps yang sebenarnya.
- SAFe mengatakan Anda memerlukan setidaknya 50+ orang untuk melakukan SAFe.
- SAFe berasumsi setiap proyek yang Anda kerjakan berukuran besar, membutuhkan banyak tim untuk menyelesaikannya. Kenyataannya tidak demikian. Tim yang fokus/selaras pada produk mampu memberikan hasil secara end-to-end sendiri dan sesuai permintaan.
- SAFe mengaku ramping dan gesit namun bertentangan dengan banyak prinsip lean, dan hampir semua manifesto agile.
- SAFe sengaja dibuat terlalu rumit dan memperbarui spesifikasi setiap tahun untuk memasarkan dan menjual sertifikasi.
- SAFe dikemas dan dirancang dengan sengaja untuk menarik para manajer dan eksekutif yang tidak memahami tangkas dan tidak ingin berkomitmen pada transformasi produk yang sebenarnya.
Kritik Perencanaan PI
Peningkatan Program (PI) adalah jangka waktu di mana Agile Release Train (ART) memberikan nilai tambahan dalam bentuk perangkat lunak dan sistem yang berfungsi dan teruji. PI biasanya berdurasi 8–12 minggu. Pola yang paling umum untuk PI adalah empat Iterasi pengembangan, diikuti oleh satu Iterasi Inovasi dan Perencanaan (IP). — Peningkatan PI, SAFe, 2021
Membuat diagram Gantt dan menggunakan kata 'Sprint' di tengahnya sebanyak 10 kali bukanlah Agile. Itu Air Terjun.
Konsultan Program SAFe:
“ITU BUKAN BAGAN GANTT. INI GRAFIK PERT.”
SAfe tampaknya menantang hal ini dengan mengajarkan variasi PLAN, DO, ACT tetapi pada prinsipnya Anda sedang mempersiapkan 12 minggu kerja yang setelah disampaikan kepada manajemen senior, kenyataan menunjukkan bahwa mereka melacak apa yang mereka anggap sebagai komitmen untuk melakukan pekerjaan tersebut. Anda dapat berargumentasi sebanyak yang Anda mau bahwa ini bukanlah maksud PI, namun di dunia nyata, manajemen sering menafsirkannya dan SAFe hanya mendorong perilaku buruk ini.
Bagan PERT Anda — atau papan SAFe PI, yang merupakan salah satu artefak utama yang dihasilkan PI — mungkin tampak memiliki nilai dengan mendefinisikan dan mengelola ketergantungan antar tim, tetapi ini adalah dikotomi tangkas yang salah. Perusahaan sejati yang berfokus pada produk membangun 'arsitektur yang digabungkan secara longgar' yang memungkinkan tim menguji dan menerapkan perubahan apa pun secara independen satu sama lain, tanpa harus bergantung pada dukungan dan layanan dari orang lain.
Anti-pola lain yang dianjurkan SAFe (meskipun sekali lagi berpotensi diperdebatkan melalui penerapan yang buruk) adalah Anda bereaksi/beradaptasi terhadap perubahan kebutuhan pelanggan hanya 4 kali setahun.
PI didasarkan pada Estimasi Relatif. Lihat artikel saya tentang mengapa '"Estimasi Relatif Membuang-buang Waktu"'.
Interval perencanaan yang tetap tidak pernah sesuai dengan kenyataan. Di Lean, perencanaan harus dilakukan sesuai permintaan. Tidak pada interval yang tetap.
Kenyataannya, ketika menjalankan perencanaan tetap selalu ada 2 hasil:
- Tim teknik menyelesaikan buku pekerjaannya SEBELUM PI berikutnya. Oleh karena itu, mereka melakukan lebih sedikit pekerjaan di sisa waktu tanpa arah yang jelas atau mereka mulai membuat perencanaan lagi di luar PI.
- Tim teknik menyelesaikan buku kerjanya SETELAH PI berikutnya. Selama PI mereka merencanakan pekerjaan baru sebelum menyelesaikan pekerjaan sebelumnya. Ketika PI berakhir, mereka kembali ke pekerjaan sebelumnya atau membuang sebagian untuk mengerjakan hal baru. Hal ini menyebabkan masalah peralihan konteks tambahan.
Insinyur juga tidak dilibatkan selama sesi Perencanaan PI 4 hari. Tim operasi, SRE, atau DevOps mengeluh bahwa mereka tidak dapat mengambil waktu istirahat dan akhirnya bekerja dengan jam kerja yang lebih panjang. Insinyur dari berbagai lokasi dan zona waktu terpaksa melakukan panggilan lebih awal atau larut malam.
Jika Anda menerapkan sesuai permintaan, secara otomatis mengisi dan memperbarui simpanan Anda berdasarkan sinyal mulai dan berhenti, praktikkan pengumpulan persyaratan berkelanjutan, lacak pekerjaan hulu hingga pengembangan insinyur (jadi manajemen produk aktual), masukkan siklus umpan balik sedini mungkin, dan bekerja dalam model pengiriman berkelanjutan, maka tidak diperlukan perencanaan besar untuk hal ini dan oleh karena itu hanya membuang-buang waktu.
Praktik Terbaik yang Menantang
Catatan terakhir dari postingan blog oleh Dan North…
Organisasi sering kali memperkenalkan Praktik Terbaik sebagai bagian dari program perubahan atau inisiatif kualitas. Bentuknya bisa bermacam-macam, mulai dari “buku masak” dan contekan hingga metodologi lengkap yang dipimpin oleh konsultan, lengkap dengan audit dan akreditasi yang diperlukan.
Artikel ini memperkenalkan model pembelajaran Dreyfus untuk menantang strategi penerapan Praktik Terbaik secara naif, dan menunjukkan bagaimana model pembelajaran tersebut tidak hanya gagal membantu, namun bahkan memiliki dampak negatif yang parah pada karyawan berkinerja terbaik Anda.
— Dan Utara, 2008
Jadi mengapa orang dengan pola pikir Agile yang asli akan menggunakan SAFe?
