Saya telah bekerja dengan / dalam / untuk gesit di bidang pengembangan web selama lebih dari 10 tahun. Sebagian besar dari mereka harus berurusan dengan kerangka lincah yang paling populer - scrum ( menurut VersionOne ). Saya ingin berbagi dengan Anda akumulasi observasi dan kesimpulan.
Saya akan mulai dengan metafora, karena kadang-kadang saya harus melihat pengantar scrum dalam skenario ini:
- Sebelum scrum : "berkembang" sebagai bayi - dia memiliki tujuan, tetapi dia tidak tahu bagaimana berjalan dengan normal, tetapi benar-benar ingin belajar untuk mencapai tujuan.
- Pendahuluan : seorang guru datang ( pelatihan scrum, kursus, pelatih gesit, dll. ) Dan menunjukkan cara berjalan. Anak itu senang, dia bergerak dalam langkah! Top-top-top. Kami memiliki sprint - kami pergi!
- Setelah perkenalan : para pemangku kepentingan pasien mengatakan: "Oke, kami melaju ke tujuan," yang mereka dapatkan "jangan mendorong tim, kita pergi!". Pengembangan menulis lintasan yang menarik dan menikmati prosesnya, tetapi tujuannya dilupakan.
- Scrum-no : lanjutkan pil kebenaran dari bisnis, scrum “bermutasi” dan memungkinkan bisnis untuk mendapatkan beberapa jenis produk dari pengembangan. Dan, sayangnya, tanda centang "kami mengerjakan scrum" dicentang secara resmi, tetapi potensi sebenarnya dari tim pengembangan belum terungkap, dan mereka mengatakan "scrum tidak nyata" di sekitar.
Menurut pendapat saya, ini terjadi karena fakta bahwa scrum sering diterapkan "secara mekanis", tanpa menyadari esensi kerangka kerja dan elemen-elemennya. Saya ingin mencoba mengungkapkan gejala "scrum mekanik"; untuk memahami apa kerugian dari pendekatan ini; memahami apa yang bisa lebih baik dengan "scrum nyata dengan gesit"; dan menemukan cara untuk membantu melawan gejala scrum. Saya akan mencurahkan beberapa artikel di sini untuk ini dan saya akan senang dengan komentar dan pertanyaan Anda.
Untuk memulainya, mari kita tentukan apa itu “scrum mekanik”. Dari sudut pandang saya, inilah saat semua peran, peristiwa, dan artefak scrum hadir secara formal, tetapi nilai dan tujuan dilupakan; ketika tidak ada budaya lincah ( yaitu tingkat kesadaran dan penerimaan manifesto dan prinsip lincah yang tinggi ). Ketika tidak ada pemahaman atau bahkan upaya untuk mencari tahu mengapa artefak ini atau itu diperlukan, atau apa tujuan dari peristiwa dalam scrum. Ini seperti robot dalam video yang tahu cara memutar jungkir balik, tetapi siapa yang akan memanggilnya pesenam? Saat menerapkan scrum, penting untuk menyampaikan kepada tim tujuan dan nilai-nilainya, dan bukan hanya mekanika. Budaya gesit memperkuat scrum dan menjadikannya "nyata". Scrum berguna untuk memberikan nilai secara teratur dan menerima umpan balik yang cepat. Scrum adalah tentang kecepatan dan pengembangan produk. Apakah itu terdengar basi secara teori? Mari kita coba mencari cara untuk mengerjakan scrum dan tidak kehilangan budaya scile dan nilai-nilai di sepanjang jalan.
Saat mem- parsing elemen scrum di ScrumGuide, peran adalah salah satu yang pertama diurai , kami akan melakukan hal yang sama. Karena ternyata banyak materi, maka, untuk memberi kesempatan merealisasikannya, ia dibagi menjadi tiga bagian ( Bagian 2 , Bagian 3 ). Mari kita mulai analisis dengan Pemilik Produk.
Pemilik Produk - Pemilik Produk (PO):
Pemilik produk adalah orang yang bertanggung jawab atas produk, ia “memiliki” jaminan produk. Alat utama PO adalah visi pengembangan produk, dan tugas utama adalah memaksimalkan nilai produk yang dihasilkan oleh tim. Segalanya tampak sederhana: "Jika Anda berani, cekatan dan terampil ...", tetapi ada nuansa. Mereka tidak mengajar kita di PO, tetapi mereka mengajar di PM (manajer proyek), dan sering PM menjadi PO, percaya bahwa ini hanya perubahan nama, dan Anda dapat mempertahankan pendekatan lama untuk bekerja. Tapi lincah tidak bekerja seperti itu. Bagaimana itu perlu?
Interaksi antara PO dan produk, Backlog
Gejala : PO tidak bertanggung jawab atas komposisi backlog, hanya bekerja pada cerita yang diterima dari peserta lain dalam proses. Atau PO tidak bertanggung jawab untuk memprioritaskan elemen jaminan simpanan. Pekerjaannya adalah membawa jaminan simpanan ke standar yang diterima oleh tim, dan dia tidak menentukan konten dan prioritas dari apa yang akan dilakukan tim.
Apa yang buruk : Jika PO tidak memiliki keberanian atau kemampuan untuk membuat produk ( membentuk jaminan, memprioritaskan, melakukan percobaan, dll. ), Ini bukan PO, tetapi beberapa jenis aktivitas lainnya. Dan tanpa scrum PO, bukan scrum. Tanpa membentuk Backlog, PO tidak dapat bertanggung jawab atas produk. Jika PO tidak bertanggung jawab atas backlog, maka adopsi keputusan produk memerlukan komunikasi tambahan - ini adalah waktu tambahan yang dihabiskan, yang secara negatif mempengaruhi kecepatan tim.
Cara merawat : Anda perlu memberi PO satu-satunya hak untuk membuat keputusan dan tanggung jawab produk atas komposisi jaminan simpanan. Jika pembuat keputusan adalah pesanan yang mapan, maka sulit untuk mengubah situasi semalam. Ketika PO adalah proxy, maka
- Atau kami menghapusnya dari persamaan dan menjadikan PO benar-benar orang yang bertanggung jawab atas komposisi dan prioritas backlog. Baik tim pengembangan dan Tim Penemuan Produk khusus dapat membantu PO bekerja di backlog, tetapi tanggung jawab untuk komposisi dan kualitas backlog harus tetap berada di tangan hanya satu orang - PO.
- Atau kita secara bertahap belajar / mengizinkan / memaksa kita untuk mengambil tanggung jawab dan membuat keputusan ( komposisi elemen jaminan, prioritas elemen, dll. ) Dari PO saat ini. Iterasi itu penting: mengkonsolidasikan kesuksesan, mendapatkan umpan balik.
Gejala : PO tidak memiliki visi untuk pengembangan produk, tidak memiliki strategi global, tidak ada tujuan kemana membawa produk dan mengapa.
Apa yang buruk : Kekuatan utama PO adalah visi produk, memahami mengapa dan untuk siapa produk itu dibuat. Dengan visi ini, ia dapat memotivasi dan "menginfeksi" orang-orang di sekitarnya. Jika tidak ada visi, kecil kemungkinan produk tersebut akan menjadi perlu dan bagus. Tim tidak akan "dikenai biaya" dengan hasilnya.
Cara merawat : PO, penting untuk terlebih dahulu merumuskan visi produk. Dia harus bisa mengatakan dalam format elevator pitch hal keren apa yang dia lakukan, untuk apa dan untuk siapa. Salah satu nilai gesit adalah transparansi. Dengan memvisualisasikan berbagai artefak pengembangan produk, kami bekerja pada transparansi. PO dapat mengartikulasikan visinya dan mempostingnya di depan tim. Lebih baik jika pekerjaan pada perumusan pitch elevator dan visi dilakukan dengan beberapa frekuensi - seperti acara scrum lainnya ( merencanakan iterasi baru - selesai - mengumpulkan umpan balik ).
Gejala : PO tidak bekerja di luar elemen backlog, tidak membawa mereka ke perjanjian yang diadopsi oleh tim, tidak memperbarui elemen backlog, tidak membersihkannya, tidak melakukan penumpukan backlog .
Apa yang buruk : Jika PO saat ini tidak cukup memperhatikan backlog secara teratur, ia masih harus melakukannya ( sprint perlu dikumpulkan ), tetapi itu akan lebih menegangkan dan mahal ( misalnya: pembersihan kolektif backlog pada perencanaan sprint ). Overhead komunikasi akan diimbangi dari waktu yang dialokasikan untuk pengembangan. PO akan mulai kehilangan kepercayaan tim: ia tidak berinvestasi dalam jaminan - tim tidak akan berinvestasi dalam peningkatan. Backlog yang buruk / tidak relevan mengurangi transparansi untuk semua pihak yang berkepentingan. Dan scrum tanpa transparansi bukanlah scrum.
Cara merawat : Sebelum PO, Anda perlu menyampaikan pentingnya mengerjakan backlog - artikel, buku, pelatihan, dll. Kita perlu mengembangkan aturan / peraturan untuk melakukan Product Backlog Refinement (PBR), sehingga pertemuan ini bermanfaat dan efektif, melakukan mini-retrospektif setelah PBR, dalam beberapa iterasi Anda dapat meningkatkan kualitas acara ini secara kualitatif. Tim perlu meningkatkan mekanisme untuk melakukan PBR, mencapai sinergi maksimum antara PO dan tim pengembangan. Backlog perlu dibersihkan secara teratur. Mendapatkan informasi terbaru, selain menambahkan cerita segar ke dalam simpanan, Anda harus ingat untuk membersihkan cerita yang kehilangan relevansinya. Tumpukan harus berisi unsur-unsur yang dapat dimengerti oleh tim dan dikerjakan ( dalam kerangka kesepakatan tim tertentu ) selama 2-3 sprint; tumpukan yang lebih dalam dapat menyebabkan kehilangan relevansi. Secara umum, jaminan simpanan harus berisi Roadmap setidaknya selama satu tahun, sehingga semua pihak yang berkepentingan merasa bahwa produk tersebut memiliki masa depan. Mempertahankan jaminan simpanan dengan perkiraan kenaikan akan membantu tim berpikir sebelumnya tentang tujuan sprint .
Gejala : PO berfungsi pada beberapa produk yang tidak terkait atau dengan beberapa tim. Sebagai pilihan - selain PO utama, PO juga memainkan peran yang berbeda dalam proses scrum (baik pengembang, atau SM).
Apa yang buruk : Menjadi PO bukanlah pekerjaan yang mudah, membutuhkan pengembalian yang besar. Jika peran PO dikombinasikan dengan kegiatan lain, maka dengan tingkat probabilitas yang tinggi ini akan berdampak buruk pada kualitas hasilnya. PO berpengalaman dan matang dapat secara bersamaan menjalankan beberapa produk dan bekerja dengan beberapa tim jika produk ini "terkait" atau merupakan bagian dari satu produk besar yang fungsinya hampir sama. Kemungkinan besar, hanya orang yang sangat, sangat unik yang secara bersamaan dapat melakukan, katakanlah, editor grafis untuk perangkat seluler dan simulator penerbangan militer. Agar efektif, Anda harus fokus pada satu tujuan sebelum menyulap beberapa.
Bagaimana cara memperlakukan : PO harus secara kritis melihat produk-produknya: seberapa baik visi yang dikembangkan dan diformulasikan? Bagaimana tim memahami dan menerima visi ini? Seberapa berkembang backlog itu? Apakah transparan untuk semua pihak? Apakah ada peta jalan produk, apakah jelas untuk semua orang? Apakah tim mengerti apa yang akan dilakukan 2-3 sprint selanjutnya? Seberapa terkenal pengguna dan pasar? Apa kualitas interaksi dengan tim pengembangan? Jika dalam beberapa masalah ini ada ruang untuk peningkatan kualitas, Anda harus meninggalkan sendiri satu produk dan fokus pada itu.
PO dan interaksi tim
Gejala : Arahan PO mengontrol tim, benar-benar bekerja pada skema PM klasik. PO membuat semua keputusan, bahkan terkecil, tim berlari kepadanya dalam masalah apa pun.
Apa yang buruk : Jika PO terlibat dalam manajemen mikro dalam tim, mengambil bagian aktif dalam pengembangan, maka, di satu sisi, itu mendemotivasi tim dan mencegahnya berkembang ( tidak ada organisasi mandiri, karena tanggung jawab atas keputusan lokal tetap ada pada PO ), di sisi lain, itu buruk untuk produk, karena upaya PO diarahkan dalam proses, dan produk dapat tetap tanpa perhatiannya.
Cara merawat : PO perlu membunuh PM dalam diri Anda, coba pendekatan manajemen non-direktif dan berhenti menganggap orang sebagai sumber daya. Jika skema manajemen direktif dibangun antara PO dan tim pengembangan, perlu melibatkan fasilitator eksternal atau internal yang dapat menyesuaikan interaksi. Batas-batas tanggung jawab antara PO dan tim pengembangan perlu didefinisikan dengan jelas - ini adalah transparansi. Harus ada hubungan saling percaya antara PO dan tim: tim sebagian besar mempercayai PO dan solusi produknya, dan PO mempercayai tim dan keputusan yang diambil tim untuk mengimplementasikan elemen jaminan. Setiap orang memiliki pemahaman bahwa pekerjaan sedang dilakukan untuk satu tujuan. Salah satu alat yang mungkin untuk PO dapat berupa tim "produk", yang mencakup analis. Ketika hipotesis didasarkan pada angka dan data, mereka lebih kredibel. Hal utama untuk PO adalah jangan lupa untuk membagikan data ini dengan tim pengembangan. Jika tim tidak independen, maka PO perlu belajar cara mendelegasikan. Kemudian tim akan dipaksa untuk mengambil keputusan, sebagai hasil dari tanggung jawab, dan lambat laun akan menjadi tim scrum.
Gejala : PO dan tim pengembangan sering konflik, ada konfrontasi yang konstan, tidak ada saling pengertian.
Apa yang buruk : PO dan kru berlayar di kapal yang sama, jika komunikasi yang efektif tidak terjalin di antara mereka, tidak mungkin bahwa kapal seperti itu akan dapat berlayar jauh. Banyak energi akan dihabiskan untuk membangun interaksi, dan bukan pada pengembangan produk. Tujuan PO dan tim adalah sama, yang berarti tidak boleh ada konflik reguler.
Cara merawat : Kami membutuhkan fasilitator berpengalaman yang dapat mengidentifikasi esensi konflik, menghilangkannya dan membangun hubungan kerja. Jika semua upaya tidak mengarah pada saling pengertian, maka mungkin ada baiknya mengubah tandem.
Gejala : PO hampir tidak berkomunikasi dengan tim. Misalnya, ini hanya tersedia sebagai bagian dari pertemuan wajib (perencanaan, sprint review).
Apa yang buruk : Tim menciptakan produk kompleks baru ( Scrum adalah kerangka kerja untuk mengembangkan, memberikan, dan mempertahankan produk kompleks. ), Karena itu ia bekerja dalam kondisi ketidakpastian yang besar. Untuk memberikan nilai maksimum, mereka memerlukan informasi yang dalam kebanyakan kasus hanya memiliki PO ( itu pekerjaannya ). Dengan tidak adanya informasi, asumsi dan keputusan yang salah dapat dibuat, sebagai akibatnya, waktu yang berharga akan hilang pada koreksi mereka.
Cara memutuskan : PO harus tersedia untuk tim, tetapi tim tidak boleh menyalahgunakannya, jika tidak, waktu PO akan dihabiskan hanya untuk pertanyaan sementara. Suatu format interaksi yang nyaman untuk semua orang harus dikerjakan, di mana tim tepat waktu menerima dari PO informasi dan keputusan yang diperlukan yang benar-benar tidak dapat dibuat oleh tim. Anda dapat memanggil retrospektif PO dengan keteraturan tertentu dan membahas masalah frekuensi, alat, dan format komunikasi di sana.
Gejala : PO tidak menanamkan atau mempromosikan budaya umpan balik tim. Atau PO memberikan umpan balik satu arah dengan menyaring pujian atau kritik.
Mengapa itu buruk : Ketika PO tidak memberikan umpan balik jujur yang teratur kepada tim, ini menurunkan semangat tim. Tidak ada sinkronisasi harapan dan hasil. Tim tidak merasakan keterlibatan, mereka sebenarnya bukan pencipta produk, mereka hanya menjalankan fungsinya. “Tim secara teratur memasok selisih. Tim secara teratur menerima umpan balik yang jujur tentang pekerjaan mereka ”- tampaknya ini adalah kesepakatan yang adil.
Cara merawat : PO, tentu saja, tidak boleh membebani tim dengan semua jumlah informasi yang ia gunakan sendiri, semua yang ia terima dari pengguna dan analis. Dia harus mengumpulkan dan mengeluarkan informasi yang sudah penting dan dapat dimengerti oleh tim. Adalah baik untuk menghasilkan format yang berbeda untuk umpan balik, dan tidak hanya berdasarkan angka kering ( misalnya: pengujian langsung, wawancara, dll .). Tim itu sendiri harus mengingatkan PO tentang perlunya umpan balik: ajukan pertanyaan, bangun proses reguler untuk menerima umpan balik. Jika Anda menjadikan PO sebagai "pemilik" dari acara ulasan sprint dan mengacaukannya dengan fakta bahwa tim membutuhkan umpan balik, setidaknya PO akan mengingatkan PO tentang pekerjaan pada umpan balik, dan dapat mengarah pada pendekatan yang lebih kreatif untuk mengatur umpan balik tersebut.
Interaksi antara PO dan pengguna pasar
Gejala : PO tidak tahu pengguna "nya"; produk melihat serangkaian fitur. PO mengabaikan permintaan dan informasi pengguna dari pengguna yang ada. Tidak berkomunikasi dengan pengguna langsung.
Mengapa itu buruk : Pertama-tama, produk dibuat untuk pengguna yang ( mungkin dia belum tahu ) kebutuhan yang dipenuhi oleh produk. Dan jika Anda tidak tahu dan memahami pengguna, maka tidak mungkin untuk "memikul tanggung jawab untuk mencapai nilai maksimum produk", seperti yang disyaratkan oleh panduan scrum.
Cara merawat : Ada banyak alat yang berbeda untuk melakukan penelitian kualitatif, misalnya, wawancara mendalam, potret pengguna, peta perjalanan pelanggan , alat untuk mengumpulkan analisis kualitatif (vs kuantitatif) , dll. dll. Anda perlu mencoba berbagai alat dan membiarkannya berguna / berfungsi untuk produk Anda. Sebagian besar alat ini pada output memiliki visualisasi hasil, ada baiknya menempatkan mereka di depan tim untuk meningkatkan transparansi. Artefak ini layak diperbarui dari waktu ke waktu. Anda dapat mengatur tim penemuan produk untuk membantu Anda melakukan penelitian yang berkualitas. Jika PO mengatur interaksi dengan pengguna, maka ia dapat menggunakan kontak ini, misalnya, pada ulasan sprint: memberi pengguna selisih baru, dan tim akan memeriksa bagaimana pengguna akan mengatasi tugas, bantuan dalam penyelesaian yang mereka berikan dalam selisih.
Gejala : PO tidak mempelajari pasar / pesaing.
Apa yang buruk : Produk hidup seolah-olah dalam ruang hampa, dan terpisah dari kenyataan, Anda harus menjadi visioner untuk menciptakan produk yang berharga dalam kondisi seperti itu.
Cara merawat : Ada sejumlah praktik untuk pemilik produk, cara belajar dan menciptakan pasar, ada baiknya mencoba berbagai dari mereka dan meninggalkan yang bermanfaat. Dalam kegiatan ini, PO dapat dibantu oleh analis atau tim. Sangat berguna untuk mencari " samudra biru " dari waktu ke waktu. Dan tentu saja, Anda harus mengambil inspirasi dari pelatihan, pertemuan makanan, dan konferensi.
Kesimpulan
Analisis peran yang tersisa akan muncul di bagian berikut. Sekarang mari kita lihat bagaimana informasi ini dapat bermanfaat bagi Anda. Kami memeriksa beberapa gejala yang mungkin terjadi, mengatakan bahwa ada yang tidak beres dalam scrum, dan opsi untuk mengubah situasi. Jika Anda mau, daftar di akhir:
- Membaca hampir setiap item, Anda mengenali diri sendiri ( tim / organisasi Anda ), yaitu Anda memiliki scrum dengan pemahaman non-kanonik. Maka ada baiknya mengajukan pertanyaan: apakah Anda perlu scrum sama sekali? Mengapa Anda membutuhkan scrum? Tugas apa yang Anda tetapkan untuknya? Apakah budaya perusahaan siap untuk nilai dan prinsip yang gesit? Jika Anda memiliki jawaban dan memahami mengapa scrum diperlukan, dan Anda benar-benar bertaruh, lanjutkan ke opsi kedua. Jika tidak, maka berhentilah berlatih penipuan diri sendiri.
- Membaca beberapa poin yang Anda pikir bukan tentang Anda. Beberapa poin mendorong Anda untuk berpikir dan mengingat situasi Anda. , , . . : ? , , , , . , , . , ? , , . ! , , , , .
- , . ? , , !
PS , scrum .
PPS Sai Kin
UPD. 2 3 .