Saya pikir orang lain sudah memberikan jawaban yang baik tetapi saya akan menambahkan saya hanya karena saya pikir tim Anda baru saja beralih ke Scrum dan sekarang kalian berada di posisi yang sangat mirip dengan kami ketika kami mulai.
Pertama, perkenalan kami dengan Agile dan lebih spesifiknya Scrum tidak terlalu mulus. Pada dasarnya manajemen turun dan berkata, mulai hari ini Anda akan melakukan Scrum dan ini adalah proses yang Anda semua akan ikuti. Begitu banyak untuk Orang - orang di Atas Proses .
Proses yang awalnya kami ikuti (secara membabi buta, saya dapat menambahkan) berakhir sangat mirip dengan bagaimana Anda menggambarkan. Orang-orang mendapatkan tugas yang ditugaskan, semua orang dipesan dan kita semua kembali ke meja kami dan pergi. Kemudian kami mengadakan pertemuan stand-up yang membosankan setiap hari.
Kunci untuk menyadari adalah bahwa Agile, dan Scrum termasuk, sebenarnya tentang orang. Ketika tim masuk ke perencanaan iterasi, jangan biarkan Scrum master Anda (yang mungkin manajer Anda) untuk memberi Anda jam, cerita dan tugas. Benar-benar HINGGA TIM. Saya pikir bagi banyak orang ini adalah konsep yang sangat sulit untuk dilalui karena selama bertahun-tahun sebelumnya mereka datang untuk bekerja dan mereka akan memiliki bos (manajer, pimpinan teknis ...) yang hanya akan menugaskan pekerjaan. Mereka menyelam ke Scrum tetapi semua orang (termasuk master scrum sendiri) terus beroperasi dalam mode yang sama.
Suatu hari, Anda akan muak dengan ini, jadi Anda akan mulai membaca buku, blog, dan terus mengajukan pertanyaan seperti ini di pertukaran tumpukan. Kesadaran yang akan Anda dapatkan adalah bahwa Anda sebagai pengembang dan rekan tim Anda harus menjadi kekuatan pendorong di belakang komitmen untuk bercerita dan menugaskan tugas. Jika kalian merasa akan mendapat manfaat dari pemrograman berpasangan, tentu saja buatlah 2 tugas untuk masing-masing insinyur dan tetapkan jam keduanya. Satu-satunya hal yang harus dilakukan oleh scrum master adalah mengukur kecepatan terhadap cerita lengkap yang Anda sampaikan SEBAGAI TEAM dalam iterasi sebelumnya.
Juga hal lain yang mengganggu saya adalah bagaimana orang-orang diberitahu bahwa kapasitas mereka SELALU 75% dari total jam, jadi itulah yang mereka komit dan kemudian untuk seluruh durasi iterasi mereka mengeluh bahwa a) mereka tidak bisa membantu Anda atau b) mereka tidak dapat melakukan hal yang benar karena mereka terlalu banyak ditugaskan. Orang tidak boleh diberi tahu berapa jam untuk berkomitmen dan mereka tentu harus mendorong kembali jika scrum master mencoba menarik sesuatu seperti ini! Setiap orang harus berkomitmen untuk apa yang mereka sukai. Misalnya, saya seorang pemimpin tim dan sering kali saya berakhir di diskusi desain acak yang tidak direncanakan, atau membantu seseorang dengan kode, atau memecahkan masalah hal-hal aneh, sehingga kapasitas saya tidak pernah di atas 50%.
Butuh siklus rilis tim 4 kami untuk belajar untuk tidak melakukan hal-hal yang baru saja saya sebutkan dan meskipun kami sudah benar-benar membaik, jika Anda bertanya kepada para ahli, kami bahkan tidak gesit. Jadi masih banyak pembelajaran yang harus dilakukan.
Pembaruan 1: Tanggapan untuk komentar Cliff
Nah Anda menawarkan telinga Anda jadi ini dia ...
Anda benar, perubahan budaya adalah kunci, tetapi perubahan ini tidak perlu terjadi di tingkat eksekutif. Manajer grup Anda sendiri dapat mengubah budaya dalam tim Anda dan mengisolasi kalian dari BS korporat yang harus ia tangani. Apa yang Anda gambarkan adalah PERSIS kami tentang dari 2007 hingga 2010. Tim kami (dan tim lain juga) menjatuhkan rilis setelah rilis. Dalam salah satu rilis menggunakan "proses untuk menjadi gesit" manajemen kami berhasil memiliki 9 orang menghasilkan pekerjaan yang biasanya akan dilakukan oleh satu orang dan kami butuh waktu dua kali lipat. Saya memiliki begitu banyak waktu luang, sehingga saya bahkan memperbarui resume saya.
Kemudian, saya berbicara dengan bos saya dan menjelaskan semua hal ini kepadanya betapa lincahnya orang dan bahwa jika Anda ingin kami peduli dengan produk, mari kita membuat keputusan yang memengaruhi cara kami bekerja dan mengirimkan produk. Saya pikir dia memutuskan untuk menjadikannya percobaan, dia membuat setiap perubahan yang kita ... yah, kebanyakan saya sendiri, tapi saya banyak berbicara dengan tim, karenanya kapasitas 50% :) ... diusulkan. Mungkin saja dia berpikir bahwa jika dia melakukan semua perubahan yang kita minta dan kita masih gagal, dia akan kembali dengan kemenangan "Sudah kubilang".
Jadi dalam 12 bulan terakhir, kami telah menghilangkan begitu banyak "bodoh" itu bahkan tidak lucu. Pertemuan kami sebenarnya masuk akal sekarang karena kami bekerja bersama, bukan sendirian. Kami masih memiliki kepemilikan (setidaknya untuk saat ini) dari bagian-bagian tertentu dari produk, tetapi kami juga sangat sering berpapasan dengan kode masing-masing. Kami terus-menerus melakukan tinjauan kode sehingga tidak hanya anggota tim yang belajar kode lain, tetapi mereka juga belajar teknik pengkodean dan desain yang lebih baik. Kami telah membagi tim monolitik, raksasa "gesit" menjadi 3 tim yang berbeda sehingga perencanaan dan pertemuan lainnya jauh lebih singkat dan orang-orang benar-benar peduli tentang mereka karena mereka tidak duduk dan mendengarkan hal-hal yang tidak mereka pedulikan. SAYA' Saya pernah melihat malam ketika 4 dari 5 orang kami (salah satu tim) akan online pukul 11 malam dan tidak ada yang mengatakan kepada kami bahwa kami harus bekerja keras atau pernah menekan kami untuk bekerja lebih dari 40 jam. Orang yang tidak peduli setengah tahun yang lalu, tiba-tiba terlibat dan bersemangat dengan pekerjaan yang mereka lakukan. Dan yang diperlukan oleh manajer kami hanyalah berkata, "kalian memutuskan apa yang benar dan melakukan apa yang perlu Anda lakukan dan saya akan menjauhkan BS perusahaan dari tim sebanyak yang saya bisa."
Ini dimulai sebagai percobaan (kecurigaan saya, dia tidak pernah mengatakan itu kepada saya), tetapi sekarang grup kami lebih baik dibandingkan dengan kelompok pengembangan lain di departemen dan kami bahkan memiliki pengembang lain yang sekarang mencoba untuk datang dan bergabung dengan kami.
Rintangan terbesar bagi kami sejak perubahan ini terjadi (dan masih menjadi masalah saat ini) adalah kenyataan bahwa para insinyur di lingkungan perusahaan yang normal seperti tikus percobaan dalam sangkar. Bahkan ketika manajer Anda memutuskan untuk benar-benar "gesit" dan menghilangkan kandang, semua orang telah berada di kandang itu begitu lama, mereka bahkan tidak menyadari bahwa mereka bebas. Begitu pun dengan semua kebebasan, mereka terus bertindak seolah-olah mereka masih terkekang. Saya pikir apa yang akan membantu adalah memiliki setidaknya beberapa orang dalam tim (seperti Anda), yang pergi ke luar batas kelompok dan mencari cara yang lebih baik dalam melakukan sesuatu. Kemudian kembali ke kelompok itu dan aduk sedikit.
Dalam kasus Anda, mungkin pemrograman berpasangan bukan solusi jika Anda mencari kekuatan eksternal lain untuk turun ke tim dan memberi tahu mereka cara bekerja. Alih-alih, membuang aturan, duduk bersama mereka, tanpa manajemen, dan bertanya kepada mereka apa yang ingin mereka lakukan? Apa yang akan membuat mereka bahagia? Produktif? Identifikasi masalah terbesar dan tanyakan kepada TEAM apa solusi yang menurut mereka seharusnya.