Pada bagian pertama, kami melihat gejala yang mengkhawatirkan dan kemungkinan cara untuk "memperlakukan" Pemilik Produk dalam scrum "mekanis". Kami melanjutkan analisis peran dan yang berikutnya adalah tim.
Namun demikian, mereka tahu mantra bahwa tim harus mengatur diri sendiri dan lintas fungsional, sepertinya bagian paling sederhana dari scrum: kami membawa orang dengan kompetensi yang tepat, memberi tahu mereka: "Anda adalah tim", dan terbang! Namun dalam kenyataannya, semuanya agak lebih rumit.
Pengorganisasian diri
Gejala : Ada hierarki eksplisit (pengajuan direktif) di luar, atau lebih buruk di dalam tim. Yaitu pada kenyataannya, pengembang produk mungkin memiliki tugas yang tidak terkait langsung dengan kegiatan tim. Atau, di dalam tim, orang tidak bebas memilih pekerjaan untuk mencapai tujuan sprint, tetapi menerima tugas dari "pemimpin".
Apa yang buruk :
Batas apa pun - batas @ CEP
Ketika seseorang diperas oleh deskripsi pekerjaan, hierarki penyerahan, dll., Hal ini mencegahnya untuk tidak diungkapkan. Kekuatan tim scrum adalah membuka peluang bagi orang-orang. Ada tugas, berani dan bertanggung jawab atas implementasinya. Seseorang harus memutuskan sendiri apa yang akan dia lakukan untuk mencapai tujuan sprint. Jika mereka mengatakan kepadanya apa yang harus dilakukan, maka ini bukan pengaturan diri sendiri dan bukan scrum.
Cara memperlakukan : Untuk orang-orang di tim, semua uraian pekerjaan dan hierarki dibatalkan, strukturnya cenderung datar.
Semua yang ada di tim adalah
pengembang produk (
panduan scrum tidak mengizinkan peran lain ). Hanya ada kepemimpinan situasional, dan orang-orang memutuskan seberapa nyaman mereka bekerja agar efektif. Tentu saja, ada aturan umum permainan di perusahaan, tim tidak melanggarnya dengan cara apa pun (
meskipun hal itu dapat memengaruhi perubahan di tingkat perusahaan ), tetapi bertanggung jawab atas semua hal internal. Jika ada hambatan serius untuk mencabut pembatasan bagi pengembang, maka ada baiknya meningkatkan masalah ini kepada mereka yang telah memutuskan untuk mengimplementasikan transformasi scrum dan gesit. Anda dapat mencoba menjalankan struktur datar, seperti percobaan untuk beberapa sprint, dan kemudian melakukan retrospektif yang luas, di mana semua pihak yang berkepentingan mendiskusikan hasil percobaan.
Gejala : Orang, selain bekerja sebagai tim, harus melakukan tugas fungsional lainnya di perusahaan. Misalnya: 50% dari waktu melakukan tugas-tugas tim, 50% - tugas-tugas departemen (pengembangan, pengujian, dll.).
Dari buruk : Salah satu nilai dalam scrum adalah fokus. Tim fokus pada tujuan sprint dan bergerak ke arah itu. Jika, selain bekerja dalam tim, seseorang harus melakukan sesuatu yang lain, maka fokusnya hilang. Akibatnya, hasilnya akan lebih buruk. Sulit untuk mempertahankan semangat tim dalam kondisi seperti itu.
Cara memperlakukan : Kita perlu memastikan bahwa orang-orang di tim HANYA bekerja di tim ini. Untuk melakukan ini, ada baiknya memahami sifat pekerjaan yang jatuh pada pengembang tim dari luar, dan menemukan cara untuk melakukannya tanpa melanggar scrum. Tentunya pekerjaan ini diperlukan untuk perusahaan, oleh karena itu, tergantung pada spesifikasi pekerjaan, Anda dapat:
- baik menempatkan pekerjaan di tumpukan tim, dan kemudian akan dilakukan sesuai dengan alur kerja tunggal.
- atau mentransfernya ke karyawan lain di luar tim. Misalnya: tidak semua perusahaan mengerjakan scrum, dan Anda perlu melakukan beberapa pekerjaan reguler pada waktu tertentu, maka pekerjaan seperti itu tidak lagi cocok untuk karyawan scrum.
- atau tim khusus dapat dibuat dan produk yang dipilih akan mengumpulkan semua karya jenis ini.
- atau, jika itu adalah fungsi unik yang dilakukan oleh satu orang untuk beberapa tim karena kurangnya spesialis. Maka ada baiknya mengeluarkan orang tersebut dari semua tim dan membangun proses lain untuknya yang tidak memecahkan sisa scrum ( misalnya: antrian tugas yang diprioritaskan ), sampai spesialis dalam tim scrum ini ditemukan.
Fungsionalitas silang
Gejala : Orang-orang dalam tim hanya melakukan pekerjaan tertentu, ada spesialisasi yang jelas. Lebih buruk lagi ketika masih diliputi oleh tugas resmi, peraturan dan birokrasi lainnya. Tidak adanya (liburan, cuti sakit, dll.) Dari salah satu anggota tim mengurangi fungsionalitas tim. Hai, faktor bus .
Apa yang buruk : Jika sebuah tim bergantung pada kompetensi salah satu anggotanya, itu adalah tim yang tidak stabil terhadap perubahan. Sulit untuk membangun komunikasi dengannya, karena Anda perlu memahami fungsinya saat ini dan mengingat risiko yang terkait dengan tingkat toleransi kesalahan ini. Spesialisasi sempit pengembang sangat menyulitkan pekerjaan organisasi untuk tim: ketika merencanakan, Anda perlu banyak berpikir tentang siapa yang akan melakukan apa; tidak setiap tugas membutuhkan proporsi kompetensi tim yang telah ditentukan, oleh karena itu sulit untuk mengumpulkan sprint yang seimbang; dalam skema semacam itu, "leher sempit" perlu muncul, mengurangi kecepatan keseluruhan tim.
Apa yang harus dilakukan : Penting untuk mempromosikan dan mendukung keterampilan berbentuk t . Agar tim fleksibel, penting agar fungsi atau pengetahuan tertentu tidak terkonsentrasi pada satu orang. Hal ini diperlukan untuk merangsang dan mendorong pengembangan berkelanjutan. Penting untuk memastikan bahwa tim meningkat, mencari cara untuk meningkatkan proses. Sebagai opsi pengembangan berbentuk-t: mengadakan seminar internal, di mana anggota tim berbagi pengetahuan satu sama lain; mengadopsi aturan pelaksanaan tugas non-inti setiap sprint oleh setiap anggota tim; pasangan mengerjakan tugas, dll. Anda dapat merangsang tim secara artifisial dengan "mematikan" anggotanya untuk sementara waktu: liburan, seminar, pelatihan, perjalanan bisnis, dll.
Gejala : Dalam rantai nilai, tim bertanggung jawab (memengaruhi) hanya sebagian kecil saja, dan sebagai hasilnya, tim tidak dapat mengeluarkan kenaikan sendiri.
Dari buruk : Jika tim memiliki sedikit efek pada pengiriman kenaikan ( rilis produk ), maka scrum juga kehilangan esensinya: rilis terjadi dengan penundaan, umpan balik terjadi dengan penundaan yang lebih besar. Secara umum, tidak ada ritme, dan karenanya kecepatan. Tanpa kecepatan - tanpa fleksibilitas. Tim seperti itu tidak merasakan kepemilikannya, itu hanya sekrup fungsional di mobil besar. Fungsionalitas tim harus cukup untuk menutup sebagian besar rantai nilai, jika tidak tim tidak akan memberikan nilai, tetapi hanya akan memproses satu jenis "benda kerja" menjadi yang lain dan mentransfernya lebih lanjut.
Kami menggambarkan ini dengan contoh dari web. Jika disederhanakan pembuatan fitur baru mencakup langkah-langkah berikut:
- Pengembangan prototipe UI / UX
- pengembangan desain
- membuat API TENANG
- Pembuatan SPA
- menulis tes integrasi
- perakitan dan casting di lingkungan tempur
Untuk pekerjaan ini, berbagai kompetensi diperlukan. Contoh dari divisi yang gagal ke dalam tim: untuk memisahkan
tim A dari UI / UX, desainer dan pengembangan frontend, mereka mempersiapkan kenaikan mereka dalam bentuk SPA; tetapi mereka bergantung pada kapan backend akan menyiapkan API agar fungsionalitas baru berfungsi; tunggu QA memeriksa semuanya secara integral dan menulis tes; dan kemudian mereka masih mengharapkan DevOps untuk menggulung semuanya ke dalam pertempuran. Sulit bagi
tim A seperti itu untuk bertanggung jawab atas pelepasan dan pengiriman nilai, itu hanya memotong "kosong" - SPA.
Cara memperlakukan : Kami menentukan kompetensi apa yang kurang dimiliki tim untuk menghasilkan peningkatan. Kami memberi tim kompetensi dengan melatih anggota tim yang ada, atau dengan menambahkan pemain baru ke tim. Karena menemukan / mengajar orang bukanlah tugas termudah dan tercepat, maka Anda dapat menjalin komunikasi dengan tim / departemen tetangga, menjelaskan nilai scrum kepada mereka dan menyetujui dengan mereka tentang aturan / aturan interaksi khusus di mana mereka tidak akan membagi scrum ke tim Anda. Penting untuk menyoroti proses memperluas fungsi tim: setelah retrospektif pertama dan mengidentifikasi kompetensi yang hilang, Anda dapat mencetaknya dan menempatkannya di depan tim. Ketika sebuah tim mengatasi kekurangan kompetensi (
dipelajari; anggota baru tim; mengatur komunikasi yang efektif dengan tim lain, dll. ), Maka kami menggantungkan solusi di atas kompetensi yang sebelumnya tidak ada. Seiring waktu, tim harus berusaha memperluas fungsionalitasnya untuk sepenuhnya mencakup rantai nilai.
Tim dan produk
Gejala : Ada tim, tetapi tidak ada produk. Tidak ada PO, tidak ada jaminan. Hanya saja orang melakukan tugas yang datang dari arah yang berbeda.
Dari buruk : Ini bukan scrum. Ketika suatu produk tidak ditugaskan ke tim, tim tidak mungkin untuk "membakar" dengan pekerjaan. Ketika ada tujuan global ( visi / strategi / roadmap pengembangan produk ), Anda ingin menuju ke sana. Anda melakukan pekerjaan, mendapatkan umpan balik, merenung, dan mengambil langkah berikutnya. Tanpa rasa kepemilikan, Anda berisiko berada dalam rutinitas: Anda tidak benar-benar membutuhkan umpan balik, tim menjadi hanya alat untuk memproses TK menjadi fungsionalitas.
Cara merawat : Tim harus memiliki produk sendiri dengan jaminan dan PO, yang dapat memicu tim dengan produk tersebut dan membawanya bersamaan dengannya - itulah intinya. Perlu mengerti mengapa Anda membutuhkan scrum? Memahami dari mana tim berasal? Memahami jika ada "produk" di antara aliran ini? Pilih satu di antara tim "pelanggan" dan jadikan pemilik produk , berikan hak tunggal untuk menjawab backlog. Mungkin perlu untuk membagi tim menjadi tim scrum bekerja dengan satu PO ( ini bisa menjadi tim scrum "pilot" ) dan tim kedua, sementara bekerja dengan cara yang sama dengan sisa "pelanggan". Memberikan transparansi maksimum dari proses dan hasil yang terjadi dalam tim scrum baru, Anda dapat meletakkan dasar untuk distribusi scrum dan gesit lebih lanjut dalam organisasi.
Gejala : Tim tidak memiliki pengaruh pada komponen produk: tidak memutuskan, "bagaimana melakukan?", Tim hanya mengatakan "apa yang harus dilakukan?" TK datang ke input, dan tim dianggap sebagai unit fungsional.
Dari buruk : Ini adalah pilihan yang sangat berbahaya jika perusahaan benar-benar menyatakan nilai-nilai lincah dan scrum. Biasanya ini menyiratkan bahwa semua karyawan adalah profesional keren yang dapat memecahkan masalah yang tidak takut untuk mengambil keputusan dan bertanggung jawab. Tetapi jika mereka tidak diizinkan untuk membuat keputusan produk, maka semua kebebasan kreatif tim biasanya menyebar dari produk ke teknologi. Karena tim tidak diizinkan untuk memutuskan bagaimana membuat hidup pengguna lebih mudah, dunia menjadi lebih baik dan produk lebih berguna; kemudian tim mulai mengembangkan basis kode, mencoba teknologi / alat / kerangka kerja baru, dll. Ada konflik kepentingan antara PO dan tim, tim mulai menjual "refactoring", "optimisasi", "peluru perak" dalam bentuk tumpukan baru, dll. Dan ini terutama dipengaruhi oleh pengguna dan produk. Dalam proses beralih dari model manajemen direktif ke gesit, ada bahaya terjebak dalam memahami tim sebagai unit fungsional ( tim belum membuat keputusan sebelumnya ). Ini penuh dengan fakta bahwa kita membunuh inisiatif tim, atau kita sampai pada situasi di mana tim lebih tertarik pada teknologi daripada produk.
Cara merawat : Anda perlu mengidentifikasi penyebab ketidakpercayaan tim atau keraguannya: mengapa tim tidak mencari solusi, tetapi hanya bekerja dengan tugas teknis yang terperinci? Setelah menemukan penyebabnya, Anda bisa menghilangkannya secara bertahap. Sebagai contoh:
- Tim tidak memiliki kompetensi atau pengalaman. : Seseorang sedang mengerjakan solusi dan menulis TK, Anda bisa menambahkan orang ini ke tim, atau membiarkannya mengerjakan beberapa tugas bersama-sama dengan tim, dengan demikian mentransfer sebagian dari keahlian dan pengalamannya ke tim. Jadi lambat laun tim akan belajar dan terbiasa memecahkan masalah produk.
- Manajemen memiliki ketakutan bahwa tim akan melakukan kesalahan. : Ini adalah ketakutan utama dalam transisi menuju gesit, tetapi tanpa mengatasinya, Anda tidak akan bisa mendapatkan kekuatan penuh dari tim scrum. Tim terikat untuk membuat kesalahan, karena semua orang salah. Tetapi kesalahan adalah sumber pengalaman dan keterampilan. Lebih bermanfaat ketika tim membuat kesalahan, karena diputuskan demikian, dan bukan karena TK eksternal yang salah. Scrum adalah ritme: cepat membuat keputusan untuk menguji hipotesis; Menerima umpan balik menyadari bahwa mereka salah jalan; membuang keputusan itu. Biaya kesalahan berkurang tajam ( menghabiskan sprint, bukan seperempat / tahun / periode rilis Anda ), yang memungkinkan Anda untuk melangkahi ketakutan akan kesalahan.
Gejala : Anggota tim tidak memiliki akses gratis ke artefak tim. Misalnya, tidak semua orang melihat sprint atau backlog umum, atau ada kesulitan dengan kemungkinan memperbarui statusnya.
Apa yang buruk : Scrum didasarkan pada transparansi, artefak membantu meningkatkan transparansi. Jika anggota tim mengalami kesulitan bekerja dengan artefak ini, maka anggota tim sendiri tidak memiliki transparansi dalam kerja tim, dan bagi pihak berkepentingan lainnya situasinya akan lebih buruk: tidak jelas siapa yang melakukan apa dan mengapa. Tidak jelas di mana tim sedang menuju tujuan.
Cara merawat : Penting untuk menentukan format artefak scrum dalam tim dan membuatnya ( Anda dapat mencurahkan retrospektif ini ), dan kemudian menempatkannya sehingga tim merasa nyaman bekerja dengan mereka. Sangat bagus jika Anda dapat membuat ruang terpisah untuk tim, kondisi di mana tim akan bekerja berdampingan (bahu-membahu) pada saat yang sama. Ini akan mengurangi overhead komunikasi. Dan di ruang umum mudah untuk memvisualisasikan segalanya ( flipchart, stiker, spidol adalah alat favorit lincah ), hal utama adalah nyaman, tidak membuat stres bagi tim. Artefak harus membantu, dan tidak mengganggu pekerjaan tim, bukan birokratisasi. Interaksi verbal baik untuk kerja tim. Jika ada kesulitan dengan organisasi pekerjaan lokal tim ( misalnya, didistribusikan atau jarak jauh ), maka Anda perlu memaksimalkan efek kerja tim dan persatuan. Misalnya, saluran kehadiran video, papan scrum interaktif dalam pandangan langsung dari setiap anggota tim, dll.
Kesimpulan
Pada bagian selanjutnya, kami terus mempertimbangkan peran scrum, dan akhirnya sampai ke master scrum. Secara singkat mengingatkan Anda apa yang harus dilakukan dengan gejala:
- Pilih gejala yang sesuai dengan situasi Anda.
- Dari jumlah tersebut, pilih yang paling tajam.
- Sadarilah rasa sakit ini.
- Anda datang dengan solusi tim ( Anda dapat mengambil kasus dari artikel sebagai titik awal ).
- Laksanakan keputusan Anda.
- Lanjutkan ke langkah 1.
Terima kasih telah membaca, saya ingin melihat "gejala" yang Anda ketahui di komentar.
Terima kasih kepada Sai Kin untuk ilustrasinya.
Bagian selanjutnya tentang Scrum Wizard