Deadline Driven Development: metodologi software development terpopular di Indonesia

deadline (n): a date or time when something must be finished.

deadline driven development (n): when management believes that the only path to improved developer productivity is imposing arbitrary, unrealistic deadlines.

Ok mari kita lupakan sejenak metodologi mana diantara Waterfall, Spiral, Rational Unified Process (RUP), eXtreme Programming (XP), Jungkir-Balik, Feature Driven Development (FDD) ataupun kerangka kerja Scrum yang terbaik dalam mengembangkan software. Mari kita lupakan perdebatan sengit #AgileVsWaterfall®. Marilah kita yang terpecah-belah dari kubu Agile dan kubu Waterfall berteman untuk kali ini saja. Semua perdebatan antara kubu Agile dan kubu Waterfall hanya membuat pimpinan perusahaan semakin tertawa terbahak-bahak karena di mata pimpinan perusahaan cuma ada satu metodologi paling ampuh dalam software development yakni: Deadline Driven Development (DDD®).

Mau sebagus apapun dokumentasi dan sereligius apapun proses user requirement gathering yang kalian lakukan berdasarkan teori Waterfall, semua itu sia-sia karena pada akhirnya metodologi yang akan digunakan oleh pimpinan perusahaan adalah: Deadline Driven Development. Mau se-funky dan se-hippie apapun proses Design Sprint dan Design Thinking yang sedang ngetren dilakukan di startup, semua itu tidak lebih dari teori indah di atas kertas karena pada akhirnya metodologi yang akan digunakan oleh pimpinan perusahaan dan investor adalah: Deadline Driven Development. Minimum Viable Product (MVP)? Who cares? Di otak pimpinan perusahaan tidak ada yang namanya MVP, semua harus selesai apapun alasannya! MVP cuma teori indah dari negara-negara barat yang tidak relevan di Indonesia karena ujung-ujungnya pimpinan perusahaan tetap akan menggunakan Deadline Driven Development.

Beginilah cara perusahaan-perusahaan — baik di korporasi maupun startup — di Indonesia mengelola software development, dengan Deadline Driven Development (DDD®). Waterfall atau Scrum cumalah pembungkus manis dari Deadline Driven Development. Hal ini tidak disadari oleh banyak software developer di Indonesia, mereka masih terjebak dalam perdebatan antara Waterfall vs Scrum.

Deadline Driven Development telah membuat banyak software developer di Indonesia kehilangan sebagian dari hidupnya dan telah merusak industri software development di Indonesia. Dalam eXtreme Programming (XP) prinsipnya adalah apapun alasannya software developer hanya boleh bekerja maksimal 40 jam dalam seminggu namun dalam metodologi Deadline Driven Development prinsipnya adalah apapun alasannya kalau software developer tidak bisa menyelesaikan mandat dari pimpinan perusahaan sebelum deadline maka mereka harus L.E.M.B.U.R kalau perlu hingga matanya berdarah. Kalau Agile memiliki 12 prinsip yang dipegang teguh selama proses pengembangan software, dalam Deadline Driven Development cukup perlu 1 prinsip saja yakni: L.E.M.B.U.R — semua proses pengembangan software dalam DDD cuma berputar di atas 1 prinsip ini.

Deadline Driven Development Advanced How To Book.

Kalau ada pakar Teknologi Informasi atau dosen yang pernah mengatakan kepada kamu kalau tidak ada silverbullet dalam metodologi pengembangan software, itu semua BOHONG karena sesungguhnya di Indonesia Deadline Driven Development adalah silverbullet tersebut. Silahkan saja tanyakan saja ke teman kamu yang berprofesi sebagai software developer apakah perusahaannya menggunakan Deadline Driven Development atau tidak. Yak, sepertinya Deadline Driven Development akan tetap eksis karena bahkan di startup keren yang ada ayunan dan XBox pun sangat religius dalam menggunakan Deadline Driven Development. Awalnya saya pikir hanya generasi baby boomers dan generasi-X saja yang menganut metodologi Deadline Driven Development, ternyata pimpinan perusahaan dari generasi-Y dan generasi milenial juga menganut metodologi ini di startup-nya secara religius.

Dan pada akhirnya jangan pernah lupa satu doktrin yang gemar diajarkan oleh dosen-dosen Teknik Informatika di Universitas kepada mahasiswa yakni: agar software developer tidak mengalami siksaan ini terlalu lama maka mereka harus menjadi analis bisnis atau manajer proyek yang akan kembali menyiksa software developer muda dan naif berikutnya secepat mungkin (tidak lebih dari 5 tahun).

Kenapa perlu ada deadline?

Deadline makes management looks like they are managing

Asal muasal deadline untuk software developer

1. Hasil konversi estimasi dari software developer

Template obrolannya kira-kira sebagai berikut:

Pimpinan: Kira-kira butuh berapa lama untuk menyelesaikan fitur X?
Developer: Sekitar 2 bulan pak.
P: Ok 2 bulan lagi saya tagih ya.
D: Tapi etapi pak, itu baru estimasi saja lho.
P: Lho tadi kan kamu bilang 2 bulan. Sudahlah, saya mau bilang ke kostumer ini.
D: (Aaah kampret. Tahu gitu gw kasih buffer aja tadi).

2. Magic Date from the HiPPo (Highest Political Power)

Template obrolannya kira-kira sebagai berikut:

Product Manager: Jon ini fitur X harus selesai akhir bulan ini.
Developer: Kenapa harus akhir bulan ini cuy?
PM: Soalnya akhir bulan ini ulang tahunnya CEO Jon.
D: Whut the *?!*?

3. Useless conversation

Template obrolannya kira-kira sebagai berikut:

Pimpinan: Kira-kira butuh berapa lama untuk menyelesaikan fitur X?
Developer: Sekitar 2 bulan pak.
P: Duh bukannya saya ingin menekan kamu nih ya. Tapi kayaknya kelamaan deh. Bisa lebih cepat lagi tidak?
D: Itu fitur kompleks Pak bikinnya. Beneran deh.
P: 1 bulan saja bisa tidak?
D: Hah?!? Wah ga mungkin banget itu Pak.
P: Sudahlah kamu pasti bisa kok. Yakin sama diri sendiri.
D: (Jiaaah tau gitu kagak usah pake pura-pura nanya Pak).

4. Taruhan di lapangan golf

CEO A: Jon bentar lagi gw bakalan launching e-commerce website nih. Mainan baru setelah selesai dengan bisnis yang lain-lain.
CEO B: Widih keren banget. Berapa lama lagi nih launching?
CEO A: Mau dibuat taruhan ga Jon? Lu yang nentuin tanggalnya deh.
CEO B: Ok deh. Kalau tim elu bisa deliver 3 bulan gw kasih Rp. 100 juta.
CEO A: Ok Jon. Deal. Kalau tim gw tidak bisa deliver dalam 3 bulan gw akan kasih elu Rp. 100 juta.

Secara singkat, prinsip lain dari metodologi Deadline Driven Development yang dianut oleh pimpinan perusahaan di Indonesia adalah: atasan selalu benar, software developer tidak perlu memperdebatkan asal-usul dari deadline.

Permasalahan dengan deadline

1. Deadline encourage software developers cut corners

Deadline is influencers of crap (Credit: Jim Benson)

Dan kalau anda masih berpikir software development adalah pekerjaan prediktif seperti konstruksi jembatan, anda harus menghilangkan cara berpikir tersebut jauh-jauh ke lautan yang dalam.

2. Deadline does not invite conversation with software developers

Slaves are not allowed to say no. Laborers may be hesitant to say no. But professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no. It’s the only way you can really get anything done.
— Robert C. Martin

Deadline yang dibuat sepihak akan memposisikan pimpinan perusahaan yang paling benar. Deadline yang dibuat sepihak adalah cara memimpin perusahaan dengan political power. Deadline yang dibuat sepihak menempatkan software developer bukan sebagai rekan kerja yang cerdas namun sebagai budak yang tidak bisa mengatakan TIDAK.


Jadi gimana dong?

We can’t solve problems by using the same kind of thinking we used when we created them. — Einstein

Untuk dapat membuat deadline menjadi tidak relevan di perusahaan, maka fundamental berpikir dan cara pandang terhadap software development harus dirubah terlebih dahulu. Daripada berorientasi pada deadline, pimpinan perusahaan dan software developer fokus pada optimising flow. Tujuan dari pendekatan berikut ini adalah berkolaborasi dengan software developer untuk mencari jalan keluar dan membuat opsi-opsi untuk mencapai tujuan. Pembicaraannya harus lebih terbuka dengan software developer dan tidak otoriter/sepihak. Dan lewat proses ini LEMBUR tidak pernah menjadi jalan keluar sama sekali.

1. Ukur Cost of Delay

Cost of delay dapat dikalkulasi secara ilmiah namun dapat juga didapatkan dari pembicaraan yang sederhana. Pembicaraan seputar cost of delay harus lebih open-minded dan tidak sepihak kira-kira seperti ini:

Product Manager: Jon ini fitur X harus selesai akhir bulan ini.
Developer: Kira-kira kita akan kehilangan berapa rupiah kalau tidak selesai akhir bulan ini?
PM: Kira-kira kita bisa kehilangan Rp. 100 juta rupiah per hari Jon.

Setelah bisa mendapatkan cost of delay, urutkan pekerjaan berdasarkan cost of delay. Pekerjaan dengan cost of delay paling tinggi berada dalam urutan paling atas. Pekerjaan dengan cost of delay yang sangat tinggi harus di-slice menjadi beberapa fungsionalitas lebih kecil (langkah selanjutnya). Pekerjaan tanpa cost of delay yang jelas diletakkan diurutan pekerjaan paling bawah karena tidak masalah bila pekerjaan tersebut mau diselesaikan kapanpun juga.

2. Slice work into smaller cost of delay

Setelah fungsionalitas besar di-slice menjadi beberapa fungsionalitas yang lebih kecil, ukur lagi cost of delay dari masing-masing fungsionalitas dan urutkan lagi berdasarkan cost of delay. Rinse, repeat.

3. Create options

One option is a trap.
Two options is a dilemma.
Three options provide a real choice.

Satu requirement yang dikunci tidak menyediakan pilihan bila requirement tersebut tidak berhasil diselesaikan pada tanggal yang diharapkan. Setelah pekerjaan di-slice dan cost of delay diukur, buat beberapa options untuk fungsionalitas kecil tersebut. Disini pimpinan perusahaan harus berkolaborasi dengan software developer untuk menghasilkan options.

Developer akan mengerjakan sebanyak mungkin dengan penuh tanggung-jawab (tanpa lembur) hingga tanggal yang ditentukan. Apa ada kemungkinan beberapa fungsionalitas kecil-kecil tidak terhantarkan? Ya ada kemungkinan, tetapi seharusnya fungsionalitas dengan cost of delay kecil yang berada di urutan bawah.

4. Deliver continuously, optimize flow-efficiency

Bila proses ini konsisten untuk dilakukan secara kolaboratif dan dengan open-mind, deadline di perusahaan akan semakin tidak relevan lagi. Kelihatannya 4 langkah di atas cukup common sense kan? Tetapi realitanya tidak banyak perusahaan di Indonesia yang dapat melakukannya dengan baik karena pimpinan perusahaan tidak dapat menahan diri untuk tidak kembali ke metodologi Deadline Driven Development. Kalau tidak ada niat baik dari pimpinan perusahaan, ya Deadline Driven Development tetap menjadi silverbullet di dalam perusahaan-perusahaan di Indonesia.


Jangan lupa untuk menekan tombol 👏🏻 di bawah sebanyak mungkin agar lebih banyak lagi pimpinan perusahaan di Indonesia yang dapat melihat artikel ini dan merubah model kerja dalam software development. Terima kasih atas dukungannya untuk memodernisasikan cara berpikir orang-orang dalam industri software development di Indonesia. Semoga industri software development di Indonesia bisa menjadi sedikit lebih baik ke depannya.


Modern Management

Gerakan memodernisasikan manajemen software development di Indonesia

Joshua 스크람 Partogi

Written by

On a mission to humanise workplaces so people can be the best version of themselves. Follow my journey https://www.youtube.com/user/jpartogi

Modern Management

Gerakan memodernisasikan manajemen software development di Indonesia

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade