Saat saya pertama kali mendengar istilah "velocity" di kelas Agile, saya pikir itu cuma istilah keren buat mengukur seberapa cepat tim menulis kode. Semacam "berapa banyak story points yang bisa diselesaikan tiap sprint". Tapi setelah membaca artikel "Velocity in Software Engineering" oleh Tom Killalea (2019), saya sadar ternyata pemahaman saya terlalu sempit.
Velocity, kata Killalea, bukan cuma tentang kecepatan menulis kode, tapi soal bagaimana kita bisa bergerak cepat dan ke arah yang benar. Kalau kamu salah arah, secepat apa pun kamu lari, ujung-ujungnya tetap nyasar.
Arah + Kecepatan = Velocity yang Sejati
Banyak organisasi, termasuk tim pengembang, terjebak pada "perasaan sibuk". Mereka kerja keras, sprint demi sprint, deploy berkali-kali. Tapi hasilnya? Pelanggan tetap tidak puas, fitur jarang dipakai, dan tim merasa burnout.
Killalea menyampaikan satu prinsip sederhana: velocity = speed + direction.
Kalau kamu cepat tapi tidak punya arah yang jelas, kamu hanya mempercepat kegagalan. Sebaliknya, kalau kamu punya visi dan tujuan yang tepat, bahkan kecepatan sedang pun bisa membawa perubahan besar.
Kisah Amazon: Dari Lambat ke Gesit
Penulis artikel ini adalah mantan CTO Amazon, dan ia mengungkap bagaimana dulu Amazon dikenal sebagai organisasi "bergerak lambat seperti lempeng tektonik". Namun, lewat reformasi internal --- termasuk penggunaan REST API, struktur tim kecil yang otonom, dan adopsi DevOps --- Amazon berubah jadi salah satu organisasi pengembang tercepat dan paling produktif di dunia.
Pelajaran buat kita? Velocity itu bukan bakat alami perusahaan. Ia dibangun dengan sengaja.
Lalu, Apa Relevansinya untuk Mahasiswa RPL?
