Kekhasan kerja tim Agile dalam SAFe dibandingkan Scrum dalam praktik

Setelah publikasi di antara teman-teman artikel pertama tentang Burn Down Chart, di komentar pertanyaan pertama yang diajukan: "Akan menarik untuk mengetahui lebih detail tentang pengalaman Anda dengan SAFe". Oleh karena itu, dalam artikel ini saya akan berusaha mengungkap kekhasan bekerja di SAFe dibandingkan Scrum dalam praktik kami. Saya sama sekali tidak mengklaim kebenaran mutlak dan akan senang menerima segala koreksi dan klarifikasi dari rekan-rekan.

Pertama saya akan menyebutkan secara ringkas hal paling utama yang membedakan bekerja di SAFe dari SCRUM, menurut saya.

• Increment di Scrum dan Program Increment di SAFe
• ART - Agile Release Train
• Jumlah tim yang berinteraksi
• PIPE
• SOS
• PO - bukan pemilik bisnis
• RTE
• Sprint kelima untuk pembelajaran
• System Demo

Increment di Scrum dan Program Increment di SAFe. Sebenarnya istilahnya berbeda, tetapi mudah tertukar karena tidak ada yang menggunakan istilah Program Increment di tempat kami, semua orang hanya mengatakan Increment - padahal itu istilah lain yang digunakan di SCRUM. Namun secara keseluruhan keduanya cukup mirip dari segi makna, menurut saya. Increment di SCRUM pada dasarnya adalah produk saat ini + cerita yang direncanakan untuk sprint dalam keadaan selesai (lulus DOD tim). Program Increment adalah interval waktu selama kereta (Agile Release Train) mengirimkan nilai inkremental ke produksi. Durasi kami adalah 4 sprint masing-masing 2 minggu untuk pengembangan dan satu sprint untuk pembelajaran.

Agile Release Train - adalah tim dari tim-tim yang bekerja pada satu aliran penciptaan nilai. Kami menyebutnya hanya kereta, tetapi menurut framework seharusnya disebut "Solution". Dalam kasus kami, aturan ini tidak sepenuhnya dipatuhi dan tim sering bekerja pada produk yang berbeda dari sudut pandang teknis, karena sebagian besar fitur bisnis diimplementasikan secara terpadu dan mencakup beberapa produk. Ini dari sisi teknis. Namun, saya yakin bahwa seseorang menganggap semua sistem IT sebagai satu produk perusahaan dan, mungkin, itu bahkan lebih tepat.

Jumlah tim yang berinteraksi di SAFe kami jauh lebih banyak, secara total direkomendasikan hingga 125 orang dalam satu kereta. Kami memiliki 3 kereta dan tidak setiap kereta mematuhi aturan ini, ada kereta dengan jumlah lebih dari 125 orang. SCRUM tidak menjelaskan bagaimana berinteraksi dengan tim lain, sejauh yang saya tahu, berbeda dengan SAFe, yang memiliki rekomendasi sangat jelas tentang hal ini. Artefak paling mencolok, menurut saya, untuk ini adalah Program Board.

Di sana ditampilkan keterkaitan antar tim dalam kereta dan, dengan membahasnya, diadakan acara mingguan Scrum Of Scrums (SOS) di tempat kami.

Kira-kira setiap 2,5 bulan (setiap 5 sprint) terjadi acara PIPE - Programm Increment Planning Event. Yaitu ketika semua tim yang tersebar berkumpul di satu ruangan selama 2 hari dan merencanakan pekerjaan mereka untuk 2,5 bulan berikutnya. Dalam proses acara ini muncul artefak seperti Program board, misalnya, yang menampilkan semua ketergantungan antar tim untuk setiap kereta, di atas saya sudah menunjukkan bagaimana tampilannya. Tugas Scrum Master setiap tim dalam acara ini adalah memfasilitasi pengungkapan sebanyak mungkin ketergantungan, kemudian jika memungkinkan, menghapusnya (misalnya melalui transfer kompetensi secara lisan dari tim ke tim atau melalui pengambilan ketergantungan dari satu tim ke tim lain agar tim dapat secara mandiri mewujudkan fiturnya tanpa bergantung pada siapa pun). Dalam praktiknya di tempat kami hal itu terjadi demikian. Pertama fitur didekomposisi menjadi User Story, User Story dibagikan ke 4 sprint. Fitur ditempatkan di Program Board dan ditetapkan ketergantungan dari tim lain yang ada. Selama acara ini dibahas dan dikoreksi.

SOS - Scrum Of Scrum. Acara ini berlangsung sekali seminggu untuk setiap kereta secara terpisah. Scrum Master semua tim dalam kereta berkumpul secara online, Program Board kereta ditayangkan dan dibahas status semua ketergantungan dan fitur tim dari kereta tertentu. Pada dasarnya acara ini diperlukan untuk sinkronisasi terpusat tim di dalam kereta. Semacam standup, tetapi sekali seminggu dan bukan untuk tim, melainkan untuk Scrum Master.

PO (Pemilik produk) - bukan pemilik bisnis. Ada Product Manager - dia bekerja dengan Business Owner dari arah bisnis yang sesuai dan pada dasarnya membagikan fitur kepada Pemilik produk. Pemilik produk bekerja sudah langsung di tim - memecah fitur menjadi User Stories (dalam kasus kami bersama tim) dan tidak selalu memecahnya, tetapi kami terus berkembang ke arah ini.

RTE (Release Train Engineer - masinis kereta. Scrum Master dari Scrum Master. Menyelenggarakan acara SOS kereta mereka. Berinteraksi dengan Product Manager pada tingkat fitur. Memfasilitasi PIPE.

Sprint kelima untuk pelatihan - ya, berbeda dengan Scrum, di sini tim dialokasikan satu sprint penuh di akhir increment untuk pelatihan. Kami, biasanya, dalam praktik menggunakannya terutama untuk menghadiri pelatihan internal termasuk tentang SAFe, tetapi tidak hanya itu. Kursus privat dan meetup kami usahakan menjadwalkan pada waktu ini jika memungkinkan. Kami juga memiliki pengembang yang memperluas stack mereka selama sprint ke-5, agar ada kemungkinan menutupi kompetensi seseorang di tim (membackup jika diperlukan).

System Demo. Sebagai hasil PIPE, setiap tim memiliki daftar tujuan untuk increment dan setiap tujuan tersebut dinilai oleh Business Owner kereta pada skala 10 poin. Ini disebut Business Value. Tujuan-tujuan ini dibagi menjadi tujuan utama dan perluasan. Tujuan utama adalah tujuan di mana tim tidak melihat risiko apa pun dalam mencapainya. Tujuan perluasan adalah tujuan dengan risiko pencapaian. Semua tujuan bersifat wajib dan volume pekerjaan direncanakan untuk semua tujuan. Pada System Demo Business Owner menerima hasil kerja untuk increment. Misalkan, tim memiliki 3 tujuan utama dengan nilai 10, 6, 8 dan 2 tujuan perluasan dengan nilai 10, 3. Bayangkan Business Owner memberikan nilai sebagai berikut: 8, 6, 4, 2, 0. Sekarang kita dapat menghitung persentase pencapaian tujuan: untuk 100% diambil jumlah awal poin untuk tujuan utama, dalam kasus kami ini adalah 10+6+8=24. Poin yang dicapai dihitung dengan mempertimbangkan tujuan perluasan (yaitu 20 dari 24 dicapai tim), sehingga sebagai hasilnya persentase pencapaian tujuan tim adalah (20*100)/24 = 83,3%. Hasil yang normal dianggap pencapaian dari 80% hingga 100%.

Dalam segala hal lainnya kami bekerja dengan SCRUM. Yah atau hampir dalam segala hal :) Mengenai pengalaman kami: saya dapat mengatakan bahwa, dari sudut pandang saya, evolusinya jelas. Selama setahun bekerja tim-tim tumbuh pesat, menjadi swakelola, beberapa tim, memang, bubar, tetapi bahkan dalam hal ini terlihat evolusi tertentu. Masih ada ruang untuk tumbuh juga.

Komentar rekan-rekan dari facebook

«Zhenya, halo! Keren, kamu menulis, bagus! Sedikit saya koreksi tentang kereta - mereka berkumpul bukan di sekitar produk, tetapi di sekitar aliran penciptaan nilai. Dan di ritel kami dari sudut pandang SAFe bukan kereta, melainkan Solution. Hanya untuk kemudahan komunikasi dan penyederhanaan pemahaman, kami terus menyebutnya kereta)»

– Konstantin Voronin (perwakilan kantor proyek Ingosstrakh)

«Nah dan mungkin seseorang akan memperhatikan bahwa dari sudut pandang SAFe penilaian tujuan berlangsung pada I&A; (di mana SD masuk sebagai bagian, tetapi tidak terkait langsung dengan penilaian) sedangkan SD itu sendiri harus berlangsung setiap sprint (setelah demo tim). Tetapi kami masih jauh dari itu, jadi kami dengan sadar menyebut semuanya seperti yang tertulis di artikelmu)»

– Konstantin Voronin (perwakilan kantor proyek Ingosstrakh)

«Zhenya, lanjutkan, please, sangat bermanfaat!»

– Alexey Ionov (Pelatih Bersertifikat SAFe)