Menghilangkan Bottleneck di Software Development Team dengan Theory of Constraint
Tulisan ini terinspirasi dari ceramah Luqman Sungkar — CTO Flip tentang buku The Goal: A Process of Ongoing Improvement — Eliyahu M. Goldratt. Secara garis besar, buku ini menjelaskan teori manajemen bernama Theory of Constraint (ToC) yang akan menjadi tema tulisan kali ini. Kita akan coba terapkan sebagian teori ini — secara sederhana — untuk mengurai bottleneck yang biasa ada pada software development team.
Siapa di sini yang merasakan produktivitas tim tidak meningkat pesat padahal anggota tim sudah ditambah? Siapa di sini yang menyadari jumlah fitur yang berhasil dirilis dalam satu bulan ternyata sama saja sebelum dan setelah developer-nya bertambah? Hampir pasti, development flow-mu memiliki constraint (bottleneck¹) yang menghambat naiknya produktivitas tim.
Ide besar dari teori ini adalah setiap sistem (apapun itu) pasti memiliki constraint yang membatasi produktivitasnya. Setiap sistem terdiri dari bagian lebih kecil (sub-sistem) yang saling terhubung dan mendukung. Meningkatkan kualitas suatu sub-sistem yang bukan constraint/bottleneck bukanlah cara meningkatkan produktivitas (throughput) yang paling efektif².
Rantai tersebut panjang tetapi lemah dan mudah putus. Kita perlu mengetahui, di mana bagian rantai itu yang membuatnya menjadi mudah putus —itu lah yang kita sebut sebagai constraint. Jika kita justru meningkatkan kualitas bagian rantai yang bukan menjadi constraint, rantai itu tetap lemah. Clip warna merah adalah constraint itu. Jika kita membiarkan clip warna merah tetap di situ, dan menguatkan rantai bagian lain, rantai itu tetap lemah. Dalam contoh kasus di awal tulisan, jumlah developer tidak menjadi constraint, sehingga menambah jumlah developer tidak menambah jumlah fitur yang berhasil dirilis dalam satu bulan.
The Five Focusing Steps³
- Identify The Constraint
Kita mencari tahu di mana sub-sistem yang menjadi bottleneck.
2. Exploit The Constraint
Apakah sub-sistem tersebut sudah melakukan performa terbaiknya? lalu, tanpa menambah kapasitas sub-sistem itu, apa quick solution yang bisa diterapkan untuk menyelesaikan bottleneck?
3. Subordinate To The Constraint
Memastikan sub-sistem lain mengetahui bottleneck dan membantu/mengurangi beban sub-sistem yang menjadi bottleneck.
4. Elevate The Constraint
Meningkatkan kapasitas sub-sistem yang menjadi bottleneck, seperti menambah peralatan, merekrut anggota baru, dan sejenisnya. Seringkali, penyelesaian bottleneck langsung lompat dari langkah 1 ke langkah ini, tanpa melewati langkah 2 dan 3. Hal tersebut bisa meningkatkan biaya yang sebenarnya bisa dihindari.
5. Repeat
Mengulangi lagi dari langkah 1 untuk menemukan bottleneck lainnya.
Contoh Kasus
Mari menyelami contoh kasus supaya lebih kebayang ya. Saya berikan ilustrasi sebuah software development cycle sederhana. Kamu saya angkat sebagai kepala development team ini.
Kamu bingung, anggota timmu sudah banyak, tetapi kenapa fitur yang berhasil di rilis setiap sprint kok segitu-gitu aja. Kamu sudah tambah developer baru untuk mempercepat proses coding, tetapi hasilnya tidak sesuai harapan.
Identify The Constraint
Kita mulai dengan “Identify The Constraint”. Untuk menemukan mana sub-sistem yang menjadi bottleneck, kamu perlu mencari berapa kapasitas maksimal yang bisa dihasilkan dari masing-masing sub-sistem pada satuan waktu terlebih dahulu. Namun, ingat, ini berbeda dengan mencari jumlah orang di masing-masing sub-sistem tersebut.
Seperti itu hasil pengamatan terhadap kondisi timmu. Masing-masing sub-sistem mampu mengerjakan sekian story point(s) untuk satu sprint. Dengan informasi itu, kamu jadi tahu bahwa yang menjadi bottleneck adalah testing. Dia menerima masukan sebesar 10 SP tetapi hanya mampu menghasilkan 5 SP. Apa jadinya jika kamu justru menambah developer padahal bottleneck-nya ada di testing?
Exploit The Constraint
Sekarang, kita sudah tahu sub-sistem mana yang menjadi constraint. Kita lanjutkan dengan “Exploit The Constraint”. Di sini, kita perlu mengecek apakah sub-sistem ini sudah berada di performa terbaiknya. Kira-kira adakah quick solution yang bisa memaksimalkan performa?
Dari pengecekanmu, kamu menemukan dua kondisi di proses testing ini:
- Proses testing itu terdiri dari test semua fitur yang dilakukan 2 kali. Jadi, saat aplikasi sudah selesai dan diserahkan ke tim tester, tim tester akan melakukan testing untuk semua fitur (full test) yang ada di aplikasi itu. Bug akan dikumpulkan, lalu diperbaiki oleh developer. Setelah itu tim tester akan test seluruh fitur lagi.
- Tim tester tidak tahu fitur apa saja yang akan dikembangkan di sprint tersebut. Dampaknya daftar test case baru bisa dibuat setelah aplikasi diterima oleh tester. Durasi testing menjadi membengkak dengan kondisi ini.
Untuk kondisi nomor 1, kamu putuskan tim tester hanya perlu melakukan full test saat pertama kali memulai testing saja. Untuk iterasi selanjutnya, tim tester cukup test bug yang sudah diperbaiki oleh developer saja — tidak perlu full test lagi.
Untuk kondisi nomor 2, kamu memutuskan tim tester akan diikutkan dalam sprint planning antara developer dan project manager. Dengan begitu, tim tester akan mengetahui sejak awal apa saja fitur yang akan dikembangkan pada sprint tersebut dan bisa membuat daftar test case sebelum proses testing dimulai.
Setelah “Exploit The Constraint” kamu lakukan, begini hasilnya:
Kapasitas tim tester meningkat hingga 1.6 kali lipat dari sebelumnya. Sebenarnya, kamu bisa saja berhenti di sini. Namun, kamu merasa kapasitas tim tester masih bisa ditingkatkan lagi supaya tidak ada reduksi SP dari tim developer ke tim tester. Kamu menuju ke langkah selanjutnya, “Subordinate The Constraint”.
Subordinate The Constraint
Di langkah ini, kamu memberi tahu seluruh anggota tim bahwa ada bottleneck di sini. Anggota tim menjadi paham dan turut memikirkan solusi. Akhirnya, sebagian developer pindah role ke tim tester untuk membuat testing automation. Memang selama proses ini, kapasitas tim developer (coding) akan turun karena anggota tim-nya berpindah. Namun, ini akan memberikan dampak lebih baik ke depannya.
Dengan begitu, kapasitas tim testing sudah 2.4 kali lipat dari kondisi awal. Kamu masih menimbang-nimbang apakah akan ke langkah selanjutnya, “Elevate The Constraint”. Jika kamu ingin menjalankan langkah ini, kamu bisa saja menambah tester baru, membeli peralatan automation testing berbayar, membeli berbagai support tools lainnya.
Kamu juga bisa lanjut langsung ke langkah ke lima yaitu, “Repeat”. Kamu menyadari bottleneck yang berada pada *development flow-*mu sudah bukan di testing lagi. Kamu akan mencari di mana bottleneck selanjutnya. Berdasarkan ilustrasi di atas, bottleneck ada di tim developer (coding) dan tim deployment. Kamu bisa ulangi langkah-langkah di atas.
Kalau menurutmu apa cara yang lebih efektif untuk kasus ini?
Contoh kasus di atas memang terlalu sederhana untuk menggambarkan masalah yang ada di sekitar kita. Goal tulisan ini memberikan framework dasar saja. Kamu bisa sesuaikan dengan masalah yang ada di timmu saat ini.
¹ dalam Theory of Constraints, constraint tidak selalu sama dengan bottleneck. Untuk menyederhanakan tulisan ini, anggap saja constraint sama dengan bottleneck.
² “Theory of Constraints (TOC) of Dr. Eliyahu Goldratt” — https://www.tocinstitute.org/theory-of-constraints.html
³ “Story points and estimation” — https://www.atlassian.com/agile/project-management/estimation
⁴ “Five Focusing Steps (POOGI)” — https://www.tocinstitute.org/five-focusing-steps.html
