Perjalanan ke Agile: Bagaimana Braze Membayangkan Kembali Proses Manajemen Proyek Perangkat Lunaknya

Membuat Rencana

Setelah beberapa refleksi, kami memutuskan untuk beralih ke metodologi yang terbukti benar untuk tim teknik—kami memutuskan ingin menjadi lebih Agile.

Untuk menghadapi tantangan baru ini, kami ingin membentuk grup yang akan mewakili dan memanfaatkan pengetahuan seluruh organisasi produk dan teknik kami—jadi kami membuat komite dengan delapan anggota yang mewakili manajemen produk, desain, dan teknik. Kami menyertakan manajer dan kontributor individu, serta orang-orang dengan berbagai tingkat latar belakang, senioritas, dan pengalaman Agile.

Komite Agile ini, seperti yang kami sebut, mendekati situasi dengan beberapa prinsip utama dalam pikiran:

• Kami ingin menggunakan solusi yang terbukti jika memungkinkan, baik di seluruh metodologi dan perangkat lunak. Dibutuhkan banyak upaya untuk menjadi unik dan kami ingin menjadi unik hanya di area yang diperlukan dan strategis. Kami juga ingin orang-orang dapat menerapkan praktik terbaik Google tentang mengelola pekerjaan mereka—atau, lebih baik lagi, membuat orang bergabung dengan Braze sudah mengetahui sebagian besar cara melakukannya.
• Kami ingin tim teknik produk di Braze sebagian besar konsisten dalam cara mereka beroperasi, karena kemampuan berbicara dalam bahasa yang sama sangat berharga.
• Kami tidak ingin melakukan sesuatu secara dogmatis, atau tanpa berpikir matang. Hanya memilih metode dan kemudian membaca buku itu tidak cukup baik; penting bagi kami bahwa akal sehat dan iterasi yang bijaksana menguasai hari itu.

Berbekal pedoman tersebut, kami memutuskan untuk menggunakan Scrum, yang merupakan kerangka kerja Agile yang terbukti efektif untuk banyak organisasi. Ini dikenal luas, skalabel, dan merupakan pilihan default yang aman saat Anda ingin mengimplementasikan proses Agile.

Selanjutnya, kami menghadapi dua keputusan utama: (1) alat apa yang harus kami gunakan untuk mendukung proses baru kami dan (2) bagaimana kami harus meluncurkan perubahan pada proses kami. Kami membicarakan, mengevaluasi, dan mendemonstrasikan beberapa perangkat lunak—dan akhirnya Jira Atlassian terbukti menjadi pilihan yang tepat bagi kami. Ini adalah solusi yang telah terbukti dengan baik, beberapa orang di tim kami sudah memiliki pengalaman menggunakannya, dan tim lain dalam Braze sudah menggunakannya, membuka peluang untuk kolaborasi lintas tim yang lebih baik karena kami semua akan bekerja dalam satu sistem.

Saat memilih rencana peluncuran untuk Agile, kami memiliki beberapa keputusan penting untuk dibuat. Pertama, bagaimana kita melatih/mengaktifkan tim? Kami dapat menyewa pelatih Agile, meminta orang-orang dengan pengalaman dalam tim melakukan pekerjaan melatih yang lain, atau meminta konsultan untuk membantu. Kedua, haruskah kita membuat tim dalam teknik yang memiliki pengalaman dengan Agile menunggu pelatihan sebelum mengimplementasikannya?

Pada akhirnya, kami memutuskan untuk membiarkan tim yang akrab dengan Jira dan Scrum memulai sejauh mereka merasa mampu, dan menyewa konsultan untuk membantu transisi di seluruh organisasi. Kami tidak tertarik memiliki orang-orang di tim kami atau pemain independen yang terutama bertanggung jawab untuk melatih anggota tim melalui transisi karena:

• Kami tidak ingin tim individu memiliki bagaimana kami melakukan Agile dan kami merasa bahwa pelatihan akan diterima dengan lebih baik dan saran akan lebih inklusif jika mereka datang dari pihak ketiga
• Kami pikir bisnis konsultasi akan lebih stabil dan lebih andal daripada pelatih Agile individu
• Kami ingin memiliki pelatihan dasar untuk seluruh organisasi teknik dan memulai tanpa membuat asumsi apa pun tentang pengetahuan yang dimiliki individu anggota organisasi tentang Agile
• Akhirnya, kami ingin agar para pelatih pergi pada titik tertentu, untuk memperjelas bahwa setiap orang di organisasi kami bertanggung jawab untuk mempertahankan proses ke depan.

Menjalankan Rencana

Setelah beberapa bulan perencanaan, kami memiliki dokumen besar yang merinci semua yang ingin kami lakukan—dan kami membagikannya dengan organisasi secara luas untuk mendapatkan umpan balik. Kemudian, setelah mengevaluasi beberapa vendor, kami memilih Eliassen untuk bermitra dengan kami dalam perjalanan ke Agile. Perjalanan itu dimulai dengan pelatihan Agile dua hari yang dijalankan oleh Eliassen, diikuti dengan pelatihan Agile selama tiga bulan dari seorang ahli yang terhubung dengan kami oleh Eliassen.

Sejak awal, kami cukup berhati-hati untuk pindah ke Jira dan Scrum. Baik internet maupun pengalaman pribadi tim kami penuh dengan kisah peringatan tentang bahaya pendekatan yang terlalu dogmatis, tentang bagaimana Jira dapat berfungsi sebagai "anti-pola", dan semua cara Scrum dapat menjadi serba salah dalam organisasi. Kami telah sangat diperingatkan oleh orang-orang yang kami konsultasikan bahwa perubahan ini kemungkinan akan memakan waktu, dan bahwa mungkin ada rasa sakit yang tumbuh sebelum kami melihat manfaat nyata dari Agile.

Untungnya, kami langsung menemukan nilai dalam proses baru. Salah satu hal menyenangkan tentang transisi ini adalah kami tidak pernah merasakan tekanan untuk mengikuti secara membabi buta aspek tertentu dari Scrum; untuk membuat segalanya bekerja lebih baik, kami akan melakukan retrospeksi tentang bagaimana segala sesuatunya berjalan setiap beberapa minggu, dan kemudian memodifikasi apa yang perlu dimodifikasi. Dan selama tiga bulan pelatihan, kami menerapkan perubahan besar di seluruh organisasi teknik:

• Semua orang belajar cara menulis, merawat, menunjuk, memecah, dan mengambil cerita pengguna
• Standup menemukan fokus baru ketika harus menyelesaikan pekerjaan yang ada
• Produk, Desain, dan Teknik semuanya belajar berbicara dalam bahasa yang sama, dan antarmuka semakin dirancang dengan baik

Hasil

Sekarang kita berada di sisi lain dari upaya sekitar enam bulan ini, perubahannya jelas—dan dramatis. Kami telah melihat pengurangan yang signifikan dalam masalah yang mengarah pada upaya ini. Dengan Agile, kami sekarang memiliki mekanisme yang jelas dan mudah dipahami untuk signoff, kolaborasi, pembuatan backlog, dan perawatan, dan kami secara teratur menjalankan retrospektif tentang apa yang harus ditingkatkan.

Kami juga memiliki lokasi yang jauh lebih konsisten untuk artefak desain, serta harapan yang lebih selaras tentang apa yang sebenarnya "selesai" untuk proyek tertentu. Melihat apa yang sedang dikerjakan tim lain menjadi mudah dan lebih sederhana dari sebelumnya bagi orang-orang untuk memahami cara bekerja sama dengan baik.

Sesuatu yang saya perhatikan di akhir transisi ini adalah bahwa jumlah total permintaan penarikan terbuka di organisasi pada waktu tertentu telah menurun, bahkan saat kami melakukan lebih banyak dan mengembangkan ukuran tim kami. Dengan bekerja sedikit demi sedikit dan fokus pada penyelesaian, jumlah item dalam penerbangan menyusut secara signifikan.

Keberhasilan yang kami miliki dalam organisasi kami juga telah menginspirasi orang lain. Kami mulai melihat tim di departemen lain di Braze memulai transformasi Agile mereka sendiri, sehingga lebih banyak orang akan berbicara dalam bahasa yang sama dan memiliki alat yang mereka butuhkan untuk mendefinisikan dan meningkatkan kolaborasi.

Bawa pulang

Dua elemen utama dari upaya kami memastikan keberhasilannya.

Pertama, fakta bahwa itu didorong oleh komite perwakilan sangat penting dalam memperoleh masukan dari seluruh organisasi teknik dan dari berbagai perspektif yang berbeda. Di seluruh perusahaan, orang merasa didengar dan terwakili dalam suatu masalah yang akan memengaruhi pekerjaan mereka sehari-hari. Pembuatan dokumen menyeluruh selanjutnya yang menguraikan motivasi dan rencana untuk transisi Agile yang dapat dibagikan dengan tim juga cukup berguna. Kami percaya dalam menunjukkan bagaimana keputusan dibuat dan memperkenalkan jalur yang jelas untuk umpan balik—karena memberikan konteks dan menetapkan artifak untuk memberikan umpan balik.

Kedua, keputusan untuk mendapatkan pihak ketiga untuk membantu melatih tim kami sangat penting. Memiliki mitra yang objektif dan berpengalaman memberi kami kemampuan untuk dengan cepat melakukan banyak perbaikan pada proses kami. Pelatih kami tahu seperti apa penampilan yang bagus dan mampu membuat rekomendasi tanpa bias, beberapa kali kami dapat bertanya, “Bagaimana tim biasanya melakukan X?” dan segera dapatkan solusi yang bisa diterapkan. Jika, di sisi lain, kami menggunakan sumber daya internal, kami akan menanggung risiko bahwa umpan balik yang kami terima berasal dari pihak yang bias dan meningkatkan pertikaian sumber daya dengan tanggung jawab yang ada.

Ada yang lain?

Jika Anda ingin mempelajari lebih lanjut tentang pendapat kami tentang produk kami dan upaya yang dilakukan untuk membuatnya, lihat Building Braze. Tertarik untuk bergabung dengan tim kami? Lihat lowongan pekerjaan kami saat ini.