Di luar upacara dan artefak

Bagaimana kami menciptakan tim Agile berkinerja tinggi dalam Teknologi Global.

oleh Hiren Patel, Manajer Senior, Manajemen Proyek

Hingga tahun 2022, tim Produk dan Rekayasa Restoran di Teknologi Global sedang membangun dasbor menggunakan metodologi air terjun. Hal ini terjadi sebagian karena McDonald's mengalihdayakan pengembangan, dan mungkin tergoda untuk menentukan semua detail ruang lingkup dan hasil akhir di muka dalam kontrak.

Tidak mengherankan, tim tersebut menghadapi masalah yang sama yang sering dikaitkan dengan proyek air terjun di mana-mana, dan pada akhirnya kurang efektif. Selain itu, ada kesenjangan desain yang besar antara produk yang dibuat versus apa yang kompatibel dalam ekosistem McDonald's.

Posting ini berbicara tentang bagaimana kinerja, serta persepsi, tim kami meningkat pada tahun 2022, setelah tim mengubah pendekatannya. Tim menerapkan kerangka kerja scrum metodologi Agile tetapi mengatakan itu tidak menjelaskan semuanya.

Tim di banyak perusahaan di seluruh dunia berasumsi bahwa mereka adalah tim Agile begitu mereka menerapkan upacara scrum dan artefak. Setelah melihat lebih dekat, menjadi jelas bahwa meskipun banyak dari tim tersebut mengadopsi mekanisme scrum, mereka tidak memiliki pola pikir yang benar untuk menjadi sukses. Faktanya, mereka sering diberi ruang lingkup tetap, tenggat waktu tetap, dan anggaran tetap, yang mereka uraikan menjadi apa yang disebut cerita pengguna dan digabungkan menjadi sprint. Intinya, mereka adalah tim air terjun yang menyamar sebagai tim Agile, meski tidak disengaja.

Tim kepemimpinan kami mendukung kami dalam mengadopsi pola pikir yang benar dan di bawah ini adalah beberapa sorotan tentang cara kami menciptakan tim Agile yang berkinerja tinggi.

Fokus pada produk daripada proyek
Ketika orang berpikir tentang proyek, mereka berasumsi bahwa proyek memiliki akhir yang terbatas. Bahkan, banyak organisasi manajemen proyek profesional terkemuka secara eksplisit mendefinisikan sebuah proyek memiliki akhir yang terbatas. Di permukaan, gagasan proyek tampak sangat praktis di dunia korporat. Kontrak disetujui lebih cepat ketika pengiriman akhir dan tenggat waktu perusahaan ditentukan di muka; perencanaan anggaran lebih sederhana ketika ruang lingkup dan jadwal sudah ditetapkan; dan mengelola harapan dengan kepemimpinan tampaknya lebih mudah ketika tiga kendala tegas.

Namun, kehadiran akhir proyek yang terbatas memiliki beberapa konsekuensi yang tidak diinginkan: Tenggat waktu memberikan tekanan pada tim dan mendorong keputusan sepanjang proyek, yang tidak selalu produktif dalam jangka panjang. Keputusan dapat dibuat dengan bias terhadap jadwal daripada melakukan apa yang diperlukan untuk mendapatkan hasil yang optimal; karena tenggat waktu sewenang-wenang yang ditetapkan beberapa bulan sebelumnya semakin dekat, tim proyek lebih fokus untuk menyelesaikan sesuatu daripada menyelesaikannya dengan benar.

Di sisi lain, ketika orang memikirkan produk, mereka menerima kenyataan bahwa produk selalu memiliki ruang untuk perbaikan. Fokus pada proyek mengarahkan orang untuk membuat keputusan berdasarkan tenggat waktu, sementara fokus pada produk mengarahkan orang untuk membuat keputusan berdasarkan apa yang terbaik bagi pemangku kepentingan.

Saat tim kami berfokus pada proyek, kami membuat dasbor yang mencentang beberapa kotak dalam pernyataan kerja, tetapi produk tersebut tidak akan banyak berguna bagi pemangku kepentingan kami di dunia nyata. Dalam enam bulan setelah kami beralih ke pola pikir yang berpusat pada produk, kami meluncurkan versi modifikasi dari dasbor tersebut, yang lebih cocok untuk pemangku kepentingan kami.

Pola pikir yang berpusat pada produk tidak selalu berarti bahwa setiap iterasi suatu produk akan menjadi sempurna, tetapi pola pikir tersebut menghasilkan produk yang lebih baik dari waktu ke waktu dibandingkan dengan pola pikir yang berpusat pada proyek. Dan untuk menjadi jelas, fokus produk-sentris tidak saling eksklusif dari peduli tentang anggaran, jadwal, dan kecepatan ke pasar.

Memberikan nilai secara sering
Tim kami mengadopsi konsep tingkat produk ketika datang ke dasbor, sehingga kami dapat mengirimkan produk yang berfungsi dengan cepat. Sedan keluarga yang khas dan supercar mewah keduanya dapat menjadi produk berkualitas tinggi, tetapi keduanya dimaksudkan untuk kelas yang berbeda. Dalam contoh lain, obeng manual dan obeng tumbuk elektrik keduanya dapat bekerja dengan produk berkualitas tinggi, tetapi keduanya juga memiliki kualitas yang berbeda.

Demikian pula, kami fokus pada bagaimana kami dapat memberikan nilai yang lebih rendah, tetapi dasbor berkualitas tinggi kepada pemangku kepentingan kami dengan cepat dan kemudian terus meningkatkan nilai selama setiap sprint. Misalnya, kami mungkin mengirimkan dasbor yang berisi tabel di sprint pertama; lalu, tambahkan kemampuan penyortiran dan pemfilteran di sprint berikutnya; kemudian, tambahkan skema warna dan fitur drill-down di sprint ketiga. Di tingkat kelas mana pun, dasbor selalu merupakan produk berkualitas tinggi yang berfungsi penuh yang dapat digunakan oleh pemangku kepentingan kami.

Pendekatan ini memungkinkan kami untuk memberikan dasbor yang berfungsi kepada pemangku kepentingan kami lebih cepat, daripada jalur alternatif di mana kami tidak akan mengirimkan apa pun kepada pemangku kepentingan kami sampai dasbor tersebut berkualitas tinggi dan bermutu tinggi, secara bersamaan.

Percayai pengembang
Seperti setiap tim Agile yang baik yang menggunakan scrum, kami menggunakan bagan burndown, tetapi kami tidak menghukum pengembang berdasarkan bagan tersebut. Bahkan ketika sebuah tim memiliki pengembang paling berbakat, bagan burndown biasanya tidak terlihat sempurna. Jika grafik burndown secara konsisten terlihat sempurna, kemungkinan pengembang Anda lebih fokus untuk membuat grafik burndown terlihat bagus daripada memaksakan diri untuk melakukan yang terbaik. Itu karena perkiraan adalah perkiraan daripada tepat dan kejutan tidak dapat dihindari di setiap sprint.

Mendorong grafik burndown yang sempurna adalah ekspektasi yang tidak realistis dan tidak perlu, yang biasanya menurunkan semangat dan mendorong pengembang untuk mempermainkan sistem. Tim yang terlalu mengandalkan bagan burndown sebagai alat utama untuk mengukur produktivitas mungkin berhasil dalam mendorong perilaku yang menghasilkan bagan burndown yang terlihat sempurna, tetapi itu belum tentu menghasilkan tim yang berkinerja tinggi. Sebagai gantinya, kami menggunakan bagan burndown untuk mendidik diri kami sendiri tentang apa yang terjadi, di mana kami menyimpang dari rencana sprint, mengapa kami menyimpang, dan apa yang dapat kami lakukan dengan lebih baik. Menanggapi kepercayaan yang kami berikan kepada pengembang, mereka mempercayai kami dengan umpan balik yang jujur ​​daripada memberi tahu kami apa yang terdengar bagus. Kami meminta pertanggungjawaban developer berdasarkan dasbor kerja yang mereka berikan, bukan bagan burndown.

Jadilah fleksibel untuk berubah
Terkadang persyaratan, prioritas, dan kebutuhan berubah. Terkadang pengembang merekomendasikan perubahan kepada kami, dan terkadang kami meminta pengembang untuk mengubah sesuatu. Selalu ada pertimbangan yang cermat dan dialog yang baik ketika terjadi perubahan sehingga setiap orang dalam tim memahami apa itu perubahan dan mengapa itu perlu. Namun yang paling penting, tim kami berusaha menerima perubahan daripada menghindarinya, bahkan jika perubahan itu muncul pada saat yang tidak tepat. Menghindari perubahan mungkin tampak seperti pilihan yang lebih baik dalam jangka pendek, karena mungkin membantu menjaga bagan burndown terlihat bagus, memungkinkan tim untuk menyampaikan sesuatu di akhir sprint, atau mungkin membantu menghindari dampak biaya. Namun, utang karena tidak menerima perubahan terakumulasi dari waktu ke waktu, dan biaya pelunasan utang itu bisa jauh lebih tinggi di kemudian hari.

Fokus pada komunikasi daripada dokumentasi
Dokumentasi sangat membantu tetapi hasilnya semakin berkurang di luar batas tertentu. Kami memiliki cerita pengguna dengan kriteria penerimaan, dokumen desain, dan dokumentasi lain yang membantu kami berkomunikasi. Namun, kami memberikan penekanan terbesar pada komunikasi terus-menerus dan memastikan pengembang memahami persyaratan dengan jelas. Mereka tidak bersikeras bahwa kami menulis detail setiap menit di tiket, dan kami tidak mengharapkan mereka mengetahui semuanya hanya dengan membaca tiket.

Kesimpulan
Pada tahun 2022, tim Produk dan Teknik Restoran menghadirkan beberapa dasbor kerja selama tiga kuartal pertama, bersama dengan beberapa putaran penyempurnaan untuk masing-masingnya. Ini merupakan peningkatan besar dari tahun sebelumnya. Selanjutnya, pemangku kepentingan mulai mengenali tim karena kemampuannya mengubah ide menjadi dasbor kerja yang benar-benar bermanfaat bagi pengguna. Siklus yang baik telah terbentuk di dalam tim yang mengarah pada peningkatan kinerja dan peningkatan moral, berkat pola pikir yang kami adopsi.