Menskalakan Agile ke tim besar

Kata-kata besar dan Agile tidak sering digunakan dalam kalimat yang sama. Organisasi besar telah mendapatkan reputasi untuk bergerak lambat. Namun, itu berubah. Banyak organisasi perangkat lunak besar yang berhasil membuat transformasi ke Agile. Mereka belajar menskalakan prinsip Agile dengan atau tanpa kerangka kerja populer seperti SAFe, LeSS, atau Nexus.

Di Microsoft, salah satu organisasi tersebut menggunakan Agile untuk membangun produk dan layanan yang dikirim di bawah merek Azure DevOps. Grup ini memiliki 35 tim fitur yang merilis ke produksi setiap tiga minggu.

Setiap tim dalam Azure DevOps memiliki fitur dari awal hingga akhir dan seterusnya. Mereka mengelola kemitraan dengan pelanggan. Mereka mengelola backlog produk mereka sendiri. Mereka menulis dan memeriksa kode ke cabang produksi. Setiap tiga minggu, cabang produksi disebarkan dan rilis menjadi publik. Tim kemudian memantau kesehatan sistem dan memperbaiki masalah situs langsung.

Menurut prinsip Agile, tim otonom lebih produktif. Organisasi Agile ingin tim mereka memiliki kontrol atas eksekusi sehari-hari mereka. Tapi otonomi tanpa penyelarasan akan mengakibatkan kekacauan. Puluhan tim yang bekerja secara independen tidak akan menghasilkan produk terpadu dan berkualitas tinggi. Keselarasan memberi tim tujuan mereka dan memastikan bahwa mereka memenuhi tujuan organisasi. Tanpa keselarasan, bahkan tim dengan performa terbaik pun akan gagal.

Untuk menskalakan Agile, Anda harus mengaktifkan otonomi untuk tim sambil memastikan keselarasan dengan organisasi.

Untuk mengelola keseimbangan yang halus antara keselarasan dan otonomi, pemimpin DevOps perlu menentukan taksonomi, menentukan proses perencanaan, dan menggunakan obrolan fitur.

Menentukan taksonomi

Tim Agile, dan organisasi Agile yang lebih besar miliknya, membutuhkan backlog yang ditentukan dengan jelas agar berhasil. Teams akan berjuang untuk berhasil jika tujuan organisasi tidak jelas.

Untuk menetapkan tujuan yang jelas dan menyatakan bagaimana setiap tim berkontribusi kepada mereka, organisasi perlu menentukan taksonomi. Taksonomi yang ditentukan dengan jelas membuat nomenklatur untuk organisasi.

Taksonomi umum adalah epik, fitur, cerita, dan tugas.

Epik

Epik menjelaskan inisiatif penting bagi keberhasilan organisasi. Epic dapat membutuhkan beberapa tim dan beberapa sprint untuk diselesaikan, tetapi mereka memiliki akhir. Epik memiliki tujuan yang jelas. Setelah dicapai, epik ditutup. Jumlah epik yang sedang berlangsung harus terkendali agar organisasi tetap berfokus. Epik dibagi menjadi fitur.

Features

Fitur menentukan fungsionalitas baru yang diperlukan untuk mewujudkan tujuan epik. Fitur adalah unit rilis; mereka mewakili apa yang dirilis kepada pelanggan. Catatan rilis yang diterbitkan dapat dibuat berdasarkan daftar fitur yang baru saja diselesaikan. Fitur mungkin memerlukan beberapa sprint untuk diselesaikan, tetapi harus direncanakan agar memastikan aliran nilai yang konsisten untuk pelanggan. Fitur dipecah menjadi cerita.

Cerita

Cerita mendefinisikan nilai tambah bertahap yang harus disampaikan tim untuk menghasilkan fitur. Tim memecah fitur menjadi potongan-potongan inkremental. Satu cerita lengkap mungkin tidak memberikan nilai yang bermakna bagi pelanggan. Namun, cerita yang telah selesai mewakili perangkat lunak berkualitas tingkat produksi. Cerita adalah unit kerja tim. Tim mendefinisikan cerita yang diperlukan untuk menyelesaikan fitur. Cerita dapat diuraikan menjadi tugas jika diinginkan.

Tasks

Tugas menentukan pekerjaan yang diperlukan untuk menyelesaikan cerita.

Inisiatif

Taksonomi ini bukan sistem satu ukuran yang cocok untuk semua. Banyak organisasi memperkenalkan suatu tingkat yang lebih tinggi dari epik yang disebut inisiatif.

Nama setiap tingkat dapat disesuaikan dengan organisasi Anda. Namun, nama-nama yang ditentukan di atas (epik, fitur, cerita) banyak digunakan dalam industri.

Tingkat otonomi

Setelah taksonomi ditetapkan, organisasi perlu menggambar garis otonomi. Garis otonomi adalah titik di mana kepemilikan tingkat beralih dari manajemen ke tim. Manajemen tidak mengganggu level yang dimiliki oleh tim.

Contoh berikut menunjukkan garis batas otonomi yang ditampilkan di bawah fitur. Manajemen memegang kendali atas epik dan fitur, yang memberikan keselarasan. Tim memiliki cerita dan tugas, dan memiliki otonomi tentang cara mereka menjalankannya.

Dalam contoh ini, manajemen tidak memberi tahu tim cara mengurai cerita, merencanakan sprint, atau menjalankan pekerjaan.

Namun, tim harus memastikan eksekusi mereka selaras dengan tujuan manajemen. Para tim memiliki backlog cerita mereka sendiri, dan mereka harus menyelaraskan backlog tersebut dengan fitur yang telah ditetapkan.

Planning

Untuk menskalakan perencanaan Agile, tim memerlukan rencana untuk setiap tingkat taksonomi. Namun, penting untuk melakukan iterasi dan memperbarui rencana. Proses ini disebut perencanaan gelombang bergulir.

Rencana ini memberikan arah untuk jangka waktu tetap dengan kalibrasi yang diharapkan secara berkala. Misalnya, paket 18 bulan dapat dikalibrasi setiap enam bulan.

Berikut adalah contoh metode perencanaan untuk setiap tingkat taksonomi: epik, fitur, cerita, tugas.

Visual

Visi dinyatakan melalui epik dan menetapkan arah jangka panjang organisasi. Epik menentukan apa yang ingin diselesaikan organisasi dalam 18 bulan ke depan. Manajemen memiliki rencana dan mengkalibrasinya setiap enam bulan.

Visi disampaikan di pertemuan semua karyawan. Karena visi dimaksudkan untuk menjadi ambisius dan banyak hal dapat berubah selama periode waktu tersebut, berharap untuk mencapai sekitar 60% visi.

Musim

Musim dijelaskan melalui fitur dan menetapkan strategi selama enam bulan ke depan. Fitur menentukan apa yang ingin diperkenalkan perusahaan kepada pelanggannya. Manajemen memiliki rencana musiman dan mempresentasikan visi serta rencana musiman tersebut pada rapat umum. Semua rencana tim harus selaras dengan rencana musiman manajemen. Diperkirakan untuk mencapai sekitar 80% dari target musiman.

Paket 3-sprint

Rencana 3-sprint mendefinisikan cerita dan fitur yang akan diselesaikan tim selama tiga sprint berikutnya. Tim memiliki rencana dan mengkalibrasinya setiap sprint. Setiap tim menyajikan rencana mereka untuk manajemen melalui obrolan fitur (lihat di bawah). Rencana ini menentukan bagaimana eksekusi tim selaras dengan rencana musiman 6 bulan. Mengharapkan tercapainya sekitar 90% dari rencana 3-sprint.

Rencana sprint

Rencana sprint mendefinisikan cerita dan fitur yang akan diselesaikan tim dalam sprint berikutnya. Tim memiliki rencana sprint dan mengirimnya melalui email ke seluruh organisasi untuk transparansi penuh. Rencana ini mencakup apa yang dicapai tim dalam sprint sebelumnya dan fokus mereka untuk sprint berikutnya. Berharap untuk mencapai sekitar 95% dari rencana sprint.

Batas otonomi

Dalam contoh ini, garis otonomi digambar untuk menunjukkan di mana tim memiliki otonomi perencanaan.

Seperti yang dinyatakan di atas, manajemen tidak memperpanjang kepemilikan di bawah garis otonomi. Manajemen memberikan panduan menggunakan rencana visi dan rencana musiman, dan kemudian memberi tim otonomi untuk membuat rencana 3-sprint dan sprint.

Obrolan fitur: Tempat otonomi bertemu dengan keselarasan

Diskusi fitur adalah pertemuan informal di mana setiap tim menyajikan rencana tiga sprint mereka kepada tim manajemen. Rapat ini memastikan bahwa tim merencanakan selaras dengan tujuan organisasi. Ini juga membantu manajemen tetap mendapatkan informasi tentang apa yang dilakukan tim. Sementara rencana 3-sprint dikalibrasi setiap sprint, diskusi fitur diadakan sesuai kebutuhan, biasanya setiap satu hingga tiga sprint.

Rapat obrolan fitur mengalokasikan 15 menit untuk setiap tim. Dengan 12 tim fitur, rapat ini dapat dijadwalkan berlangsung sekitar tiga jam. Setiap tim menyiapkan dek 3 slide, dengan slide berikut:

Features

Slide pertama menguraikan fitur yang akan dinyalakan tim dalam tiga sprint berikutnya.

Utang

Slide berikutnya menjelaskan bagaimana tim mengelola utang teknis. Utang adalah segala sesuatu yang tidak memenuhi standar kualitas manajemen. Direktur teknik menetapkan bilah kualitas, yang sama untuk semua tim (penyelarasan). Contoh bilah kualitas termasuk jumlah bug per insinyur, persentase pengujian unit yang lolos, dan tujuan performa.

Masalah dan dependensi

Masalah dan dependensi yang tercantum pada slide akhir mencakup apa pun yang memengaruhi kemajuan tim, seperti masalah yang tidak dapat diselesaikan tim atau dependensi pada tim lain yang memerlukan eskalasi.

Setiap tim menyajikan slide mereka langsung ke manajemen. Tim menyajikan bagaimana rencana 3-sprint mereka selaras dengan rencana musiman 6 bulan. Kepemimpinan mengajukan pertanyaan klarifikasi dan menyarankan perubahan arah. Mereka juga dapat meminta rapat tindak lanjut untuk menyelesaikan masalah yang lebih mendalam.

Jika rencana tim gagal selaras dengan harapan manajemen, manajemen dapat meminta rencana ulang. Dalam peristiwa langka ini, tim akan merencanakan ulang dan menjadwalkan obrolan fitur kedua untuk meninjaunya.

Kepercayaan: Perekat yang mempersatukan keselarasan dan otonomi

Saat berlatih Agile dalam skala besar, kepercayaan adalah jalan dua arah:

• Manajemen harus mempercayai tim untuk melakukan hal yang benar. Jika manajemen tidak mempercayai tim, mereka tidak akan memberikan otonomi tim.

• Tim mendapatkan kepercayaan dengan memberikan kode berkualitas tinggi secara konsisten. Jika tim tidak dapat dipercaya, manajemen tidak akan memberi mereka otonomi.

Manajemen harus memberikan rencana yang jelas bagi tim untuk menyelaraskan dan kemudian memercayai tim mereka untuk mengeksekusi. Tim harus menyelaraskan rencana mereka dengan organisasi dan menjalankan dengan cara yang dapat dipercaya.

Saat organisasi melihat untuk menskalakan Agile ke skenario yang lebih besar, kuncinya adalah memberi tim otonomi sambil memastikan mereka selaras dengan tujuan organisasi. Blok bangunan penting adalah kepemilikan yang jelas dan budaya kepercayaan. Setelah organisasi memiliki fondasi ini, mereka akan menemukan bahwa Agile dapat menskalakan dengan sangat baik.

Langkah selanjutnya

Ada banyak cara bagi tim dengan ukuran apa pun untuk mulai melihat manfaat hari ini. Lihat beberapa praktik yang dapat diskalakan ini.

Pelajari tentang fitur Azure DevOps untuk manajemen portofolio dan visibilitas di seluruh tim.

Microsoft adalah salah satu perusahaan Agile terbesar di dunia. Pelajari selengkapnya tentang cara Microsoft menskalakan perencanaan DevOps.