Pengembangan Berbasis Misi

Seiring pertumbuhan perusahaan, penskalaan pengembangan produk Agile menjadi lebih ketat. Menurut 52% responden di 13th State of the Agile Report, perbedaan antara budaya organisasi dan nilai Agile adalah kelemahan utama dalam pekerjaan mereka.

Pemimpin organisasi dapat memanfaatkan budaya Agile untuk meningkatkan pengembangan produk. Budaya Agile yang kuat melibatkan otonomi tim dalam menghadapi masalah yang kompleks, kerja sama yang erat dengan klien, dan visi serta strategi jangka panjang.

Nilai-nilai abstrak ini sulit untuk dinilai dan dilibatkan. Dalam sebuah organisasi, menerapkan strategi yang efektif untuk memanfaatkannya menjadi pekerjaan yang tidak sepele. Pendekatan Mission Driven Development (MDD) telah muncul dari startup tahap menengah sebagai alternatif untuk menumbuhkan budaya seperti itu.

Tantangan Penskalaan

Beberapa pola perlambatan dapat muncul saat penskalaan. Motivasi tim bisa berkurang dengan proyek yang tidak jelas akhir ceritanya. Manajer produk dapat merasa tersesat dalam rapat operasional dan dengan demikian kehilangan waktu untuk merancang jalur produk strategis. Penerapan fitur dan produk baru dapat melambat seiring dengan pertumbuhan sistem yang semakin kompleks.

Hambatan ini harus didekati dari perspektif budaya dan praktis. Mengatasinya melibatkan melepaskan kendali, menumbuhkan otonomi tim, menerapkan transparansi radikal, dan menyiapkan kerangka kerja pengembangan produk yang efisien untuk mendorong hasil.

Tantangan Menskalakan Kerangka Agile Tradisional

Saat menskalakan Agile, level manajemen dan tim perlu disinkronkan. Tingkat manajemen bertanggung jawab untuk mengembangkan strategi perusahaan, menciptakan dan mengkomunikasikan visi produk, melaksanakan keputusan kepegawaian, dan mendorong pengembangan tim. Tingkat tim melakukan tugas yang diperlukan untuk secara efisien menerjemahkan visi dan strategi ini menjadi produk dan fitur yang berharga.

Kerangka kerja Agile tradisional (XP, Scrum, dan Kanban) dioptimalkan untuk beroperasi di tingkat tim, sehingga hubungan manajemen sebagian besar tidak tertangani. Gelombang baru kerangka kerja Agile berskala berkembang untuk mengisi celah ini, yaitu, SAFe, LeSS, Scrum of Scrums, Nexus, DAD, dll. Namun, pendekatan ini memerlukan banyak perencanaan untuk diterapkan dan upaya untuk mengelola dan memelihara.

Pendekatan yang ringan, kerangka kerja Pengembangan Berbasis Misi memberikan panduan yang cukup untuk menerapkan struktur yang kuat seputar pengembangan penskalaan dan memanfaatkan nilai-nilai Agile.

Elemen Inti Pengembangan Berbasis Misi

Misi

Titik awalnya adalah Mission Discovery. Sebuah misi bisnis membutuhkan waktu dan usaha dan harus mengidentifikasi masalah laten, ruang solusi, dan hasil bisnis yang diinginkan. Ketika didefinisikan secara akurat, misi mendorong motivasi, mendorong kolaborasi, dan mempromosikan penelitian tentang ruang desain yang lebih luas.

Pasukan

Aktor yang bertanggung jawab untuk keberhasilan setiap misi adalah regu. Bekerja sama dengan manajer produk, tim kecil yang terdiri dari 2-4 orang melakukan aktivitas yang diperlukan untuk memberikan solusi yang sesuai dengan tujuan misi dan batasan waktu.

Siklus 6 Minggu

Kotak waktu 6 minggu memungkinkan semua regu untuk mengikuti garis waktu yang sama untuk perencanaan dasar sambil juga memberikan waktu yang cukup untuk memberikan hasil yang berarti.

Periode Penyangga

Kerangka kerja MDD biasanya mencakup periode penyangga satu atau dua minggu untuk integrasi dan penerapan akhir, pelatihan dan pengembangan keterampilan, kegiatan inovasi, dan perencanaan siklus berikutnya, antara lain.

Pentingnya Siklus 6 Minggu

Sementara periode enam minggu mungkin tampak banyak bagi beberapa praktisi Agile, ini mengandung beberapa manfaat penting.

Tim yang bekerja dalam siklus pendek cenderung kehilangan keterlibatan untuk visi produk, karena mereka merasa seperti memeriksa "daftar cucian" perbaikan, bug, dan fitur kecil. Ini mengancam otonomi tim untuk mengeksplorasi dan memilih cara terbaik untuk memberikan solusi.

Seiring siklus berjalan lebih lama, akurasi estimasi produk menurun. Akibatnya, memerlukan upaya perencanaan yang berat oleh tim produk.

Enam minggu telah disebut sebagai Goldilocks dari kerangka waktu produk, menyediakan cukup waktu untuk memberikan Produk yang Layak Minimum melalui pemikiran inovatif, pembuatan prototipe cepat, dan pengiriman berkelanjutan.

Siklus 6 minggu lebih meningkatkan keterlibatan visi tim dengan memanfaatkan otonomi. Manajemen mikro tidak diperlukan selama misi dinyatakan dengan jelas dan siklusnya cukup singkat bagi tim untuk fokus hanya pada hasil yang diinginkan.

Terakhir, manajer produk dapat terlibat dalam aktivitas perencanaan setiap enam minggu, mempertahankan prediktabilitas yang cukup bagi tim untuk tetap berada di jalur menuju misi. Akibatnya, lebih banyak waktu dapat difokuskan pada dimensi strategis dan eksplorasi pengembangan produk.

Implementasi Pengembangan Berbasis Misi

Mari kita ambil, misalnya, startup tahap menengah yang memiliki produk B2B yang menawarkan pengoptimalan harga jaringan yang meningkatkan pendapatan klien melalui penggunaan aplikasi kecerdasan buatan. Bisnis baru-baru ini menandatangani putaran pendanaan baru, dengan tujuan mengkonsolidasikan dirinya sebagai pelaku industri yang relevan dan meningkatkan pangsa pasar sebesar 300%.

Dalam skenario ini, ada beberapa tantangan pengembangan produk:

• Bagaimana umpan balik dari klien saat ini dan klien potensial diperoleh untuk memvalidasi hipotesis nilai yang tertunda?
• Fitur apa yang harus dibangun atau dihapus dari platform untuk pengalaman pengguna yang menarik?
• Bagaimana struktur manajemen dapat dibentuk untuk menangani penskalaan dan memanfaatkan nilai-nilai budaya untuk mempercepat pertumbuhan?

Pada akhirnya, untuk menghindari kerangka kerja yang kompleks, perusahaan memutuskan untuk menerapkan kerangka Pengembangan Berbasis Misi. Dalam Pengembangan Berbasis Misi, detail "jarak terakhir" ditentukan oleh setiap organisasi. Elemen utama yang harus ditentukan adalah:

• Penemuan misi
• Struktur misi
• perakitan regu
• Inspeksi dan adaptasi
• Iterasi penyangga
• Perencanaan kapasitas

Penemuan Misi

Titik awalnya adalah Mission Discovery. Tim Herbig menggambarkan penemuan sebagai proses berulang untuk mengurangi ketidakpastian seputar masalah atau ide untuk memastikan bahwa produk yang tepat dibuat untuk audiens yang tepat. Sebelum misi apa pun dilakukan dalam siklus iterasi, itu harus divalidasi sekomprehensif mungkin.

Proses Mission Discovery dilakukan oleh tim yang dialokasikan secara khusus. Tim penemuan dipimpin oleh manajer produk dan terdiri dari peneliti produk, analis bisnis, dan desainer. Ketika ada beberapa manajer produk, mereka melapor ke Chief Product Officer (CPO), yang memastikan visi bersama di seluruh produk, kesesuaian produk dan strategi perusahaan global, dan pengiriman tepat waktu.

Titik awal yang direkomendasikan untuk penemuan misi adalah tantangan, masalah, atau peluang. Mulai dari tantangan, misalnya, membantu tim mengeksplorasi lebih banyak ruang desain, akhirnya memperluas kemungkinan solusi.

Validasi misi melibatkan beberapa kegiatan yang membantu perusahaan lebih memahami kebutuhan klien:

1. Melakukan riset pasar dan analisis pesaing
2. Memahami ruang masalah di mana misi didefinisikan
3. Merancang sketsa dan prototipe dengan ketelitian rendah
4. Mendefinisikan ruang lingkup yang jelas untuk misi
5. Mengumpulkan umpan balik dan validasi klien

Kegiatan-kegiatan ini membantu misi menjadi pedoman yang kokoh bagi regu pengembangan dan menjamin bahwa nilai akan tercipta bagi pengguna.

Akibatnya, beberapa misi divalidasi untuk masuk ke Backlog Misi, yang terus berkembang dengan aktivitas penemuan dan pengumpulan umpan balik.

Sebagai contoh, mari kita ambil tantangan ini: Fitur apa yang harus dibangun dari platform untuk menghasilkan pengalaman pengguna yang menarik? Hanya satu tim penemuan, yang dipimpin oleh manajer produk, yang cukup untuk mengatasi tantangan ini.

Mari kita asumsikan bahwa saat ini, platform perusahaan contoh mengambil data mentah klien dan mengembalikan jaringan harga yang dioptimalkan pada file data yang diproses. Namun, UX platform belum dioptimalkan untuk pengalaman yang menawan. Tujuannya pada titik ini adalah untuk menentukan apakah nilai klien akan datang dari peningkatan UX, pengembangan fitur baru, atau peningkatan layanan platform.

Setelah riset pasar awal, keputusannya adalah mengembangkan fitur baru. Fitur kandidat untuk platform adalah:

• Penetapan harga yang sangat cepat
• Antarmuka yang cepat dan responsif
• Aturan penetapan harga yang cerdas dan canggih
• Repricing dan sejarah penjualan

Untuk tujuan penemuan, perusahaan memutuskan untuk mengambil pendekatan sprint desain: proses lima hari untuk menjawab pertanyaan bisnis penting melalui desain, pembuatan prototipe, dan pengujian ide dengan pengguna. Proses penemuan dijalankan untuk setiap fitur kandidat untuk melihat mana yang akan menciptakan nilai lebih bagi klien saat ini dan calon klien. Fitur teratas yang dipilih untuk pengembangan adalah aturan penetapan harga yang cerdas dan canggih.

Struktur Misi

Mencapai definisi misi yang solid bukanlah tugas yang sepele. Itu harus menggambarkan tantangan bisnis yang jelas dan menetapkan batasan untuk hasilnya, sementara juga memberikan ruang yang cukup bagi regu untuk sampai pada solusi yang inovatif dan efisien. Misi yang jelas dan tepat:

• Menyatakan dengan jelas tantangan bisnis, setelah mengidentifikasi dan menggambarkan ruang masalah.
• Mensintesis semua informasi dan wawasan yang ditemukan pada fase sebelumnya.
• Tautan ke hasil bisnis yang diinginkan.
• Berorientasi pada hasil, dengan jelas menunjukkan gambaran keberhasilan misi.
• Realistis dan dapat dicapai dalam kesempatan siklus 6 minggu.
• Cukup sempit untuk menjamin fokus dan cukup lebar untuk menghindari detail.

Dalam contoh, setelah satu minggu penemuan, informasi dan umpan balik pengguna telah dikumpulkan dan disintesis.

Pengguna target: Analis harga klien.

Ruang masalah: Pengguna ingin dapat menetapkan dan mengelola aturan penetapan harga yang cerdas dan canggih sehingga mereka dapat menyesuaikan harga secara otomatis dengan kondisi tertentu.

Kondisi yang paling berharga untuk aturan adalah harga pesaing, urgensi pengiriman, total pesanan, inventaris yang tersedia, dan diskon untuk klien premium.

Wawasan: Aturan harus diterapkan dalam prioritas khusus dan dapat dimodifikasi, jika diperlukan.

Analis ingin dengan mudah melihat aturan mana yang berlaku pada waktu tertentu untuk produk tertentu.

Hasil bisnis yang diinginkan: Tingkatkan keterlibatan platform pengguna sebesar 25%, yang diukur dengan waktu yang dihabiskan di platform.

Majelis Pasukan

Proses pembentukan tim dilakukan secara ad hoc untuk setiap siklus pengembangan. Otonomi tim dan prinsip-prinsip pengorganisasian diri tetap menjadi pusat. Perakitan tim dipandu oleh berbagai faktor, mulai dari kompleksitas misi, keterampilan pengembang dan desainer, minat, dan chemistry skuad.

Proses pembentukan skuad difasilitasi oleh pelatih Agile. Sebelum keputusan apa pun, setiap orang ditanyai jenis pekerjaan apa yang ingin mereka lakukan selama enam minggu ke depan. Kemudian, berdasarkan pengalaman, pengetahuan, dan keterampilan, regu dibangun untuk memastikan mereka memiliki pengetahuan dan keterampilan yang diperlukan untuk berhasil menangani misi.

Pelatih tangkas bekerja dengan beberapa regu di sepanjang siklus pengembangan, membantu mereka meningkatkan hambatan dan ketergantungan. Ketika beberapa pelatih Agile ada, mereka melapor kepada Kepala Agile, yang bertanggung jawab atas perakitan regu, peningkatan berkelanjutan, dan pengiriman produk Agile.

Ukuran skuad yang direkomendasikan adalah 2-4 orang: biasanya, satu desainer dan satu atau dua pengembang, tergantung pada kompleksitas misi. Seorang insinyur QA dianggap membantu satu atau lebih regu dalam mencapai standar kualitas yang diinginkan.

Regu sering dicampur setelah setiap siklus, sehingga setiap orang dapat bekerja sama dengan orang yang berbeda, menyebarkan pengetahuan, dan bekerja pada dimensi produk yang berbeda, meskipun regu berkinerja tinggi dapat bekerja sama untuk beberapa siklus.

Pasukan tertentu dalam contoh harus mempertimbangkan orang-orang dengan desain UI, pemrosesan data, dan kemampuan visualisasi data.

Memeriksa dan Beradaptasi Dalam Siklus

Transparansi, inspeksi, dan adaptasi harus terus didorong oleh pelatih Agile melalui praktik standar Agile.

Pertemuan mingguan singkat diadakan untuk mengatur pekerjaan dan memfasilitasi peningkatan hambatan dan ketergantungan. Perawatan dilakukan, jika perlu, untuk memastikan bahwa regu sepenuhnya memahami misi dan cerita pengguna. Retrospektif singkat dilakukan pada akhir setiap minggu untuk mengidentifikasi dan menerapkan perubahan dan perbaikan.

Praktik penyampaian yang berkelanjutan harus dipertahankan sepanjang siklus. Tujuan misi dapat dicapai lebih awal, karena kotak waktu siklus 6 minggu adalah pendekatan berbasis irama untuk menetapkan aturan dasar sambil membantu mencapai prediktabilitas regu.

Praktik yang baik untuk meningkatkan transparansi adalah demo di akhir minggu keempat, berdasarkan pencapaian yang disepakati antara regu dan manajer produk. Tujuan dari demo ini adalah untuk menyesuaikan, mengurangi, atau meningkatkan cakupan sesuai kebutuhan.

Untuk misi contoh, rencana rilis telah disepakati antara skuad dan manajer produk dalam empat rilis berbeda:

1. Rilis 1:
   • UI fitur aturan baru
   • Aturan harga pesaing
2. Rilis 2:
   • Aturan urgensi pengiriman
   • Aturan total pesanan
   • Prioritas aturan
3. Rilis 3:
   • Aturan inventaris yang tersedia
   • Aturan aplikasi visualisasi
4. Rilis 4:
   • Diskon untuk klien premium

Rilis 3 disepakati sebagai demo untuk minggu keempat. Karena rilis telah dilakukan sepanjang siklus pengembangan, hasil bisnis yang diinginkan (dalam hal ini, keterlibatan pengguna) harus dilacak sejak siklus pengembangan dimulai. Secara grafis, kemajuan diharapkan sebagai berikut:

Periode Penyangga

Mengambil satu atau dua minggu sebagai periode penyangga adalah praktik yang direplikasi melalui implementasi Mission Driven Development, serta melalui pendekatan penskalaan lainnya seperti SAFe.

Dalam SAFe, inovasi dan iterasi perencanaan dilakukan di setiap siklus pengembangan. Ini berfungsi sebagai pengalih konteks, memungkinkan proses dan kegiatan eksplorasi dan inovasi yang biasanya ditinggalkan oleh kerangka kerja yang berfokus pada penyampaian lainnya. Contoh kegiatan yang dilaksanakan dalam buffer week ini:

• Integrasi akhir dari solusi . Saat menerapkan menjelang akhir siklus 6 minggu, kemungkinan integrasi, verifikasi, dokumentasi, dan validasi tetap tertunda. Waktu khusus membantu memastikan integrasi solusi baru yang efektif dan lancar dalam produk yang sudah ada.
• Perencanaan dan prioritas misi . Misi disempurnakan, diklasifikasikan dalam kelompok kecil atau besar, dan diprioritaskan untuk siklus pengembangan berikutnya. Saat memprioritaskan misi, beberapa perusahaan menerapkan hari-hari promosi di mana misi teratas disajikan kepada perusahaan dan kemudian—dengan cara kolaboratif—berkomitmen untuk siklus pengembangan berikutnya.
• Hackathon . Hackathon semakin populer di kalangan startup dan perusahaan berkat kemampuan mereka untuk mendorong inovasi, menciptakan komunitas, dan membangun pengetahuan dan keterampilan baru dengan cara yang menyenangkan. Hasil disajikan kepada orang lain dan menjadi kandidat untuk Backlog Misi.
• Pengembangan prototipe eksperimental atau proyek sampingan . Ini adalah praktik umum untuk memberi waktu kepada para insinyur dan desainer untuk mengerjakan apa pun yang mereka putuskan, selama mereka menunjukkan pekerjaan yang dilakukan pada akhir waktu penyangga.
• Pekerjaan rekayasa . Pekerjaan rekayasa murni seperti pengembangan infrastruktur, otomatisasi pengujian, pengurangan utang teknis, dan migrasi sistem biasanya dilakukan.
• Pengembangan keterampilan dan pengetahuan baru . Laju evolusi pengetahuan yang cepat memaksa pengembang untuk tetap mengikuti tren global. Waktu penyangga cocok untuk mengadakan pelatihan di tempat, komunitas praktik, dan lokakarya teknologi, antara lain.

Periode penyangga harus bergantung pada kesenjangan pengetahuan yang teridentifikasi, tujuan inovasi, dan kebutuhan untuk siklus berikutnya. Misalnya, periode buffer satu minggu dapat terlihat seperti ini:

Perencanaan Kapasitas

Saat memutuskan komitmen misi untuk siklus pengembangan berikutnya, praktik umum, menurut salah satu pendiri Basecamp Jason Fried, adalah mengidentifikasi kelompok kecil atau besar terlebih dahulu. Batch besar mengacu pada fitur atau fungsi produk yang besar, sedangkan batch kecil mengacu pada iterasi atau tugas yang lebih kecil. Dalam contoh yang diberikan, misi yang dipilih untuk fitur baru dapat dianggap sebagai kumpulan besar.

Rekomendasi di sini sangat mudah: selalu memiliki campuran batch kecil dan besar. Batch kecil adalah misi yang diperkirakan memakan waktu 3-4 minggu, dan batch besar bisa memakan waktu enam minggu atau lebih.

Jika tim batch kecil telah menyelesaikan misinya pada minggu ke 3 atau 4, demo yang disepakati adalah kesempatan untuk menilai apakah skuad harus terus bekerja untuk meningkatkan solusi yang diterapkan, membantu regu lain, mengambil misi batch kecil baru, atau memulai pekerjaan yang tidak direncanakan.

Campuran yang baik dari batch besar dan kecil membuat orang tidak bekerja pada kapasitas 100%, sehingga memungkinkan mereka untuk bermanuver dan beradaptasi jika ada pekerjaan yang tidak direncanakan. Tim batch besar mendapatkan fokus sebanyak mungkin selama siklus, sementara tim batch kecil dapat menangani tugas ad hoc yang muncul dari pekerjaan yang tidak terduga.

Menggabungkan batch kecil dan besar juga mengurangi risiko. Hanya memiliki batch besar dapat meningkatkan kemungkinan dampak negatif pada pengalaman pengguna. Jika beberapa fitur baru dirilis berdekatan, mereka harus disertai dengan manajemen perubahan yang baik. Selanjutnya, dalam kasus pekerjaan yang tidak direncanakan, akan ada lebih sedikit kapasitas yang tersedia. Terakhir, jika beberapa tim besar gagal, pengulangan dapat dianggap tidak produktif dan dengan demikian menurunkan semangat regu.

Risiko Pengembangan Berbasis Misi

Ada banyak manfaat dari penerapan Mission Driven Development, tetapi seperti halnya kerangka kerja preskriptif lainnya, ia memiliki beberapa risiko bawaan yang perlu dipertimbangkan.

Lingkup Misi

Misi harus realistis, bertujuan pada kesesuaian yang baik antara kompleksitas tantangan dan keterampilan regu; jika tidak, dampak pada hasil pembangunan dapat menjadi signifikan.

Misi yang terlalu ambisius dapat meningkatkan frustrasi dan kecemasan, yang berdampak negatif pada kinerja skuad. Di sisi lain, misi yang tidak antusias dapat menyebabkan demotivasi dan kebosanan pasukan. Dengan demikian, mentalitas Produk yang Layak Minimum harus tetap konstan dalam kerangka kerja.

Mengapa sebuah Misi

Misi bisnis yang kuat harus memiliki definisi yang komprehensif tentang ruang masalah dan hubungannya dengan visi perusahaan. Jika hubungan ini tidak jelas, wawasan berharga dapat hilang karena kurangnya pemahaman tentang bagaimana penyelesaian masalah berdampak pada tujuan perusahaan.

Perangkap Air Terjun

Jatuh ke dalam model air terjun selama enam minggu adalah kecenderungan alami untuk regu. Ada dua faktor utama untuk ini. Pertama, tekanan untuk penerapan lebih kuat menjelang akhir siklus. Kedua, regu ingin memeras ruang lingkup sebanyak mungkin dalam misi, menghasilkan urgensi untuk disebarkan di akhir siklus pengembangan. Oleh karena itu, praktik pengiriman berkelanjutan harus didorong untuk mencapai rilis Agile sepanjang siklus dan menghindari risiko terkait air terjun.

Operasi Produk

Tugas operasi produk seperti mengelola infrastruktur, layanan, atau komponen pemantauan harus disimpan di luar lingkup regu, karena dapat memengaruhi kecepatan. Mengandalkan standar dan praktik pengembangan seperti desain atomik mengurangi upaya pengembangan dan akibatnya mempercepat penskalaan. Praktik umum lainnya di bawah kerangka kerja ini adalah tim operasi pusat yang menangani infrastruktur, selain mengelola operasi dan pemantauan produk.

Siklus 6-Minggu sebagai Kerangka Myopic

Beberapa skenario tidak akan cukup untuk kerangka kerja. Ini menjadi benar terutama ketika berhadapan dengan sistem besar dan kompleks yang dapat memiliki dampak besar pada pengalaman klien, seperti proyek R&D atau migrasi sistem kritis.

Opsi Ringan untuk Scaling Agile

Menskalakan Agile untuk mengikuti laju pengembangan produk dan pertumbuhan perusahaan merupakan tantangan laten bagi para praktisi Agile. Sebagai pendekatan Agile yang baru-baru ini dikembangkan, kerangka kerja Mission Driven Development telah mendapatkan popularitas di kalangan perusahaan karena kemudahan penggunaan dan implementasinya. Kerangka kerja MDD menggerakkan proses inovasi produk transversal end-to-end, dari penemuan hingga pengiriman, yang mengisi kesenjangan yang ada dalam struktur Agile tradisional. Mission Driven Development berpotensi menjadi Scrum baru bagi perusahaan yang sedang berkembang.