Ini benar-benar hanya dump otak pribadi tentang topik scrum di organisasi besar.
Scrum penting, terutama dalam konteks perusahaan besar yang paling berpengalaman dengan saya, karena tiga alasan:
Melindungi “pembuat” di dunia “manajer” Menyusun percakapan seputar penetapan prioritasMenumbuhkan budaya pengambilan keputusan pada “tingkat” yang sesuai (man, saya benci kata ini)
Saya tahu, saya tahu itu bukan tiga alasan masuk Anda mengapa Anda menggunakan scrum, kemungkinan besar sesuatu di sepanjang baris: waktu-ke-pasar, kemampuan beradaptasi (jika Anda beruntung, Anda bahkan mungkin harus berurusan dengan VUCA dunia), umpan balik pelanggan, perangkat lunak yang berfungsi di atas konsep, dll., Dll, dll. yang semuanya benar. Tapi sebenarnya, saya pikir ada sesuatu yang lebih mendasar di tempat kerja, ketika berbicara tentang scrum di perusahaan besar, sesuatu yang melampaui perangkat lunak, produk dan langsung masuk ke topik budaya & pola pikir.
Jadwal pembuat dan manajer
Ini secara langsung terinspirasi dari posting hebat oleh Paul Graham, yang disebut jadwal Maker, jadwal Manajer. Ide umumnya adalah bahwa ada dua jenis utama jadwal (atau unit penghitungan waktu) dan itu berbeda karena sifat pekerjaan yang perlu dilakukan di dalamnya.
Ada manajer – Paul Graham menyebutnya “bos”, tetapi di banyak organisasi lebih banyak orang daripada hanya “bos” yang bekerja pada jadwal ini, mungkin siapa pun dalam fungsi koordinasi – yang dihitung dalam satuan satu jam. Pada dasarnya orang-orang dalam jadwal ini berpikir dalam satuan waktu yang kecil: mereka akan menghabiskan 15 menit untuk menjawab email ini, 30 menit berbicara dengan rekan ini untuk mendapatkan jawaban, mungkin menghabiskan 45 menit untuk presentasi powerpoint. Bahkan ada beberapa rekan yang saya kenal, yang menghitung dalam 5 menit blok.
Lalu ada jadwal Marker, yang berlawanan memiliki blok yang jauh lebih besar, misalnya setengah hari. Ini adalah waktu yang dibutuhkan untuk mengerjakan sepotong kode untuk pengembang atau untuk adegan untuk penulis misalnya. Saya juga melihat ini sebagai tugas tunggal di mana seseorang harus mengikuti arus untuk mendapatkan efisiensi dan hasil terbaik.
Sekarang masalah benar-benar muncul ketika dua jadwal ini bentrok: apa yang mungkin hanya slot 5 menit dalam satu jadwal, sebenarnya mengganggu blok setengah hari untuk jadwal lainnya. Dan ini sekali lagi adalah sesuatu yang coba ditangani secara aktif oleh pendekatan scrum. Ada satu hari diblokir untuk acara yang diperlukan antara sprint & check-in harian yang ada di awal atau di akhir “Jadwal Pembuat” sehingga pengembang paling tidak terganggu dan memiliki cukup waktu untuk masuk ke aliran.
Saya baru saja menyentuh secara dangkal tentang artikel ini, tetapi ini telah menjadi inspirasi besar untuk cara saya bekerja dengan Tim Pengembang saya (saya adalah pemilik produk) dan saya biasanya mencoba memberikan artikel ini kepada tim baru mana pun dalam fase badai, jadi bahwa terutama pemangku kepentingan yang bekerja terutama pada jadwal Manajer memahami dampak dari “hanya meminta pengembang untuk melakukan perubahan kecil ini”. Dan saya pikir ini adalah sesuatu yang dilakukan scrum dengan sangat baik di organisasi atau perusahaan yang lebih besar: ini menciptakan kesadaran tentang sifat pekerjaan yang berbeda tetapi juga memastikan (jika Anda mengikuti pedoman) bahwa tim scrum terlindung dalam sprint dari aliran dan jadwal terganggu.
Menyusun percakapan seputar penetapan prioritas
Argumen ini mungkin tersebar lebih luas tetapi kemungkinan Anda telah menemukan percakapan berikut:
” – Jadi kita perlu memiliki fungsionalitas A dan fungsionalitas B untuk sprint berikutnya, semua pemangku kepentingan menyetujui hal ini.
– Oke, tapi kami telah memperkirakan kedua cerita pengguna (mungkin menggunakan scrumpoker-online.org ;-)) dan kemungkinan besar kami tidak akan dapat melakukan keduanya, jadi mana yang lebih penting.
– Tidak, Anda sepertinya tidak mengerti saya, kita perlu melakukan keduanya.
– Tidak, saya setuju, tetapi sumber dayanya sedemikian rupa sehingga kami tidak dapat melakukan keduanya, jadi mana yang kami kerjakan terlebih dahulu?”
Setuju, ini cukup stereotip, tetapi saya telah melakukan percakapan ini cukup sering untuk mengatakan bahwa fokus dari daftar prioritas yang diurutkan dalam scrum (backlog) bernilai emas dalam organisasi yang ingin melakukan semua hal, di mana semuanya adalah prioritas utama. Ini memaksa setiap orang untuk membuat salah satu atau diskusi (setidaknya untuk tugas berikutnya yang sedang dikerjakan) dan sementara jika Anda adalah pemilik produk yang diberdayakan, Anda dapat membuat keputusan itu sendiri, keputusan itu juga diajukan dan dikomunikasikan dengan jelas kepada para pemangku kepentingan . Jadi backlog adalah cara terstruktur untuk mengerjakan tugas-tugas terpenting bagi tim pengembangan tetapi juga merupakan alat yang hebat untuk mengkomunikasikan nilai ke seluruh origaniasi. Ini juga merupakan perubahan pola pikir yang positif bagi organisasi besar: pastikan bahwa kita bekerja pada apa yang memberikan nilai paling besar dan membawa transparansi yang memungkinkan percakapan seputar hal ini.
Membina budaya pengambilan keputusan pada “tingkat” yang sesuai
Banyak perusahaan saat ini bercita-cita untuk meratakan struktur hierarkis, sambil memastikan bahwa kepemimpinan bukanlah hambatan untuk pengambilan keputusan – seringkali solusi untuk ini adalah dengan menetapkan inisiatif yang meningkatkan pengambilan keputusan pada “tingkat” yang tepat, untuk menginspirasi karyawan untuk mengambil alih kepemimpinan. topik mereka sendiri. Scrum juga memberikan kerangka untuk melakukan ini, dengan memberikan definisi peran yang jelas dan termasuk elemen pengambilan keputusan dan tanggung jawab.
Secara sederhana, pemilik produk bertanggung jawab (dan membuat keputusan) tentang “apa”, jadi fungsi apa yang harus dan harus dikerjakan. Tentu saja keputusan ini tidak dibuat secara sepihak tetapi dengan mempertimbangkan masukan dari pengguna, pemangku kepentingan, dan tim pengembang – tetapi pada akhirnya PO mengatakan: “fungsi B sebelum fungsi A”. Tetapi ketika kita berbicara tentang “bagaimana”, pemilik produk tidak lagi bertanggung jawab tetapi tim pengembang melakukannya dan mereka dapat mempertimbangkan masukan dari pemilik produk (jika dia berpengalaman secara teknis) tetapi keputusan akhir ada di tangan tim pengembang.
Scrum dengan partisi ulang peran, didukung oleh acara terstruktur, memberikan kerangka kerja untuk memastikan bahwa keputusan dibuat oleh orang-orang di “tingkat” yang tepat . Mungkin melangkah lebih jauh dari scrum itu menghilangkan gagasan bahwa ada “tingkat” untuk pengambilan keputusan! Keputusan tentang solusi apa yang harus diterapkan akan dipisahkan menjadi bagian-bagian yang lebih kecil (misalnya “apa” dan “bagaimana”) dan dengan demikian memungkinkan keputusan dibuat oleh orang-orang yang paling siap untuk membuat keputusan itu. Tidak perlu percakapan tentang “tingkat” tetapi hanya percakapan tentang bidang keahlian dan tanggung jawab, sesuatu yang dapat membantu perusahaan mencapai tujuan yang tampaknya mereka tuju.
Ketika saya menyelesaikan posting ini, saya menyadari bahwa saya telah melakukan sedikit kata-kata kasar pribadi – tetapi saya akan tertarik dengan pendapat Anda tentang beberapa ide yang telah saya lemparkan.
Seperti ini:
Seperti Memuat…
Recent Comments