"Agile sudah mati." Orang mengatakan itu sepanjang waktu. Tetapi mereka selalu menambahkan: "Kami hanya bercanda." Mereka agak berarti bahwa
Anda memiliki praktik yang salah dan bodoh sehingga Agile mati untuk
Anda . Tapi Agile yang "asli" tidak mati. Hanya saja semua orang melakukan kesalahan. Jadi saya menyadari: Agile yang sebenarnya adalah, Anda tahu, Agile
dalam teori . Bahkan saya menerapkannya. Dan tahukah Anda? Aku muak dengan itu.
Baru-baru ini, saya melihat pertahanan lama yang sama dalam artikel saya: "Tapi-tapi-tapi, masalahnya adalah air terjun, scrum dan implementasi Agile yang salah, ketidakpatuhan dari Manifesto ... bla bla bla." Lalu Bob Marshall mengatakan yang sebenarnya. Dia berkata, “Diam, Charles. Manifesto Agile adalah kendi yang kita isi. ” Dia membuat beberapa komentar yang harus saya setujui. Saya memikirkannya. Hasilnya adalah artikel ini.
Ini tes untuk Anda. Bagaimana baris pertama manifes Agile dimulai? Jangan mengintip. Tidak tahu Semuanya baik-baik saja. Itu tidak masalah. Dikatakan: "Kami menemukan metode pengembangan perangkat lunak yang lebih maju ..." Berhenti. Perhatikan, katanya: "pengembangan perangkat lunak." Itu tidak mengatakan: "menarik organisasi Anda," "melunasi hutang untuk transformasi," "memotongnya dengan perintah ini dan mengontrol omong kosong," "berfokus pada hasil dan meningkatkan pekerjaan pembukaan," "memperbaiki sistem penganggaran abad pertengahan Anda," atau apa pun nilai tambah yang lebih maju yang orang coba untuk berinvestasi di dalamnya. Tetapi kenyataannya adalah bahwa ketika orang mengatakan bahwa Agile mengacu pada keseluruhan organisasi, itu adalah revisionisme. Ini tidak adil.
Perhatikan juga bahwa itu dimulai "Kami
menemukan ..." Dia tidak mengatakan: "Kami telah menerima dari atas ..." Tidakkah Anda berpikir bahwa kami telah mempelajari sesuatu sejak tahun 2001? Maksudku, ya, sebagian besar organisasi besar masih macet di tahun 1987, tapi oke, kamu. Berlawanan dengan kepercayaan populer, foto di bawah ini sebenarnya bukan dari tindakan menandatangani manifesto. Bisakah kita akhirnya berhenti berpura-pura?
Manifes melayani tujuan tertentu, tetapi tidak akan membawa Anda ke tempat yang Anda inginkan. Jadi mulailah studi Anda. Pengetahuan kita memiliki tanggal kedaluwarsa, dan tidak selama yang kita pikirkan. Setiap orang memiliki kolega (biasanya bos) yang mengklaim bahwa mereka "tidak punya waktu untuk belajar." Anda sendiri tahu bahwa mereka terlalu percaya diri dalam pengetahuan mereka. Jadi temukan daftar buku yang bagus. Ikuti perkembangan blog yang bagus. Inilah awalnya: jika Anda belum membaca
Sense & Respond ,
Lean Enterprise ,
A Seat at the Table dan
Semua Orang Adalah Agen Perubahan , saya sarankan Anda segera melakukannya. Dan untuk atasanmu.
Mulai membaca posting oleh John Cutler, Melissa Perry, Bob Marshall, Allen Holub, Laura Klein, Erica Hall, Neil Killick dan yang mereka rujuk. Apakah mereka semua sepakat satu sama lain (atau dengan saya)? Tidak, tetapi mereka cerdas dan mereka juga akan membuat Anda lebih pintar. Mulailah membaca dan dorong orang lain. Fast Company mengatakan, rata-rata CEO membaca 60 buku setahun. Berapa banyak buku yang dibaca pemimpin Anda? Dan apa yang mereka baca? (Artikel HBR, laporan Gartner, dan novel Maeve Binchi tidak masuk hitungan). Karena mari kita hadapi: jika pemimpin Anda adalah ahli Scrum, maka Anda benar-benar terjebak di tahun 80-an dan 90-an.
Mari kita beralih ke pembelajaran berkelanjutan dan berhenti berpura-pura bahwa Agile adalah semacam obat. Ini harus dikatakan:
Agile adalah dan selalu menjadi optimisasi lokal untuk sedikit peningkatan efisiensi sistem . Hanya Agile yang ditempatkan secara tidak adil di bawah mikroskop, tim pengembang perangkat lunak. Ini tidak meningkatkan fleksibilitas organisasi. TIDAK. Menariknya, menurut Ken Schwaber (lihat “Tidak Aman di Kecepatan Apa Pun”), Agile adalah upaya untuk “mengkompensasi kerusakan yang disebabkan oleh air terjun,” namun itu tidak pernah memberi organisasi alternatif yang holistik dan layak untuk air terjun. Karena ada perbedaan antara teori dan praktik. Bekerja pada suatu produk lebih merupakan praktik. Ketika kita mengeluh tentang AINO (Agile In Name Only), kita tidak jujur pada diri kita sendiri.
Teori versus praktik, ingat? Kita harus pragmatis. Agile dalam praktiknya hampir selalu AINO. Sepertinya masalah dengan gerakan itu sendiri, bukan? Bagaimanapun, ada hal-hal yang lebih penting untuk dipelajari, termasuk (tetapi tidak terbatas pada) Lean UX, Lean Enterprise, Melampaui Anggaran, Teori Kendala, Throughput Accounting, Thinking Design, DevOps, Terapi Organisasi Marshall, dll.
Anda mungkin bertanya mengapa Lean UX berada di puncak daftar? Karena kenyataan bahwa
pada intinya Lean UX mempopulerkan konsep orientasi hasil. Pikirkan: jika Anda tidak tahu perubahan perilaku seperti apa yang Anda coba buat, maka Anda tidak akan mengerti tindakan Anda. Jika Anda tidak memiliki sinyal pivot yang jelas, maka Anda tidak lagi fleksibel. Lagipula, itulah Agile yang berputar. Beberapa orang mungkin keberatan: "Tidak-tidak-tidak, periksa dan beradaptasi!" Tentu saja Teori versus praktik, ingat? Saya tidak melihat tim fleksibel yang menguji dan beradaptasi. Saya melihat tim Agile berusaha mengejar ketinggalan, main-main dengan Jira dan Rally dan bertindak seolah-olah mereka sedang membangun tembok bata berdasarkan pesanan.
Agile sebenarnya cenderung menutupi masalah utama - ini adalah kurangnya kepercayaan vertikal secara sistemik, dua arah. Agile Coachis pergi, memperburuk situasi: mereka meninggalkan manajer yang berbicara babi dan tim pengembangan yang beralih ke Esperanto. Tim percaya bahwa manajemen rusak, dan manajemen percaya bahwa fokus utama masih harus pada volume, waktu dan efisiensi, mengabaikan jadwal yang sewenang-wenang dan estimasi waktu adalah
bentuk limbah . (Apakah Anda tahu poin cerita apa yang sebenarnya diciptakan untuk
menyembunyikan waktu dan membantu menyelesaikan masalah itu sendiri? Ada juga konsekuensi yang tidak menyenangkan di sini, kan? Teori dan praktik).
Tebak siapa yang akan menang? Dua kubu dengan dua perspektif yang sangat berbeda, di mana satu kubu mendapat peringkat dari yang lain? Jika tim seperti orang buta yang merasakan gajah dan tidak setuju dengan apa itu, maka kepemimpinan seperti gajah buta yang menyerang orang dan setuju bahwa mereka semua datar. Solusinya adalah mengenali bahwa sistem itu tim. Selesaikan dengan optimisasi lokal dan sadari bahwa kepercayaan adalah masalah nomor 1. Berhenti menempatkan pengembang secara tidak adil di bawah mikroskop, membiarkan orang lain bersembunyi di dalam kotak hitam. (Mengapa kita tidak tertarik pada bagaimana tim pengembangan strategis bekerja? Atau bagaimana kendala arsitek sistem lama?)
Dan sementara kita melakukan ini, kita harus berhenti memperlakukan tim pengembangan seolah-olah mereka bekerja di pabrik. Kami tidak mencap piring plastik. Kami membuat perangkat lunak. Anda harus berhenti bertingkah seperti kami
melayani restoran pizza . Berikut aturan lainnya. Kami tidak menggunakan resep yang terbukti sama. Kami
mengembangkan resep . Jika Anda belum mengerti, ini adalah pekerjaan pembuka, bukan hanya pengiriman. Mengabaikan penemuan menyebabkan kerugian besar: fungsi yang tidak digunakan dan pekerjaan lain yang tidak mencapai hasil. Ini mengungkapkan kelemahan Agile yang dalam. Dia menyarankan bahwa pengguna dapat dianggap sebagai kelinci percobaan: "Hei, gunakan saja produk menyebalkan ini, maka kita akan memperbaikinya." Kecuali produk yang menyebalkan biasanya tetap seperti itu, bukan? Perbaikan di masa depan menjadi "biaya" yang tidak perlu.
Tapi-tapi-tapi, Agile benar-benar fokus pada penelitian! Benar? Kami akan jujur. Teori versus praktik, ingat? Jika Anda mencari nafkah dengan merancang atau meneliti, maka jawab pertanyaan ini. Bagaimana perasaan Anda tentang bekerja dengan tim yang fleksibel? Apakah Anda awalnya dipandang sebagai nilai dan diminta untuk membantu "menguji dan beradaptasi"? Atau Anda diminta untuk "membuktikan nilai Anda"? Seperti yang dikatakan Alan Cooper, ketika Anda diminta untuk "membuktikan nilai Anda", Anda dibuat jelas bahwa Anda berada dalam sistem yang tidak menghargai Anda. Harap dicatat bahwa mereka meminta peserta secara perorangan untuk membuktikan nilai mereka - mereka tidak bertanya berapa banyak kode mereka yang sebenarnya bias dalam indikator ke arah yang benar. Dengan kata lain, mereka masih fokus pada orang,
bukan pada pekerjaan itu sendiri . Mereka mungkin masih fokus pada tulang, bukan nilai, mengabaikan area di mana sebagian besar nilai benar-benar mengalir.
Jika Anda bekerja dengan tim yang fleksibel, lain kali Anda diminta untuk “menunjukkan nilai Anda,” coba ini. Mulailah dengan mengajukan pertanyaan kepada
mereka . Apakah mereka tahu berapa harga penundaan itu? Latihan apa yang mereka gunakan untuk mengevaluasi parameter ini? Hasil spesifik apa yang ingin mereka capai? Berapa proporsi produk mereka yang benar-benar mencapai kinerjanya? Apakah mereka tidak tahu? Jika ada cara yang lebih cepat dan lebih murah untuk mencari tahu apa yang harus dikembangkan, selain hanya mengeluarkan kode, apakah mereka tertarik untuk belajar? Apa efisiensi aliran mereka? Seberapa buruk itu? Berapa banyak waktu yang mereka habiskan dalam rapat? Jika ada permainan desainer dan tindakan sederhana yang akan mengarah ke solusi yang lebih baik dalam waktu yang jauh lebih sedikit, apakah mereka tertarik untuk belajar? Karena saya tidak hanya akan menunjukkan nilai saya kepada Anda - saya akan mengajarkan Anda untuk menciptakan nilai lebih
dalam segala hal yang Anda lakukan .
Ini cara berpikir yang berbeda. Ini adalah meta. Ini strategis. Seperti yang dikatakan Austin Gowella, Agile dan air terjun berfokus pada
pengembangan . Desain adalah
ujian . Jika mereka tidak tertarik, Anda bisa pergi. Jika mereka menurunkan kepala mereka untuk merilis produk, dengan fokus pada biaya, mereka bahkan tidak akan pernah cukup tahu untuk memahami bahwa Anda biasanya mendapatkan lebih dari apa yang Anda fokuskan (um, tulang). Ini adalah pabrik fitur. Tanggung jawab bersama. Mereka pura-pura membuat piring plastik. Anda memiliki hal-hal yang lebih penting untuk dilakukan. Karena nilai riil disediakan oleh opsi yang dihasilkan melalui
penelitian . Semakin banyak opsi yang Anda buat dan semakin fleksibel pendekatan Anda, semakin banyak jalan yang mungkin dan hasil yang lebih baik. Apa yang mereka coba capai? Sudahkah mereka mengeksplorasi tiga hingga lima cara untuk mencapai ini? Ini akan mengarah pada pengambilan keputusan yang lebih baik untuk masa depan. Satu pilihan bukan pilihan. Dua adalah dilema. Tiga - sekarang Anda telah mencapai sesuatu.
Pernah mendengar tentang Hukum Keragaman yang Diperlukan? Komponen dengan opsi terbanyak
mengendalikan sistem . Menerapkannya pada perebutan kekuasaan bodoh Agile vs Waterfall. Anda memiliki eksekutif yang mencoba mempertahankan kontrol sistem dari atas, dan tim yang fleksibel yang mencoba membawa nilai lebih dekat ke sumbernya (pengguna nyata dan pelanggan). Jalan keluar dari perang saudara yang tidak berarti adalah mengajar orang bagaimana menghasilkan opsi
di semua tingkatan . Jalan ke depan bukanlah Agile Against a Waterfall. Ini adalah pekerjaan strategis dari atas ke bawah (air terjun) yang cerdas dengan taktik bottom-up yang berorientasi empiris. Desain dan penemuan membantu dalam kedua kasus.
Jadi ... apa solusinya? Ini adalah fokus yang masuk akal pada hasil yang jelas, bukan pengiriman, dengan hasil yang direncanakan alih-alih tanda yang direncanakan, bukan dengan proyek, tetapi dengan tim produk yang andal yang berwenang untuk memeriksa asumsi dan menemukan jalur terpendek menuju nilai.
Sekarang untuk pelatihan (diadaptasi berdasarkan John Cutler chart).
Jadi ... apakah itu berarti Agile pergi? Tentu saja tidak. Ini hanya posting blog yang bodoh. Saya tidak punya kekuatan. Dan bahkan jika itu, Agile masih tidak akan menghilang.
Gerakan Agile telah membuat banyak konsep ini menjadi mungkin . Selain itu, bertentangan dengan kepercayaan populer, praktik lincah tidak ditemukan oleh gerakan Agile. Mereka muncul beberapa dekade sebelumnya.
Jadi tidak, saya tidak ingin Agile pergi.
Saya hanya ingin kita lebih jujur.