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 dirilis ke produksi setiap tiga minggu.

Setiap tim dalam Azure DevOps memiliki fitur dari awal hingga akhir dan seterusnya. Mereka memiliki hubungan pelanggan. Mereka mengelola backlog produknya 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.

Berdasarkan prinsip Agile, tim otonom lebih produktif. Organisasi Agile ingin tim mereka memiliki kontrol atas eksekusi sehari-hari mereka. Tapi otonomi tanpa keselarasan 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 berkinerja terbaik akan gagal.

Untuk menskalakan Agile, Anda harus mengaktifkan otonomi untuk tim, sembari 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. Epik dapat mengambil beberapa tim dan beberapa sprint untuk dicapai, tetapi mereka tidak tanpa akhir. Epik memiliki tujuan yang jelas. Setelah dicapai, epik akan ditutup. Jumlah epik yang sedang dalam proses harus dapat dikelola agar organisasi tetap fokus. Epik diuraikan menjadi fitur.

Fitur

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

Cerita

Cerita menentukan nilai bertahap yang harus dikirimkan tim untuk membuat fitur. Tim memecah fitur menjadi potongan-potongan bertahap. Satu cerita yang selesai mungkin tidak memberikan nilai yang bermakna kepada pelanggan. Namun, cerita yang selesai mewakili perangkat lunak berkualitas produksi. Cerita adalah unit kerja tim. Tim menentukan cerita yang diperlukan untuk menyelesaikan fitur. Cerita secara opsional diuraikan menjadi tugas.

Tugas

Tugas menentukan pekerjaan yang diperlukan untuk menyelesaikan sebuah cerita.

Inisiatif

Taksonomi ini bukan sistem satu ukuran yang cocok untuk semua. Banyak organisasi memperkenalkan tingkat di atas 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.

Garis otonomi

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

Contoh berikut menunjukkan baris otonomi yang digambar di bawah fitur. Manajemen memiliki 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. Sementara tim memiliki backlog ceritanya, mereka harus menyelaraskan backlog dengan fitur yang ditetapkan untuk mereka.

Perencanaan

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

Rencana ini memberikan arah dalam 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.

Vision

Visi diekspresikan 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 pada forum. Karena visi dimaksudkan untuk menjadi ambisius dan banyak hal dapat berubah selama periode waktu tersebut, berharap untuk mencapai sekitar 60% dari visi.

Musim

Musim dijelaskan melalui fitur dan menetapkan strategi selama enam bulan ke depan. Fitur menentukan apa yang ingin dinyalakan organisasi untuk pelanggannya. Manajemen memiliki rencana musiman dan menyampaikan visi dan rencana musiman pada forum. Semua rencana tim harus selaras dengan rencana musiman manajemen. Berharap untuk menyelesaikan sekitar 80% dari rencana 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 menyampaikan rencana mereka untuk manajemen melalui obrolan fitur (lihat di bawah). Rencana ini menentukan bagaimana eksekusi tim selaras dengan rencana musiman 6 bulan. Berharap untuk menyelesaikan sekitar 90% dari rencana 3 sprint.

Rencana sprint

Rencana sprint menentukan 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 diselesaikan tim dalam sprint sebelumnya dan fokus mereka untuk sprint berikutnya. Berharap untuk menyelesaikan sekitar 95% dari rencana sprint.

Garis 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 musim, dan kemudian memberi tim otonomi untuk membuat rencana sprint dan sprint 3.

Obrolan fitur: Di mana otonomi memenuhi keselarasan

Obrolan fitur adalah rapat upacara rendah di mana setiap tim menyampaikan rencana 3 sprint kepada manajemen. Rapat ini memastikan bahwa tim merencanakan selaras dengan tujuan organisasi. Ini juga membantu manajemen tetap mendapatkan informasi tentang apa yang dilakukan tim. Sementara paket 3-sprint dikalibrasi setiap sprint, obrolan fitur diadakan sesuai kebutuhan, biasanya setiap sprint satu-ke-tiga.

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:

Fitur

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

Utang

Slide berikutnya menjelaskan bagaimana tim mengelola utang teknis. Utang adalah apa pun 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 menampilkan slide mereka langsung ke manajemen. Tim menyampaikan bagaimana rencana 3-sprint mereka selaras dengan rencana musiman 6 bulan. Kepemimpinan mengajukan pertanyaan yang mengklarifikasi dan menyarankan perubahan arah. Mereka juga dapat meminta rapat tindak lanjut untuk menyelesaikan masalah yang lebih dalam.

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: Lem yang memegang keselarasan dan otonomi bersama-sama

Saat melakukan 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 penyusun kritis jelas merupakan kepemilikan dan budaya kepercayaan. Setelah organisasi memiliki fondasi ini, mereka akan menemukan bahwa Agile dapat menskalakan dengan sangat baik.

Langkah berikutnya

Ada banyak cara bagi tim dengan ukuran apa pun untuk mulai melihat keuntungan saat ini. Lihat beberapa praktik ini yang menskalakan.

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.