Apa itu rencana pengiriman?
Seiring pertumbuhan organisasi pengembangan, organisasi perlu diatur ulang menjadi beberapa tim yang lebih kecil yang dapat secara efisien mengelola unit kerja yang dibagi. Tim-tim ini biasanya memiliki jadwal kerja, papan, dan proses lain yang memenuhi kebutuhan unik mereka dalam konteks tujuan organisasi yang lebih besar. Seiring waktu, organisasi mungkin menemukan bahwa mereka menikmati manfaat jaringan dengan mengonsolidasikan proses mereka di sekitar kerangka kerja yang konsisten.
Rencana pengiriman adalah visualisasi dari satu atau beberapa jadwal kerja. Tujuan ini memberikan tim dan manajemen pandangan keseluruhan tentang apa dan kapan yang masing-masing tim rencanakan untuk diproduksi. Tujuan ini memungkinkan pengambilan keputusan yang mengoptimalkan investasi di seluruh organisasi.
Tim harus secara teratur meninjau paket pengiriman mereka untuk memastikan bahwa jadwal kerja mereka selaras dengan jadwal tim lain. Tinjauan ini harus menjawab pertanyaan seperti:
- Apakah kami yakin dapat memberikan apa yang telah diterapkan pada jadwal kami saat ini?
- Apakah kita yakin bahwa tim yang diandalkan akan memberikan apa yang kita butuhkan pada jadwal mereka saat ini?
- Apakah ada jadwal Anda yang bisa kami isi dengan pekerjaan?
- Apakah ada masalah dengan ketergantungan dalam tim atau dengan tim lain?
Rencana pengiriman menambah nilai pada titik mana pun dalam siklus hidup proyek. Karena dibuat secara dinamis berdasarkan backlog tim, tim selalu up-to-date dan menawarkan wawasan terbaru.
Mari bergabung ke dalam diskusi tim web Tailspin.
Andy: Saya baru saja mengadakan rapat besar dengan manajemen teknik. Saya mendemonstrasikan pekerjaan yang kami lakukan dengan Azure Boards, dan tim bersemangat tentang prospek untuk mendapatkan tim lain di dalamnya.
Mara: Keren! Kapan mereka akan mulai?
Itu bagian terbaiknya. Mereka sudah memiliki! Tadi malam pemimpin proyek mesin game membuat tim dengan beberapa sprint dan mulai menambahkan item kerja. Saya melihat sekilas pagi ini, dan itu terbentuk dengan baik. Mari saya tunjukkan apa yang mereka lakukan.
Andy menavigasi ke papan sprint mesin game saat ini. Dia dan Mara meninjau item pekerjaan dengan penuh antusias.
Andy: Hmm...Saya baru menyadari bahwa mereka tidak berencana untuk menyebarkan versi beta-nya di akhir sprint ini. Bukankah kita berharap untuk mengintegrasikan papan peringkat dengan database beta pada sprint berikutnya? Kita tidak dapat melakukannya jika mereka tidak mengirim beta terlebih dahulu.
Mara: Poin yang bagus. Kita memiliki dependensi pada tim itu untuk menghasilkan kiriman tersebut sehingga kita dapat menghasilkan salah satu dari kta sendiri.
Andy: Ini bisa sangat merusak produktivitas kita di sprint berikutnya. Aku akan menelepon mereka untuk mencari tahu apa yang terjadi.
Sayangnya, struktur tim yang lebih canggih dapat mengakibatkan kesenjangan atau jeda dalam komunikasi. Ketika satu tim diblokir, mereka mungkin tidak dapat menghasilkan sesuatu yang bergantung pada tim lain. Ini mungkin bukan masalah besar bagi sekelompok kecil tim yang mengadakan rapat harian untuk semua pihak. Namun, seiring dengan skala tim secara ukuran dan lokasi, semua orang tidak dapat lagi mengetahui segala sesuatu yang terjadi di semua tempat. Pada titik inilah organisasi perlu bertransisi dari model "pendorongan" murni (seperti pengumuman langsung atau email) ke model "penarikan" (di mana tim dapat meninjau dan melacak jadwal masing-masing).
Andy: Oke, saya baru saja berbicara dengan pimpinan pengembang. Dia memberi tahu saya bahwa tim mereka diblokir dari pengiriman beta sampai tim seni kembali dari Cliffchella.
Mara: Festival musik puncak gunung?
Andy: Ya, tampaknya, ini adalah masalah besar bagi komunitas desain, dan seluruh tim mereka baru saja berhenti bekerja selama seminggu penuh. Tim mesin game cukup kesal karena jadwal mereka tergeser tiga minggu. Seandainya mereka tahu itu akan terjadi, mereka akan memastikan untuk mendapatkan artefak yang mereka butuhkan sebelumnya. Mereka juga meminta maaf karena tidak memberi tahu kita lebih awal. Mereka tidak tahu bahwa kami menunggu versi beta mereka untuk mengirimkan bagian kami.
Mara: Yah, setidaknya kami senang bahwa tim mesin game menerbitkan paket sprint mereka. Ini membantu kami menemukan masalah dependensi ini cukup awal untuk menyesuaikan jadwal.
Andy: Saya hanya berharap ada cara untuk melihat potensi risiko yang muncul dengan lebih mudah ini. Tim kami memiliki begitu banyak dependensi di seluruh perusahaan sehingga tidak mungkin kami dapat menghadiri setiap rapat dan berlangganan setiap grup distribusi.
Mara: Kita harus membuat rencana pengiriman sehingga kita dapat melihat tim kita sprint berdampingan. Hal ini akan membantu kedua tim lebih mudah mengidentifikasi bagaimana jadwal kami saling memengaruhi.
Rekomendasi untuk mengelola beberapa tim Agile
Pendekatan Agile, bersama dengan Azure DevOps dapat secara substansial meningkatkan transparansi dan prediktabilitas proyek. Namun, proyek mungkin masih mengalami tantangan yang sama, sering kali terkait dengan personel atau miskomunikasi. Berikut adalah beberapa hal yang perlu dipertimbangkan saat menskalakan upaya Agile Anda.
Membangun kepercayaan pada orang dan proses Anda
Penolakan awal implementasi Agile sering skeptis tentang kemampuan mereka untuk meningkatkan kinerja tim. Penting bagi para pemimpin pemikiran di dalam organisasi untuk membangun kepercayaan dengan mengilustrasikan bagaimana alat dan proses membuahkan hasil. Terkadang hasil ini merupakan peningkatan produktivitas yang mudah diukur. Namun, jangan lupa untuk menyoroti kemenangan tim yang dicapai dengan menghindari potensi masalah, seperti kesalahan jadwal yang dapat dihindari atau masalah kualitas. Saat orang mulai mengaitkan manfaat dengan proses pencapaiannya, Anda akan lebih berantusias.
Memosisikan organisasi di atas tim (dan individu)
Beberapa tim dan individu mendapatkan teritorial ketika proses atau kebijakan baru diusulkan. Daripada menyusun kebijakan baru sebagai pengungkapan negatif performa tim atau individu tertentu, soroti bagaimana transparansi baru di seluruh organisasi memberi tahu semua orang tentang ekspektasi. Memiliki satu tempat untuk setiap orang dapat melacak bagaimana pekerjaan mereka terkait dengan organisasi yang memenuhi tujuannya akan menunjukkan pentingnya komitmen mereka terhadap proses tersebut.
Menumbuhkan budaya transparansi
Sayangnya, istilah "transparansi" mendapat pandangan buruk. Tidak ada yang meminta transparansi lebih ketika semuanya berjalan dengan baik. Sebaliknya, transparansi (atau kekurangannya) sering disalahkan ketika tim sedang berjuang. Bahkan dengan semua peluang transparansi yang diberikan untuk tim Agile, kejujuran individu dan tim tetap harus diperhatikan. Tekankan bahwa salah satu alasan transparansi adalah untuk dapat mengidentifikasi dan menangani potensi masalah sebelum terlambat. Kita semua tahu bahwa orang terkadang mengalami keadaan yang mencegah mereka memenuhi tenggat waktu jadwal. Tetapi jika mereka tidak merasa aman dalam melaporkan berita yang mengecewakan sampai saat-saat terakhir, dampaknya bisa jauh lebih merusak. Membangun tingkat kenyamanan dengan transparansi dapat dimulai dengan berterima kasih kepada orang-orang karena melaporkan kemungkinan penundaan sedini mungkin.