Tim terus gagal memenuhi tujuan sprint

Kami adalah perusahaan perangkat lunak kecil dengan satu produk.

Kami menggunakan scrum , dan pengembang kami memilih fitur yang ingin mereka sertakan dalam setiap sprint. Sayangnya selama periode 18 bulan terakhir, tim belum pernah mengirimkan fitur yang mereka berkomitmen untuk sprint.

Saya telah membaca banyak posting / jawaban yang menyatakan sesuatu di sepanjang baris "perangkat lunak dilakukan ketika selesai, tidak lebih cepat, tidak lebih ... tidak membantu untuk menekan tim, untuk menempatkan lebih banyak orang di dalamnya, ... "Saya telah menerima umpan balik serupa dari salah satu pengembang atas pertanyaan saya bagaimana kita dapat meningkatkan tingkat keberhasilan sprint. Oh, dan ya kami menggunakan retrospektif .

Pertanyaan saya pada dasarnya:

Kapan adil mencari masalah dalam kualitas pengembang?

Saya mulai berpikir bahwa jika Anda dapat memilih pekerjaan / fitur Anda sendiri dan masih gagal setiap sprint baik: - Anda tidak dapat mengawasi kompleksitas kode Anda sendiri; - atau kodenya sangat rumit sehingga tidak ada yang bisa mengawasi kerumitannya.

Apakah saya melewatkan sesuatu?

Anda harus bertanya dulu, 'siapa yang peduli'?

Menyelesaikan sprint terasa menyenangkan, dan di beberapa perusahaan menghasilkan cookie dari induk scrum. Tetapi ujian terakhir adalah apakah perusahaan memenuhi tujuannya.

Di atas bercanda. Jika perusahaan berhasil sementara tidak pernah menyelesaikan konten sprint yang direncanakan, Anda sebaiknya menggunakan Kanban sebagai gantinya: Anda mengurutkan backlog, Anda mengerjakan apa yang paling penting, dan Anda tidak terlalu khawatir tentang iterasi yang ditentukan.

Salah satu nilai dari iterasi yang didefinisikan adalah untuk mendorong perbaikan proses (atau mengusir yang berkinerja buruk dalam beberapa mentalitas). Anda tidak mengerti sekarang. Jadi, Anda dapat mengadopsi sisa proses yang meningkatkan proses (dan akhirnya menyelesaikan sprint), atau Anda dapat memutuskan bahwa Anda menyukai apa yang Anda miliki.

Apakah saya melewatkan sesuatu?

IYA!

Anda pergi 18 bulan - atau di suatu tempat di lingkungan 36 sprint dengan retrospektif, tetapi entah bagaimana tidak bisa memperbaikinya? Manajemen tidak meminta pertanggungjawaban tim, dan kemudian manajemen mereka tidak meminta pertanggungjawaban mereka karena tidak meminta pertanggungjawaban tim?

Anda kehilangan bahwa perusahaan Anda benar-benar tidak kompeten .

Jadi, bagaimana cara memperbaikinya. Anda (dev) berhenti melakukan begitu banyak pekerjaan. Jika cerita begitu besar sehingga Anda tidak bisa melakukan itu, maka Anda perlu memecah cerita menjadi potongan-potongan kecil. Dan kemudian Anda meminta pertanggungjawaban orang atas apa yang mereka katakan akan dilakukan. Jika ternyata mereka hanya bisa menyelesaikan fitur kecil setiap sprint, maka cari tahu mengapa dan membuatnya lebih baik (yang mungkin melibatkan penggantian pengembang). Jika ternyata mereka tidak tahu bagaimana cara berkomitmen untuk jumlah pekerjaan yang wajar, Anda memecat mereka .

Tapi sebelum itu, saya akan melihat manajemen yang membiarkan semuanya berjalan selama itu, dan mencari tahu mengapa mereka tidak melakukan pekerjaan mereka .

Saya ingin menyarankan Anda untuk melakukan perubahan kecil dan mencoba Kanban selama beberapa minggu, bukan Scrum . Ini mungkin bekerja lebih baik untuk tim Anda.

Sementara Scrum mendorong produktivitas dengan membatasi waktu kerja yang tersedia dalam sprint, Kanban mendorong produktivitas dan kecepatan dengan membatasi jumlah masalah yang aktif dan bersamaan. Estimasi waktu tidak lagi menjadi bagian dari proses. ( sumber )

Singkatnya, apa itu Kanban?

Kanban juga merupakan alat yang digunakan untuk mengatur pekerjaan demi efisiensi. Seperti Scrum, Kanban mendorong pekerjaan untuk dipecah menjadi potongan-potongan yang dapat dikelola dan menggunakan Papan Kanban (sangat mirip dengan Papan Scrum) untuk memvisualisasikan pekerjaan itu saat ia berkembang melalui alur kerja. Di mana Scrum membatasi jumlah waktu yang diizinkan untuk menyelesaikan sejumlah pekerjaan tertentu (melalui sprint), Kanban membatasi jumlah pekerjaan yang diizinkan dalam satu kondisi apa pun (hanya begitu banyak tugas yang dapat dilanjutkan, hanya begitu banyak yang dapat dilakukan di sini). -melakukan daftar.)

Bagaimana SCRUM dan Kanban sama?

Baik Scrum dan Kanban memungkinkan tugas-tugas besar dan kompleks untuk dipecah dan diselesaikan secara efisien. Keduanya menempatkan nilai tinggi pada peningkatan berkelanjutan, optimalisasi pekerjaan dan proses. Dan keduanya berbagi fokus yang sangat mirip pada alur kerja yang sangat terlihat yang membuat semua anggota tim di loop pada WIP dan apa yang akan terjadi.

Lihat detail lainnya dari tautan ini

Pertanyaan saya pada dasarnya: kapan adil mencari masalah dalam kualitas pengembang

Tidak ada informasi yang cukup di pos Anda untuk menjawab pertanyaan itu. Tidak ada cara untuk mengetahui apakah mereka gagal karena mereka tidak kompeten, atau gagal karena mereka berkomitmen untuk melakukan lebih banyak pekerjaan daripada yang wajar.

Jika saya adalah pengembang yang sangat berbakat, di tim pengembang yang sangat berbakat, dan kami gagal menyelesaikan cerita X dalam dua sprint (atau 36!), Apakah kami tidak kompeten? Atau, apakah kita hanya menghisap estimasi? Itu tergantung pada apakah cerita itu "membuat layar masuk" atau "mengirim seorang pria dengan aman ke mars".

Masalahnya dimulai dengan cerita buruk dan / atau perkiraan buruk

Estimasi sulit. Sangat sulit. Manusia menghisapnya, itulah sebabnya Scrum membuat kami memecah pekerjaan menjadi balok-balok yang seharusnya tidak memakan waktu lebih dari satu atau dua hari, dan untuk mengumpulkan kelompok-kelompok kecil balok-balok itu yang kami yakin dapat kami selesaikan dalam waktu singkat . Semakin besar blok, dan semakin lama periode waktu, estimasi kami semakin tidak akurat.

Seperti apa toko Anda? Apakah ditulis dengan baik, dengan kriteria penerimaan yang baik? Apakah mereka masing-masing cukup kecil untuk dilakukan hanya dalam beberapa hari? Tanpa cerita yang ditulis dengan baik (yang merupakan kesalahan dari seluruh tim pengembangan, termasuk pemilik produk), tim tidak dapat diharapkan untuk melakukan estimasi yang baik.

Masalahnya diperparah oleh retrospektif yang buruk

Apa yang Anda lakukan salah, tampaknya, adalah bahwa Anda tidak mengambil keuntungan dari retrospektif. Anda telah pergi 18 bulan tanpa menyelesaikan masalah ini, jadi tim tidak memperhatikan masalah, atau gagal mengatasinya dalam retrospektif mereka.

Apakah setiap retrospektif berakhir dengan setidaknya satu item tindakan untuk diambil oleh tim, agar dapat bekerja lebih baik di sprint berikutnya. Apakah setiap retrospektif termasuk berbicara tentang item tindakan dari sprint sebelumnya untuk melihat apakah mereka dilakukan dan apakah mereka efektif?

Solusinya bukan menyalahkan, itu untuk belajar

Langkah pertama harus berhenti mencari kesalahan, dan sebagai gantinya, mulai bekerja untuk meningkatkan tim. Tim Anda mungkin tidak kompeten, hanya buruk dalam estimasi dan perencanaan. Paksa tim untuk menyelesaikan sprint, bahkan jika itu berarti mereka memilih satu cerita dan menyelesaikan seminggu lebih awal. Jika mereka tidak bisa melakukan itu, maka mereka tidak kompeten, atau ceritanya terlalu rumit. Jawaban atas pertanyaan itu harus jelas.

Begitu mereka dapat menyelesaikan satu cerita, mereka akan tahu dengan kepastian yang masuk akal bahwa mereka dapat melakukan sejumlah X poin cerita dalam sprint. Matematika sederhana akan membantu menjawab pertanyaan apakah mereka dapat melakukan lebih banyak cerita atau tidak.

Perbaikan berkelanjutan adalah solusinya

Begitu mereka menyelesaikan satu cerita dalam sprint, sekarang saatnya untuk melihat apakah mereka dapat melakukan dua. Busa, bilas, ulangi. Ketika mereka mulai gagal dalam tujuan sprint, Anda telah menemukan batas kemampuan estimasi mereka. Kembalilah ke jumlah poin cerita dari cerita sebelumnya dan pertahankan sejenak.

Setiap saat, perhatikan retrospektif dengan serius. Jika mereka tidak menyelesaikan sprint, cari tahu mengapa dan lakukan itu. Apakah mereka memiliki terlalu banyak hal yang tidak diketahui? Apakah mereka memiliki campuran keterampilan yang salah? Seberapa baik perkiraan mereka? Jika mereka memperkirakan sebuah cerita adalah X poin, apakah itu membutuhkan jumlah pekerjaan yang relatif sama dengan cerita priori yang bernilai X poin? Jika tidak, gunakan itu untuk menyesuaikan poin cerita ke depan.

Anda mengatakan Anda "menggunakan retrospektif." Tapi apa yang sebenarnya dilakukan tim dalam retrospektif ini? Karena Anda telah pergi 18 bulan tanpa sekali pun menangani aspek proses Anda ini, saya kira jawabannya adalah: tidak ada yang sangat berguna.

Bagi saya, retrospektif adalah bagian terpenting dari proses. Buang atau ubah apa pun tentang scrum yang Anda inginkan (dengan persetujuan tim bersama selama retrospektif, tentu saja), tetapi berkomitmen untuk secara teratur meluangkan waktu untuk berbicara tentang bagaimana proses itu bekerja untuk semua orang, berbagi apa yang berhasil dan apa yang tidak bekerja, dan mengusulkan ide untuk ditingkatkan. Teruslah berusaha meningkatkan proses Anda sedikit demi sedikit setiap sprint, dan cepat atau lambat, Anda dapat memiliki sesuatu yang bekerja dengan cukup baik.

Dalam kasus Anda, proses itu tampaknya tidak berhasil. Karena tujuan sprint tidak terpenuhi, sebaiknya fokus retrospektif tentang mengapa hal ini terjadi. Jelas, tim terlalu banyak bekerja untuk sprint. Tetapi mengapa mereka melakukan itu?

• Apakah mereka meremehkan kompleksitas pekerjaan?
• Apakah manajemen menekan mereka untuk melakukan lebih banyak pekerjaan daripada yang diperkirakan dapat ditangani oleh tim?
• Apakah mereka memiliki terlalu banyak gangguan / darurat yang mengambil sumber daya dari menyelesaikan pekerjaan yang direncanakan?
• Apakah mereka mengalami hambatan yang menunda penyelesaian pekerjaan (katakanlah, menunggu aset dari tim desain eksternal)?
• Dan bahkan: apakah satu atau lebih anggota tim tidak mampu melakukan pekerjaan sama sekali?

Ini adalah pertanyaan-pertanyaan yang seharusnya ditanyakan oleh tim pada setiap sprint selama 18 bulan terakhir. Kemudian, dengan berbekal jawaban, mereka dapat mengusulkan perbaikan proses yang disarankan ke uji coba untuk sprint berikutnya. Ini mungkin termasuk:

• Kurang kerja di sprint berikutnya (ya!)
• Lebih konservatif dalam perkiraan
• Katakan siapa pun yang menekan kita untuk melakukan lebih banyak pekerjaan untuk mereguk, karena kita sudah mengambil lebih dari yang bisa kita capai sekarang
• Kelola interupsi dengan lebih baik dan sesuaikan jumlah pekerjaan dalam sprint berikutnya untuk mengakomodasi keadaan darurat yang tidak dapat dihindari
• Perbaiki kemacetan atau rencanakan di sekitar yang tidak bisa Anda hindari
• Jangan berikan cerita kepada anggota tim yang tidak dapat menyelesaikannya (dan secara terpisah, cari tahu respons manajemen untuk mengatasi situasi dengan anggota tim yang berkinerja buruk, dari pelatihan dan bimbingan hingga pemecatan)

Ini adalah jenis percakapan yang seharusnya terjadi setiap sprint selama 18 bulan terakhir. Ini bukan tentang memberi tekanan pada tim atau menambahkan lebih banyak sumber daya, tetapi tentang menggunakan retrospektif Anda untuk meningkatkan proses Anda secara berkelanjutan. Itu jelas tidak terjadi di sini.

Anda akan berpikir bahwa pada sprint ke-15 dengan gol-gol yang gagal, tim akan membahas hal ini dalam retrospektif mereka berkali-kali, sampai pada titik di mana mereka memutuskan untuk mengambil tujuan sprint paling minimal yang mungkin hanya demi mendapatkan satu yang lengkap. Pada sprint 25 yang belum selesai, saya hanya akan melakukan sprint dengan perubahan string tunggal dan tidak ada yang lain. Jika tim tidak dapat mengelola itu dalam sprint, masalahnya bahkan lebih buruk daripada yang Anda biarkan.

Untuk menjadi jelas, seperti yang telah ditunjukkan beberapa orang di sini, tujuan sprint adalah perkiraan, bukan komitmen besi, dan tujuan yang hilang bukanlah indikasi apa pun selain membuat ramalan yang tidak akurat. Sebuah tim yang hebat dapat kehilangan banyak tujuan karena mereka adalah peramal yang buruk, sementara tim yang buruk dapat memenuhi setiap tujuan dan tidak memberikan nilai aktual apa pun. Tetapi jika perkiraan Anda salah dalam arah yang sama selama 18 bulan berturut-turut, bagian dari proses Anda itu tidak berfungsi. Gunakan retrospektif Anda untuk memperbaiki proses sehingga perkiraan Anda cukup dekat dengan kenyataan sebenarnya dari apa yang tim dapat berikan setiap sprint.

"Perangkat lunak selesai ketika dilakukan, tidak lebih cepat, tidak lebih lambat."

Ini benar, tetapi untuk setiap tugas yang mulai dikerjakan oleh pengembang Anda, apakah semua orang di organisasi Anda memahami Definisi Selesai untuk setiap tugas?

Tampaknya salah satu masalah terbesar Anda adalah Estimasi , tetapi pengembang hanya dapat memberikan perkiraan realistis ketika mereka memiliki 'definisi selesai' yang jelas dan jelas. (Yang termasuk masalah proses perusahaan - misalnya dokumentasi pengguna, paket kerja pada rilis resmi, dll.)

Tidak mengherankan bahwa estimasi berlebihan menyebabkan masalah, mengingat sebagian besar pengembang melihat bahwa memperkirakan waktu yang dibutuhkan untuk menyelesaikan tugas adalah yang paling sulit yang harus mereka tanyakan.

Namun, sebagian besar pengembang cenderung memiliki pegangan yang masuk akal (meskipun optimis ) pada jumlah upaya yang dapat mereka lakukan, untuk jangka waktu tertentu.

Masalahnya sering adalah bahwa pengembang berjuang untuk menciptakan hubungan antara tugas dan jumlah jumlah usaha yang diperlukan ketika mereka sedang berhadapan dengan informasi yang tidak lengkap - terutama jika mereka ditekan untuk datang dengan semua jawaban up-depan untuk tugas benar-benar besar .

Ini secara alami menyebabkan perkiraan waktu menjadi terputus dari kenyataan, dan mereka kehilangan pandangan terhadap hal-hal seperti proses pembuatan dan dokumentasi pengguna.

Putus cenderung dimulai pada awal ketika tugas dijelaskan; dan biasanya diperparah oleh orang non-teknis yang menyusun daftar persyaratan tanpa mengetahui jumlah upaya yang diperlukan.

Terkadang orang-orang di manajemen senior menentukan tugas dan sepenuhnya mengabaikan masalah proses perusahaan; itu tidak biasa bagi manajemen senior untuk berpikir bahwa hal-hal seperti mendefinisikan tes, atau membuat versi resmi dirilis, atau memperbarui dokumen pengguna hanya terjadi secara ajaib tanpa waktu atau usaha. yg dibutuhkan.

Terkadang proyek gagal sebelum pengembang bahkan menulis sederet kode karena seseorang, di suatu tempat tidak melakukan pekerjaan mereka dengan benar.

Jika tim pengembangan tidak terlibat dalam menyetujui persyaratan atau menangkap kriteria penerimaan, maka itu merupakan kegagalan manajemen - karena itu berarti seseorang yang tidak memiliki pemahaman yang cukup tentang kode dan masalah teknis telah menjadikan bisnis untuk serangkaian persyaratan yang tidak lengkap, dan membiarkan proyek terbuka untuk salah tafsir, cakupan creep, pelapisan emas, dll.

Jika tim pengembangan terlibat dalam menangkap dan menyetujui persyaratan, maka itu bisa merupakan kegagalan tim, yang bertanggung jawab untuk mengklarifikasi detail (dan kriteria penerimaan - yaitu "Seperti apa tampilan yang dapat dikirim? Kapan itu dilakukan ?" ). Tim pengembang juga bertanggung jawab untuk mengatakan TIDAK ketika ada masalah pemblokiran lain di jalan, atau jika persyaratan hanya tidak realistis.

Jadi, jika pengembang terlibat dalam penangkapan persyaratan:

• Apakah tim memiliki kesempatan untuk duduk bersama manajer produk untuk mengklarifikasi persyaratan / definisi yang telah dilakukan?
• Apakah tim mengajukan pertanyaan yang cukup untuk mengklarifikasi persyaratan yang disiratkan / dianggap? Seberapa sering pertanyaan-pertanyaan itu dijawab dengan memuaskan?
• Apakah tim menuntut kriteria Penerimaan (definisi selesai) sebelum memberikan perkiraan?
• Seberapa baik kriteria Penerimaan biasanya ditangkap untuk setiap tugas? Apakah dokumen tersebut samar-samar dengan detail yang jarang atau apakah itu menggambarkan fungsionalitas yang nyata, dan mengatakan bahwa pengembang dapat secara jelas menerjemahkan ke dalam pengujian?

Kemungkinannya adalah bahwa produktivitas tim Anda tidak menjadi masalah; tim Anda mungkin melakukan semua upaya yang mereka dapat lakukan sehubungan dengan pengembangan. Masalah nyata Anda dapat berupa satu atau lebih hal berikut ini:

• Persyaratan tidak lengkap dan tidak jelas.
• Persyaratan / tugas yang terlalu besar di tempat pertama.
• Komunikasi yang buruk antara tim pengembangan dan manajemen tingkat atas.
• Kurangnya kriteria penerimaan yang jelas sebelum tugas diserahkan kepada tim.
• Spesifikasi tes penerimaan yang tidak lengkap atau tidak jelas / ambigu. (yaitu Definisi Selesai)
• Tidak cukup waktu yang dialokasikan untuk mendefinisikan / menyetujui kriteria penerimaan.
• Pengembang tidak mempertimbangkan waktu untuk menguji kode dasar yang ada atau memperbaiki bug yang ada
• Pengembang memang menguji kode dasar yang ada tetapi tidak meningkatkan bug sebagai Masalah Pemblokiran sebelum memberikan perkiraan pada persyaratan
• Manajemen melihat masalah / bug dan memutuskan bahwa bug tidak perlu diperbaiki sebelum menulis kode baru.
• Pengembang berada di bawah tekanan untuk memperhitungkan 100% dari waktu mereka, meskipun mungkin 20% (atau jumlah yang serupa) dari waktu mereka mungkin diambil oleh rapat, gangguan, email, dll.
• Perkiraan disetujui berdasarkan nilai nominal dan tidak ada yang menyesuaikan ruang untuk kesalahan atau kontingensi (mis. "Kami memutuskan ini akan memakan waktu 5 hari, jadi kami akan mengharapkannya selesai pada 8.").
• Perkiraan diperlakukan oleh semua orang (pengembang dan manajemen) sebagai angka tunggal alih-alih angka "rentang" yang realistis - yaitu
  • Perkiraan kasus terbaik
  • Estimasi realistis
  • Estimasi kasus terburuk

... daftarnya bisa bertahan lebih lama dari itu.

Anda perlu melakukan beberapa "pencarian fakta" dan mencari tahu mengapa perkiraan tersebut secara konsisten terputus dari kenyataan. Apakah perangkat lunak dasar yang ada buruk? Apakah tidak memiliki cakupan unit test? Apakah pengembang Anda menghindari komunikasi dengan manajemen? Apakah manajemen menghindari komunikasi dengan pengembang? Apakah ada keterputusan antara ekspektasi manajemen dan ekspektasi pengembang dalam hal "Definisi Selesai" ?

Saran saya untuk me-reboot tim adalah memilih cerita sekecil mungkin per tim, per sprint, dan selesaikan satu cerita itu, dan satu cerita itu saja!

Saya setuju dengan poster-poster lain, baik tim tidak kompeten, atau mereka berusaha melakukan terlalu banyak hal.

Mulailah dengan hal-hal terkecil, kisah-kisah yang paling dikupas, dan selesaikan satu sprint. Dapatkan tim untuk menyelesaikan sprint dan menjadi sukses, dan itu akan membantu mereka untuk melihat bagaimana memprioritaskan waktu dan komitmen kerja mereka. Seiring waktu tim akan dapat melakukan lebih banyak dan lebih banyak pekerjaan sampai mereka mencapai produktivitas puncaknya.

Anda harus mengumpulkan data dan membangun tingkat kepercayaan berdasarkan kinerja masa lalu.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

Contoh paling sederhana adalah dengan sprint waktu konstan, seperti setiap dua minggu. Perkirakan berapa banyak poin cerita yang tim akan selesaikan dalam dua minggu. Kemudian setelah sprint dua minggu selesai, lihat berapa banyak poin cerita yang benar-benar selesai. Seiring waktu, Anda mungkin melihat Anda memperkirakan 15 poin, tetapi hanya selesai 10. Dalam kasus sederhana itu, Anda dapat mulai bergerak maju dengan penyesuaian kecepatan sehingga Anda hanya merencanakan 10 poin per sprint. Atau Anda berencana menyelesaikan 66% dari taksiran pekerjaan.

Dengan membangun tingkat kepercayaan dengan standar deviasi, Anda dapat memberi tahu manajemen: sesuai dengan tujuan proyek saat ini, kami berharap hanya 50% kepercayaan yang bisa kami selesaikan dalam 3 minggu, tetapi kepercayaan 95% kami bisa selesaikan dalam 5 minggu.

Gagasan di balik Agile dan Scrum adalah membangun umpan balik yang ketat sehingga Anda dapat mengukur proses Anda. Anda harus bertanya "Di mana itu rusak?", Karena tampaknya telah rusak sepenuhnya.

1. Rencanakan apa yang akan Anda lakukan dan buat daftarnya
   • Ini harus terdiri dari memilih item dari tumpukan item yang perlu diselesaikan. Sebelum sesuatu ditarik ke dalam daftar yang harus dilakukan untuk sprint, tim harus setuju bahwa mereka sepenuhnya memahaminya dan bahwa mereka memperkirakan secara kasar akan membutuhkan waktu kurang dari sprint untuk menyelesaikannya.
   • Idealnya, backlog dipesan berdasarkan prioritas (untuk bisnis) dan Anda dapat menarik dalam urutan prioritas.
   • Jika item dari backlog terlalu besar, pilah menjadi beberapa bagian yang lebih kecil. Kemudian pisahkan potongan-potongan itu menjadi tugas-tugas individual yang dapat diselesaikan dalam satu hari atau kurang.
   • Jangan berharap perencanaan ini mudah atau cepat.
2. Jalankan item dari daftar untuk periode waktu yang ditentukan (sprint)
3. Tinjau apa yang telah Anda capai
   • Cerita apa yang selesai?
   • Jika tidak ada cerita yang selesai, lalu tugas apa yang mengarang cerita selesai?
   • Jika tidak ada tugas yang diselesaikan, lalu apa tepatnya yang dilakukan semua orang Senin lalu? Selasa lalu ?, dll. - pada titik ini, saatnya untuk introspeksi yang parah ...

4. Memecahkan masalah (menganalisis umpan balik dan beradaptasi)

   • Berapa lama hal-hal yang selesai dilakukan?
   • Apa yang mencegah tugas diselesaikan?
   • Apakah anggota tim memecah cerita (fitur) menjadi tugas yang dapat diselesaikan dalam 1 hari atau kurang? Jika tidak, lakukan ini dan jadikan itu bagian dari daftar yang harus dilakukan.
   • Perubahan apa pada daftar tugas atau item pada daftar tugas yang dibuat selama sprint? Apakah ini alasan untuk tidak menyelesaikan? Jika ya, jangan ubah daftar, atau fiturnya. Lempar fitur yang diubah pada jaminan simpanan hingga stabil.
   • Bagaimana Anda bisa mengurangi ukuran dan ruang lingkup beberapa item menjadi sesuatu yang bisa diselesaikan dalam sprint? Pilih sesuatu yang kecil seperti peningkatan logging, perbaikan bug sederhana, kesalahan ketik, hanya untuk menyelesaikan beberapa hal agar tim dapat mengukur apa yang dapat mereka lakukan. Jika Anda tidak dapat melakukan ini, maka berhentilah berlari dan rencanakan kembali .

5. Kembali ke langkah pertama dan ulangi sampai rilis ...

Apakah ada kendala dokumentasi, masalah kopling menciptakan dependensi, masalah komunikasi, tidak cukup informasi dalam persyaratan? ... Apa? Apakah para pengembang menghabiskan waktu mereka untuk mencoba mempelajari teknologi baru? Apakah mereka menghabiskan banyak waktu dalam desain? Apakah hal-hal seperti pembelajaran dicatat dalam daftar tugas sprint?

Apakah Anda pikir tim Anda berpikir mereka telah mengisolasi masalah mereka setiap retrospektif? Apakah tim bertindak untuk memperbaiki masalah. Apakah tim tidak merespons dan manajemen hanya menentukan solusi dan tindakan yang diambil?

Mengingat rentang waktu yang lama, ada yang salah secara sistemik, tidak hanya dengan pengembang. Pada titik tertentu (sebelum satu tahun naik) seseorang di tim (termasuk master scrum) harus bertanya, apa, sekecil apa pun, yang bisa kita capai?

Dalam situasi Anda, retrospektif sudah terlambat.
Apakah Anda mengadakan pertemuan harian dan benar-benar mendapatkan status dari orang lain tentang apa yang mereka lakukan dalam 24 jam sebelumnya?
Apakah scrum master menggunakan pertemuan itu untuk mengukur kemajuan setiap pengembang terhadap tujuan mereka?
Anda perlu menggunakan bagian metodologi Scrum itu untuk memantau perkembangannya. Seharusnya memberi Anda wawasan yang baik tentang apa yang dilakukan orang.
Apakah mereka terganggu? Menghabiskan terlalu banyak waktu untuk minum kopi, atau membantu orang lain di SE / SO, atau membaca berita, atau melakukan inspeksi yang tidak diperhitungkan? Atau apakah mereka benar-benar kepala-ke-bawah, penuh di depan dan benar-benar berkomitmen? Pandangan harian seharusnya memberi Anda ide yang bagus. Ini juga akan membantu menjaga para dev fokus pada tugas yang ada, sehingga mereka tidak harus mengakui bahwa mereka tidak melakukan apa-apa kemarin.
Dan tentu saja jika mereka melaporkan kemajuan yang mantap sepanjang sprint dan masih tidak memberikan pada akhirnya, maka mereka berbohong dan mungkin sudah waktunya untuk pengembang baru.

Memperkirakan upaya dan waktu yang dibutuhkan untuk menyelesaikan tugas yang kompleks, seperti kode pemrograman, sulit. Seperti yang dikatakan Joel Spolsky :

Pengembang perangkat lunak tidak terlalu suka membuat jadwal. Biasanya, mereka mencoba pergi tanpa satu. "Itu akan dilakukan ketika sudah selesai!" Kata mereka, berharap bahwa zinger yang berani dan lucu akan mengurangi bos mereka menjadi cekikikan, dan dalam riang berikutnya, jadwal akan dilupakan.

Namun, perusahaan memerlukan tenggat waktu untuk beroperasi. Seperti yang disarankan Joel, coba gunakan Penjadwalan Berbasis Bukti yang akan menghasilkan perkiraan waktu dengan probabilitas terkait, yang dapat dikaitkan dengan manajemen sebagai jenis risiko apa pun.

Scrum melakukan beberapa hal.

Pertama, ini mendorong penentuan prioritas. Pemasok pekerjaan harus mengatakan apa yang ingin mereka lakukan terlebih dahulu, dan tidak mengatakan "semuanya sama pentingnya".

Kedua, itu menghasilkan produk yang agak dapat digunakan bahkan jika tidak semuanya selesai. Itulah titik memiliki "produk yang berpotensi untuk dikirim" pada akhir setiap iterasi.

Ketiga, ini memberikan umpan balik yang lebih ketat. Dengan bersikeras bahwa hal-hal "diselesaikan" pada akhir sprint, Anda menghindari masalah "90% fitur lengkap, tetapi hanya setengah jalan dilakukan"; ketika mendorong tenggat waktu, Anda dapat mendorong hal-hal yang perlu dikesampingkan sehingga sepertinya Anda hampir mencapai tenggat waktu, atau Anda dapat memalsukannya. Dengan memiliki definisi selesai, dan bersikeras pada hal-hal yang dilakukan, Anda tahu jika ada sesuatu yang lebih sulit daripada yang terlihat lebih awal daripada nanti.

Keempat, itu menghindari persediaan dengan memindahkan perencanaan terperinci dekat dengan melakukan pekerjaan. Merencanakan hal-hal yang jauh adalah bentuk inventaris: modal dihabiskan untuk sumber daya yang tidak tersedia untuk dijual atau digunakan langsung oleh pelanggan. Inventaris semacam itu dapat membusuk (rencana berubah dengan sendirinya, informasi baru membuatnya usang), tidak selaras dengan kebutuhan (ternyata kita tidak memerlukan jaringan terdistribusi apa pun, karena hal yang menggunakannya tidak sepadan), dan mengurangi nilai barang yang dikirim (jika dalam setengah tahun terakhir waktu Anda dihabiskan untuk perencanaan untuk tahun depan dan seterusnya, Anda bisa mendapatkan pengiriman dua kali lebih banyak jika Anda mengerjakan hal-hal yang harus siap sekarang). Jika Anda dapat memindahkan perencanaan lebih dekat ke eksekusi tanpa kehilangan (rumit!), Anda dapat mengurangi inventaris.

Itu bukan satu-satunya cara untuk menyelesaikan masalah ini. Anda tampaknya menggunakan scrum di mana ia menyediakan aliran pekerjaan bagi pengembang untuk dikerjakan untuk setiap periode waktu, dengan menambahkan pekerjaan baru secara berkala untuk dilakukan, dan memeriksa kemajuan.

Ini adalah cara yang berguna untuk menggunakan pola scrum-esque. Itu membuat pekerjaan terus mengalir, itu membuat perencanaan dekat dengan produksi, itu memberikan beberapa putaran umpan balik, dll. Bahkan memiliki keuntungan karena itu tidak membengkokkan pengembangan dan pengujian agar sesuai dengan sistem (jika pengujian paling baik dilakukan dengan pekerjaan pada dasarnya selesai , mencoba menyelesaikan dan menguji dalam sprint yang sama memaksa back-end sprint untuk tidak melibatkan pengembangan baru!)

Kegagalan untuk menempatkan apa yang akan mereka lakukan dalam sprint itu bukan bukti bahwa pengembang Anda tidak melakukan pekerjaan yang baik. Ini berarti mereka tidak mengikuti SCRUM dari atas, alih-alih menggunakan bagian-bagian kerangka kerja.

Jika mereka membagi dua (atau memotong-motong) seberapa banyak mereka berkomitmen untuk setiap sprint, tetapi menjaga semuanya tetap sama, maka mereka akan menyelesaikan lebih dari yang telah mereka lakukan pada setiap sprint! Anda akan menghasilkan jumlah kode yang sama. Jelas bahwa "kegagalan sprint" bukanlah bagian yang penting, karena itu hanyalah detail proses internal. Tujuan perusahaan adalah menyelesaikan masalah, dan itu bagus; tidak mengikuti proses tertentu, kecuali jika tujuan Anda adalah semacam sertifikasi proses ISO tertentu.

Proses ini ada tunduk pada tujuan dari hal-hal yang dilakukan.

Di sisi lain, karena mereka tidak mengikuti aturan scrum, Anda tidak mendapatkan sama jenis umpan balik. Anda harus memeriksa hal-hal yang dihasilkan untuk melihat apakah jenis cacat yang dihasilkan adalah kekurangan yang dirancang untuk ditangani oleh SCRUM; Adakah cerita yang hidup seperti zombie selamanya, dan hanya terbunuh sampai larut malam? Apakah ada cerita yang tampaknya mudah, meledak, dan secara retrospektif tidak sepadan dengan pekerjaan total? Apakah produk benar-benar dapat dikirim pada saat Anda membutuhkan / ingin mengirimkannya?

"Perangkat lunak selesai ketika dilakukan, tidak lebih cepat, tidak lebih lambat" adalah resep untuk kegagalan jika Anda belum menentukan seperti apa "selesai" itu.

Sebagian besar insinyur akan mencoba untuk menghasilkan solusi terbaik, tetapi ini dapat dengan mudah menyebabkan pelapisan emas, terutama dengan insinyur yang kurang berpengalaman. Satu- satunya tanggung jawab manajemen adalah untuk menentukan dengan tepat di mana tujuannya dan untuk menjaga insinyur Anda menuju ke arah itu. Insinyur akan sering berusaha untuk mengambil pergantian sisi untuk meningkatkan fitur, dan terserah manajemen untuk memutuskan apakah pergantian sisi akan mempercepat hal-hal jangka panjang, atau apakah itu hanya meningkatkan untuk peningkatan yang sama.

Inti dari pengembangan yang gesit adalah bahwa setiap karya baru harus sama baiknya dengan yang dibutuhkan untuk memenuhi sprint itu DAN TANPA LEBIH BAIK !!!!!! Ya, itu tentang penekanan yang paling saya dapat tambahkan di StackOverflow - dan itu masih belum cukup penekanan. Jika Anda menemukan bahwa orang-orang menambahkan hal-hal yang tidak diperlukan saat ini maka mereka perlu pelatihan tentang cara melakukan pengembangan tangkas dengan benar.

Oh, dan ya kami menggunakan retrospektif.

Oh bagus, jadi Anda tahu mengapa tim Anda gagal, bukan? Anda memiliki 36 peluang untuk berbicara tentang apa yang berhasil dan tidak berhasil, sehingga para pembuat scrum harus sepenuhnya memahami bagaimana menyelesaikan masalah, bukan?

Saya punya firasat, dengan deskripsi yang Anda berikan, bahwa perusahaan Anda telah jatuh ke dalam mentalitas "SCRUM membuat kami produktif". Yang benar adalah SCRUM tidak membuat Anda produktif. Sebaliknya, ini adalah alat untuk membantu Anda membuat diri Anda produktif dengan cara mengidentifikasi realitas pembangunan yang sering diabaikan oleh manajemen dan pengembang.

Apa yang diidentifikasi oleh scrum master sebagai masalah potensial dengan tim? Apakah mereka secara konstan menetapkan pekerjaan dua kali lebih banyak daripada yang bisa mereka tangani? Jika demikian, master scrum harus dengan lembut menyarankan agar mereka mengambil lebih sedikit pekerjaan, karena master scrum dapat melihat kecepatan tim.

Kapan adil mencari masalah dalam kualitas pengembang?

Waktu di mana seseorang harus mencari masalah dalam kualitas pengembang adalah saat Anda yakin itulah masalahnya. Ini bukan masalah baru yang dibuat oleh SCRUM. Inilah realitas bisnis. SCRUM harus memberi Anda jauh lebih banyak informasi tentang kemampuan anggota tim Anda daripada pendekatan tradisional. Anda harus tahu apakah masalahnya adalah "pengembang perangkat lunak tidak cukup baik" versus "ekspektasi manajemen tidak realistis" ke tingkat yang jauh lebih baik daripada yang akan Anda pahami dengan pendekatan tradisional. Inilah saatnya bagi manajemen untuk melakukan apa yang paling baik dilakukan oleh manajemen: mencari tahu orang yang tepat untuk pekerjaan itu, sehingga perusahaan dapat menghasilkan uang. Jika Anda tidak tahu di mana masalahnya, bayangkan betapa sulitnya mengatakannya tanpa semua retrospektif itu!

Jika Anda berpikir orang-orang mungkin cukup baik (menyiratkan perekrutan mereka bukan kesalahan pihak manajemen), maka saran saya adalah mulai berpikir di luar kotak. Jika pekerjaan tidak selesai, pertimbangkan untuk mengubah bentuk pekerjaan untuk pengembang. Salah satu cara termudah yang saya temukan untuk membuat tenggat waktu penyelesaian sprint adalah menyesuaikan kriteria DILAKUKAN sehingga Anda akan senang dengan hasilnya, tidak peduli bagaimana itu dilakukan. Dengan demikian diselesaikan menjadi tautologi.

Ini menempatkan tanggung jawab pada manajemen, terutama master SCRUM. Caranya adalah dengan menulis tugas-tugas yang, jika selesai, sangat berharga, tetapi jika dibiarkan tidak lengkap mereka masih memberikan nilai tambah yang cukup bagi perusahaan untuk menjadi layak gaji mereka. Setelah 18 bulan, saya berharap retrospektif Anda telah mengajarkan Anda sesuatu. Jika belum, mungkin Anda harus menulis cerita dengan maksud eksplisit dari cerita yang gagal untuk menemukan sesuatu yang salah di perusahaan Anda dan membawanya ke cahaya. Itu akan memberi perusahaan dengan data berharga yang sangat besar, mengingat betapa frustrasi yang tampaknya dimiliki perusahaan dengan tim pengembangan. Masalahnya mungkin memang pengembang, seperti yang Anda tanyakan. Atau masalahnya mungkin patologi dalam pola pikir perusahaan yang belum Anda ketahui sampai sekarang!

Jika memang masalahnya ada pada perusahaan, bukan pengembang, informasi yang Anda peroleh dari cerita yang tidak lengkap ini mungkin bernilai lebih dari produk yang Anda kumpulkan dari yang sukses! Mungkin informasi yang menyelamatkan seluruh perusahaan Anda! Itu sepertinya informasi yang sangat berharga bagi saya, dan Anda dapat menggunakan SCRUM sebagai alat untuk membantu Anda mengumpulkannya.

"Kapan adil untuk melihat kualitas pengembang?"

Sepanjang waktu. Jelas beberapa orang lebih produktif daripada yang lain, Anda tidak perlu alasan sebagai atasan mereka untuk mengukur kinerja mereka.

Yang sulit adalah bagaimana Anda melakukannya. Saran saya adalah mempekerjakan beberapa kontraktor berpengalaman untuk bekerja bersama staf perm Anda pada set tugas yang sama yang diperkirakan oleh para perm Anda dan lihat apakah mereka memiliki kecepatan yang lebih tinggi.

Ini akan memberi Anda perbandingan yang baik dengan pasar saat ini tanpa mengunci Anda ke dalam sewa jangka panjang.

Mungkin juga memberikan perm guys sedikit tendangan pantat.

Selain itu, jika mereka mengeluh kontraktor melompati kualitas dll untuk mendapatkan kecepatan maka itu akan mendorong pembicaraan tentang di mana nilai bisnisnya. Pemeliharaan jangka panjang atau produk jangka pendek dikirim.

Jika itu adalah barang jangka panjang maka itu akan memaksa Anda untuk mengukurnya dan meletakkannya di sprint sebagai persyaratan!

Sudah ada beberapa jawaban bagus. Secara khusus, estimasi yang buruk, komitmen yang berlebihan, dan / atau pekerjaan yang tidak terjadwal sering menjadi penyebab slippage.

Tapi saya ingin tahu mengapa pengembang "[Anda] memilih fitur yang ingin mereka sertakan dalam setiap sprint". Pengembang biasanya harus mengerjakan fitur dengan prioritas tertinggi terlebih dahulu - dan prioritas adalah keputusan bisnis, yaitu yang harus berasal dari pemilik produk yang bertindak sebagai proxy untuk pemangku kepentingan bisnis.
(Ada pengecualian untuk ini. Secara khusus, fitur-fitur berisiko tinggi umumnya bekerja lebih awal. Dan dalam beberapa kasus, fitur yang dihadapi pengguna mungkin tergantung pada fungsionalitas lain, misalnya "kita benar-benar perlu menambahkan database sebelum kita dapat mengimplementasikan X". )

Di sisi lain, perkiraan adalah keputusan teknis, dan tidak boleh dibuat (atau ditebak) oleh pelaku bisnis. Anda tidak mengatakan apa-apa tentang ini - saya mengemukakan intinya hanya karena, dalam pengalaman saya, ketika pengembang memilih apa yang akan dikerjakan, cukup umum bagi pebisnis untuk mencoba menentukan berapa lama waktu yang diperlukan.

Sepertinya Anda memiliki proses yang cukup disfungsional. Saya akan merekomendasikan untuk tidak membawa konsultan pengembang, setidaknya untuk saat ini, karena itu mungkin akan berdampak negatif pada moral. Tetapi sepertinya organisasi Anda dapat menggunakan bantuan di sisi manajemen proyek. Di situlah saya akan mulai, dengan membawa pelatih lincah yang berpengalaman - jika bukan untuk keterlibatan jangka menengah hingga jangka panjang, maka setidaknya untuk penilaian atau "pemeriksaan kesehatan". Pelatih yang baik akan memberi tahu Anda jika Anda memiliki pengembang yang berkinerja buruk, tetapi setidaknya dengan cara ini, seluruh tim (bukan hanya para pengembang) yang berada di bawah pengawasan.

Satu pengamatan lain: dalam pengalaman saya sangat sulit untuk membuat scrum berhasil sebagai metodologi manajemen proyek jika Anda tidak juga mengikuti proses pengembangan yang baik. Apakah Anda melakukan pengujian unit otomatis? atau bahkan lebih baik, pengujian penerimaan otomatis? Apakah pasangan devs Anda, atau apakah Anda setidaknya sering melakukan tinjauan kode dan / atau penelusuran? Apakah Anda mempraktikkan beberapa bentuk integrasi berkelanjutan?