Flazzo memiliki fokus utama untuk menambah nilai bisnis Anda.

Blog

4 tanda sprint Anda gagal dan 4 cara memperbaikinya

16995404-thumb.jpg
Blog

4 tanda sprint Anda gagal dan 4 cara memperbaikinya

[ad_1]

Sprint memiliki tempat suci dalam kelincahan dan sering digunakan sebagai alat keterlibatan untuk merampingkan tim teknik. Acara berdurasi dua minggu ini mengubah daftar keinginan produk Anda menjadi tugas yang dapat ditindaklanjuti, membentuk curah pendapat menjadi hasil yang dapat ditindaklanjuti, dan bahkan menciptakan budaya ulasan dan retro.

Sprint tidak hanya mempercepat penyelesaian proyek, tetapi bahkan menciptakan budaya akuntabilitas, terutama dalam tim yang tersebar secara geografis. Meskipun sprint selalu menjadi cara jitu untuk mempercepat manajemen proyek, sprint dapat menciptakan ketidakseimbangan proses yang serius jika tidak dijalankan dengan benar.

Kami tidak pernah gagal sprint, kami gagal sprint.

Meluncurkan sprint baru seperti menengahi sebuah proyek sambil menciptakan ruang untuk perbaikan pada saat yang bersamaan. Karena sprint adalah acara yang berumur pendek, tim sering kesulitan untuk mengenali kapan sprint menyimpang dari tujuan yang telah disepakati sebelumnya. Untungnya, ada beberapa indikator kunci yang bisa menandakan kegagalan perencanaan sprint.

1. Tidak ada lagi pekerjaan yang tidak direncanakan selama sprint

Di dunia yang sempurna, sprint seharusnya tentang merencanakan pekerjaan Anda dan membangun rencana Anda. Tetapi pengembangan produk adalah proses yang berkelanjutan, melibatkan banyak iterasi, dengan terlalu banyak ketergantungan eksternal. Pekerjaan yang tidak direncanakan tidak dapat dihindari dalam sprint, dan sebagian besar tim bahkan menyisihkan sebagian waktu yang tidak penting untuk pekerjaan yang tidak direncanakan. Namun, jika tim menghabiskan lebih dari 10% waktu pengkodean aktual mereka untuk tugas yang tidak direncanakan, itu adalah bahan yang sempurna untuk sprint yang gagal.

Pekerjaan yang tidak direncanakan adalah segala sesuatu yang menghalangi pengembang menyelesaikan pekerjaan yang sebenarnya, apakah itu membuat lampu tetap menyala atau macet karena konstruksi yang tidak teratur. Apakah Anda ingat ketika Anda harus menangguhkan kode karena perbaikan kode tidak difaktorkan ulang dan gagal? Itulah pekerjaan yang tidak direncanakan. Ini memaksa pengembang untuk terus berjuang, bahkan mengalihkan perhatian mereka dari tugas sprint yang sebenarnya.

Pekerjaan tinggi yang tidak direncanakan adalah anti-pola pertama dan terpenting dari sprint Anda saat ini.

Jika tim tidak memperkirakan tingkat upaya yang diperlukan untuk pekerjaan yang direncanakan dengan benar atau tidak mempertimbangkan potensi masalah yang mungkin timbul, hal itu dapat menyebabkan peningkatan pekerjaan yang tidak direncanakan. Selain itu, hal ini juga dapat membahayakan produktivitas developer dan moral tim, karena kerja ekstra dapat menghambat tujuan sprint yang telah ditentukan sebelumnya.

Bagaimana menangani pekerjaan yang tidak terjadwal

Sebenarnya, pekerjaan yang tidak direncanakan akan tetap ada dan tidak dapat dihilangkan sepenuhnya. Tetapi ada beberapa hal yang dapat kami lakukan untuk membatasi kejutan dan membuat sprint Anda bekerja di luar kendali, dan membuat sprint backlog Anda kewalahan.

Data adalah jawaban atas tantangan pekerjaan yang tidak direncanakan untuk tim teknik. Pada retrospeksi sprint Anda berikutnya, luangkan waktu diskusi 15 menit untuk membahas pembagian pekerjaan yang tidak direncanakan versus poin cerita yang direncanakan. Dengan cara ini, tim dapat menghemat beberapa jam kosong untuk pekerjaan yang tidak direncanakan dalam sprint mendatang.

Dokumentasi yang baik memecahkan banyak masalah pengiriman untuk tim teknik, dan salah satunya adalah pekerjaan yang tidak direncanakan. Sumber daya dukungan, informasi kontrol akses apa pun, dukungan pelatihan, atau lebih banyak konteks dalam kegagalan build tertentu sangat membantu dalam mengurangi beberapa pekerjaan yang tidak direncanakan.

2. Bug vs. Cerita vs. Masalah

Memastikan keselarasan kerja sama pentingnya dengan memastikan keselarasan tim di seluruh tujuan sprint. Perpaduan bug, cerita, dan log masalah yang sehat untuk setiap pengembang per sprint dapat membantu mencapai hal ini.

Kelelahan serangga itu nyata. Ini terjadi ketika pengembang menghabiskan terlalu banyak waktu untuk debugging, daripada poin cerita. Bug tidak bisa dihindari, seperti pekerjaan yang tidak direncanakan. Namun, jika pengembang menghabiskan terlalu banyak waktu — bahkan melebihi 20% dari total waktu sprint mereka untuk memperbaiki masalah kode — itu adalah tanda bahaya berikutnya yang harus diwaspadai oleh tim.

Menghabiskan terlalu banyak sumber daya untuk bug terkadang mengorbankan fitur yang berharga. Selain itu, jika tim terlalu memprioritaskan bug, maka mereka berada di ambang kolaborasi yang terganggu dan kecepatan sprint yang rendah. Ini biasanya terjadi ketika tim tidak memperkirakan kompleksitas pekerjaan dengan benar.

Cara Meminimalkan Kelelahan Serangga

Perbaikan cepatnya adalah membuat titik cerita terpisah untuk setiap bug yang bukan bagian dari sprint Anda yang sebenarnya. Namun, membuat poin cerita baru tidak dapat menyelesaikan masalah sebenarnya dari bug yang tidak proporsional dalam sprint Anda.

Sekarang mari kita bicara tentang cara yang paling berkelanjutan.

Gunakan alat analisis teknik untuk memvisualisasikan pemecahan masalah sprint Anda. Buat bagian prioritas untuk semua jenis masalah – bug, poin cerita, bahkan insiden. Cobalah untuk mendokumentasikan masalah apa pun yang mungkin dihadapi tim teknik Anda. Saring masalah ini berdasarkan prioritas selama rapat perencanaan itu sendiri.

Tinjauan pengiriman proyek oleh Hatica

3. Kesehatan Tim Menurun

Kepuasan pengembang selalu sebanding dengan efektivitas sprint, tetapi sebagian besar manajer gagal mengikat kerja keras pengembang dengan kegagalan sprint. Sebagian besar tim teknik mengambil pendekatan “pengembang bekerja paling baik di bawah kinerja”. Ini adalah resep sempurna untuk sprint yang berkinerja buruk dan bahkan gagal.

EM mengenal pengembang mereka lebih baik dari siapa pun – kemampuan mereka, kekurangan mereka, dan keadaan di mana mereka menonjol. Menetapkan tugas pengembang di luar kapasitas kerja mereka dapat menumbangkan kemampuan tim untuk menyampaikan.

Sebagian besar pengembang menyambut introvert, dan sebenarnya sulit bagi mereka untuk mengekspresikan diri setiap kali kelebihan beban. Bandwidth beban kerja yang terlalu tinggi dapat menyebabkan pengembang kehabisan tenaga dengan sangat cepat, bahkan membuat mereka menyerah atau menghasilkan pekerjaan yang tidak produktif.

Bagaimana memastikan produktivitas pengembang

Di sini, seharusnya menjadi tanggung jawab pimpinan teknik untuk menciptakan perpaduan masalah yang sehat bagi setiap pengembang. Jika pengembang kewalahan oleh peringatan insiden di hari-hari awal sprint, manajer dapat mematikan beberapa lampu tepat waktu dan memindahkan pengembang ke rilis fitur.

Kadang-kadang bahkan mengalokasikan waktu luang untuk pengembang juga dapat membantu mereka mengisi ulang dan membangun kembali dengan lebih baik di sprint yang akan datang.

4. Lewati sprint retrospectives

Gagasan melakukan sprint retro adalah untuk mendokumentasikan apa yang berhasil dan apa yang tidak berhasil dalam sprint ini, serta tantangan dan penghalang. Rapat sprint retrospektif adalah tempat yang tepat bagi tim untuk mendiskusikan umpan balik dan menyusun daftar peningkatan yang dapat dicapai, namun sebagian besar anggota tim dengan sengaja mengabaikannya.

Sebagian besar pengembang membenci retro. Bagi mereka, retrospektif itu monoton, kekurangan data untuk mendukung hasil sprint, atau bahkan membawa perubahan nyata pada sprint mendatang. Kadang-kadang retro ini dilakukan dengan setengah hati, dan di lain waktu kurangnya visibilitas kinerja sprint mencegah retro yang dapat ditindaklanjuti. Jika retrospektif dilakukan secara teratur tanpa hasil yang jelas, hal itu dapat membuang-buang waktu dan kehilangan efektivitas.

Cara melakukan sprint retro yang efektif

Pikirkan retrospektif Scrum sebagai peluang bagi tim teknik untuk merefleksikan kinerja mereka. Analisis kerja dapat meningkatkan visibilitas ke dalam tren sprint sehingga tim memiliki pemahaman faktual tentang segala hal yang berhasil/tidak berhasil selama sprint tersebut.

Dasbor Performa Sprint oleh Hatica

Dengan wawasan berbasis data, tim dapat dengan mudah melewati tantangan sprint dan bahkan mengidentifikasi akar penyebab pemblokir. Data ini mendorong diskusi produktif untuk menemukan solusi jangka panjang. Misalnya, jika tim menyadari bahwa mereka merilis lebih sedikit fitur karena waktu siklus yang tinggi, mereka dapat menggali lebih dalam penyebab lonjakan tersebut dan memperbaikinya sebelum sesi perencanaan sprint berikutnya.

Distribusi waktu siklus

Kesimpulan

Andy Hiles sangat masuk akal ketika dia menyebut setiap sprint sebagai eksperimen untuk melihat “apakah kita memecahkan masalah yang ingin kita selesaikan”. Sprint yang sukses adalah langkah pertama untuk pengiriman proyek yang sukses dan pengembangan produk yang luar biasa.

Libatkan seluruh tim Anda dalam prosesnya, mulai dari perencanaan hingga perebutan sprint dan retro. Tetapkan tujuan yang terukur dan dapat dicapai, alokasikan waktu buffer yang memadai, dan fokus pada penggalian data untuk wawasan yang dapat mengubah cara tim melakukan sprint.

Sprint yang sehat adalah situasi win-win untuk semua orang di sepanjang siklus bisnis: dari pelanggan hingga CTO, CEO, pemimpin teknik, dan kontributor individu.

[ad_2]