Apa itu Agile? Filosofi yang Berkembang Melalui Praktek

Awalnya dirancang untuk tim pengembangan perangkat lunak, Agile sekarang menjadi pendekatan manajemen proyek utama untuk industri dan perusahaan di seluruh dunia. Daya tariknya terletak pada kesederhanaan dan fleksibilitasnya: kurangnya praktik preskriptif Agile membuatnya sangat mudah diadopsi. Namun, ketika memandu transformasi Agile di beberapa perusahaan, saya menemukan fleksibilitas ini juga menghasilkan kesalahpahaman tentang apa artinya menjadi Agile. Banyak perusahaan memprioritaskan mematuhi kerangka kerja yang diturunkan dari Agile daripada memahami filosofi itu sendiri.

Sebaliknya, manajer proyek dan pelatih yang merakit dan membimbing tim Agile harus mulai dengan melatih mereka dalam mengadopsi pola pikir Agile, yang pada dasarnya menginternalisasi nilai dan prinsip inti filosofi. Hanya dengan demikian mereka harus menggabungkan, menyesuaikan, atau menghilangkan praktik dari kerangka kerja Agile berdasarkan apa yang paling sesuai dengan persyaratan proyek.

Dengan menelusuri perkembangan historis Agile dan mengaitkan prinsip-prinsip pendiriannya dengan kebutuhan spesifik perusahaan dan tim, artikel ini dapat membantu manajer proyek menciptakan masa depan yang optimal untuk transformasi Agile. Seperti yang ditunjukkan oleh kasus berikut, Agile tidak boleh dianggap sebagai pendekatan manajemen proyek secara ketat, melainkan filosofi pengembangan produk yang terus berkembang dalam praktik.

Anteseden Agile

Pertama kali dikompilasi pada tahun 2001, “Manifesto for Agile Software Development,” kumpulan ringkas dari empat nilai inti dan 12 prinsip, merupakan respons radikal terhadap pendekatan linier dan proses yang sarat dengan aturan dan rim dokumentasi. Tetapi sejarah Agile berasal beberapa dekade sebelumnya dengan metode untuk merampingkan manufaktur industri.

Anteseden dari filosofi untuk fokusnya pada perbaikan berulang, model Plan-Do-Study-Act dikembangkan pada tahun 1930-an oleh fisikawan dan ahli statistik Bell Labs Walter Shewhart. Setelah Perang Dunia II, anak didiknya, W. Edwards Deming, menerapkannya untuk melatih para manajer di Toyota. Metode ini merupakan bagian integral dari pengembangan Toyota Production System, sumber utama pemikiran Lean dengan loop build-measure-learn yang efisien.

Pada tahun 1970-an, konsep ini dikembangkan lebih lanjut ketika Barry Boehm mengusulkan teknik Wideband Delphi, menggunakan proses berulang untuk secara akurat dan obyektif memperkirakan tenaga kerja dan waktu yang dibutuhkan untuk mengembangkan perangkat lunak.

Dengan menjamurnya komputer pribadi pada pertengahan 1980-an, menjadi jelas bahwa perangkat lunak sebagai produk dan layanan akan menjadi landasan cara orang melakukan bisnis. Ketika para profesional mulai memberikan perhatian serius pada pendekatan bertahap dan berulang untuk rekayasa perangkat lunak, Agile melampaui proses Waterfall sebagai pendekatan pengembangan dan manajemen yang unggul.

Para peneliti menemukan bahwa produsen yang berinovasi lebih cepat daripada pesaing mereka menggunakan metode multidisiplin, berorientasi tim untuk menggerakkan produk melalui siklus hidupnya. Ini secara luas dianggap sebagai inspirasi Jeff Sutherland untuk menemukan kerangka kerja Scrum pada tahun 1993, yang memungkinkannya untuk menyelesaikan proyek yang tampaknya mustahil sesuai jadwal dan anggaran, dengan bug minimal.

Nilai Agile dalam teori—muncul dari anteseden ini—telah dibuktikan dalam penggunaan Agile dalam praktik saya, dengan penekanan pada pengembangan berulang, kerja tim kolaboratif, dan estimasi yang akurat.

Apa itu Agile dalam Teori?

Karena perusahaan terus mengadopsi cara kerja Agile, mereka berisiko membuatnya lebih menentukan daripada yang pernah dimaksudkan oleh para pembuat filosofi. Dalam pengalaman saya, para pemimpin yang ingin mengadopsi Agile terlalu fokus pada kerangka kerja—atau serangkaian praktik khusus dan nomenklatur terkaitnya—dan tidak cukup pada nilai dan prinsip.

Seperti yang diketahui dengan baik oleh praktisi yang mahir dalam menanamkan prinsip Agile, setiap organisasi yang ingin menjalani transformasi Agile harus menemukan dan menyesuaikan pendekatan yang sesuai dengan mereka. Saya memfasilitasi proses pembelajaran ini dengan menunjukkan kepada tim bagaimana mengikuti nilai dan prinsip manifesto dan kemudian mengambil inspirasi dari kerangka kerja, seperti Scrum, Kanban, dan Extreme Programming (XP), untuk menerapkannya dalam praktik.

Prinsip manifesto sekarang menjadi sifat kedua bagi manajer proyek Agile:

1. Individu dan interaksi atas proses dan alat
2. Produk yang berfungsi melalui dokumentasi yang komprehensif
3. Kolaborasi pelanggan melalui negosiasi kontrak
4. Menanggapi perubahan mengikuti rencana

Peringatan yang mengikuti prinsip-prinsip ini dalam manifesto, bagaimanapun, sering diabaikan: "Artinya, sementara ada nilai di item di sebelah kanan, kami lebih menghargai item di sebelah kiri." Banyak praktisi Agile akhirnya mengabaikan nilai-nilai di sebelah kanan dan hanya berfokus pada apa yang ada di sebelah kiri. Hasil? Kebalikan dari mengikuti kerangka proses-berat secara membabi buta: tidak ada proses sama sekali, yang sama-sama bermasalah.

Mencapai keseimbangan yang tepat antara item di kanan dan kiri telah menjadi kunci bagaimana saya memandu transformasi Agile. Ini juga dicontohkan oleh pendekatan manajemen di Apple, Google, Amazon, Facebook, dan Netflix, tidak ada yang berlangganan kerangka kerja Agile tunggal. Mereka telah mewujudkan prinsip-prinsip manifesto pertama dan terutama, sambil mengikuti atau mengubah bagian dari kerangka kerja yang berbeda berdasarkan apa yang paling berhasil bagi mereka; sebagai hasilnya, mereka telah beradaptasi dengan perubahan pasar dan mampu memberikan produk baru dengan cepat.

Apa yang Agile dalam Praktek?

Dalam ikhtisar berikut, saya telah memodifikasi ungkapan asli dari nilai-nilai manifesto. Perubahan pada semantik membantu memperjelas bagaimana saya menerapkan nilai Agile dalam praktik.

Pada nilai pertama, saya mengganti istilah “individu” dengan “orang” karena menjadi gesit berarti berorientasi pada tim. Adapun yang kedua, jelas bahwa perangkat lunak harus "berfungsi", jadi fokusnya sekarang adalah "pengiriman" yang sukses dan tepat waktu. Nilai ketiga hanyalah "kolaborasi," karena itu berlaku sama untuk rekan kerja yang bekerja bersama dan tim yang bekerja dengan klien. Akhirnya, "kerangka" menggantikan "mengikuti rencana," karena ini mencegah kesalahpahaman bahwa perencanaan harus ditinggalkan sama sekali.

Orang Di Atas Proses

Transformasi tangkas sulit dilakukan, terutama karena sebagian besar bisnis terbiasa mengikuti proses secara ketat. Menyelesaikan sejumlah langkah dengan seperangkat alat tertentu, alih-alih mengembangkan produk inovatif, menjadi tujuan akhir.

Saya kecewa melihat mentalitas ini memunculkan “industri Agile” yang menguntungkan. Seperti yang dijelaskan oleh pendiri Agile, Ward Cunningham dan Jon Kern, banyak bisnis menjual perangkat lunak yang mereka klaim akan membantu perusahaan “menjadi Agile.” Tetapi menjadi Agile berarti mengadopsi filosofi, tidak menggunakan perangkat lunak dan mengikuti program yang ditentukan.

Mencapai keseimbangan yang tepat bukan tentang menghilangkan prosedur, melainkan menemukan prosedur yang paling mendukung tujuan pengembangan masing-masing tim. Untuk salah satu klien saya, sebuah organisasi teknologi perusahaan besar, saya menerapkan Disiplin Agile, sebuah pendekatan yang dikembangkan di IBM. Ini menggabungkan banyak praktik dari berbagai kerangka kerja, termasuk Scrum dan Kanban. Ini menggunakan pengembangan berulang tetapi sedikit lebih banyak proses daripada Agile tradisional, terutama di fase awal, karena itu dimaksudkan untuk mengisi celah yang ditinggalkan oleh Scrum. Disiplin Agile bekerja untuk klien ini karena organisasinya sangat berorientasi pada proses. Itu memungkinkan saya untuk bertemu tim di tengah jalan, mendapatkan dukungan mereka, dan membujuk mereka untuk mengadopsi alur kerja Scrum.

Saya menggabungkan rapat perbaikan backlog, rapat tinjauan, dan scrum harian untuk memfasilitasi kolaborasi intra dan antar tim. Penyempurnaan backlog adalah bagian dari Panduan Scrum, tetapi pertemuan penyempurnaan tidak. Saya menambahkan ini untuk mengaktifkan percakapan yang sehat tentang mengapa kami berencana untuk mengimplementasikan fitur tertentu dalam sprint mendatang, yang berguna untuk pemula Agile. Saya juga memilih nomenklatur “tonggak sejarah”—istilah yang digunakan dalam manajemen proyek Waterfall—karena lebih familiar bagi klien. Ulasan dan interaksi scrum harian adalah elemen konvensional dari Panduan Scrum, tetapi saya membuatnya lebih terstruktur dalam hal jadwal, durasi, dan alur.

Selain itu, sementara kepatuhan yang ketat terhadap Scrum akan membuat setiap orang sepenuhnya didedikasikan untuk salah satu peran yang tercantum dalam Panduan Scrum, ada orang-orang di tim klien saya yang keahliannya tidak sesuai dengan satu peran. Menggunakan metode Disiplin Agile memungkinkan saya untuk membagi tanggung jawab posisi ini di antara beberapa anggota tim dan menciptakan proses yang memainkan kekuatan orang-orang yang terlibat.

Pengiriman Perangkat Lunak Melalui Dokumentasi

Alasan lain saya lebih memilih alur kerja Scrum atau Kanban yang disesuaikan daripada kepatuhan yang ketat dengan salah satu kerangka kerja adalah karena mereka memberi saya kesempatan untuk menambahkan produk yang layak minimum (MVP) ke dalam rencana sebagai tujuan. Berasal dari Lean, praktik membuat MVP konsisten dengan pengembangan berulang dan telah menjadi teknik populer di kalangan praktisi Agile. Ini memungkinkan tim untuk mengirimkan perangkat lunak berkualitas tinggi dan barang lainnya kepada pengguna secara efisien dan kemudian menyempurnakannya berdasarkan umpan balik. Menerapkannya sebagai bagian dari pendekatan hibrida yang sebagian besar didasarkan pada Scrum atau Kanban telah meningkatkan kemampuan tim saya untuk menciptakan produk yang memenuhi kebutuhan pelanggan.

Saat ini saya bekerja dengan startup yang berbasis di AS dan menggunakan metode ini dalam membangun pasar cryptocurrency untuk NFT. Kami berfokus pada pembuatan MVP, jadi kami hanya menulis dokumentasi minimal yang diperlukan untuk saat ini. Meskipun pendekatan ini efektif untuk berbagai macam produk, ini sangat berguna untuk cryptocurrency dan NFT, yang berada dalam kategori eksperimental baru yang berubah dengan cepat. Alih-alih menyusun spesifikasi dan fitur lengkap, dan harus mengubahnya berulang kali sebelum rilis, kami dapat mencurahkan waktu itu untuk memasukkan umpan balik pengguna guna meningkatkan pengembangan pasar kami.

Kolaborasi Atas Kontrak

Organisasi teknologi perusahaan besar yang disebutkan di atas sangat bergantung pada kontrak untuk banyak proyek biaya tetap. Kontrak menguraikan metode yang akan mereka gunakan untuk menyelesaikan pekerjaan, serta individu tertentu yang akan bertanggung jawab untuk setiap tugas. Setelah ditandatangani, kontrak tidak dapat diubah tanpa proses permintaan yang panjang.

Bagian dari transformasi yang saya pimpin adalah kolaborasi yang diprioritaskan daripada kesepakatan kaku ini. Rencana yang kami terapkan menggantikan kontrak dengan dokumen satu halaman. Masing-masing menyatakan bahwa kami setuju untuk menggunakan Agile untuk bekerja secara kolaboratif—dengan pelanggan kami, serta rekan tim dan kolega kami dari tim yang berbeda—antara tanggal mulai dan akhir yang ditentukan. Apa pun yang keluar dari kolaborasi akan menjadi hasilnya. Saya tidak memasukkan secara spesifik tentang apa produk jadinya. Karena kami meminta umpan balik pelanggan dan memasukkannya ke dalam pengembangan produk kami, menghapus spesifikasi dari dokumen rencana kami membuat kami lebih menerima tanggapan mereka dan mendorong mereka untuk bekerja dengan kami lebih aktif.

Untuk mendapatkan manajemen di papan, saya meminta mereka untuk membiarkan saya memimpin bukti konsep dengan satu tim kecil yang bekerja dengan satu klien kecil, yang telah menyatakan keprihatinan bahwa waktu pengembangan terlalu lama, bahkan sebelum perubahan yang diperlukan menambah masalah. Dengan meminta pelanggan ini berkolaborasi langsung dengan pemilik produk kami, kami dapat membuat perubahan di tengah pengembangan dan mengurangi waktu pengiriman secara signifikan.

Hasil ini meyakinkan manajemen untuk mengizinkan saya meluncurkan rencana tersebut ke lebih banyak tim. Secara keseluruhan, kontrak yang disederhanakan dan alur kerja Agile kami mengurangi waktu yang dibutuhkan untuk mengembangkan dan membawa fitur produk ke pasar.

Adaptasi Lebih Dari Kerangka

Klien saya yang lain, sebuah perusahaan teknologi kesehatan, juga gagal mencapai keseimbangan dalam hal mengakui pentingnya kedua sisi nilai Agile, yaitu menanggapi perubahan daripada mengikuti rencana. Namun, dalam kasus ini, itu membuat kebalikan dari kesalahan yang dimiliki klien teknologi perusahaan saya: Alih-alih mengikuti proses terlalu kaku, itu telah mengindeks fleksibilitas secara berlebihan sementara sebagian besar mengabaikan proses. Para insinyur jarang tahu apa yang harus mereka kerjakan karena tidak ada prioritas atau jadwal. Mereka kehilangan waktu dan produktivitas karena mencoba mencari tahu setiap hari dan menyelesaikan tugas yang kurang penting sebelum tugas yang lebih penting.

Saya mengusulkan penerapan Scrum kepada CEO dan CTO, menjelaskan bahwa sprint akan memaksa para insinyur untuk disiplin dan merencanakan dalam peningkatan dua minggu, dibandingkan dengan memutuskan apa yang harus dikerjakan setiap hari. Juga, saya menyarankan agar mereka mempekerjakan pemilik produk, yang akan memperbaiki kurangnya akuntabilitas produk tim. Saya meminta para eksekutif untuk memberi saya tiga atau empat bulan untuk bekerja dengan tim mereka sebelum mereka dapat mengharapkan untuk melihat hasilnya.

Setelah mendapatkan persetujuan mereka, pertama-tama saya memperkenalkan nilai dan prinsip Agile, kemudian melatih tim tentang backlog produk dan berbagai teknik untuk mengaturnya, termasuk membuat epos dan cerita pengguna, dan membuat subtugas. Teknik dan pertemuan yang kami sertakan dalam alur kerja kami adalah penyimpangan dari Scrum tradisional karena tidak muncul di Panduan Scrum. Saya mengintegrasikannya ke dalam rencana karena epik, cerita, dan subtugas beresonansi dengan tim selama pelatihan dan pertemuan mendorong diskusi yang produktif.

Saya juga menyertakan konsep kecepatan, tambahan terakhir untuk XP yang mengukur perkiraan upaya total untuk semua cerita pengguna di setiap iterasi produk. Namun, saya menggunakan istilah "kapasitas", yang lebih saya sukai karena menekankan seberapa banyak anggota tim kerja dapat mengambil alih daripada seberapa cepat mereka dapat menyelesaikan tugas.

Untuk perkiraan, saya mulai dengan ukuran T-shirt, teknik yang mengukur proyek dan tugas sebagai kecil, sedang, dan besar; seiring kemajuan tim, saya beralih ke poin cerita, teknik estimasi yang lebih tradisional. Poin cerita sering disalahgunakan oleh tim yang belum tahu di Agile, yang mencoba mengubahnya menjadi jam atau hari kerja, terlalu fokus pada kerangka waktu dan menilai orang berdasarkan kemampuan mereka untuk memenuhi tenggat waktu.

Ukuran kaos lebih abstrak, sehingga memudahkan tim untuk menghindari perangkap ini. Namun, itu juga kurang tepat. Jadi, begitu tim memahami cara memperkirakan secara relatif, saya mengalihkannya ke teknik yang lebih canggih.

Pada saat tim menyelesaikan dua sprint, manajemen senior dapat melihat karyawan mereka bekerja lebih produktif dan berkomunikasi lebih efektif. Pengembang terlibat dengan pemangku kepentingan dan manajemen eksekutif untuk pertama kalinya. Mereka telah bertemu dengan tim dukungan pelanggan dan telah memperoleh pemahaman tentang bagaimana fitur yang mereka terapkan meningkatkan kehidupan pengguna.

Pendekatan ini segera menyebabkan peningkatan kualitas perangkat lunak perusahaan dan pengurangan waktu pengiriman untuk fitur baru dari bulan ke minggu.

Apa Masa Depan Agile?

Pandemi COVID-19 menciptakan realitas baru di mana tim tidak dapat lagi ditempatkan bersama, yang merupakan cara yang lebih disukai untuk bekerja di dalam Agile saat pertama kali dibuat. Namun, gagasan bahwa harus tetap seperti ini adalah mitos: Karena pekerjaan jarak jauh telah menjadi hal biasa, menjadi jelas bahwa komunikasi yang dekat sangat mungkin dilakukan dengan perangkat lunak konferensi video. Tim yang bekerja dengan saya sekarang terdistribusi sepenuhnya, dan saya memberikan pelatihan dari jarak jauh. Beberapa tim bahkan memilih untuk bekerja secara asinkron, menggunakan alat seperti Notion dan Loom, serta plugin Slack seperti Standuply.

Model kolaborasi terdistribusi adalah dunia kerja baru, dengan kelincahan di pusatnya. Keseimbangan kehidupan kerja yang diberikan kepada tim jarak jauh memiliki dampak positif pada moral dan kesehatan mental, yang meningkatkan produktivitas dan kualitas; itu menempatkan orang di atas proses dan fleksibel dan mudah beradaptasi, menjadikannya pada dasarnya Agile.

Pelatih yang gesit, master Scrum, dan manajer proyek harus kembali ke akar filosofi dan menyajikannya seperti yang dilakukan oleh pembuat manifesto: seperangkat pedoman pengembangan dan penyampaian yang fleksibel dan dinamis. Mereka harus mengajari para eksekutif dan pemimpin tim bahwa, meskipun mereka dapat mengambil inspirasi dari manajemen proyek, mereka tidak benar-benar mengelola apa pun di Agile—mereka membimbing tim dan membebaskan mereka untuk melakukan pekerjaan terbaik mereka.