5 Harapan Palsu Scrum dan Cara Memperbaikinya

Seperti banyak konflik klasik yang tidak pernah berakhir, perdebatan tentang bagaimana tim pengembangan harus mengatur dan mengatur diri sendiri terus berlanjut. Saat ini, sepertinya ada lebih banyak kritikus daripada penggemar Scrum. Tiga keluhan yang paling umum adalah:

1. Prosesnya dapat menjadi pusat perhatian di atas pekerjaan.
2. Ini dapat dengan mudah dikacaukan untuk manajemen mikro dengan nama lain.
3. Stand-up harian bisa terasa seperti pertemuan di mana seseorang harus membenarkan keberadaannya.

Dalam kasus lain, peran Scrum tidak terwakili dengan tepat. Terkadang, pemilik produk menginginkan terlalu banyak hal di dalam sprint atau ingin mengubah prioritas di tengah sprint—seorang master Scrum yang secara obsesif berfokus pada mempertahankan kecepatan dan mengadopsi setiap upacara Scrum baru yang mereka pelajari. Setelah beberapa waktu dengan kerangka kerja, pertanyaan umum tampaknya muncul: "Apakah kita atau metodologi?"

Harapan Palsu Scrum

Meskipun ada banyak disfungsi seperti yang diuraikan di atas, akar penyebab sederhana untuk sebagian besar dari mereka adalah bahwa Scrum tidak dirancang untuk menyelesaikan masalah mendasar dalam suatu organisasi hanya dengan mengikuti prosesnya. Gagal mengenali ini dapat menempatkan tim baru dalam bahaya segera setelah mereka mulai.

Harapan Palsu #1: Scrum Membuat Tim Bekerja Lebih Cepat

Scrum menggunakan terminologi yang terdengar bagi orang luar seperti akan mempercepat proses tanpa menambahkan sumber daya tambahan. Sangat mudah untuk terjebak dalam terminologi sebagai tim baru di Scrum (misalnya, apa itu master Scrum? Apa perbedaan antara pemilik produk dan manajer produk? Apa poin cerita dan bagaimana mereka ditugaskan?)

Lebih meresahkan adalah banyak yang melihat istilah seperti kecepatan dan sprint dan berpikir "kecepatan." Namun, tujuan dari setiap metodologi Agile, termasuk Scrum, adalah untuk memberikan produk jadi. Akhirnya, saat tim Anda menjadi lebih kompeten dengan Scrum, Anda akan dapat memberikan fungsionalitas baru lebih cepat. Namun, kecepatan belum tentu menjadi tujuan utama. Perbedaan ini harus diartikulasikan dalam tim Scrum Anda dan juga ketika Anda membangun kesadaran di dalam perusahaan Anda untuk mendukung metodologi Scrum.

Anda tidak menjual kecepatan; Anda menjual penyelesaian.

Harapan Palsu #2: Kepatuhan pada Scrum Akan Memperbaiki Masalah Budaya Perusahaan

Setiap orang memiliki gaya kerja yang berbeda. Beberapa orang menyukai pertemuan. Yang lain menggunakan frasa seperti "bekerja keras, bermain keras." Penting untuk menyadari bahwa gaya kerja apa pun yang dihargai perusahaan Anda, Anda menerima kelebihan dan kekurangannya. Perusahaan yang menghargai rapat kemungkinan akan kesulitan dengan stand-up harian. Tim yang agresif dan berorientasi pada kecepatan akan memiliki masalah dengan scope creep di dalam sprint.

Terkadang mudah untuk melupakan gambaran besarnya, terutama untuk tim yang baru terbentuk. Yang penting adalah memberikan produk jadi alih-alih mengikuti setiap bagian terakhir dari proses. Daripada menyalahkan metodologi, selalu cari cara untuk memperbaiki gaya kerja Anda untuk memenuhi tujuan Anda.

Harapan Palsu #3: Kontributor Kritis Dapat Mengirim Delegasinya ke Rapat

Setelah Anda memulai metodologi, sangat penting bahwa tim asli berpartisipasi daripada mendelegasikan. Jika ada satu keluhan hampir universal yang saya lihat dari pengembang, itu adalah bahwa master Scrum dan pemilik produk tidak tersedia saat dibutuhkan dan delegasi mereka tidak diberdayakan. Tidak ada yang suka datang ke pertemuan mengharapkan keputusan hanya untuk diberitahu bahwa orang yang dapat membuat keputusan tidak tersedia.

Delegasi mungkin merupakan praktik umum, tetapi di Scrum, Anda juga harus memberdayakan para peserta.

Harapan Palsu #4: Stand-up Harian Akan Memaksa Semua Orang untuk Lebih Fokus

Rapat stand-up harian tidak boleh hanya terfokus pada apa yang dilakukan semua orang dalam 24 jam terakhir. Jauh lebih penting untuk memberikan prioritas pada penghalang jalan atau pendekatan baru untuk memecahkan masalah.

Scrum membutuhkan peran tertentu, terutama master Scrum, untuk bersikap tegas namun tidak terlalu kuat. Penting bagi master Scrum untuk menciptakan lingkungan positif yang mengarah pada produk yang sudah jadi.

Harapan Palsu #5: Kita Akan Berhasil pada Percobaan Pertama

Scrum melibatkan menebak, berpikir deduktif, dan membuat kesalahan. Orang jarang melakukannya dengan benar pada percobaan pertama. Scrum bersifat iteratif dalam segala hal: tidak hanya dalam cara Anda mencapai produk jadi, tetapi juga dalam cara Anda mengatur dan mengoperasikan prosesnya. Scrum dirancang untuk memiliki hambatan masuk yang rendah untuk diadopsi oleh tim, tetapi juga membutuhkan komitmen untuk mengulangi dan terus meningkatkan partisipasi dalam kerangka kerja.

Cara Memperbaiki Proses Scrum yang Rusak

Scrum tahan terhadap kekeliruan biaya hangus. Sifat berulang dari Scrum menciptakan peluang untuk beradaptasi atau membuang proses yang tidak efektif. Pertimbangkan beberapa saran berikut jika proses Scrum Anda tidak seefektif yang Anda harapkan.

Perbaiki Harapan Anda

Baik itu mengurangi waktu ke pasar, menciptakan produk yang menarik, atau membantu tim berkolaborasi, kesuksesan membutuhkan komitmen dan waktu. Untuk tim baru, pencapaian yang wajar untuk dicapai adalah apakah setelah setiap sprint Anda dapat memperkenalkan kode yang berfungsi dan dapat diuji ke dalam lingkungan produksi Anda.

Tim tingkat lanjut dapat mengukur kesuksesan dengan kemampuan mereka untuk membangun, menguji, dan menerapkan sesuai permintaan. Apakah Anda dapat mengukur dan mengukur reaksi pengguna terhadap fitur baru? Apakah organisasi yang lebih luas siap mendukung perubahan yang dilakukan tim terhadap produk?

Berdayakan Peserta Anda

Penting untuk membimbing anggota tim secara offline dalam hal bagaimana mereka dapat meningkatkan nilai mereka bagi tim. Jika mereka diminta untuk membuat keputusan, tingkatkan kepercayaan diri mereka dengan melatih mereka tentang kapan dan bagaimana melibatkan anggota tim lainnya. Manajer harus siap untuk membersihkan penghalang jalan dan mendukung tim saat dibutuhkan.

Mengatasi Masalah Secara Proaktif

Scrum tidak dirancang untuk memberikan perubahan pada perusahaan Anda. Jika Anda membiarkan masalah tidak terselesaikan, kemungkinan besar Anda akan menemukan masalah ini muncul ke permukaan dalam proses pengembangan produk Anda. Scrum master dapat memperkenalkan kerangka kerja yang dirancang untuk menciptakan cara positif bagi anggota tim untuk menyusun umpan balik mereka untuk mengurangi perasaan konflik.

Salah satu contohnya adalah kerangka kerja “Saya berharap, saya bertanya-tanya, Bagaimana jika”. Selama diskusi tim atau retrospektif, seorang anggota tim dapat memberikan umpan balik dengan membuka pernyataan mereka dengan salah satu dari tiga frasa ini. Misalnya, mereka dapat mengatakan, "Saya berharap pertemuan stand-up dapat lebih fokus pada penghalang jalan yang mungkin perlu saya waspadai hari itu." Anda juga dapat menggunakan pembuka Anda sendiri seperti "Saya suka ...".

Solusi umpan balik terstruktur lainnya yang dapat membantu selama rapat adalah metode Triage dari Holocracy, yang dibuat oleh Brian Robertson dan digunakan oleh perusahaan seperti Zappos. Misalnya, peserta membangun agenda “ketegangan” untuk didiskusikan. Setiap peserta menjelaskan masalah mereka dengan mengatakan "Saya memiliki ketegangan" dan kemudian membuat daftar orang dan sumber daya yang mereka butuhkan untuk menyelesaikannya. Dengan mendorong peserta untuk secara langsung mengatasi masalah sebagai "ketegangan", Holocracy memungkinkan peserta untuk berkomunikasi secara bebas tanpa menciptakan suasana konflik.

Gunakan Retrospektif untuk Memecahkan Masalah dan Mengulangi Proses

Di banyak perusahaan, retrospektif tidak diberikan perhatian yang tepat. Ini terutama karena ketakutan yang dimiliki banyak orang bahwa retrospektif adalah tempat untuk argumen, konflik, dan keluhan lama. Sangat penting bagi tim untuk mengembangkan aturan dasar yang mencerminkan nilai tim dan budaya perusahaan.

Sama pentingnya adalah kebutuhan untuk menghindari investasi dalam proses statis. Apa yang berhasil sekali mungkin tidak berhasil selamanya. Banyak tim berjuang dengan pergantian peserta. Ini biasa terjadi di banyak perusahaan karena peserta dipindahkan ke tim lain, dipromosikan, atau meninggalkan perusahaan sama sekali. Saat komposisi tim berkembang, penting untuk tidak tetap berkomitmen bahwa semuanya berulang di Scrum. Kesalahan akan terjadi, tetapi mudah-mudahan, itu akan berumur pendek saat Anda mengulanginya.

Scrum Bekerja Terbaik Saat Prinsipal Hadir

Berada di tim, Anda harus berkomitmen untuk hadir dan tersedia. Pengembangan produk mungkin merupakan proses paling penting yang dapat dilakukan perusahaan Anda untuk meningkatkan pertumbuhan jangka panjangnya. Oleh karena itu, penting bahwa proses Scrum, sebagai jalur utama menuju pengembangan produk baru, mendapat perhatian yang layak. Di banyak lingkungan, tim pengembang sering kali bekerja terlepas dari keputusan dan diskusi yang mendorong tujuan perusahaan. Scrum berbeda. Scrum adalah tempat keputusan, arahan, dan pengembangan bersatu sebagai satu proses. Terlalu penting bagi sebuah proses untuk mengirim delegasi atau meninggalkan anggota tim dari rapat yang berlangsung dalam metodologi Scrum.

Ringkasan: Anda Dapat Memperbaiki Proses Scrum yang Rusak

Karena sifatnya yang berulang, Scrum membantu menjaga bisnis agar tidak terlalu jauh ke jalan dan berkomitmen pada apa yang mungkin berakhir dengan ide yang buruk atau proses yang diimplementasikan dengan buruk. Mengikuti prinsip ini dapat membantu melepaskan diri dari kesalahan masa lalu dan secara berulang meningkatkan proses Scrum.

Penting untuk fokus pada individu dan tim yang Anda miliki. Anggota tim berubah. Semua proyek berbeda. Kepatuhan yang ketat terhadap suatu proses tidak selalu menghasilkan hasil terbaik. Apa yang Anda investasikan pada anggota tim Anda di luar proses sama pentingnya dengan bagaimana Anda berperilaku dalam proses tersebut.

Scrum bisa fleksibel. Jika ada yang tidak berfungsi, pertimbangkan untuk memasukkan elemen dari kerangka kerja lain baik di dalam Agile maupun di luar. Mengidentifikasi dan mengadopsi gaya komunikasi terstruktur yang diskusi konfrontatif.

Scrum bermanfaat bagi ROI jangka panjang dengan memungkinkan tim untuk membangun produk lengkap sebagai tanggapan terhadap perubahan kebutuhan klien. Scrum mungkin merupakan metodologi terbaik untuk menjaga Anda dari komitmen berlebihan terhadap ide-ide buruk sambil memberikan ruang bagi ide-ide hebat untuk berkembang lebih jauh.