Bisakah scrum master mengalokasikan tugas?


19

Kami mengikuti scrum dalam proyek kami. Saya melihat sebagian besar kali scrum master mengalokasikan tugas untuk kita. Namun, saya membaca dari banyak buku scrum bahwa scrum bekerja sebaliknya (pendekatan 'tarikan') dan anggota tim mengambil tugas atau fitur. Apakah scrum master menugaskan tugas pendekatan yang benar atau apakah itu bertentangan dengan ideologi tangkas?


4
Anda mengajukan pertanyaan dengan cara yang menurut Anda ada cara yang benar untuk mengimplementasikan scrum. Ini bukan bagaimana Anda harus melihatnya. Scrum adalah kerangka dasar dengan beberapa pedoman yang sangat umum. Tetapi setiap tim dan setiap proyek harus menyesuaikan pedoman agar sesuai dengan kebutuhan saat ini. Tanpa lebih banyak detail tentang tim Anda, mustahil untuk memberikan saran khusus.
Martin York

+1 Martin - Tepat. Ini sebuah kerangka kerja. Tidak perlu dogmatis atau murni dalam pendekatan Anda.
Agile Scout

4
@ Scout: Seorang ScrumMaster yang bertindak sebagai manajer proyek perintah-dan-kontrol bukanlah Scrum atau gesit.
Martin Wickman

@MartinWickman - Dia belum menyebutkan bahwa tim merasa mereka "diperintahkan". Mungkin mereka telah melepaskan tanggung jawab ini dan memilih untuk fokus pada penulisan kode alih-alih memilih pekerjaan. "Jika kamu memilih untuk tidak memutuskan, kamu masih telah membuat pilihan." Peart
JeffO

Jawaban:


19

Menurut Artikel Wikipedia tentang Scrum , tugas Sprint tidak ditugaskan oleh ScrumMaster:

Tugas pada sprint backlog tidak pernah ditugaskan; melainkan, tugas-tugas didaftarkan oleh anggota tim sesuai kebutuhan, sesuai dengan prioritas yang ditetapkan dan keterampilan anggota tim. Ini mempromosikan pengaturan diri tim, dan dukungan pengembang.

Lebih jauh, definisi ScrumMaster adalah bahwa dia adalah orang yang bertanggung jawab untuk memastikan orang mengikuti aturan proses Scrum.

ScrumMaster Orang yang bertanggung jawab untuk proses Scrum, memastikan itu digunakan dengan benar dan memaksimalkan manfaatnya.

ScrumMaster tidak menetapkan tugas, sederhana dan sederhana. Tim mengatur diri sendiri, dan keputusan siapa yang mengerjakan apa yang diputuskan oleh tim.

Ini benar Scrum. Namun, banyak organisasi mungkin menggunakan variasi ini.


Iya. PO memprioritaskan. Perkiraan anggota tim dan pilih. Sederhana dan kuat.
Martin Wickman

8

Begitulah seharusnya bekerja, tetapi seperti semua hal yang bekerja dengan baik dalam teori ... itu tidak selalu benar-benar bekerja.

Ada dependensi, keinginan pelanggan, dan driver dari luar. Beberapa hal harus diselesaikan sebelum Anda dapat mengerjakan widget mewah yang ingin dikerjakan semua orang.

Ada kemampuan pengembang dasar mengemudi dari dalam. Beberapa hal hanya sulit dan beberapa orang lebih baik. Tentu, ketika bekerja dalam timeline tak terbatas saya hanya bisa membiarkan Anda mengetahuinya; tetapi ketika sesuatu harus dikerjakan maka menugaskan orang yang paling tepat untuk menyelesaikannya dan yang terbaik adalah yang mendapatkan pekerjaan itu.

Dan kemudian ada masalah kepribadian seperti Scrum Master yang terlalu mengontrol dan / atau pengembang yang tidak dapat mengikat sepatu mereka sendiri tanpa diminta. Tim saya, misalnya, memiliki keduanya. Cukup bekerja lebih baik bagi semua orang untuk mengabaikan fakta kecil tentang Scrum ini dalam kasus-kasus seperti itu.

Dengan kata lain, jangan hanya melakukannya karena proses mengatakan demikian. Lakukan apa yang berhasil. Persetan sisanya.

Tentu saja, kemudian ada juga fakta dasar lain dari keberadaan manusia .... mungkin Anda bahkan tidak tahu siapa Scrum Master sebenarnya. Mungkin bukan orang dengan gelar itu. Mungkin Anda bahkan tidak memilikinya.


"Beberapa hal harus diselesaikan sebelum kamu bisa mengerjakan widget mewah yang semua orang ingin kerjakan." Jika ini sesekali, tentu saja. Jika tidak, mungkin Anda harus menggunakan sprint yang lebih pendek - atau mungkin Scrum bukan pendekatan yang tepat untuk tim Anda.
Robin Green

4

Tidak pernah.

Scrum sangat jelas dalam hal ini. Tim Pengembangan, sebagai kelompok, bertanggung jawab untuk menyelesaikan item dalam tumpukan Sprint. Mereka juga sepenuhnya mengendalikan bagaimana cara mereka menyelesaikan pembangunan dan tidak ada yang diizinkan memberi tahu mereka bagaimana melakukannya.

Sebagai pelatih, Scrum Master memang memiliki peran untuk menunjukkannya ketika dia melihat Tim dalam bahaya kehilangan tujuan Sprint karena alasan apa pun. Tetapi kemudian dia perlu meminta mereka untuk mencari tahu bagaimana mereka akan menghadapinya, dan kemudian keluar dari jalan mereka.

Pendekatan lain adalah membiarkan Tim menyelesaikan Sprint, meminta mereka bertanggung jawab atas kurangnya hasil dan kemudian membiarkannya didiskusikan dalam Retrospektif Sprint.


3

Seperti ideologi apa pun, ada kalanya buku peraturan perlu dibuang, atau diabaikan dengan hati-hati.

Gunakan penilaian untuk apa yang tampaknya tepat. Berhati-hatilah dengan seseorang yang menjadi manajer proyek de-facto - atau lebih buruk lagi, mengintimidasi orang untuk melakukan hal-hal tertentu.

Ada perbedaan besar antara alokasi tugas dengan mendikte (Anda AKAN melakukan X) dan alokasi dengan diskusi dan kesepakatan. Terkadang perjanjian itu mungkin suam-suam kuku.

Kemudian lagi, mungkin tim perlu mengarahkan ... sulit diketahui.

Namun, saya khawatir tentang proses apa pun yang menegaskan Anda harus mengikuti proses untuk surat tanpa ruang gerak atau penilaian. Proses semacam itu adalah pengganti untuk berpikir.


Berpikir itu sulit dan saya hanya bisa melakukan begitu banyak per hari. Semoga biarkan sesuatu atau orang lain memikirkan hal-hal kecil.
Edward Strange

1
Dalam scrum Anda mendelegasikan tanggung jawab ini kepada tim. Anda tidak berhenti berpikir. Bahkan Anda berpikir secara kolektif. Jadi keputusan lebih baik.

2
Saya melewati sebuah kasus di mana tidak seorang pun di tim akan melakukan tugas. Meskipun upaya berulang kali untuk mendorong inisiatif untuk hanya mengambil kartu dari papan, pekerjaan akan berhenti sampai saya sendiri menarik kartu dan menyerahkannya. Saya pikir itu berasal dari mentalitas transisi. Ketika para insinyur terbiasa membuat penugasan didorong di atas piring mereka, mungkin sulit untuk membalikkannya.
smithco

2

Menurut pendapat saya scummaster tidak boleh melakukan itu, anggota tim harus sendiri mengambil tugas. Jika scrummaster hanya melakukan administrasi seperti halnya di tim kami tidak ada masalah. Master scrum kami memastikan papan scrum kertas tetap sinkron dengan file excel. Peran master scrum harus menjadi fasilitator yang kami memastikan Anda dapat melakukan pekerjaan Anda tanpa hambatan. Inilah cara kami bekerja. Apakah Anda tahu mengapa scrummaster Anda melakukan ini? Apakah dia seorang manajer proyek yang takut menjadi usang? Apakah dia takut tim tidak akan mengambil tugas sendiri? Mungkin ide yang bagus untuk membahas hal ini selama retrospektif.


1

Saya telah menjadi master scrum di kedua jenis lingkungan (di mana saya mendorong tugas ke individu dan di mana individu menarik tugas).

O tim Push, sumber daya pengembangan tidak dapat dipertukarkan. Pekerjaan Windows Client harus pergi ke pengembang windows dan pekerjaan web ke pengembang web. Jadi saya bisa mendorong tugas ke sumber daya selama sesi perencanaan. Saya juga dapat melakukan perencanaan kapasitas individu untuk mengetahui kapan harus berhenti mendorong.

Metode tarik bekerja dengan baik pada tim di mana tugas apa pun dapat diambil oleh sumber daya apa pun. Tapi, saya tidak bisa melakukan perencanaan kapasitas individu selama sesi perencanaan, sebaliknya saya harus bergantung pada kecepatan rata-rata untuk mengetahui kapan cukup sudah. (Butuh ~ 3-4 sprint sebelum kami memiliki ide bagus tentang kecepatan).

Saya menemukan sebuah artikel menarik yang menguraikan pro / kontra dari Push vs Pull.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.