Apakah tim tangkas dewasa membutuhkan manajemen?

Setelah perdebatan sengit baru-baru ini tentang Scrum, saya menyadari masalah saya adalah bahwa saya menganggap manajemen sebagai aktivitas yang tidak perlu dan berlebihan dalam tim yang sangat gesit. Saya percaya tim Agile yang matang tidak memerlukan manajemen atau proses pengambilan keputusan non-teknis apa pun. Bagi saya (yang kelihatannya keliru), sangat jelas bahwa satu-satunya yang cocok dan mampu mengelola tim pengembang yang matang adalah pelatih mereka (yang merupakan kolega yang paling kompeten secara teknis dengan keterampilan komunikasi yang tepat). Saya tidak bisa membayangkan bagaimana master Scrum dapat berkontribusi pada tim seperti itu.

Saya mengalami kesulitan besar untuk menyadari dan memahami nilai dari hal-hal seperti itu di Scrum dan manajer sebagai seseorang yang bukan pengembang veteran tetapi sangat terampil dalam merencanakan siklus produksi ketika seorang pelatih ada dalam tim. Apa artinya itu? Bagaimana mungkin seseorang tanpa keterampilan pengembangan dapat mengelola tim yang sangat teknis? Mungkin manajemen di sini berarti sesuatu yang lain?

Saya melihat manajemen sebagai total buang waktu dan produk sampingan dari ketidakdewasaan. Dalam pemahaman saya, tim yang matang sepenuhnya mengelola diri sendiri. Tampaknya saya salah karena banyak orang hebat mengatakan yang sebaliknya tetapi saya tidak dapat meyakinkan diri saya sendiri.

Anda membuat sejumlah kesalahan di sini.

Yang pertama mengasumsikan bahwa Scrum Master adalah seorang manajer. Mereka tidak. Mereka pada dasarnya adalah administrator-sekaligus-fasilitator. Mereka memastikan hal-hal terjadi pada jadwal Scrum, tetapi mereka tidak harus memberi tahu Anda bagaimana caranya, jika Anda adalah tim Agile yang sepenuhnya matang. Kebanyakan hanya terjadi begitu saja.

Tetapi mereka tidak memantau kualitas pekerjaan Anda atau menandatangani liburan Anda atau hal-hal semacam itu. Mereka juga tidak mengelola produk atau proyek; itu dilakukan oleh orang lain.

Kesalahan yang lebih besar yang Anda buat adalah dengan asumsi bahwa Anda bisa pergi dari situasi yang telah Anda jelaskan dalam pertanyaan lain ("Pengembang jauh dari mampu melakukan praktik pemrograman tangkas saat ini. Tidak ada tes unit, tidak ada program pasangan, tidak ada CI ( huh? apa itu?) ... Anda mendapatkan ide. ") untuk" Agile team yang matang sepenuhnya "dalam semalam. Itu tidak mungkin. Lupakan. Jangan coba-coba.

Jika hasil semalam adalah yang Anda inginkan, lihatlah pendekatan manajemen proyek yang lebih terstruktur. Dan mempekerjakan beberapa manajer.

Jika bisnis ingin Anda menjadi gesit, butuh waktu, butuh perubahan budaya. Dan ya, pada awalnya, ketika Anda berada dalam tahap peningkatan Chaotic , itu akan membutuhkan manajemen. Baik itu individu atau kelompok, seseorang harus membuat keputusan.

Anda memerlukan seseorang atau kelompok untuk bertanggung jawab untuk melihat gambaran yang lebih besar, menjelaskan situasi saat ini baik untuk pengembang dan bisnis, dan menjelaskan opsi yang Anda miliki untuk perbaikan, mencari tahu apa yang dibutuhkan bisnis dan kemudian membimbing orang melalui Itu.

Ini akan menjadi waktu yang lama sebelum Anda dapat menyebut diri Anda sebagai tim Agile yang sepenuhnya matang dan mengelola diri sendiri. Sebagian besar tim tidak pernah sampai di sana.

Dalam pemahaman saya, tim yang matang sepenuhnya mengelola diri sendiri.

Mari kita asumsikan sejenak bahwa Anda benar. Saya tidak tahu satu atau lain cara, jadi jangan membicarakannya.

Masalahnya muncul bahwa bahkan tim yang mengelola diri sendiri berakhir dengan seseorang dengan keterampilan sosial dan politik yang baik yang dapat mewakili tim ke departemen lain. Seseorang yang melacak apa yang dilakukan semua orang, saat mereka berlibur, dll. Seseorang yang menangani omong kosong dan penganggaran SDM. Seseorang yang berdebat dengan kelompok QA dan PM sehingga anggota tim lainnya tidak perlu. Seseorang yang memediasi perselisihan antarpribadi yang tak terhindarkan antara pengembang. Seseorang menjadwalkan rapat dan menjaga semangat.

Orang ini adalah seorang manajer.

• Anda tiba di rumah suatu hari dan Anda membayar cek tidak ...
• Anda ingin mengambil cuti, tapi timnya terlalu sibuk dan sudah setahun ...
• Istri atau anak Anda sakit dan mengharuskan Anda mengurangi hingga 20 jam seminggu
  selama 6 bulan.
• Departemen keuangan telah menyerukan pemotongan anggaran dan seseorang harus pergi.
• Mesin kopi pecah dan tidak ada yang bisa memperbaikinya.
• Tim Anda sangat bagus, tidak ada cacat untuk diperbaiki dan tidak ada fitur untuk ditambahkan, Anda sudah kehabisan pekerjaan - apa yang harus dilakukan sekarang.
• Pelanggan tidak akan membayar untuk pekerjaan yang dilakukan
• Pelanggan menginginkan lebih banyak pekerjaan dilakukan daripada yang dapat Anda capai dan siap membayarnya.

Saya tidak melihat apa pun dalam daftar ini yang belum terjadi pada saya dalam karier saya. Saya tidak melihat apa pun dalam daftar ini yang membutuhkan ketrampilan yang sangat teknis untuk diselesaikan. Saya melihat banyak hal dalam daftar ini yang membutuhkan keterampilan khusus yang, sejujurnya, sebagian besar pengembang tidak memiliki, dan manajer yang baik melakukannya, tidak peduli apa yang telah mereka kelola di masa lalu.

Berhentilah mengantongi manajer - kenali bahwa Anda memiliki serangkaian keterampilan dan mereka memiliki keterampilan yang berbeda. Semua keterampilan ini diperlukan di organisasi mana pun. Anda akan melakukan pekerjaan mereka sama seperti mereka akan melakukan pekerjaan Anda. Jarang ada orang yang pandai di kedua pekerjaan itu, jarang ada orang yang pandai di keduanya yang bisa melakukan keduanya secara bersamaan. Apa yang terjadi tanpa palungan adalah hal-hal yang perlahan-lahan terkikis ke dalam keadaan disfungsi. Jika Anda beruntung, itu diakui cukup awal, seorang manajer dipekerjakan, dan semua masalah tiba-tiba menghilang seolah-olah dengan sihir, dan Anda dibiarkan melanjutkan pekerjaan yang Anda bayarkan daripada bermain politik kantor konyol (berbicara dari pengalaman di sini).

Saya melihat manajemen sebagai total buang waktu dan produk sampingan dari ketidakdewasaan.

Wow. Anda belum bekerja dengan manajer yang baik belakangan ini, bukan? (Kita semua pernah bekerja dengan yang buruk).

Saya pernah melihat orang sesekali membuat kesalahan dengan menganggap segala sesuatu yang tidak mereka pahami sepenuhnya mudah.

(Orang-orang bisnis sangat bersalah dalam hal ini - apakah Anda pernah menerima spesifikasi kualitas yang buruk DAN tenggat waktu yang ditetapkan?)

Di sebagian besar bisnis, tim pengembangan ada sebagai bagian dari keseluruhan yang lebih besar. Manajer ada sebagai antarmuka antara tim dan seluruh perusahaan. Seorang manajer yang baik akan bekerja dalam hubungan itu di kedua arah, memastikan tim mendapatkan apa yang mereka butuhkan (persyaratan, ruang kantor, komputer baru, pengakuan, bonus, dll) serta mengomunikasikan prioritas (yang selalu berubah) yang keluar dari kantor sudut .

Kantor sudut ada karena banyak alasan, yang sebagian besar tidak relevan dengan pos ini.

Ingatlah bahwa sebagian besar manajer membuat keputusan terbaik dengan informasi yang tersedia bagi mereka yang mungkin tidak sama dengan informasi yang tersedia untuk Anda .

Jika Anda memiliki tim pengembangan sepenuhnya matang yang merupakan bagian dari perusahaan sepenuhnya matang yang telah sepenuhnya matang pelanggan dan tidak pernah berubah, Anda mungkin mungkin menghilangkan kebutuhan untuk sebagian besar manajemen. Istilah untuk itu adalah Utopia .

Semoga beruntung dengan itu.

ps - baca Jangan menyebut diri Anda seorang programmer - saran yang sangat baik, dan menjelaskan lebih baik daripada saya bagaimana sisa dunia bisnis memandang kita.

Pekerjaan seorang master scrum atau manajer pada umumnya tidak bertindak sebagai penguasa diktator. Tugas seorang manajer adalah memastikan bahwa timnya siap untuk sukses dalam bisnis. Itu termasuk merekrut orang yang tepat, mendapatkan peralatan yang tepat, dan menjaga pandangan strategis produk. Seorang manajer harus seperti hakim garis, menjaga detail dan hal-hal kecil yang tidak penting bagi keberhasilan tim dari mengganggu kemajuan mereka.

Sebagian dari masalahnya adalah bahwa "Guru Scrum" sangat mungkin merupakan peran yang paling tidak akurat dalam semua sejarah. "Scrum Fasilitator" akan sedikit lebih akurat, tetapi seperti yang ditunjukkan orang lain sebelumnya, pekerjaan SM bukan untuk mengelola tim tetapi untuk membuat masalah hilang sehingga tim (yang mengatur diri sendiri) dapat melanjutkan pekerjaan mereka. Ya, master scrum juga bertanggung jawab untuk memastikan bahwa scrum terjadi: tugas diperbarui dengan jam tersisa, stand-up ditahan dan menambah nilai, burn-down diperbarui dan kecepatan dilacak dan seterusnya, tetapi itu masih berupa pelatihan dan peran fasilitasi, bukan peran mengelola.

Bagian lain dari masalah adalah bahwa orang-orang di kantor sudut ingin mengetahui jawaban atas pertanyaan seperti "kapan saya bisa mengirimkan perangkat lunak?" dan "fitur apa yang dikandungnya?" dan mereka terbiasa menanyakan "Manajer Proyek" pertanyaan-pertanyaan itu dan mendapatkan jawaban yang didukung dengan banyak grafik Gantt yang tampak mengesankan dan sedikit atau tanpa menyebutkan hal-hal tidak nyaman seperti kerucut ketidakpastian.

Di bawah Scrum, layak untuk memulai dengan daftar kasar "dan" siap "," mungkin "dan" tidak akan "fitur untuk setiap tanggal kapal tertentu, tetapi pasti ada peran untuk seseorang - mungkin master scrum - dalam menjaga kantor sudut up to date dengan perubahan yang tak terhindarkan dalam daftar itu dari waktu ke waktu. Saya tergoda untuk memikirkan kegiatan itu, bersama dengan memproses umpan balik yang dihasilkan dan mengelola permintaan fitur baru sebagai "manajemen", meskipun manajemen itu berbeda dari apa yang mungkin dilakukan oleh banyak Manajer Proyek di masa lalu.

Jika menurut Anda tidak diperlukan manajemen, siapa yang akan melakukan pekerjaan organisasi berikut, siapa yang akan merespons dalam situasi berikut?

• klien baru harus ditemukan. Bagaimana Anda menjual produk Anda? Bagaimana cara Anda beriklan?
• bahan harus dibeli, pemasok harus ditemukan
• diskusi diplomatik dengan perusahaan lain, atau bank, atau kantor pemerintah harus dipimpin

Saya berada di tim kecil tanpa manajer dan berhasil. Mengapa? Sejujurnya aku tidak tahu.

Tebakan terbaik saya adalah tipe orang seperti Anda. Beberapa orang "adalah" komputer, jadi mereka perlu diberi makan suatu proses. Orang lain adalah "programmer" dan memiliki kemampuan untuk menciptakan dunia dan struktur mereka sendiri dari ketiadaan.

Saya harus membuat sistem atau diperbudak oleh lelaki lain; Saya tidak akan beralasan dan membandingkan: bisnis saya adalah menciptakan. - William Blake

EDIT dalam menanggapi komentar glenatron:
Ini lebih dari sekedar tim pengembang. Kami memiliki CEO, resepsionis yang menjawab telepon, dan seorang pria IT. Kami berkomunikasi dengan klien secara langsung melalui email, telepon, atau rapat. Bisnis utama kami adalah menciptakan produk kami sendiri dan menjualnya, daripada memburu kontrak. Tapi ada kontrak juga.

Saya lebih memikirkannya dan ini adalah alasan saya pikir itu berhasil:
1. Kami terutama menciptakan produk kami sendiri daripada menciptakan produk orang lain.
2. Kami memiliki etos kerja yang konsisten secara independen tanpa pengawasan.
3. Kami memiliki pengetahuan domain.
4. Keberuntungan. Sejumlah orang yang rukun dan bekerja bersama dengan baik.

Seseorang menyebutkan bahwa perusahaan Valve juga tidak memiliki manajemen. Valve menciptakan produk mereka sendiri daripada menciptakan produk orang lain. Saya pikir perusahaan produk cocok untuk manajemen diri. Tidak ada risiko untuk menempuh jalan yang berbeda dari yang diharapkan klien karena Anda adalah klien. Dalam sebuah perusahaan game, ini terutama benar. Buat game Anda menyenangkan.

Anda tidak dapat mengatur cara Anda untuk bersenang-senang. Anda tidak dapat mengatur jalan Anda ke kreasi seni asli.