Apakah Agile manajemen mikro yang baru?

Pertanyaan ini sudah lama muncul di kepala saya, jadi saya ingin bertanya kepada mereka yang mengikuti praktik lincah / scrum di lingkungan pengembangan mereka.

Perusahaan saya akhirnya memberanikan diri untuk menggabungkan praktik lincah dan telah mulai dengan tim 4 pengembang dalam kelompok lincah berdasarkan percobaan. Sudah 4 bulan dengan 3 iterasi dan mereka terus melakukannya tanpa sepenuhnya gesit untuk kita semua. Hal ini disebabkan oleh fakta bahwa kepercayaan manajemen untuk memenuhi persyaratan bisnis dengan permintaan jenis ad hoc dari atas.

Baru-baru ini, saya berbicara dengan pengembang yang merupakan bagian dari inisiatif ini; mereka mengatakan kepada saya bahwa itu tidak menyenangkan. Mereka tidak diizinkan untuk berbicara dengan pengembang lain oleh master Scrum mereka dan tidak diizinkan untuk menerima panggilan telepon apa pun di area kerja (yang mungkin tidak masalah sampai batas tertentu). Sebagai contoh, jika saya ingin berbicara dengan teman saya untuk tendangan yang ada di tim lincah, saya tidak diizinkan tanpa persetujuan dari master Scrum; yang duduk tepat di sebelah tim lincah.

Gagasan dari semua ini atau gesit adalah untuk memberikan kekosongan yang lengkap untuk pengembang tangkas dari gangguan apa pun dan meminta mereka dimasukkan ke dalam 6 jam produktif yang baik Baiklah, teman-teman, saya bukan guru yang gesit tetapi apa yang saya baca dari dokumen Yahoo agile rollout dan sejenisnya untuk organisasi lain, itu memberi saya perasaan bahwa gesit itu tidak murah. Dibutuhkan sumber daya dan anggaran untuk menanamkan tangkas ke dalam tim dan memperbaiki masalah saat mereka tiba untuk mengembalikan mereka ke jalur yang benar.

Sebagai permulaan, ini membutuhkan pelatihan untuk pengembang dan pelatihan untuk manajer dan lain-lain, dll ... Master Scrum saat ini adalah seorang manajer yang mengambil beberapa hari kelas pelatihan tangkas yang dibayar oleh manajemen sekarang memimpin tim tangkas ini. Saya juga mendengar dalam pertemuan itu bahwa manifesto lincah tidak menentukan bahwa lincah tidak diatur dalam batu dan disesuaikan secara berbeda untuk masing-masing perusahaan. Yah, semua itu terdengar bagus dan masuk akal.

Sebagai kesimpulan, saya selalu berpikir gesit seharusnya membawa harmoni dalam tim pengembangan yang menghasilkan pengembang yang bahagia. Namun, saya mendapatkan perasaan yang sangat berlawanan ketika berbicara dengan para pengembang di tim tangkas. Mereka tidak bahagia bahwa mereka tidak dapat berbicara apa pun selain bekerja, duduk dengan tenang sepanjang hari hanya bekerja, dan mereka merasa itu hanyalah cara lain bagi manajemen untuk membuat mereka bekerja lebih banyak.

Tolong beritahu saya, jika ini adalah salah satu contoh praktik baik yang digunakan untuk tujuan keuntungan egois untuk lebih banyak dolar? Atau mungkin, hanya kami para pengembang seperti saya dan tim lincah ini merasa bahwa mereka tidak suka bekerja di lingkungan di mana mereka hanya bernapas karena mereka sedang bekerja.

Ini adalah perusahaan di bidang perawatan kesehatan yang memiliki kantor di seluruh AS. Ini benar-benar terasa seperti lincah gaya koboi yang membuat saya benar-benar tidak ingin lincah sama sekali, terutama di perusahaan saya saat ini.

Semua itu ada hubungannya dengan manajemen yang benar-benar murah. Memotong kopi mahal untuk versi yang lebih murah, menekankan pada tabungan dan menjadi produktif sambil tetap bersandar mungkin.

Perasaan saya adalah bahwa seseorang dalam manajemen di belakang pintu membuang ide ini, yang gesit membuat Anda menghasilkan lebih banyak sehingga kami dapat menunjukkan kepada atasan kami bahwa kami memproduksi lebih banyak dengan jumlah karyawan yang sama. Atau, mungkin, ini akan memungkinkan kami untuk mengurangi jumlah karyawan jika itu masalahnya.

Mereka mengadakan rapat harian 5 menit. Tetapi tidak diizinkan untuk mengobrol atau berbicara dengan seseorang di luar tim mereka. Semua fokus ada pada pekerjaan.

Anda menggambarkan kediktatoran manajerial, bukan gesit. Agile adalah tentang pengembangan bertahap dalam bidang persyaratan yang berubah, bukan tentang mendikte orang tentang cara mereka melakukan pekerjaan secara individu.

Mereka tidak diizinkan untuk berbicara dengan pengembang lain oleh master Scrum mereka dan tidak diizinkan untuk menerima panggilan telepon apa pun di area kerja

Ini benar-benar bukan bagian dari praktik Agile - dan masalah terpisah.

Motivasi metodologi Agile yang besar adalah peningkatan komunikasi antar pengembang. Membatasi pengembang <-> komunikasi pengembang adalah masalah terpisah dari praktik Agile. Saya tidak mengatakan ini tidak terjadi - itu jelas terjadi, dan itu dilabeli sebagai bagian dari peluncuran "gesit" di organisasi Anda, tetapi ini benar-benar masalah terpisah dari gesit (dan agak bertentangan dengan semangat pengembangan tangkas, IMO).

Kedengarannya seperti implementasi tangkas yang cukup menyimpang. Agile, jika ada, harus mengurangi manajemen mikro, bukan meningkatkannya. Tim membuat komitmen dan bagian dari proses adalah bahwa manajemen percaya bahwa tim akan mencapainya. Scrum harian adalah cara bagi pengembang untuk berkomunikasi satu sama lain dan cara untuk menginformasikan apa yang mereka lakukan, bukan bagaimana mereka menghabiskan waktu mereka (yang merupakan kesalahan yang saya lihat di beberapa tempat). Bahkan proses estimasi harus menghapus penjagaan waktu eksplisit dari estimasi, karena Anda harus memperkirakan kompleksitas relatif, bukan berapa lama sebuah cerita (kesalahan umum lainnya). Mengontrol waktu yang dihabiskan pengembang adalah ciri manajemen mikro, dan menghilangkan waktu dari proses adalah salah satu prinsip inti lincah.

Lingkungan yang Anda gambarkan terdengar seperti varietas taman omong kosong pseudo-Agile .

Saya terlibat dengan Agile sebelum Agile. Sekitar tahun 2000 saya kehabisan kode, mendengar tentang Extreme Programming, mencobanya, dan menyukainya. Itu memberi saya sebagai pengembang konteks di mana memproduksi perangkat lunak yang solid adalah hal yang paling penting, dan itu memberi saya alat untuk meminimalkan banyak omong kosong yang membuat saya gila. Saya menyukainya.

Masalahnya hari ini, yang saya jelaskan secara rinci di tempat lain , adalah bahwa sebagian besar orang "mengadopsi Agile" hari ini tidak tertarik untuk meningkatkan apa pun jika itu membuat mereka tidak nyaman. Jadi bagi mereka, "Agile" hanyalah tongkat baru untuk mengalahkan pengembang dengan cara yang sama. Berbeda dengan, katakanlah, cara untuk secara radikal meningkatkan produktivitas sambil menghilangkan semua omong kosong yang memperlambat pembangunan.

Sekarang juga. Saya memulai sebuah perusahaan, dan saya akan menggunakan banyak XP, ditambah banyak trik lain yang saya sandarkan di dunia Agile. Tapi justru karena cerita seperti milikmu, aku tersentak setiap kali mendengar tentang adopsi Agile akhir-akhir ini.

Jadi untuk menjawab pertanyaan Anda secara langsung: Agile seharusnya bukan manajemen mikro yang baru. Itu harus tentang memberdayakan orang-orang yang melakukan pekerjaan aktual untuk menyelesaikannya. Tetapi dalam kasus Anda, Agile terdengar seperti kebohongan terbaru yang mereka sampaikan kepada Anda saat mereka menuruti insting buruk mereka sendiri. Untuk itu saya benar-benar minta maaf.

Ini tidak gesit.

Pertama, Scrum tidak gesit . Scrum, terus terang, adalah omong kosong. Saya dibesarkan di sebuah rumah Pemrograman Ekstrim (secara harfiah - saya memiliki Kent Beck duduk di sofa ayah saya dan berbicara kepada saya tentang pengujian), dan saya dapat mengatakan langsung kepada Anda bahwa Scrum bukan. Scrum adalah alat manajemen proyek - ritme yang ditentukan untuk proyek pengembangan. Tetapi tidak ada yang bisa dikatakan tentang pengembangan itu sendiri, dan sangat sedikit untuk mengatakan tentang persyaratan, perencanaan, dan hubungan dengan pelanggan. XP memiliki banyak hal untuk dikatakan tentang semua itu; metodologi lain yang ingin menyebut dirinya gesit harus memiliki sesuatu untuk ditambahkan ke percakapan. Para pendukung Scrum menggambarkannya bukan sebagai proses, tetapi sebagai pembungkus untuk suatu proses. Seorang pria bijak pernah menunjukkan bahwa bungkus adalah barang yang Anda buang dan buang untuk mendapatkan barang-barang bagus.

Oke, teriaklah!

Kedua, prinsip dasar XP, yang saya yakini sangat penting untuk setiap proses gesit, adalah bahwa ia berpusat pada pengembang . Ini adalah cara memberi pengembang kekuatan untuk melakukan pekerjaan yang mereka tahu harus mereka lakukan, dan sering kali berhenti melakukannya. Tim yang gesit dapat disusun sebagai demokrasi atau otokrasi, tetapi pemimpinnya adalah pengembang. Ada peran untuk manajer proyek dan sebagainya - peran vital - tetapi itu bukan salah satu dari kepemimpinan tim. Memiliki manajer - maaf, 'scrum master' - duduk di sana memerintah orang-orang di sekitar adalah pertanda pasti bahwa tim tidak gesit.

Saya merasa harus ada yang ketiga. Tidak ada.

Scrum adalah anak haram Agile. Ini adalah gaya paling terjun dari semua metodologi lincah, dan itulah sebabnya itu yang paling populer di kalangan manajer.

Semua metode lincah adalah tentang menghasilkan kode kerja tanpa omong kosong menghalangi. Baca lagi. Dan lagi.

Apa pun yang menghalangi tujuan itu, terlepas dari "aturan tangkas" adalah buruk. Jika aturan menghalangi, ubah aturan f * * ! Itu cara lincah, itulah yang membuatnya relevan dan efektif.

Contoh terbaik dari ini diberikan oleh Alistair Cockburn (salah satu pencetus manifesto lincah):

“Tempatkan 4-6 orang di ruangan dengan workstation dan papan tulis dan akses ke pengguna. Mintalah mereka memberikan perangkat lunak yang sudah berjalan dan diuji kepada pengguna setiap satu atau dua bulan, dan jika tidak biarkan mereka sendiri. "

Jika itu bekerja untuk kualitas pria yang Anda miliki, maka itu yang Anda butuhkan. Anda tidak memerlukan master scrum atau metodologi "lincah". Jika duduk di scrum harian bekerja untuk Anda, maka f * * * melakukannya. Membuat Anda berdiri hanyalah pencabutan menyedihkan dari kemampuan Anda untuk berpikir sendiri.

Ada respons terhadap jenis gesit yang Anda lakukan. Ini dia. Cetak dan pin itu di suatu tempat ketika tidak ada orang lain di sekitar dan biarkan mereka menemukannya sendiri.

Master Scrum saat ini adalah seorang manajer yang mengambil beberapa hari kelas pelatihan tangkas dibayar oleh manajemen sekarang memimpin tim tangkas ini.

Itu masalahmu. Manajemen menginginkan beberapa Agile, mereka tidak benar-benar tahu apa itu, dan mereka memaksakannya kepada tim. Itulah yang harus dilakukan ketika Anda ingin menurunkan produktivitas pengembang secara signifikan;)

Usulan proses baru harus berasal dari pengembang. Atau setidaknya ditinjau & disetujui oleh mereka jika itu adalah ide manajemen.

Bagaimanapun, jika pengembang menolaknya, jangan menerapkannya ! Atau itu akan menjadi bencana yang Anda gambarkan.

"Agile" dan "metodologi manajemen" lainnya sering disalahgunakan untuk memaksa manajemen mikro pada orang. OTOH, terkadang juga disalahgunakan untuk mempertahankan pengerjaan yang buruk.

"we Agile" adalah alasan yang paling sering saya dengar karena kurangnya perencanaan, kurangnya pemikiran tentang desain, fitur, kualitas, siklus rilis. Ini biasanya dari pengembang dan manajemen yang lebih rendah. Ini juga alasan yang paling sering saya dengar dari manajer menengah, arsitek, wiraniaga, dll. Untuk manajemen mikro, tenggat waktu yang terus berubah dan daftar pemain, memaksa lembur besar-besaran pada orang-orang (tenggat waktu yang terus berubah dan pembuat daftar memastikan bahwa tentu saja), dll. .

Keduanya tentu saja sering bertentangan langsung, dan dapat terjadi pada proyek yang sama.

Untuk menjawab pertanyaan awal Anda, apakah Agile manajemen mikro baru, saya akan mengatakan tidak.

Pertama, baca ini (manifesto Agile) dan Anda akan melihat bahwa tidak berbicara dengan rekan pengembang Anda tidak terdaftar.

Sebenarnya "Individu dan Interaksi" adalah kebalikan dari tidak berbicara dengan co-developer Anda.

Agile harus menjadi manajemen diri yang baru. Jika gesit dipraktikkan dengan benar, banyak keputusan dibuat oleh pelanggan dan pengembang yang mengerjakan kisah pengguna dengan cakupan yang masuk akal yang ditambahkan ke dalam simpanan saat tugas diidentifikasi.

Scrum harian adalah tentang komunikasi, bukan manajemen. Akan ada beberapa diskusi tentang prioritas dan load balancing, tetapi orang yang dikelola di scrum mudah-mudahan master scrum. SEBAGAI pengembang, saya menghadiri, mengatakan apa yang saya lakukan, apa yang akan saya lakukan, dan bantuan apa yang saya butuhkan. Maka master scrum harus mulai bertindak membersihkan rintangan untuk kemajuan saya.

Tim lincah tidak boleh merasa seperti pekerjaan sehari-hari dikelola secara hierarkis. Jika keputusan dibuat dari jauh oleh seseorang yang berada di puncak organisasi hierarkis, sudah saatnya desentralisasi pengambilan keputusan! Bagi sebagian orang dan beberapa organisasi, ini mungkin jembatan yang terlalu jauh. Jika yang berikut ini tidak benar untuk organisasi Anda:

Hidup Agile Manifesto

"Kami menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukannya dan membantu orang lain melakukannya."

Hindari "Temui bos baru, Sama seperti bos lama." Berasal Agile dari dalam tim sebanyak mungkin. Kadang-kadang ini terjadi dengan memilih koalisi yang bersedia berada di proyek percobaan menggunakan Agile. Jika Anda dapat membentuk tim Agile Anda dari sukarelawan atau anggota yang diundang yang memiliki rekam jejak untuk kerja tim yang baik, mereka dapat menyelesaikannya. Gunakan tim kecil pada proyek pendek, mungkin untuk pelanggan in-house atau sangat mudah diakses.

Merangkul perubahan. Mungkin Anda bisa mengikuti pelatihan, tapi mungkin anggaran Anda ketat dan uangnya tidak ada. Peluang lain dapat memberikan peningkatan juga. Lakukan beberapa bacaan, mintalah anggota tim mempelajari apa yang dapat mereka lakukan tentang Agile dan saling mengajar. Anda mungkin dapat menemukan staf baru atau yang sudah ada yang memenuhi syarat untuk menjadi model dan memimpin dalam adopsi Agile.

Tim tangkas seperti tim sepak bola yang bekerja menuju tujuan yang dipahami secara umum. Saya telah menjadi bagian dari tim lincah selama beberapa tahun dan kuncinya adalah komunikasi yang efektif dan efisien di semua pemegang pasak. Manajer / Scrum master hanyalah fasilitator tim dan manajemen tradisional / manajemen mikro akan membunuh semangat tim.

Di tim yang saya telah bekerja, kami didorong untuk bermain game tim setelah jam kerja untuk meningkatkan persahabatan dalam anggota. Saya telah mengumpulkan pemikiran-pemikiran itu di sini .

Untuk menjawab pertanyaan Anda: Tidak. Agile bukanlah bentuk manajemen mikro. Tetapi seperti alat apa pun, orang dapat menggunakannya dengan salah. Agile luar biasa ketika diterapkan dengan benar dan ketika orang konsisten dengannya.

Pikiranku pada topik "Devs tidak berbicara dengan siapa pun kecuali master scrum":

Saya telah bekerja di tempat di mana itu adalah aturan sebelumnya. NAMUN, aturan itu lebih terkait dengan meminta orang untuk menyelesaikan tugas. Sebagai contoh, saya tidak bisa secara acak naik ke tester dev dan meminta mereka untuk melakukan beberapa pengujian untuk saya dalam beberapa jam ke depan. Saya perlu berbicara dengan master scrum sehingga mereka dapat berdiskusi dengan anggota tim mereka bagaimana pekerjaan itu akan cocok dengan sprint jika itu darurat (atau jika perlu didorong ke backlog untuk sprint masa depan).

Dalam hal itu, saya mengerti konsep "devs not talk to another" karena benar-benar diterjemahkan menjadi menyalurkan tugas melalui satu pos pemeriksaan sehingga pengembang tertentu tidak bekerja terlalu keras atau begitu sibuk melakukan tugas darurat sehingga mereka tidak dapat merencanakannya. kerja selesai.

Kalau tidak, devs HARUS berbicara satu sama lain. Selalu. Ini membantu Anda mengatasi masalah lebih cepat, menjadi lebih dekat sebagai sebuah tim, dan memberikan lebih cepat.

Hanya untuk menawarkan perspektif lain: Saya juga pernah berada di lingkungan di mana orang berpikir dev "terlalu banyak bicara". Setelah duduk, kami menemukan bahwa sebenarnya diterjemahkan ke "devs tidak cukup mandiri untuk menyelesaikan pekerjaan mereka sendiri. Karena semuanya sangat terfragmentasi, devs harus pergi ke tiga orang lain untuk menyelesaikan tugas kecil."

Jadi, ketika para manajer memutuskan untuk bergerak dengan gesit, mereka berharap untuk membantu membawa informasi ke tempat yang tepat dan menghentikan banyak fragmentasi dalam organisasi. Beberapa orang agak kecewa bahwa setelah Agile diimplementasikan, para dev masih berlari bolak-balik satu sama lain. Tapi, apa yang tidak mereka sadari adalah hal itu semakin jarang terjadi. Butuh waktu lama. Jadi, mungkin jika itu yang terjadi di organisasi Anda, bisa jadi orang diharapkan gesit untuk memperbaiki keadaan dalam semalam. Itu bukan cara kerjanya.

Penulis Asli Smith Janes mungkin telah memberikan pengalaman. Tapi ini adalah masalah khas yang saya temukan dalam proyek Agile.

1. Sebagian besar organisasi, pengembang seharusnya bekerja dalam banyak proyek, dalam Agile / scrum .. Sprint tidak pernah dianggap sebagai fakta ini. Scrum Master Anda menganggap Anda harus menyelesaikan cerita Anda di akhir sprint .. Master Scrum Anda mungkin hanya didedikasikan untuk satu proyek, tetapi tidak untuk pengembang. INI ADALAH DISTRAKSI - tidak perlu hanya menerima telepon atau memungkinkan panggilan telepon.
2. Saya telah melihat proyek Agile di mana Sprint direncanakan, Cerita dimasukkan dalam Sprint, tanpa harus berkerumun..di tengah jalan atau tengah sprint .. pengembang menemukan dependensi yang tidak terselesaikan, persyaratan atau cerita tidak selesai diceritakan ..... Ini adalah salah satu Penyalahgunaan di sebagian besar proyek gesit.
3. Pengujian: TTD .. ya itu sangat bagus .. tapi saya telah melihat sebagian besar proyek Agile sepenuhnya bergantung pada TTD ... tidak ada cakupan atau waktu yang diizinkan untuk pengujian Fungsional atau Manusia .. Penyalahgunaan lain ... Banyak Master Scrum juga tidak tahu atau mengerti pentingnya pengujian Fungsional. Sepotong kode Anda mungkin berfungsi sempurna, jika tidak melayani kebutuhan bisnis .. tidak ada gunanya .. Ini terjadi ketika bisnis tidak berpartisipasi dengan baik di depan .. atau partisipasi ada ... tetapi tidak mencerminkan pengambilan keputusan bisnis .. Pada akhirnya, pengembang disalahkan, Anda tidak memberikan fungsionalitas..atau akan berakhir dengan perubahan menit terakhir ... jam ekstra panjang karena master Scrum Anda tidak ingin disalahkan karena cerita tidak selesai.

Pelanggaran di sini ... rendahnya partisipasi bisnis atau peserta yang tidak sepenuhnya berpengetahuan atau pebisnis putus di tengah sprint.

1. Tidak Semua proyek cocok untuk Agile ... Sebagian besar manajer atau master scrum tidak mengetahui hal ini .. Proyek pemeliharaan .. Cacat mungkin awalnya diasumsikan dapat dilakukan dalam 8 jam, diterima dalam sprint. Setelah menghabiskan 4 jam, temukan ini adalah Java / produk lain ... (Saya baru-baru ini menghadapi cacat yang berhubungan dengan Quartz Scheduler..di dalam proyek kami) dan cacat ini dapat mengarah pada peningkatan produk / paket..terhadap birokrasi, persetujuan, pendanaan, versi baru atau peningkatan harus disetujui oleh Teknik Internal dll., 5.Retrospeksi: hanya beberapa proyek Agile melakukan langkah ini .. Jika sama sekali dilakukan .. Manajemen, Scrum Master tidak pernah mengambil tanggung jawab atas cerita yang gagal ..
2. Penyandingan .. Banyak pengembang memperlakukan penyandingan sebagai tempat untuk menyalahgunakan rekan kerja .. mengkritik desain lain, praktik pengkodean ... memperlakukan pemberi kerja sebagai kerja tim., Belajar dari satu sama lain ... Cara lain untuk Melecehkan Agile / Scrum.

Agile jelas merupakan metodologi yang baik .. Kecuali jika organisasi Anda tidak mengikuti sepenuhnya atau tidak terlatih .... Disalahgunakan .... efek samping 60+ jam kerja / minggu, permainan menyalahkan, moral rendah.

Agile adalah manajemen mikro yang menyamar. Tidak ada tempat untuk inisiatif atau kreativitas dalam Agile, itu telah menghilangkan kesenangan dari pemrograman untuk memungkinkan manajer yang tidak kompeten untuk tetap mengontrol bahkan tanpa memiliki petunjuk dari sudut pandang teknis.