1

ANALISIS PENGEMBANGAN PERANGKAT LUNAK AGILE DI

PERUSAHAAN STARTUP (STUDI KASUS PERUSAHAAN
XYZ)
ABSTRAK
Startup adalah perusahaan baru yang bertujuan untuk mencari model bisnis yang repeatable (dapat diulang) dan
scalable (dapat dikembangkan menjadi besar). Objek penelitian ini adalah sebuah perusahaan startup di Surabaya,
Indonesia. Penulis melakukan observasi dengan langsung mengikuti kegiatan operasionalnya. Penelitian ini bertujuan
untuk mengamati secara kualitatif praktik penerapan metode pengembangan perangkat lunak di sebuah perusahaan

Arief Rakhman1), Sholiq, S.T., M.Kom., M.SA. 2)

Jurusan Sistem Informasi, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember (ITS)
Jl. Arief Rahman Hakim, Surabaya 60111 Indonesia
e-mail: armanke13@is.its.ac.id 1), sholiq@is.its.ac.id 2)
startup lokal Indonesia, membandingkannya dengan temuan-temuan di penelitian-penelitian sebelumnya dalam jurnal
internasional, dan mewawancarai praktisi perusahaan startup mengenai metode pengembangan perangkat lunak yang
digunakan. Hasil yang diharapkan adalah berupa laporan analisis deskriptif kualitatif yang bermanfaat bagi
perusahaan objek penelitian, juga perusahaan-perusahaan lain yang mempunyai karakteristik serupa. Penelitian ini
juga diharapkan dapat berkontribusi dalam penelitian bertema startup atau metode pengembangan agile.
Keyword: metode pengembangan agile, perusahaan startup
1. PENDAHULUAN
Startup adalah perusahaan baru yang bertujuan untuk
mencari model bisnis yang repeatable (dapat diulang) dan
scalable [1]. Ini adalah salah satu definisi dalam buku
bisnis mengenai startup yang cukup populer. Sedangkan
secara akademik, walaupun sudah ada beberapa penelitian
yang membahas tentang startup, definisi tentang perusahaan
startup secara akademik belum disepakati [2]. Dalam
konteks penelitian ini, yang dimaksud startup adalah
software startup.
Startup dimulai oleh satu atau beberapa founder
(pendiri) untuk membuat produk perangkat lunak untuk
diluncurkan pada pasar yang potensial. Perusahaanperusahaan startup mengembangkan perangkat lunak di
tengah kondisi yang sangat tidak pasti, berhadapan dengan
pasar yang tumbuh dengan cepat, namun beroperasi dengan
sumber daya yang terbatas. Karena itu, startup memiliki
karakteristik khusus yang menghadapi beberapa tantangan
dalam pengembangan perangkat lunak. [2]
Konteks startup ini berbeda dengan UKM (Usaha Kecil
dan Menengah) atau SME (Small and Medium Enterprise)
di bidang pengembangan perangkat lunak [3]. UKM
pengembang perangkat lunak biasanya berbentuk software
house yang menerima pekerjaan konsultasi dan
pengembangan perangkat lunak dari klien dan bekerja
dalam proyek-proyek. Startup lebih fokus untuk
mengembangkan satu atau beberapa produk tertentu yang
berhubungan dengan produk utama, kemudian menjalankan
operasi untuk mengembangkan dan memasarkan produk
tersebut hingga mencapai skalabilitas tertentu. Tujuan akhir
perusahaan startup adalah untuk mencapai model bisnis
yang dapat bertahan secara berkelanjutan, atau mencapai
exit strategy, berupa diakusisinya sebuah perusahaan atau
produk perangkat lunak dengan nilai properti intelektual
atau bagian kepemilikan saham tertentu.
Praktik pengembangan dan operasional perusahaan
startup biasanya dimulai oleh founder dan tim yang kurang

berpengalaman, umumnya sebagai wirausahawan baru dan

pemuda yang baru lulus dari perguruan tinggi. Karena
kurangnya pengalaman, mereka masih membutuhkan
banyak wawasan dan panduan. Panduan ini bisa berasal
dari penelitian akademik yang formal, bukan hanya dari
literatur abu-abu (gray literatures) berupa berita dan artikel
blog, yang seringkali berasal dari pengalaman (anekdot)
dari satu founder ke founder yang lain yang startup-nya
berhasil. Selain itu, penelitian yang membahas mengenai
topik startup dan metode pengembangan agile masih jarang,
khususnya di Indonesia. Hal ini membuka peluang topik
penelitan meode pengembangan perangkat lunak dalam
konteks perusahaan startup di Indonesia.
2. STUDI LITERATUR
Beberapa teori yang berkaitan dengan penelitian ini
adalah metode pengembangan agile, perusahaan startup,
dan beberapa penelitan sebelumnya yang relevan.
2.1 Perusahaan Startup
Istilah startup berasal dari bahasa Inggris, yang dalam
Kamus Bahasa Inggris Oxford berarti A newly established
business. [4]. Sutton [5] mengajukan beberapan karakter
startup berdasarkan tantangan yang dihadapinya:
-Tidak mempunyai sejarah operasional atau
hampir tidak punya startup hanya memiliki
pengalaman
yang
sedikit
dalam
proses
pengembangan
perangkat
dan
manajemen
organisasi.
-Sumber daya yang terbatas startup biasanya
berfokus untuk membuat produk, mempromosikannya dan mengembangkan aliansi strategis dengan
partner.
-Dipengaruhi banyak hal tekanan dari
investor, pelanggan, partner dan kompetitor yang
berdampak pada pengambilan keputusan dalam

2
perusahaan. Setiap stakeholder penting untuk
diperhatikan, namun mungkin tidak konsisten satu
sama lain.
-Teknologi dan pasar yang dinamis kebaruan
dari perusahaan perangkat lunak seringkali butuh
untuk mengembangkan atau mengoperasikan dengan
teknologi disruptif untuk memasuki pasar yang
berpotensi tinggi.
Paternoster, dkk [2] mengumpulkan tema berulang yang
muncul dalam penelitian dalam konteks startup. Disebutkan
bahwa para peneliti dalam jurnal akademik menggunakan
definisi yang berbeda-beda, namun ada beberapa
karakteristik yang berulang dalam penelitian-penelitian
tersebut:

Perusahaan yang baru

berdiri
Organisasi yang flat

Beresiko tinggi untuk

gagal
Belum dapat
beroperasi hanya dari
hasil usaha

Tabel 1 Karakteristik Perusahaan Startup

Karakteristik
Deskripsi
Keterbatasan sumber
daya
Sangat reaktif pada
perubahan
Inovasi

Ketidakpastian

Berevolusi secara cepat

Tekanan waktu

Ketergantungan
terhadap pihak ketiga

Tim yang kecil

Satu produk
Tim yang kurang
berpengalaman

Sumber daya ekonomi,

manusia, dan fisik sangat
terbatas
Startup mampu untuk
beraksi dengan cepat pada
perubahan pasar
Karena ekosistem yang
sangat kompetitif, startup
butuh untuk fokus dalam
menggarap segmen market
yang sangat inovatif.
Startup berhadapan dengan
ekosistem yang sangat tidak
pasti dalam sudut pandang
yang berbeda: pasar, fitur
produk, kompetisi, orang,
dan keuangan.
Startup yang sukses
bertujuan untuk tumbuh dan
meningkatkan skala bisnis
dengan cepat.
Lingkungan seringkali
memaksa startups untuk
merilis produk dengan
cepat dan bekerja dalam
tekanan yang terus
menerus.
Dikarenakan keterbatasan
sumber daya, startups
sangat memanfaatkan solusi
eksternal untuk
mengembangkan
produknya: API eksternal,
perangkat lunak open
source, outsourcing, dll
Startup terdiri dari tim yang
kecil.
Aktivitas perusahaan
berkisar di sekeliling satu
produk/layanan saja
Tim pembangun perangkat
lunak banyak diisi oleh
orang dengan pengalaman
kurang dari 5 tahun dan
seringkali lulusan baru

Sejarah operasional
yang sedikit

universitas.
Perusahaan baru didirikan
Startup biasanya berpusat
pada founder dan setiap
orang dalam perusahaan
punya tanggung jawab yang
besar, tanpa butuh
manajemen tingkat tinggi.
Tingkat kegagalan startup
sangat tinggi.
Khususnya pada tingkat
awal, startup butuh
pembiayaan eksternal untuk
mempertahankan aktivitas
mereka (Venture Capitals,
Angel Investments,
Personal Funds, dll)
Pada awalnya basis dari
kultur organisasional belum
ada.

Dikarenakan perbedaan karakteristik ini, maka peneliti

harus secara konkret mendeskripsikan definisi yang
digunakan dalam penelitian berkonteks perusahaan startup.
2.2 Metode Pengembangan Agile
Sebuah metodologi pengembangan sistem didefinisikan
sebagai sebuah koleksi kebijakan (policies), proses, dan
prosedur yang biasa digunakan oleh tim pengembang
perangkat lunak untuk meningkatkan produktivitas personal
TI dan kualitas solusi TI yang lebih berkualitas. [6]. Dalam
implementasinya, sebuah metodologi pengembangan
perangkat lunak disesuaikan dengan situasi proyek yang
berbeda-beda. Tidak ada contoh template yang siap pakai
untuk setiap keadaan. Dalam metodologi agile pun, terdapat
beberapa jenis metode yang berupa kerangka kerja
(framework), yang dimaksudkan untuk menyesuaikan
dengan situasi dan karakteristik proyek tertentu.
Istilah agile dapat ditranslasikan ke dalam bahasa
Indonesia sebagai lincah. Lincah dalam Kamus Besar
Bahasa Indonesia (KBBI) dapat bermakna (1) selalu
bergerak; tidak dapat diam; tidak tenang; (2) tidak tetap
(tempat tinggal, pikiran, dsb); (3) selalu bertukar (pekerjaan
dsb) [7]. Makna tersebut dapat menggambarkan sifat
umum dari metode pengembangan agile, yaitu selalu
bergerak, tidak tetap, atau fleksibel. Dengan sifat adaptif
tersebut, metode pengembangan agile diharapkan dapat
menjadikan tingkat kesuksesan proyek pengembangan
perangkat lunak lebih tinggi.
Kesuksesan proyek pengembangan perangkat lunak
tersebut dapat diukur dalam keberhasilan menghasilkan
produk perangkat lunak dengan kualitas baik, scope
tertentu, dan waktu dan biaya yang efisien. Juga lebih tepat
(efektif) dalam memenuhi kebutuhan, karena lebih fleksibel
dalam mengakomodasi permintaan pengguna.
Pengembangan Perangkat Lunak Agile adalah
metodologi yang berbeda dengan metodologi yang berbasis
perencanaan (plan-based). Contoh varian dari metodologi
Agile bermacam-macam, seperti metode Extreme
Programming, Scrum, DSDM (Dynamic Systems
Development Method), Adaptive Software Development,
Crystal, Feature-Driven Development (FDD), Lean

3
software development dan metode-metode lain yang
memiliki karakter sesuai dengan prinsip-prinsip agile.
Menurut Dyba dan Dingsoyr [8], metode pengembangan
agile dapat dilihat sebagai reaksi dari metode tradisional
yang menekankan pendekatan yang rasional, berdasar
pada keteknikan (engineering-based) yang mengklaim
bahwa terdapat solusi optimal dan dapat diprediksi untuk
setiap permasalahan. Para tradisionalis mendorong
perencanaan yang ekstensif, proses-proses yang
terkodifikasi, dan penggunaan kembali metode dengan teliti
untuk menjadikan proses pengembangan menjadi aktivitas
yang efisien dan dapat diprediksi. Reaksi itu bisa dianggap
wajar, karena banyak terjadinya kasus kegagalan proyek
pengembangan perangkat lunak, salah satu sebab utamanya
adalah karena sisi kebutuhan dan kepuasan pengguna
terhadap sistem informasi yang kurang dapat diprediksi.
Munculnya metode pengembangan agile sebagai
alternatif, bukan berarti menggantikan sama sekali metode
yang lama yang sudah ada. Metode ini bisa dianggap
sebagai pelengkap untuk membangun modul tertentu atau
bisa diterapkan dalam proyek percontohan (pilot project)
sebelum diterapkan secara luas misalnya dalam sebuah
perusahaan korporasi.
Beberapa penelitian menyebutkan bahwa metode agile
tidak sesuai untuk membangun sistem yang safety-critical
seperti perangkat lunak untuk militer dan pesawat terbang.
Pendapat ini juga tidak selalu berlaku karena organisasi
seperti FBI (Federal Bureau of Investigation) Amerika
Serikat melaporkan juga pernah menggunakan metode
Agile untuk mengembangkan sistem perangkat lunak
manajemen kasus Sentinel. [9].
Pada manifesto agile pertama, disebutkan bahwa
individu dan interaksi lebih penting daripada proses dan
alat. Pernyataan ini terbukti dalam temuan empiris di
berbagai pengembangan agile, seperti milik Paternoster,
dkk [2] dan Fontana, dkk [10]. Dalam konteks perusahaan
startup, Coleman dan OConnor [11] juga menyebutkan
bahwa yang diperlukan perusahaan startup adalah
peningkatan praktik (practice improvement) bukan
peningkatan proses (process improvement). Perusahaan
startup memang dimaksudkan sebagai perusahaan yang
belum dewasa (immature), yang selalu ingin belajar (eager
to learn) dari kesalahan dan kegagalan, dan cepat
beradaptasi dan berevolusi menjadi lebih dewasa (mature).
Untuk itu, pengembangan produk dilakukan secara iteratif
melalui trial-error dengan cara yang lincah (agile).
Fontana, dkk [10] dalam salah satu tahap penelitian
mereka untuk mendefinisikan maturitas pengembangan
agile, melakukan tinjauan literatur untuk membuat daftar
praktik pengembangan agile. Literatur yang dijadikan
sumber adalah jurnal IEEE, ACM, dan database Science
Direct, termasuk hasil dari konferensi (proceeding). Daftar
praktik agile tersebut berfungsi sebagai basis untuk
membuat instrumen pengukuran, yaitu berupa kuesioner.
Daftar tersebut memuat 70 praktik pengembangan
perangkat lunak dari lima literatur. Kemudian setelah data
kuesioner didapat, praktik-praktik tersebut dikategorikan
dalam 19 cluster. Daftar praktik tersebut (setelah
diterjemahkan) adalah sbb.
Tabel 2 Daftar Praktik Agile
Kelompok
Deskripsi Praktik
1. Kolaborasi
Berkomunikasi langsung
setiap hari

2.Kemunculan
kebutuhan

3. Manajemen
kode dan
pengujian

4. Kepedulian
terhadap
solusi (produk)
5.
Pengembanga
n berdasar
pengujian
6. Organisasisendiri secara
berkelanjutan
(sustainable
selforganization)

Saling bertanya dan saling

belajar antara satu sama
lain
Berkolaborasi dengan
anggota tim
Menjaga pekerjaan agar
tetap sederhana
Tidak kehilangan otonomi
dalam tekanan kerja untuk
memenuhi deadline
Membagi tanggung jawab
Mendorong budaya bekerja
bersama sebagai tim
daripada sendiri-sendiri
Membolehkan kebutuhan
untuk berevolusi ketika
proyek sedang berlangsung
Membolehkan munculnya
kebutuhan-kebutuhan
Menjalankan uji penerimaan
pengguna (user acceptance
test)
Mengumpulakan
pengukuran-pengukuran
pengujian
Mengelola konfigurasi
perangkat lunak (version
control)
Mengelola source code
Merencanakan perilisan
Perencanaan ketika
sebelum dan selama proyek
berlangsung
Menggunakan standar kode
Memperhatikan tentang
arsitektur database
Mendefinisikan cakupan
menurut jadwal
Menjalankan unit pengujian
(unit tests) terotomasi
Melakukan Pengembangan
berdasar pengujian (testdriven development)
Menggunakan kepemilikan
kode secara kolektif
Melakukan integrasi kode
secara terus menerus
(continuous code
integration)
Menjaga ritme kerja
berkelanjutan (lembur
dilakukan secara minimal)
Merespon pada tekanan
dengan mengubah prioritas
atau cakupan daripada
bekerja lembur atau
menambah orang
Mengorganiasi-sendiri
(mandiri, self-organizing)
Memberikan umpan balik
secara terus menerus
Mengimplementasikan

7. Kesederhanaan
8. Pertemuan

9. Iterasi

10. Mengelola
kebutuhan

11. Proses
perangkat
lunak
tradisional

11. Proses
perangkat
lunak
tradisional

infrastruktur
pengembangan yang
mendukung kelincahan
(agility)
Mengembangkan
kemampuan agility orangorang
Memiliki pengguna yang
berpartisipasi secara aktif
selama proyek
Mengembangkan produk
yang merespon kebutuhan
bisnis
culan
Menggunakan desain
perangkat lunak yang
sederhana
Melakukan pertemuan
pelacakan kemajuan secara
harian
Melakukan pertemuan
retrosprektif
Melakukan pengembangan
secara iteratif dan
inkremental
Merilis perangkat lunak
dalam jangka waktu yang
pendek-pendek
Terus-menerus
menghasilkan perangkat
lunak yang dapat berjalan
(working software)
Menggunakan product
backlog untuk
mendefinisikan kebutuha
Menggunakan cerita untuk
mendefinisikan kebutuhan
Menentukan spesifikasi
arsitektur perangkat lunak
Menggunakan timebox
(paket waktu kerja) dalam
perencanaan
Membuat estimasi bersama
orang yang akan
mengerjakan
us
Mengidentifikasi penyebab
permasalahan dan
bertindak untuk mencegah
terjadinya di masa depan
Menangani kompleksitas
organisasional secara
sederhana
Menangani persyaratan
regulasi secara sederhana
Menangani kompleksitas
domain secara sederhana
Menangani kompleksitas
organisasional secara
sederhana
Menangani persyaratan
regulasi secara sederhana

12. Manajemen Proyek

secara agile

13. Pemantauan proyek

14.
Penyebaran
secara fisik
15. Pengkodean secara
agile

16. Kehadiran
pengguna

17. Memperhatikan kode

18. Kebutuhan
yang
sederhana
(lightweight)
19. Analisis
tradisional

Menangani kompleksitas
domain secara sederhana
Menangani kompleksitas
teknikal secara sederhana
Menangani disiplin
perusahaan secara
sederhana
Menggunakan planning
game
Membuat estimasi proyek
secara agile
Menulis dokumentasi secara
agile
Melacak dan melaporkan
kemajuan iterasi
Mengintegrasikan aktivitas
manajemen secara
langsung ke dalam tugastugas pengembangan
Tersebar secara geografis
(lain kota atau negara)
Tersebar secara fisik hingga
merefleksikan filosofi agile
Melakukan refaktor kode
(code refactoring)
Melakukan ppemrograman
berpasangan (pair
programming)
Fokus pada pekerjaan
(prioritas tidak berubah
selama iterasi)
Melakukan hal-hal ketika
harus hal-hal tersebut
dilakukan, bukan
sebelumnya
Melakukan penjaminan
kualitas secara agile
Membolehkan pengguna
untuk mendorong iterasi
Pengguna berada di tempat
yang sama dengan tim
(collocation)
Melakukan desain teknikal
kebutuhan
Mendistribusikan keahlian
pada tim dengan sesuai
Menjalankan pengujian
yang ringan (lightweight)
dan peninjauan
Menganalisis dan
menginspeksi kode
Mendefinisikan kebutuhan
yang sederhana
(lightweight)
Menggunakan metafora
untuk menjelaskan
kebutuhan
Melaksanakan analisis
sistem secara tradisional

5
Selanjutnya, penulis menggunakan daftar praktik agile
ini sebagai salah satu instrumen panduan dalam
pengumpulan data.
2.2.1 Daftar Istilah dalam Metode Pengembnngan Agile
Dalam rangka menambah pemahaman terhadap
prinsip, karakteristik, dan teknik-teknik yang digunakan
dalam Pengembangan Agile, dibutuhkan daftar istilah yang
dapat menjadi referensi. Alzoabi [12] dalam bab berjudul
Agile Software: Body of Knowledge, telah menjelaskan
tentang metodologi agile, karakteristik umumnya, dan
penjelasan singkat dari metode-metode agile yang terkenal
di industri dan penelitian. Dari artikel tersebut, diambil
(diterjemahkan) sebagai referensi istilah-istilah dalam
metode pengembangan agile berikut.
Agile Software Development Methods: Sebuah
kumpulan proses perangkat lunak yang bersifat kreatif,
fleksibel, adaptif, responsif, dan berpusat pada orang.
Metode ini berfokus pada komunikasi antara tim
pengembang dan pengguna, dokumentasi yang sedikit, dan
menerima perubahan.
Iteratif: Kata iteratif berarti mengembangkan
perangkat lunak melalui perulangan-perulangan.
Metodologi agile berusaha untuk memecahkan masalah
perangkatlunak dengan menemukan secara suksesif
mendekati sebuah solusi mulai dari kumpulan kebutuhan
inti minimal. Hal ini berarti tim agile merancang sebuah inti
sistem dan kemudian mengubah fungsionalitas dari tiap
subsistem seiring dengan perilisan baru ketika kebutuhan
diperbarui setiap kali. Karena itu, metode ini tidak seperti
metode pengembangan perangkat lunak tradisional yang
mencoba merancang solusi menyeluruh dengan sekali coba.
Para praktisi metodologi agile memahami kesulitan yang
dihadapi pengguna untuk menyatakan kebutuhan mereka
dengan cara yang benar dan justru mulai dengan beberapa
fungsi inti dari sistem dan kemudian mengubah siste setelah
mendapatkan pemahaman mendalam terhadap kebutuhan
dan keinginan pengguna melali kolaborasi yang ekstensif
dengan para pemegang kepentingan dalam proyek.
Incremental: Sebagai sebuah hasil dari pendekatan
iteratif dari metode agile, setiap subsistem dikembangkan
dengan cara yang membolehkan kebutuhan untuk muncul
dan digunakan untuk mengembangkan subsistem lain
berdasarkan iterasi yang sebelumnya. Pendekatan ini adalah
untuk memidularisasi sistem ke dalam subsistem yang lebih
kecil mengacu pada spesifikasi fungsionalitas dan
menambah fugsionalitas baru dengan setiap rilis baru.
Setiap rilis harus dapat diuji dan berupa subsistem yang
dapat digunakan. Ketika pengembangan berlanjut,
increments (tahapan-tahapan) baru ditambahkan hingga
sistem selesai dikembangkan. [13]
Simplicity: Prinsip KISS (Keep It Simple, Stupid)
adalah sentral dalam metode pengembangan agile. Kode,
desain, pengujian, dan dokumentasi yang sederhana akan
membantu dalam melakukan berbagai hal dengan cepat dan
menyesuaikannya jika dibutuhkan. [14]
Interaction with customers : Prinsip ini juga
sentral dalam metode agile karena menfokuskan pada
konsep seperti on-site customers (pengguna terlibat di
tempat) untuk mendapatkan umpan balik dengan segera
mengenai fungsionalitas yang dibutuhkan saat munculnya,
menjadikan lebih akurat dan memuaskan pengguna.
Self-organizing: Istilah ini mengenalkan sebuah
pendekatan yang radikal pada manajemen. Di sini metode

agile mengasumsikan pengembang yang terampil dan

memiliki kualifikasi tinggi yang seharusnya punya
kebebasan untuk merencanakan, mengorganisasi,
mengkoordinasi dan mengontrol proyek perangkat lunak
tanpa benar-benar dibimbing [14]. Dalam situasi
pengembangan agile, konsep self-organizing (pengeloaan
mandiri) memberikan tim otonomi untuk mengorganisasi
diri mereka sendiri dalam menyelesaikan tugas-tugas kerja.
Ini berarti bagaimana pendekatan pengembangan sistem,
pemilihan teknologi, komunikasi dengan pengguna, dll
diserahkan seluruhnya pada tim untuk meneukan solusi
terbaik. Pendekatan ini berbeda sama sekali dengan cara
tradisional di mana manajer proyek harus mengontrol
pekerjaan.
Activity: Aktivitas yang dimaksud dalam konteks
pengembangan agile ini adalah pengerjaan penulisan kode,
bukan berbagai perencanaan yang terkadang menghabiskan
kebanyakan waktu dalam pembangunan perangkat lunak.
Hal ini ditekankan melalio kode yang terdokumentasi
sebagai aktivitas dokumentasi yang utama.
Lightweight (ringan): Hal ini berarti
meminimalkan segala hal yang terlihat tidak perludalam
proses pengembangan seperti dokumentasi yang eksesif
(berlebihan), perencanaan yang ekstensif, dll untuk
meningkatkan kecepatan dan efisiensi dalam
pengembangan. Sebagai gantinya, metode agile mengganti
dokumentasi yang besar dengan diskusi yang seru dengan
on-site customers (pelanggan yang terlibat di tempat) [14]
Refactoring: Teknik ini mengizinkan para pengembang
untuk mencapai fungsionalitas terlebih dahulu baru
kemudian melihat lebih dekat pada kode. Yang berarti
bahwa setelah fungsionalitas didapat, perubahan-perubahan
kecil kapada kode dilakukan hingga pemakaiannya
tidakvterpengaruh, kode yang dihasilkan menjadi lebih
berkualitas. [15]
Test-Driven Development: Teknik ini berarti bahwa
tes terotomasi dirancang sebelum coding dimulai. Rancang
tes-nya, tulis kode-nya, jalankan tes-nya, ubah hingga tes
dapat dilewati. [15]
Acceptance Testing: Pengujian terakhir yang
dilakukan pada sistem yang sudah selesai dikembangakan,
biasanya melibatkan pengguna, sponsor proyek, customer,
dll. [16]
Continuous Integration:: Kode diintegrasikan
dan diujji setelah beberapa jam maksimal dalam sehari
kegiatan pengembangans [14]. Ini mengizinkan untuk
deteksi error secara dini.
Pair Programming: Dua pengembang bekerja
samaa secara bergantian pada satu PC. Bug diidentifikasi
ketika muncul, karenanya produk menjadi berkualitas tinggi
[16] Keduanya bekerja sebagai tim kecil, satu berpikir
secara strategis dan yang lain berpikir secara taktis.
Keduanya bisa saling berganti peran. [14]
On-Site Customers: Seorang pengguna, yang
merupakan anggota dari tim pengembang, akan
bertanggung jawab untuk mengklarifikasikan kebutuhan
dan akan memberikan umpan balik dengan segera kepada
tiim pengembang. [16]
Backlog: Kebutuhan fungsionalitas produk yang
belum dipenuhi oleh rilis produk yang sekarang. Bug,
kerusakan, peningkatan yang diminta pengguna, dll adalah
item di dalam backlog.
Product Owner: Orang yang bertanggung jawab
untuk membuat dan mengatur prioritas Product Backlog

6
contohnya kebutuhan-kebutuhan. Berdasarkan tingkat
kepentingan yang dirasakan, product owner memilih apa
yang dimasukkan dalam setiap iterasi/sprint , dan meninjau
sistem di akhir sprint untuk mengontrol kualitas.
Scrum Master: Dia adalah ahli dalam Scrum dan
memahami siapa yang emngetahui dan mendorong iterasi
produk, tujuan, dan nilai-nilai dan praktik Scrum, menyelenggarakan pertemuaan harian (the Scrum Meeting)
dan demonstari iterasi (the Sprint Review), mendengarkan
kemajuan, menghilangan penghalang (blocks), dan menyediakan sumber daya. Scrum Master adalah juga seorang
pengembang dan berpartisipasi dalam pengembangan
produk (bukan hanya manajemen)
Development Sprints (release): Pengembangan
rilis fungsionalitas baru, dengan menghargai variabell
waktu, kebutuhan, kualitas, biaya, dan kompetisi. Interaksi
dengan variabel-variabel ini mendefinisikan akhir dari fase.
Terdapat beberapa, sprints pengembangan iteratif, atau
cycles (siklus), yang digunaan untuk mengevolusi sistem.
Developing by Feature: Setiap fungsi yang
implemen-tasinya akan memakan waktu lebih dari dua
minggu, dipecah menjadi fungsi-fungsi yang lebih kecil,
hingga fungsi yang dihasilkan dapat diimplementasikan
dalam dua minggu. Dalam sistem bisnis, sebuah fitur
mewakili sebuah langkah dalan beberapa aktivitas dalam
sebuah proses bisnis. Sebuah fitur adalah fungsi yang kecil,
bernilai yang dapat diimplementasikan dalam dua minggu.
Penamaan fitur adalah : <action> the <result> <by | for |of |
to | > <a(n)> <object>
Configuration Management: Ini membantu dalam
mengindentifikasi versi terakhir dari berkas source code
dan menyediakan pelacakan historis dari semua artifak
dalam proyek.
Domain Experts:Ini adalah orang bisnis yang mana
memiliki masalah. Ini dapat berupa user, customer, analis
bisnis, atau campuran di antaranya. Mereka menyediakan
pengetahuan yang dibutuhkan oleh pengembang untuk
memahami sistem dan mengembangkannya. Pengetahuan
dan partisipasi mereka sangat signifikan dalam kesuksesan
hasil sistem.
Time-Boxed: Menentukan deadline yang fixed
(tetap) akan memaksa para pengembang untuk
berkompromi di awal proyek dan akan mengantarkan pada
pengekatan yang lebih realistik dalam pengembangan.

2.3 Penelitian-Penelitian Lain

Abrahamsson, dkk [17] menyebutkan dalam editorial
jurnal keluaran khusus (special issue) European Journal of
Information System, bahwa masih dibutuhkan penelitian
untuk memahami lebih dalam bagaimana metode agile
digunakan dalam praktik. Untuk konteks Indonesia yang
secara kultural dan kemajuan inovasi berbeda dengan
negara maju, penelitian semacam ini juga masih
dibutuhkan.
Salleh, dkk menginvestigasi adopsi Metode Agile oleh
21 pengembang perangkat lunak di Indonesia menggunakan
survey [18]. Survey ini menyebutkan bahwa tantangan
utama adopsi metode agile di Indonesia berkisar pada
masalah orang, organisasional dan pengguna.
Asri, dkk [19] melakukan peninjauan terhadap metode
Scrum, XP (Extreme Programming) dan Crystal sebagai
varian dari Metode Agile. Dalam penelitian ini ditinjau

persamaan dan perbedaan masing-masing metode, proses,

lingkup penggunaan, adopsi, dll. Pada akhirnya dibuat
komparasi antara ketiga metode agile tersebut.
Dyba dan Dingsoyr [8] meninjau apa yang telah
diketahui dari 36 penelitian empiris mengenai manfaat,
keterbatasan, dan kekuatan dari metode agile.
Dengan menggunakan pendekatan grounded theory,
Coleman dan OConnor [11] menjelaskan bagaimana
pembentukan proses (process formation) di perusahaan
startup. Data penelitian mereka berasal dari survey terharap
perusahaan startup di Irlandia.
Steve Blank [20] menulis sebuah rekomendasi solusi di
Harvard Business Review untuk perusahaan startup berupa
teknik Lean Startup yang muncul dari Lean Startup
Movement gagasan Eric Ries [21]. Komponen utama dari
Lean Startup adalah siklus build-measure-learn yang
mengikuti evolusi produk. Dalam Lean Startup, rencana
bisnis dibuat satu halaman berupa business model canvas.
Untuk menguji hipotesis solusi dengan keluar ruangan
meminta orang untuk mencoba produk yang masih berupa
minimum viable product. Dan umpan balik (feedback) dari
orang-orang dijadikan sebagai data untuk memperbarui ide
dan produk. Siklus tersebut terus berulang sambil mengikuti
empat langkah costumer development : customer discovery
customer validation custemer validation company
building.
2.4 Model Startup C2C
Perusahaan startup tidak hanya berkutat dengan
pengembangan produk dan jasa, tapi juga harus
memperhatikan sisi bisnis. Model bisnis menjadi bagian tak
terpisahkan dan juga sangat mempengaruhi proses
pengembangan produk dan jasa pada perusahaan startup.
Yahya [22] dalam disertasinya membahas tentang
peluang ekonomi industri kreatif di Indonesia dan
mengajukan sebuah model bisnis startup C2C (Creativity to
Commerce), setelah membahas tiga model startup yang
telah ada sebelumnya, yaitu: The Four Steps of Epiphany
oleh Steve Blank, model Lean Startup oleh Eric Ries,
model Running Lean oleh Ash Maurya. Ketiga model
startup tersebut kebanyakan berasal dari hasil pengalaman
dan pengamatan para praktisi terhadap perusahaanperusahaan startup Silicon Valley.
Model Startup C2C berusaha untuk menyesuaikan
model startup yang sudah ada dengan karakteristik
perusahaan digital company Indonesia dan juga untuk
diterapkan dalam inkubator bisnis.
Dalam penelitian ini, model startup C2C dijadikan
panduan untuk membuat pertanyaan terbuka (open
questions) dalam wawancara. Model startup C2C dianggap
cocok dengan objek studi kasus. Pertanyaan-pertanyaan
wawancara disusun untuk mengetahui lingkungan bisnis,
baik internal maupun eksternal perusahaan startup, yang
mempengaruhi pengembangan produk perangkat lunak.
3. METODE PENELITIAN
Dalam melakukan penelitian, perlu disesuaikan antara
sifat masalah dan objek penelitian dengan metodologi
penelitian yang digunakan. Ketidaksesuaian metodologi
penelitian dapat mengakibatkan kesalahan rancangan
penelitian (research design error).
Dalam penelitian ini, masalah yang ingin diteliti bersifat
relatif baru untuk tema penelitian sejenis di Indonesia,
objek penelitian didapatkan dengan sampel purposif (bukan

7
sampel acak) yang telah ditentukan sejak awal penelitian,
dan banyak fenomena yang akan digali berbentuk tacit
knowledge (pengetahuan tidak terucapkan, tidak
terdokumentasi dengan baik). Observasi awal berupa
pengalaman penulis di perusahaan juga pertimbangan
pemilihan topik dan masalah penelitian. Selain itu,
preferensi penulis yang lebih cenderung pada penelitian
kualitatif karena ingin menggali banyak informasi dari
perusahaan studi kasus.
Untuk meneliti masalah dan objek penelitian dengan
karakteristik seperti disebut di atas, maka lebih tepat
digunakan metodologi penelitian kualitatif.
Langkah-langkah dalam penelitian metodologi kualitatif
tidak selalu mengikuti alur satu arah. Di tengah jalannya
penelitian dimungkinkan ada perubahan tertentu sebagai
adaptasi terhadap temuan di lapangan.
3.1 Instrumen Penelitian dan Sampling
Instrumen penelitian dalan penelitian kualitatif adalah
pewawancara itu sendiri. Hal ini berbeda dengan penelitian
kuantitatif yang biasanya menggunakan instrumen berupa
kuesioner yang dirancang sedemikian sehingga valid dan
reliabel. Dalam wawancara untuk menggali data tentang
bagaimana perusahaan startup mengembangkan produk
software-nya, diperlukan instrumen berupa pewawancara
yang mengetahui hal-hal terkait dengan startup. Dalam
konteks penelitian ini, instrumen yang dimaksud adalah
penulis sendiri sebagai peneliti dalam studi kasus. Untuk
itu, penulis mempersiapkan salah satunya diri dengan
mempelajari istilah-istilah yang sering digunakan
perusahaan startup, istilah-istilah dalam pengembangan
agile. Startup mempunyai banyak istilah teknologi atau
buzzwords yang tidak umum diketahui masyarakat, seperti
MVP (Minimum Viable Product), monetization, Test Driven
Development, dsb. Informasi dan pengetahuan tentang
istilah-istilah tersebut penting untuk membangun hubungan
wawancara yang jujur dan terbuka dari pihak pewawancara
dan informan/responden.
Untuk keperluan sampel penelitian, digunakan
purposive sampling, bukan random sampling yang sering
digunakan dalam penelitian kuantitatif. Purposive sampling
ini dilakukan dengan memilih sampel yang sesuai dengan
deskripsi umum teori pengembangan agile dalam
penelitian, juga dimasukkan dalam konteks penelitian ini
sebagai studi kasus perusahaan startup.
Perusahaan-perusahaan startup, menurut pengamatan
dan pengalaman penulis, biasanya mempunyai sebuah
wadah komunitas tertentu. Sebelumnya terdapat beberapa
kandidat perusahaan startup yang akan dijadikan sampel
dalam studi kasus, namun akhirnya dipilih hanya satu yang
aksesnya lebih mudah (convenience sampling). Perusahaan
tersebut sebuah perusahaan startup yang didirikan oleh
teman seangkatan penulis. Perusahaan startup ini sudah
berdiri sejak tahun 2013. Dalam perusahaan startup ini ada
empat anggota tetap tim. Yang dipilih sebagai
responden/informan adalah dua pendiri (founder)
perusahaan tersebut.
Sebelumnya penulis sempat mempertimbangkan untuk
menggabungkan metode kualitatif dengan kuantitatif.
Penggabungan metode (mixed methods) sebenarnya lebih
tepat jika tujuan penelitian adalah untuk menghasilkan hasil
yang dapat lebih digeneralisasi. Namun mengingat
keterbatasan sumber daya dan waktu, juga risiko tinggi
kegagalan penelitian akibat pengembalian respon kuisioner

yang rendah, maka dibatasi untuk metode kualitatif saja.

Untuk penelitian lebih lanjut mungkin bisa menggunakan
hasil penelitian ini dalam penelitian kualitatif dengan
jumlah sampel yang lebih banyak (studi multi kasus) atau
penelitian kuantitatif.
Pewawancara dalam penelitian kualitatif bertindak
sebagai instrumen penelitian. Berbeda dengan penelitian
kuantitatif yang biasanya menggunakan instrumen berupa
kuesioner yang dirancang agar valid dan reliabel. Dalam
wawancara untuk menggali data tentang bagaimana
perusahaan startup mengembangkan produk software-nya,
diperlukan instrumen berupa pewawancara yang
mengetahui hal-hal terkait dengan startup.
Perusahaan-perusahaan startup, menurut pengamatan
dan pengalaman penulis biasanya mempunyai sebuah
wadah komunitas tertentu. Startup juga punya banyak
istilah teknologi atau buzzwords yang tidak umum
diketahui masyarakat, seperti MVP (Minimum Viable
Product), monetization, Test Driven Development, dsb.
Informasi dan pengetahuan tersebut penting untuk
membangun hubungan wawancara yang jujur dan terbuka
dari pihak pewawancara dan informan.
Dalam melakukan wawancara, diharapkan akan
didapatkan data berupa situasi (konteks), pengalaman dan
tindakan, objek konkret maupun abstrak, peristiwa (event),
ruang (space) dan waktu,pengetahuan, pendapat (opini),
persepsi dan perasaan dari yang diwawancarai, yang
semuanya berfokus pada topik yang sedang diteliti. Datadata tersebut sangat sulit didapatkan jika menggunakan
penelitian kuantitatif.
Selain hal di atas, pewawancara juga diharapkan dapat
menjaga perspektif penelitian untuk meminimalkan bias
yang dapat merusak validitas data.
Metode pengerjaan penelitian ini dibuat agar pengerjaan
penelitian ini dapat dilakukan secara sistematis dan
memenuhi kaidah-kaidah penelitian ilmiah. Metode
pengerjaan penelitian ini secara ringkas dapat dijelaskan
dalam gambar.
Metode penelitian ini mengikuti panduan metode studi
kasus. Metode studi kasus dilakukan dengan menganalisis
secara lebih mendalam praktik penerapan pengembangan
perangkat lunak di sebuah perusahaan startup.
Untuk melakukan studi kasus, penulis mengumpulkan
data berupa wawancara mendalam, pengumpulan dokumen
digital dan non digital, ikut terlibat langsung dalam
mengalami proses operasional sehari-hari, dan menuliskan
hasil observasi dalam catatan.

8
kai berkisar antara startup dan agile software
development.
Literatur utama yang ditemukan dan dijadikan
referensi dalam penelitian ini adalah:

3.2 Identifikasi Masalah

Penerapan metode pengembangan perangkat lunak tidak
selalu sesuai dengan teori. Proses dan metodologi formal
hampir selalu mengalami modifikasi tertentu agar sesuai
dengan kebutuhan proyek. Begitu pula dengan penerapan
metode pengembangan perangkat lunak dalam konteks
perusahaan startup.
Strategi identifikasi masalah dilakukan untuk menjelaskan pengalaman-pengalaman tim perusahaan startup dalam
menerapkan metode pengembangan perangkat lunak. Pada
tahap ini peneliti menggali isu-isu dengan segala kompleksitasnya dan berfokus pada pemahamannya terhadap
kejadian-kejadian dari sudut pandang subjek sendiri yang
dijadikan sebagai acuan dengan penekanan pada proses
[23].
Pengidentifikasian
masalah
dilakukan
dengan
menggunakan pendekatan studi kasus. Hal ini berkaitan
dengan tujuan penelitian ini, yaitu menghasilkan
pengamatan dan analisis secara kualitatif terhadap praktik
penerapan metode pengembangan agile dalam studi kasus
sebuah perusahaan startup. Dari studi kasus diharapkan
akan dapat diamati hal-hal yang dapat dijadikan tambahan
penguat temuan dan teori yang sedang dikembangkan
dalam berbagai penelitian [24].
3.3 Studi Literatur
Studi literatur dilakukan dengan menelusuri buku
teks, jurnal dan tulisan para ahli dalam bidang metode
pengembangan perangkat lunak, dan juga tulisan para
praktisi dan pengusaha perusahaan startup yang
mempraktikkan metode pengembangan agile. Studi literatur
ini dilakukan untuk membangun dasar teori dan
mengumpulkan temuan dari penelitian sebelumnya dan
praktik penerapan teori oleh para praktisi dalam konteks
perusahaan startup.
Penelusuran literatur utamanya dilakukan melalui
portal sciencedirect.com, Google Scholar, dan portal
Perpustakaan Nasional (pnri.go.ig). Kata kunci yang dipa-

1. Paternoster, dkk.
(2014). Software development in startup companies:
A systematic mapping study. Information and
Software Technology. [2] Dalam makalah ini
Paternoster, dkk melakukan studi pemetaan
sistematis dengan menelusuri dan mengumpulkan
berbagai literatur akademik bertema startup,
mencoba menggali apa yang telah diketahui tentang
pembangunan perangkat lunak di perusahaan startup,
dan potensi implikasi penerapannya dalam praktik.
Dari makalah ini penulis mengambil daftar
karakteristik perusahaan startup.
2. Dyba,
T.,
&
Dingsyr, T. (2008). Empirical studies of agile
software development: A systematic review.
Information and Software Technology, 833-859. [8]
Dalam makalah ini dibahas tentang apa yang telah
diketahui tentang kelebihan dan kekurangan metode
pengembangan agile, disertai bukti empirisnya yang
ditemukan dalam berbagai literatur hingga tahun
2008.
3. 3. R. M. Fontana,
I. M. Fontana, P. A. d. R. Garbuio, S. Reinehr dan A.
Malucelli, Processes versus people: How should
agile software development maturity be defined?,
The Journal of Systems and Software, no. 97, pp.
140-155, 2014. [10] Dalam makalah ini dibahas
tentang maturitas pengembangan perangkat lunak
agile. Dalam manifesto agile, metode pengembangan
agile disebut memiliki prinsip lebih mengutamakan
individu dan interaksi daripada proses dan alat dalam
pengembangan perangkat lunak. Hal ini menjadikan
berbagai perspektif pengukuran maturitas yang
berfokus pada proses pengembangan perangkat lunak
kurang sesuai. Lebih jauh, makalah ini mengajukan
definisi maturitas pengembangan perangkat lunak
agile Dari makalah ini penulis mengmbil rujukan
daftar praktik agile (agile practices) yang
diidentifikasi dari berbagai literatur akademik.
3.4 Pengumpulan Data
Pengumpulan data merupakan serangkaian aktivitas
yang bertujuan untuk mengumpulkan informasi yang
menandai dalam rangka menjawab masalah penelitian.
Cresswell (2009) memberikan penjelasan tentang aktivitas
dalam penelitian kualitatif. Data yang akan dikumpulkan
melalui penelitian penelitian ini adalah data yang sesuai
dengan fokus penelitian yaitu tentang metode
pengembangan agile di perusahaan startup.
Jenis data yang digali adalah dalam bentuk kata-kata
atau ucapan lisan (verbal) dan perilaku dari subjek (tim
dalam perusahaan startup) berkaitan dengan metode
pengembangan agile.
Mengumpulkan data dari perusahaan startup cukup sulit.
Hal ini dikarenakan karakteristik dari perusahaan yang
memang tidak banyak melakukan dokumentasi. Jadi teknik
pengumpulan data yang digunakan adalah wawancara
secara mendalam.

9
Wawancara dilakukan dengan dialog langsung (tatap
muka) dengan anggota tim pengembang perusahaan startup
dan anggota tim lainnya yang berperan dalam
pengembangan. Selain wawancara yang terjadwal,
pewawancara juga dapat melengkapi data dengan
percakapan tambahan melalui media komunikasi online.
3.4.1 Observasi Awal
Perusahaan yang dijadikan studi kasus ini merupakan
perusahaan startup tempat penulis melakukan Kerja Praktek
pada bulan Agustus hingga Oktober 2013. Pada saat itu
produk yang sedang dikembangkan perusahaan adalah
layanan direktori dan pencarian kampus yang dapat diakses
melalui kampus.co.id. Penulis berpartisipasi secara moderat
dalam menambah dan memperbarui konten dalam layanan
tersebut.
Setelah mendapatkan beberapa pengalaman dalam Kerja
Praktek tersebut, timbul niat penulis untuk meneliti lebih
lanjut tentang bagaimana seharusnya perusahaan startup
dijalankan. Hal ini dikarenakan penulis merasa banyak hal
yang dilakukan dalam perusahaan terlalu sering berubahubah, tim tidak memiliki panduan yang cukup atau terlalu
variatif karena diambil dari berbagai sumber dari internet.
Selain itu, panduan berupa berbagai artikel online tersebut
dirasakan kurang sesuai dengan konteks kultural sifat
perusahaan startup di Indonesia dan target pasarnya.
Pada bulan November hingga tahun berikutnya sekitar
bulan April 2014, penulis melanjutkan membantu pekerjaan
operasional dalam perusahaan sebagai intern. Pada bulan
Januari 2014 perusahaan melakukan perubahan besar
berupa pivot produknya menjadi layanan sertifikasi online
di domain internet cert.kampus.co.id. Penulis mengamati
proses pengembangan produk yang sering diistilahkan
sebagai pemrograman koboi, yaitu desain awal seminimal
mungkin dengan kebutuhan fitur didapat dari investor dan
asumsi-asumsi tim, lalu segera membuat prototype desain
user interface (UI), melakukan aktivitas coding, dan terus
melakukan perbaruan secara iteratif.
Sampai di sini penulis merasakan banyak hal yang
berbeda dari teori proses pembangunan perangkat lunak
yang didapatkan oleh penulis sebelumnya dalam kuliah. Hal
ini menyebabkan timbul keinginan penulis untuk
menelusuri literatur akademik mengenai metode
pengembangan perangkat lunak yang sedang menjadi tren
dan populer menggantikan metode pengembangan
perangkat lunak lama. Seiring dengan itu, penulis juga
mulai memikirkan hipotesis sementara (working
hypothesis) untuk mengidentifikasi dan merumuskan
masalah dan rancangan penelitian (research design) yang
sesuai.
3.4.2 Strategi Wawancara
Masalah yang mungkin muncul dalam pelaksanaan
penelitian adalah keterbatasan akses, kesalahpahaman
terhadap tujuan, topik dan bidang penelitian antara peneliti
dengan informan/responden, ketidakterbukaan (atau
kekurang-terbukaan) responden terhadap pertanyaan yang
diajukan yang mempengaruhi data, dsb.
Untuk membangun akses, peneliti mengontak responden
beberapa minggu sebelumnya untuk menjelaskan tujuan
penelitian, meminta kesediaan wawancara (disertai tanda
tangan surat keterangan kesediaan jika perlu),
menjadwalkan kegiatan wawancara.
Untuk
menghindari
kesalahpahaman,
peneliti
menunjukkan proposal penelitian disertai draft pedoman

wawancara yang nantinya akan digunakan. Hal ini

dimaksudkan juga agar responden dapat mempersiapkan
diri sebelum wawancara diakukan. Selain itu, peneliti juga
menunjukkan iktikad baik dalam pelaksanaan penelitian
yang diusahakan dapat bermanfaat juga bagi responden,
tidak terbatas hanya untuk peneliti atau kalangan sendiri.
Masalah
ketidakterbukaan
responden
terhadap
pertanyaan semi-terbuka perlu disiasati dengan pemilihan
setting dan situasi yang nyaman bagi responden. Peneliti
bisa memilih tempat selain tempat kerja yang formal,
seperti cafe, masjid, atau kampus. Untuk jadwal wawancara
juga menyesuaikan dengan agenda responden. Peneliti
sebaiknya tidak mengiterupsi jam kerja efektif, jadi bisa
dipilih waktu istirahat siang hari, sore, atau malam hari.
Wawancara dilakukan dengan dialog langsung (tatap
muka) dengan anggota tim pengembang perusahaan startup
dan anggota tim lainnya yang berperan dalam
pengembangan. Selain wawancara yang terjadwal,
pewawancara juga dapat melengkapi data dengan
percakapan tambahan melalui media komunikasi online.
Wawancara yang dilakukan sebaiknya tidak lebih dari
30 menit. Pedoman wawancara dibuat dalam bagian-bagian.
Jika di tengah wawancara ada suatu hal yang menyebabkan
terhendi, maka bisa dilanjutkan bagian yang belum
ditanyakan, tidak perlu mengulangi lagi dari awal. Bagian
pertama berisi pertanyaan untuk menggali informasi latar
belakang dari responden, bagian kedua tentang pertanyaan
inti topik penelitian, bagian ketiga berisi informasi dan
masukan tambahan yang berguna bagi penelitian dan
pewawancara. Responden/informan sebagai subjek
wawancara berhak untuk menolak memberikan jawaban
pada pertanyaan tertentu.
Setelah wawancara dilakukan, rekaman hasil
wawancara didengarkan berulang-ulang, ditranskripsikan,
dikodifikasi, kemudian dilihat pola respon terhadap
pertanyaan, membandingkannya dengan respon responden
lain (tria-ngulasi), mencatat poin-poin yang penting dan
mempersiap-kannya untuk analisis.
Selain hal di atas, saat mewawancarai dan mendengarkan rekaman, pewawancaran sebagai peneliti juga
diha-rapkan tetap dapat menjaga perspektif penelitian untuk
meminimalkan bias yang dapat merusak validitas data.
3.4.3 Pedoman Wawancara
Dalam melakukan wawancara, diharapkan akan
didapatkan data berupa situasi (konteks), pengalaman dan
tindakan, objek konkret maupun abstrak, peristiwa (event),
ruang (space) dan waktu, pengetahuan tidak eksplisit (tacit
knowledge), pendapat (opini), persepsi dan perasaan dari
yang diwawancarai, yang berbagai hal lainnya terkait
dengan topik yang sedang diteliti. Data-data tersebut sangat
sulit didapatkan jika menggunakan penelitian kuantitatif.
Pertanyaan pedoman wawancara dibuat berdasarkan
temuan literatur. Pertanyaan-pertanyaan ini merupakan hasil
perincian dari rumusan masalah penelitian yang utama.
Sebagaimana telah dituliskan pada Pendahuluan, rumusan
masalah penelitian ini adalah:
Sebagai studi kasus, bagaimana sebuah perusahaan
startup menerapkan Metode Pengembangan Perangkat
Lunak Agile?

10
Lebih lanjut,
didetailkan sbb.

rumusan

masalah

tersebut

dapat

2.Apa saja karakteristik perusahaan startup

dalam studi kasus?
3. Apa saja praktik pengembangan perangkat
lunak yang diterapkan di perusahaan startup? Apakah
termasuk agile?
4. Bagaimana praktik kerja di perusahaan
startup dalam studi kasus?
Untuk memandu pelaksanaan wawancara, dibuat
pedoman wawancara. Pedoman wawancara diambil dari
rincian rumusan masalah yang telah ditentukan dalam
proses identifikasi masalah dan studi literatur, yaitu:
1. Apa saja karakteristik perusahaan startup dalam studi
kasus?
Pedoman wawancara untuk pertanyaan ini diambil dari
tabel karakteristik perusahaan startup.(Error: Reference
source not found)
2. Apa saja praktik pengembangan perangkat lunak yang
diterapkan di perusahaan startup? Apakah termasuk
agile?
Pedoman wawancara untuk pertanyaan ini diambil dari
tabel Daftar Praktik Agile (Agile Practices) (Error:
Reference source not found)
3. Bagaimana praktik kerja di perusahaan startup dalam
studi kasus?
Pedoman wawancara untuk pertanyaan ini diambil dari
bagian kesimpulan makalah rujukan utama dari
Paternoster, dkk [2].
3.5. Uji Keabsahan Data
Setelah data terkumpul dari obser vasi dan wawancara,
uji keabsahan data dilakukan dengan cara tirangulasi dan
member checking.
3.5.1 Triangulasi
Triangulasi merupakan proses pengumpulan data yang
bersifat menggabungkan berbagai sumber dan teknik
pengumpulan data yang sudah ada. Teknik triangulasi
dalam penelitian kualitatif bertujuan bukan untuk mencari
kebenaran tentang fenomena tetapi lebih pada peningkatan
pemahaman peneliti terhadap apa yang telah ditemukan.
Kebenaran data dimaksud valid atau tidak dalam konteks
ini adalah perbandingan satu set data dari satu sumber
dengan set data lain yang diperoleh dari sumber lain.
Penulis sebagai instrumen penelitian kualitatif telah
melakukan pengamatan, pencermatan, pengenalan dan
pemahaman terhadap penerapan metode pengembangan
agile dalam perusahaan startup studi kasus, seperti telah
dijelaskan sebelumnya, yaitu pada saat observasi awal.
Selain itu, wawancara dengan pedoman yang sama
dilakukan pada dua orang anggota tim yang berbeda peran
dalam perusahaan startup. Hal ini bisa memenuhi syarat
triangulasi sumber.
3.5.2 Member Checking
Member checking sebagai validasi data dalam penelitian
kualitatif bertujuan untuk mengetahui akurasi hasil
penelitian. Proses ini dilakukan dengan menyimpulkan
deskripsi-deskripsi ke hadapan informan untuk mengecek

apakah hasil wawancara atau data/informasi sudah akurat.

Menurut Sugiyono [24] member checking adalah proses
pengecekan data yang diperoleh peneliti kepada pemberi
data. Proses ini bertujuan untuk mengetahui seberapa jauh
data yang diperoleh sesuai dengan apa yang sampaikan oleh
informan.
Proses ini bisa dianggap terwakili pada saat wawancara
pengambilan data, yaitu posisi pewawancara dan responden
bersama-sama melihat dan mengisi isian dan catatan
wawancara. Pada saat wawancara responden selalu diminta
mengkonfirmasi jawabannya, menanyakan pertanyaannya
jika kurang jelas, dan diminta menjelaskan jawabannya
lebih jauh dengan pancingan-pancingan jika diperlukan.
4. HASIL DAN PEMBAHASAN
4.1 Observasi Awal
Perusahaan studi kasus merupakan perusahaan startup
tempat penulis melakukan Kerja Praktek pada bulan
Agustus hingga Oktober 2013. Pada saat itu produk yang
sedang dikembangkan perusahaan adalah layanan direktori
dan pencarian kampus yang dapat diakses melalui
kampus.co.id. Penulis berpartisipasi secara moderat dalam
menambah dan memperbarui konten dalam layanan
tersebut.
Setelah mendapatkan beberapa pengalaman dalam Kerja
Praktek tersebut, timbul niat penulis untuk meneliti lebih
lanjut tentang bagaimana seharusnya perusahaan startup
dijalankan. Hal ini dikarenakan penulis merasa banyak hal
yang dilakukan dalam perusahaan terlalu sering berubahubah, tim tidak memiliki panduan yang cukup atau terlalu
variatif karena diambil dari berbagai sumber dari internet.
Selain itu, panduan berupa berbagai artikel online tersebut
dirasakan kurang sesuai dengan konteks kultural sifat
perusahaan startup di Indonesia dan target pasarnya.
Pada bulan November hingga tahun berikutnya sekitar
bulan April 2014, penulis melanjutkan membantu pekerjaan
operasional dalam perusahaan sebagai intern. Pada bulan
Januari 2014 perusahaan melakukan perubahan besar
berupa pivot produknya menjadi layanan sertifikasi online
di domain internet cert.kampus.co.id. Penulis mengamati
proses pengembangan produk yang sering diistilahkan
sebagai pemrograman koboi, yaitu desain awal seminimal
mungkin dengan kebutuhan fitur didapat dari investor dan
asumsi-asumsi tim, lalu segera membuat prototype desain
UI, melakukan aktivitas coding, dan terus melakukan
perbaruan secara iteratif.
Sampai di sini penulis merasakan banyak hal yang
berbeda dari teori proses pembangunan perangkat lunak
yang didapatkan oleh penulis sebelumnya dalam kuliah. Hal
ini menyebabkan timbul keinginan penulis untuk
menelusuri literatur akademik mengenai metode
pengembangan perangkat lunak yang sedang menjadi tren
dan populer menggantikan metode pengembangan
perangkat lunak lama. Seiring dengan itu, penulis juga
mulai memikirkan hipotesis sementara (working
hypothesis) untuk mengidentifikasi dan merumuskan
masalah dan rancangan penelitian (research design) yang
sesuai.
4.2 Identifikasi Masalah
Isu besar dalam perusahaan startup adalah
pengembangan produknya, yaitu berupa perangkat lunak.
Berbagai hal dalam perusahaan startup berkisar pada

11
aktivitas pengembangan perangkat lunak, seperti
pembentukan tim, alur pekerjaan, penjadwalan rilis produk,
dsb. Dalam berbagai sumber literatur non-akademik yang
menyebutkan metode pengembangan yang mendekati gaya
kerja perusahaan startup adalah metode agile. Oleh karena
itu, diambil asumsi bahwa pengembangan perangkat lunak
agile adalah metode yang dipakai oleh perusahaan startup.
Selain isu tersebut, walaupun sudah ada berbagai
literatur yang membahas tentang perusahaan startup, masih
belum ada definisi perusahaan startup yang disepakati. Hal
ini akan menyulitkan untuk menelusuri literatur akademik.
Untuk itu, perlu dikumpulkan daftar karakteristik
perusahaan startup dalam literatur akademik. Kamudian,
karakteristik tersebut perlu dicocokkan dengan konteks
perusahaan startup dalam studi kasus untuk keperluan
konfirmatori.
Isu lain yang diidentifikasi adalah praktik kerja
(work practices) yang membahas tentang aktivitas
perusahaan startup selain pengembangan perangkat lunak.

penelitian ini, hasil studi literatur telah dimasukkan ke

dalam Bagian 2 Studi Literatur makalah ini.

4.3 Penelusuran Literatur

Penelusuran literatur utamanya dilakukan melalui
portal sciencedirect.com, Google Scholar, dan portal
Perpustakaan Nasional. Kata kunci yang dipakai berkisar
antara startup dan agile software development.
Literatur utama yang ditemukan dan dijadikan
referensi dalam penelitian ini adalah:
1. Paternoster, dkk. (2014). Software development in
startup companies: A systematic mapping study.
Information and Software Technology. Dalam makalah ini
Paternoster, dkk melakukan studi pemetaan sistematis
dengan menelusuri dan mengumpulkan berbagai literatur
akademik bertema startup, mencoba menggali apa yang
telah diketahui tentang pembangunan perangkat lunak di
perusahaan startup, dan potensi implikasi penerapannya
dalam praktik. Dari makalah ini penulis mengambil daftar
karakteristik perusahaan startup.
2. Dyba, T., & Dingsyr, T. (2008). Empirical studies
of agile software development: A systematic review.
Information and Software Technology, 833-859. Dalam
makalah ini dibahas tentang apa yang telah diketahui
tentang kelebihan dan kekurangan metode pengembangan
agile, disertai bukti empirisnya yang ditemukan dalam
berbagai literatur hingga tahun 2008.
3. Fontana, R., Fontana, I., Garbuio, P. d., Reinehr, S.,
& Malucelli, A. (2014). Processes versus people: How
should agile software development maturity be defined?
The Journal of Systems and Software(97), 140-155. Dalam
makalah ini dibahas tentang maturitas pengembangan
perangkat lunak agile. Dalam manifesto agile, metode
pengembangan agile disebut memiliki prinsip lebih
mengutamakan individu dan interaksi daripada proses dan
alat dalam pengembangan perangkat lunak. Hal ini
menjadikan berbagai perspektif pengukuran maturitas yang
berfokus pada proses pengembangan perangkat lunak
kurang sesuai. Lebih jauh, makalah ini mengajukan definisi
maturitas pengembangan perangkat lunak agile Dari
makalah ini penulis mengmbil rujukan daftar praktik agile
(agile practices) yang diidentifikasi dari berbagai literatur
akademik.
Selain makalah di atas, ditemukan juga berbagai
makalah lain untuk menjelaskan hal-hal lain tentang
pengembangan agile dan perushaan startup. Dalam

Pedoman wawancara untuk pertanyaan ini diambil dari

tabel Daftar Praktik Agile (Agile Practices)

4.4 Pengumpulan Data

Pengumpulan data dilakukan dengan wawancara
mendalam. Untuk memandu pelaksanaan wawancara,
dibuat pedoman wawancara. Pedoman wawancara diambil
dari rincian rumusan masalah yang telah ditentukan dalam
proses identifikasi masalah dan studi literatur, yaitu:
1. Apa saja karakteristik perusahaan startup dalam studi
kasus?
Pedoman wawancara untuk pertanyaan ini diambil dari
tabel karakteristik perusahaan startup.
2. Apa saja praktik pengembangan perangkat lunak yang
diterapkan di perusahaan startup? Apakah termasuk
agile?

3. Bagaimana praktik kerja di perusahaan startup dalam

studi kasus?
Pedoman wawancara untuk pertanyaan ini diambil dari
tabel bagian kesimpulan makalah utama pertama.
4.5 Analisis Data
Untuk melakukan analisis data kualitatif, dilakukan
transkripsi data rekaman wawancara, kodifikasi, kemudian
menginterpretasikan pola-pola respon wawancara.
4.5.1 Latar Belakang Studi Kasus
Perusahaan studi kasus adalah sebuah perusahaan
startup yang berdiri sejak tahun 2013. Perusahaan ini
didirikan oleh dua orang alumni Sistem Informasi ITS,
yaitu Ardiaz Ajia Aryandika dan Glend Maatita. Beberapa
produk sudah dicoba luncurkan ke pasar oleh perusahaan
startup ini, salah satunya adalah search engine / direktori
kampus.co.id. Kemudian pada Februari 2014, dengan
menggunakan domain yang sama, kampus.co.id di-pivot
dengan produk utamanya menjadi cert.kampus.co.id yang
menyediakan layanan sertifikasi berbagai keterampilan
secara online. Hingga wawancara terakhir, jumlah
pengguna sudah mencapai sekitar 13.000 pengguna. Untuk
menjalankan kegiatan operasionalnya, perusahaan startup
dibiayai dari seed investment.
4.5.2 Karakteristik Perusahaan Startup
Berdasarkan hasil wawancara dan observasi yang
dilakukan peneliti, diketahui bahwa perusahaan studi kasus
memiliki karakteristik-karakteristik perusahaan startup. Hal
ini mengkonfirmasi bahwa tema penelitian ini berpeluang
untuk berkontribusi dalam topik penelitian perusahaan
startup. Deskripsi perusahaan studi kasus sesuai dengan
karakteristik perusahaan startup dalam berbagai penelitian.
Penelitian ini juga menambah kontribusi definisi dalam
karakterisasi perusahaan startup yang diharapkan akan
berguna bagi penelitian-penelitian tentang startup
selanjutnya.
Satu karakteristik yang tidak sesuai adalah perusahaan
startup dalam studi kasus ini disebutkan hanya fokus

12
membangun satu produk. Perusahaan dalam studi kasus
tidak hanya membangun satu produk namun fokusnya lebih
luas ke satu bidang, yaitu menyasar ke produk dan layanan
pendidikan tinggi. Perusahaan startup studi kasus ingin
membangun berbagai produk dan layanan yang inline
dengan fokus pendidikan tinggi, dan masing-masing produk
dan layanan diharapkan dapat saling terkait dan saling
mendukung dalam operasionalnya.
Kalau kita bilangnya bukan satu produk tapi
mungkin lebih ke satu bidang ya. Jadi ada benang
merahnya. jadi kalo kita misalnya bidangnya pendidikan
tinggi, misalnya perguruan tinggi dan sebagainya. Jadi
mungkin tidak satu produk. Tapi mungkin beberapa produk
tapi masih inline dan bisa saling mendukung. (Wcr.R1.18,
merespon pertanyaan karakteristik perusahaan startup:
membuat satu produk)
.. nggak selalu satu produk. Ada startup yang
misalkan startup di industri game misalnya. Dia bisa
menelurkan paling tidak dua game dalam setahun. Jadi dia
nggak cuma berkutat dalam satu produk. (Wcr.R2.16,
merespon pertanyaan karakteristik perusahaan startup:
membuat satu produk)
4.5.3 Praktik Pengembangan Perangkat Lunak Agile di
Perusahaan Startup Studi Kasus
Perusahaan startup studi kasus mengkonfirmasi tidak
adanya kumpulan praktik terstandar yang dipakai dalam
mengembangkan perangkat lunak. Namun setelah
dilakukan wawancara dengan menggunakan pedoman
daftar praktik agile, terdapat banyak praktik yang ternyata
dilakukan di perusahaan. Hal ini mengkonfirmasi temuan
Paternoster, dkk [2] bahwa perusahaan startup mengambil
praktik-praktik agile secara oportunistik, disesuaikan
dengan kebutuhan dan kemampuan untuk menerapkannya.
Dalam perusahaan startup studi kasus, praktik
pengembangan perangkat lunak yang dipilih adalah praktikpraktik agile. Praktik-praktik itu tidak diterapkan secara
kaku, namun pelaksanaannya membutuhkan disiplin diri
dan disiplin tim, sambil terus berusaha mematuhi prinsipprinsip agile. Praktik-praktik tersebut tidak diterapkan
semuanya secara sekaligus, namun dipilih-pilih lagi
berdasarkan situasi dan kondisi startup sepanjang siklus
hidupnya.
Dalam hal kolaborasi, perusahaan startup studi kasus
mempraktikkan saling bertanya dan saling belajar antara
satu sama lain, berkolaborasi dengan anggota tim, menjaga
pekerjaan agar tetap sederhana, membagi tanggung jawab,
dan mendorong budaya bekerja bersama sebagai tim
daripada sendiri-sendiri.
Dalam hal kemunculan kebutuhan (emerging requirement), perusahaan startup studi kasus membolehkan
munculnya kebutuhan-kebutuhan, dan memungkinkannya
untuk berevolusi ketika proyek sedang berlangsung. Hal ini
diperkuat dengan pernyataan penjelas responden
pertamadan kedua berikut.
Jadi requirement, misalkan kita sudah state bahwa kalo
ada penambahan pada tahap development itu
memungkinkan sebenarnya. Dan biasanya seperti itu, ada
penambahan yang harus dilakukan. jadi ya mungkin itu

agak sedikit salah ya, tapi mau nggak mau harus dilakukan
karena ya itu kan dinamis.. terlalu dinamis malah startup.
(Wcr.R1.27, saat menjelaskan pertanyaan penerapan
evolutionary requirement)
Nah habis wireframing ini, kita kasih ke desainer, jadi yang
menginterpretasikan wireframe yang kita buat itu desainer. Tentu
desainer juga terus kita kasih feedback sampe ketemu bentuk
prototype-nya. Baru setelah prototype itu jadi baru kita bikin
fungsi-fungsi aplikasinya.. backend.. dan segala macem dari
prototype itu.

Setelah prototype itu baru aplikasi itu jadi. 'Jadi' itu pun
belum tentu semua fturnya akan kepake, bisa ditambah bisa
dikurangi, tergantung nanti kondisi ke depan. Kita ada
wawancara dengan calon user. Kita konsultasi dengan
beberapa mentor, dsb.. ya intinya, akan terus berubah. Asal
ide besarnya untuk aplikasinya masih tetep sama.
(Wcr.R2.22, saat menjelaskan tahap-tahap pengembangan
secara garis besar)
Evolutionary requirement.. bener [ini dilakukan], jadi
requirement akan terus berubah selama project
berlangsung. (Wcr.R2.24, merespon pertanyaan tentang
evolutionary requirement)
Dalam manajemen kode dan pengujian, perusahaan
startup studi kasus menjalankan user acceptance test,
mengumpulkan test metrics, mengelola konfigurasi
perangkat lunak (version control), mengelola source code,
merencanakan perilisan, dan perencanaan saat sebelum dan
selama proyek berlangsung. Kode adalah aset intelektual
yang perlu dikelola sedemikian sehingga dapat digunakan,
dikembangkan, dan di-deliver kepada pengguna. Praktik
agile bukan praktik yang tidak mengindahkan manajemen
seperti yang mungkin dipikirkan oleh sebagian orang.
Justru manajemen kode dilakukan terintegrasi dalam proses
pengembangan, dan mengumpulkannya bersama aktivitas
pengujian. Pengujian yang dilakukan berfokus kepada
pengguna, maka pengujian dilakukan utamanya melalui uji
penerimaan kepada pengguna. Pengujian tidak dilakukan
khusus oleh tester atau hanya bisa melalui prosedur
penjaminan kualitas (quality assurance) formal yang bisa
memakan lebih banyak waktu.
Untuk manajemen kode, perusahaan startup studi
kasus menggunakan berbagai alat yang tersedia di internet
bagi para pengembang modern, seperti Git version control,
platform repositori source code Github dan Bitbucket.
Jadi untuk tools, kita bagi jadi dua aja ya; jadi ada
tools untuk software development, sama tools untuk
management software development. ... Kalau untuk
software development sendiri, tools and technology-nya
hampir semua sih open source. ... terus untuk version
control kita pake Git, open source juga. Kalau untuk
repository-nya kita pakai BitBucket. Trus untuk tools
pengembangannya kita pakai IDE/text editor Sublime
[Sublime Text]. Ya kebanyakan open source, dan ya
kalaupun nggak open source kita masih cari yang free,
kecuali terpaksa ... ya kita bayar. (Wcr.R2.32, menjawab
tentang Tools and Technologies yang dipakai oleh
perusahaan startup)

13
(kalau untuk development-nya? apakah pake tools
tertentu?) pake-nya github ya.. (Wcr.R1.66, menjawab
tentang Tools and Technologies yang dipakai oleh
perusahaan startup)
Perusahaan startup sangat mempedulikan produk yang
sedang mereka bangun, sebagai solusi berharga yang
mereka percayai dapat menyelesaikan masalah orang-orang.
Karena itu, mereka juga memperhatikan sarana pendukung
agar produk tersebut memenuhi standar, dapat memenuhi
kebutuhan skalabilitas dan berusaha men-deliver-nya
sesegera mungkin kepada pasar. Demikian juga, karena halhal tersebut perusahaan startup studi kasus menggunakan
standar kode, memperhatikan tentang arsitektur database,
dan men-definisikan cakupan menurut jadwal (tidak
berdasarkan anggaran). Standar kode yang digunakan oleh
perusahaan startup studi kasus mengikuti standar kerangka
kerja (framework) PHP Laravel. Teknologi database yang
dipilih adalah MySQL yang memiliki dukungan komunitas
open source yang kuat, sesuai dengan kemampuan sumber
daya perusahaan startup dan kebutuhan membangun produk
di atasnya dan mencukupi kemungkinan untuk menmpung
skalabilitas. Arsitektur database dipilih yang berbasis
teknologi cloud computing untuk menghemat biaya dan
memitigasikan risiko kegagalan skalabilitas kepada
penyedia layanan database server dan application server.
Perusahaan startup juga mendefinisikan cakupan (scope)
berdasarkan jadwal, karena waktu adalah sumber daya yang
sangat terbatas, yaitu mereka harus menghasilkan sesuatu
sebelum sumber daya finansial untuk operasional habis
digunakan [18].
Coding standards.. iya, soalnya kita pake framework,
kecuali kalau kita bikin sendiri kan nggak standard. (Pakai
framework apa itu kalau boleh saya tahu..) Pake Laravel..
PHP Laravel, ini udah ada coding standardnya sendiri, kita
bangun aplikasi di atasnya sudah pasti ngikuti coding
standard. (Wcr.R2.28, menjawab pertanyaan tentang
coding standards)
Khusus untuk pengujian, dalam perusahaan startup
studi kasus dipraktikkan unit test walaupun belum
terotomasi, dan mem-praktikkan TDD atau Test-Driven
Development. (lihat jawaban wawancara Wcr.R1.46 dan
Wcr.R2.30)
Bekerja pada peruusahaan startup menuntut anggota
tim di dalamnya untuk serba mandiri, tidak pasif menunggu
perintah atau
keputusan,
namun proaktif
dan
mengorganisasi sendiri secara berkelanjutan (sustainable
self-organization). Praktik-praktik yang termasuk cluster ini
adalah:
- Berusaha mengorganiasi-sendiri (mandiri, selforganizing)
- Menggunakan kepemilikan kode secara kolektif
- Melakukan integrasi kode secara terus menerus
(continuous code integration)

- Menjaga ritme kerja berkelanjutan (lembur

dilakukan secara minimal)
- Merespon pada tekanan dengan mengubah
prioritas atau cakupan daripada bekerja lembur atau
menambah orang
- Memberikan umpan balik secara terus menerus
- Mengimplementasikan
infrastruktur
pengembangan yang mendukung kelincahan (agility)
- Mengembangkan kemampuan agility orang-orang
- Memiliki pengguna yang berpartisipasi secara
aktif selama proyek
- Mengembangkan produk yang merespon
kebutuhan bisnis
Indikator praktik ini dilakukan pada perusahaan startup
studi kasus dikonfirmasi dalam wawancara seperti kutipan
berikut
Self-organizing.. iya, jadi harusnya setiap anggota
startup ini cerdas. maksudnya dia bisa tau mana yang perlu
dilakukan mana yang nggak. Dan karena di startup ini
nggak ada birokrasi, maka mereka melakukan yang bener,
ini untuk mereka. (Wcr.R2.24, menjawab tentang poin
self-organizing)
.. Doing continuous integration.. iya, jadi kita pake
istilahnya [alat/tool-nya] 'Travis'... Collective code
ownership.. iya, ini hasil dari pair programming, jadi setiap
orang itu punya pengetahuan yang sama terhadap kode,
kalau di startup seharusnya memang gitu, jadi seorang
programmer harus bia baca, bisa ngerti coding-an
programmer lain, nggak ada 'blindspot', (Wcr.R2.30,
merespon tentang continuous code integration dan
colective code ownnership)
Perusahaan startup studi kasus mengutamakan
keseder-hanaan. Dokumentasi tidak dibuat jika tidak benarbenar dibutuhkan. Pengumpulan kebutuhan bisa melalui
komunikasi lisan secara sederhana saja. Selain itu perangkat
lunak didesain juga dengan sederhana, yaitu asal kebutuhan
terpenuhi, tidak harus dengan tampilan yang mewah atau
teknologi terkini.
Dalam mendefinisikan kebutuhan, perusahaan startup
studi kasus juga melakukannya dengan sederhana
(lightweight), yaitu dipecah hingga ukuran fitur kecil seperti
fungsi kode. Namun perusahaan startup studi kasus tidak
menggunakan metafora untuk memperjelas kebutuhan.
Lightweight requirement.. iya, jadi setiap requirement
dipecah kecil-kecil, nggak terlalu besar, (Wcr.R2.28,
merespon tentang lightweight requirement)
Kesederhanaan juga tampak pada perusahaan startup
studi kasus pada pertemuan/meeting yang dilakukan.
Meeting tidak perlu dilakukan setiap hari, walaupun
beberapa praktisi agile menyebutkan itu diperlukan.
Meeting harian diperlukan jika startup dalam fase awal idea
conception dalam aktivitas brainstorming, wireframing, dan

14
prototyping, namun jika sudah berumur dua-tiga tahun
seperti perusahaan startup studi kasus, meeting bisa
dilakukan secara mingguan, atau bahkan bulanan karena
yang menjadi target adalah pertumbuhan skalabilitas,
beralih dari fokus awal pada pembangunan produk. Dan
juga, pekerjaan yang tidak membutuhkan saling bertemu
bisa dilakukan dari jarak jauh (remote).
Untuk di Beenary Lab, kita cenderung ke Scrum
sebenarnya. Jadi Scrum itu ciri khas utamanya ada ...
standup meeting. Jadi standup meeting itu kita sebelum
kerja kita meeting singkat.. ya nggak harus standup.. jadi
yang pasti kita tentukan apa aja target hari ini.
(Wcr.R2.23)
Manajemen proyek dalam perusahaan startup studi
kasus dilakukan sekedarnya, tanpa dokumentasi dan tanpa
menerapkan planning game seperti dalam eXtreme
Programming (XP). Yang dilakukan adalah membuat
estimasi proyek secara agile.
Nah, documentation itu kita nggak ada.. sama sekali
nggak ada ... Making agile project estimation.. iya, tapi
mungkin nggak sesuai formatnya.. aku nggak tahu
formatnya [yang terstandar]. kayak yang pernah kita buat
itu.. termasuk cost nggak sih? Yang pertama timeline, rilis
per fitur, user acquisition.. nggak tau itu termasuk agile
(agile
project
estimation) nggak..
(Wcr.R1.33,
karakteristik estimasi yang tidak fixed, bisa berubah-ubah
seiring dengan perkembangan proyek menunjukkan bahwa
estimasi secara agile sedang dilakukan)
Pengembangan perangkat lunak pada perusahaan
startup studi kasus dilakukan secara iteratif, juga dalam hal
pemantauan proyeknya.
Delivering software continuously.. iya. (jadi kalo ada
fitur baru.. langsung di-push, gitu) iya, jadi langsung di-test
ke user. (Wcr.R1.30, merespon tentang praktik delivering
software conti-nuously)
Tracking dan reporting ini kita pake Basecamp
sebenernya, sama Time Doctor. (Wcr.R1.37, merespon
poin Tracking and reporting iteration progress)
Sayangnya, praktik pengintegrasian aktivitas manajemen secara langsung ke dalam development tasks masih
belum dilakukan. Ke depannya hal ini direncanakan oleh
CEO untuk dicoba terapkan pada perusahaan startup studi
kasus.
management activities.. iya harusnya. (untuk
pertanyaan ini sebenarnya untuk keadaan as-is.. bukan
'seharusnya'.. jadi as-is aja, bukan akan rencananya
dilakukan) iya, ini dilakukan. (harusnya akan dilakukan,
jadi to-be ya?) iya, harusnya.. akan dilakukan.
(Wcr.R1.38, merespon poin project monitoring:
Integrating management activities directly into
development tasks)

Dalam pengelolaan kebutuhan, perusahaan startup

studiu kasus menggunakan product backlog untuk
mendefinisikan kebutuhan, dan sekali-sekali (seringnya
tidak) menggunakan bantuan cerita. Setiap kebutuhan
dikelola dalam bentuk paket-paket pekerjaan yang terbatas
pada timebox, misalnya mingguan atau harian, yaitu
semacam penghitungan estimasi waktu orang-hari yang
dibutuhkan dalam proyek konvensional. Namun untuk
mengantisipasi terjadinya masalah terkait kesalahan
kebutuhan di masa depan masih belum dilakukan oleh
perusahaan startup studi kasus.
Selain itu, kebutuhan dikelola bersama dalam tim secara
multidisipliner, agar berbagai perspektif bisa diselaraskan,
misalnya untuk pemngembangan produk kampus.co.id yang
membutuhkan perspektif edukasisecara akademis, training
dan sertifikasi dari profesional, sisi bisnis untuk keperluan
monetisasi, sisi teknis dari pengembang, kebutuhan desain
produk untuk rancangan UI dan UX, dsb.
Mengenai penyebaran secara fisik, perusahaan startup
studi kasus pernah memiliki anggota tim yang bekerja dari
jarak jauh (secara remote), yaitu dari Bandung.
Jadi itu juga kenapa kita sukanya [hire]
freelance/outsource. Mungkin kita bisa hire yang dari
Bandung, Jakarta, dan itu sebenarnya juga menekan biaya
sebenarnya [bisa bekerja remote], tanpa harus terikat.. tanpa
harus (menyediakan) biaya operasional yang lebih tinggi
kalau misalnya harus ngantor dan lain sebagainya.
(Wcr.R1.04, menjelaskan jawaban pertanyaan mengenai
karakte-ristik keterbatasan sumber daya)
pernah [ada yang bekerja secara remote], iya, kalau
sekarang nggak kayaknya.. (Wcr.R2.26, meralat jawaban
pertanyaan Being geographically distributed)
4.5.3 Praktik Kerja di Perusahaan Startup Studi Kasus
Perusahaan startup studi kasus mengkonfirmasi
bahwa dalam kegiatannya menjalankan beberapa praktik
kerja startup yang ditemukan dalam literatur.
Pelaksanaannya tidak mengikuti proses tertentu secara
kaku, namun dilakukan secara adaptif dan dengan
penyesuaian-penyesuaian (tailored). Hal ini bisa diketahui
dari wawancara.
Jadi kita.. cara mengembangkannya sebenernya kayak
gini.. dari awal kita punya ide, trus kita tuangkan ide itu
dalam bentuk sebuah aplikasi. Nah untuk membuat aplikasi
itu awalnya kita.. istilahnya wireframing, bikin sketsa. Jadi
ide itu kita tuangkan dalam bentuk aplikasi, nah [wireframe
itu membantu menjelaskan] aplikasi itu seperti apa...
Hampir setiap hari brainstorming sama wireframing. Jadi
wireframing itu diikuti dengan brainstorming.
Wireframing itu bikin sketsa. Nah setelah sketsa itu jadi.. ini
sketsa sangat kasar, di aplikasi itu kira-kira ada fitur apa
saja.. terus bentuk setiap fitur itu kayak apa aja. Ini masih

15
kasar belum.. hampir pasti akan sangat berbeda ketika
aplikasi sudah jadi.
Nah habis wireframing ini, kita kasih ke desainer, jadi yang
menginterpretasikan wireframe yang kita buat itu desainer.
Tentu desainer juga terus kita kasih feedback sampe ketemu
bentuk prototype-nya. Baru setelah prototype itu jadi baru
kita bikin fungsi-fungsi aplikasinya.. backend.. dan segala
macem dari prototype itu.
Setelah prototype itu baru aplikasi itu jadi. 'Jadi' itu pun
belum tentu semua fturnya akan kepake, bisa ditambah bisa
dikurangi, tergantung nanti kondisi ke depan. Kita ada
wawancara dengan calon user. Kita konsultasi dengan
beberapa mentor, dsb.. ya intinya, akan terus berubah. Asal
ide besarnya untuk aplikasinya masih tetep sama.
(Wcr.R2.22,
merespon
permintaan
agar
pengembangan dijelaskan secaara garis besar)

3.

5.2 Saran
Ada beberapa hal yang dapat disarankan sebagai
penelitian lebih lanjut atau penerapan dalam praktik kerja
dan pengembangan perangkat lunak pada perusahaan
startup:
1.

proses

Ya kalau agile itu sebenarnya ada banyak kayak Scrum,

FDD.. itu sebenarnya cuma kerangka aja. Ya nanti akan
diadopsi, secara adaptif akan diimplementasikan di
masing-masing perusahaan. Jadi di setiap startup, di setiap
perusahaan, hampir pasti berbeda implementasinya.
Untuk di Beenary Lab, kita cenderung ke Scrum
sebenarnya. Jadi Scrum itu ciri khas utamanya ada product
backlog, sama yang paling penting itu standup meeting.
Jadi standup meeting itu kita sebelum kerja kita meeting
singkat.. ya nggak harus standup.. jadi yang pasti kita
tentukan apa aja target hari ini. kita lebih condong ke
Scrum. Walaupun tidak menutup kemungkinan kita sering
pair programming juga.. sering pakai metodologinya
TDD..

2.

3.

4.

(Wcr.R2.23, merespon pertanyaan apakah ada praktik agile

tertentu yang mengikuti kerangka kerja, seperti Scrum,
FDD, atau lainnya)
5. PENUTUP
Berikut akan disampaikan secara singkat hal-hal yang
dapat disimpulkan dari pembahasan. Selain itu juga
dikumpulkan berbagai saran untuk para pembaca dari
kalangan praktisi atau akademisi.

5.

5.1 Kesimpulan
Beberapa hal yang dapat disimpulkan dari penelitian
Tugas Akhir ini adalah :
1.

2.

Perusahaan startup memliki karakteristik

tertentu yag membedakannya dengan tipe
perusahaan lain, seperti UKM atau korporasi
besar.
Hal
ini
mengakibatkan
metode
pengembangan perangkat lunak yang diterapkan
di perusahaan startup juga sebaiknya mengikuti
karakteristik tersebut.
Perusahaan startup seharusnya memilih metode
pengembangan
perangkat
lunak
yang
disesuaikan dengan kebutuhan dan kemampuan
untuk menerapkannya. Beberapa praktik agile
bisa
dipilih
sebagai
panduan
dalam
pengembangan produk perangkat lunak.

Praktik kerja dalam perusahaan startup

sebaiknya dijalankan secara adaptif dan
mengutamakan kesederhanaan dalam praktik,
juga menjadikan prinsip-prinsip agile sebagai
panduan.

6.

7.

Perlu diadakan penelitian lebih lanjut untuk

meningkatkan cakupan generalisasi penelitian
ini. Penelitian ini hanya melibatkan saru
perusahaan sebagai studi kasus. Selanjutnya
lebih baik dipilih studi multi-kasus atau dengan
penelitian kuantitatif yang mengumpulkan
perusahaan-perusahaan
startup
sebagai
responden.
Kesuksesan pengembangan perangkat lunak
dalam startup perlu diukur pada kasus-kasus
startup yang berhasil hingga menemukan model
bisnis yang repeatable dan scalable.
Penelitian ini memiliki kekurangan dalam hal
data observasi yang sudah agak lama, berasal
dari pengalaman penulis sekitar satu tahunan
yang lalu. Untuk penelitian selanjutnya
sebaiknya menggunakan data observasi yang
lebih baru.
Kekurangan lain dalam penelitian Tugas Akhir
ini adalah pada proses pengumpulan data yang
masih sederhana. Hal ini dikarenakan batasan
sumber daya waktu penelitian yang tersedia
untuk penulis, juga keterbatasan penulis sendiri
sebagai peneliti yang masih pemula, apalagi
dalam jenis penelitian kualitatif yang jarang
dilakukan di lingkungan akademik institut
teknik. Idealnya, wawancara dalam penelitian
kualitatif dilakukan berulang-ulang hingga
inkuiri mencapai titik jenuh, yaitu terjawabnya
pertanyaan penelitian disertai habis-nya
temuan informasi baru dari jawaban pertanyaan
wawancara.
Analisis data kualitatif yang dilakukan masih
kurang. Jika ada penelitian lanjutan dari Tugas
Akhir ini, sebaiknya ada analisis susunan
kronologis praktik pengembangan perangkat
lunak dalam sebuah perusahaan startup. Untuk
objek
penelitiannya
bisa
mengobservasi
pengembangan perangkat lunak di beberapa
inkubator bisnis startup. Beberapa inkubator
bisnis ada yang menyelenggarakan program
mentoring startup tiga bulanan atau enam
bulanan.
Berdasarkan saran yang didapat dari wawancara
kepada responden kedua, ditemukan bahwa
dalam daftar praktik agile dalam Tabel 2.2 ada
beberapa poin yang duplikat. Hal ini seharusnya
dieliminasi sebelum dijadikan pertanyaan
wawancara.
Berdasarkan saran yang didapat dari wawancara
kepada responden pertama, ditemukan bahwa
pertanyaan-pertanyaan yang diajukan masih
terlalu general Sebaiknya untuk penelitian

16

8.

9.

selanjutnya pertanyaan dibuat lebih teknis lagi.

Mungkin dari dartar praktik agile yang sama,
namun dengan deskripsi yang lebih banyak
menyertakan contoh-contoh ketimbang istilahistilah.
Dalam meakukan wawancara sebaiknya jangan
menempatkan pertanyaan yang membutuhkan
jawaban panjang lebar pada akhir sesi, karena
bisa saja pewawancara dan responden sudah
kelelahan
untuk
menjawab
pertanyaanpertanyaan sebe-lumnya.
Dalam penerapan praktik pengembangan
perangkat lunak, perusahaan-perusahaan startup
maupun selainnya sebaiknya mencoba metode
pengembangan agile. Hal ini dilakukan untuk
meningkatkan tingkat kesuksesan pengembangan perangkat lunak.

DAFTAR PUSTAKA
[1]

S. Blank and B. Dorf, The Startup Owner's

Manual, Pescadero, California: K&S Ranch
Press, 2012.

[2]

N. Paternoster, C. Giardino, M. Unterkalmsteiner,

T. Gorschek and P. Abrahamsson, "Software
development in startup companies: A systematic
mapping study," Information and Software
Technology, 2014.
http://www.sciencedirect.com/science/article/pii/
S0950584914000950,
http://dx.doi.org/10.1016/j.infsof.2014.04.014

[3]

C. Giardino, M. Unterkalmsteiner, T. Gorschek

and P. Abrahamsson, "What Do We Know about
Software Development in Startups?," IEEE
Software, vol. 31, no. 5, pp. 28-32, Sept-Oct
2014. http://ieeexplore.ieee.org/stamp/stamp.jsp?
tp=&arnumber=6898758&isnumber=6898682,
http://dx.doi.org/10.1109/MS.2014.129

[4]

Oxford University Press, [Online]. Available:

http://www.oxforddictionaries.com/definition/eng
lish/start-up?q=startup. [Accessed December
2014].

[5]

S. Sutton, "The role of process in software startup," IEEE Software, vol. 17, no. 4, p. 3339,
2000. http://ieeexplore.ieee.org/stamp/stamp.jsp?
tp=&arnumber=854066&isnumber=18557,
http://dx.doi.org/10.1109/52.854066

[6]

F. K. Y. Chan and J. Y. L. Thong, "Acceptance of

agile methodologies: A critical review and
conceptual framework," Decision Support
Systems, vol. 14, no. 4, pp. 803-8014, 2009.
www.sciencedirect.com/science/article/pii/S0167
923608002133,

http://dx.doi.org/10.1016/j.dss.2008.11.009
[7]

Badan Pengembangan dan Pembinaan Bahasa

Kemdikbud, "Kamus Besar Bahasa Indonesia
dalam jaringan," 2008. [Online]. Available:
http://badanbahasa.kemdikbud.go.id/kbbi/index.p
hp. [Accessed December 2014].

[8]

T. Dyba and T. Dingsyr, "Empirical studies of

agile software development: A systematic
review," Information and Software Technology,
vol. 50, no. 9-10, pp. 833-859, 2008.
www.sciencedirect.com/science/article/pii/S0950
584908000256,
http://dx.doi.org/10.1016/j.infsof.2008.01.006

[9]

C. Fulgham, J. Johnson, M. Crandall and L.

Jackson, "The FBI Gets Agile," IT Professional,
pp. 57-59, Septembe-October 2011.
http://ieeexplore.ieee.org/stamp/stamp.jsp?
tp=&arnumber=6028561&isnumber=6028548,
http://dx.doi.org/10.1109/MITP.2011.88

[10]

R. M. Fontana, I. M. Fontana, P. A. d. R.
Garbuio, S. Reinehr and A. Malucelli, "Processes
versus people: How should agile software
development maturity be defined?," The Journal
of Systems and Software, no. 97, pp. 140-155,
2014.
http://www.sciencedirect.com/science/article/pii/
S0164121214001587,
http://dx.doi.org/10.1016/j.jss.2014.07.030

[11]

G. Coleman and R. V. O'Connor, "An

Investigation into Software Development Process
Formation in Software Start-ups," Journal of
Systems and Software, vol. 81, no. 5, pp. 772784, 2008.
http://doras.dcu.ie/18659/1/ColemanandOConnor.
pdf

[12]

Z. Alzoaobi, "Agile Software: Body of

Knowledge," in Business Intelligence and Agile
Methodologies for Knowledge-Based
Organizations: Cross-Disciplinary Applications,
A. A. Rahman and M. Alnoukari, Eds., Hershey,
Pennsylvania: Business Science Reference, 2012,
pp. 14-34. http://dx.doi.org/10.4018/978-161350-050-7.ch002

[13]

E. Mnkandla and B. Dwolatzky, "Balancing the

human and the engineering factors in software
development," in AFRICON, 2004. 7th
AFRICON Conference in Africa, Gaborone,
Bostwana, 2004.
http://ieeexplore.ieee.org/stamp/stamp.jsp?
tp=&arnumber=1406881&isnumber=30508,

17
http://dx.doi.org/10.1109/AFRICON.2004.14068
81
[14]

K. Beck, Extreme programming explained:

Enbrace Change, Boston: Addison-Wesley, 2000.

[15]

S. Ambler, "Quality in an agile world," Software

Quality Professional, vol. 7, no. 4, pp. 34-40,
2005.
http://www.oamk.fi/~palo/English_2/AgileQualit
y.pdf

[16]

[17]

[18]

[19]

Huo, et al., "Software quality and agile methods,"

in MA Computer Software and Applications
Conference (COMPSAC) Proceedings of the 28th
Annual International, 2004.
http://ieeexplore.ieee.org/stamp/stamp.jsp?
tp=&arnumber=1342889&isnumber=29570
P. Abrahamsson, K. Conboy and X. Wang, "'Lots
done, more to do': the current state of agile
systems development research," European
Journal of Information Systems, pp. 281-284,
2009. http://ulir.ul.ie/handle/10344/2293
N. Salleh, E. Al-Kautsar, R. Hoda and A. l.
Asmawi, "A Window into the Emergence of Agile
Software Development Landscape in Indonesia,"
SCRG Publication, 2014.
home.ijasca.com/data/documents/PiD_648_IJAS
CA_salleh_2014.pdf
S. A. Asri and F. Baskoro, "An Analysis of Agile
Methods: XP, Scrum and Crystal Methods,"
International Conference Information &

Communication Technology and System, pp. 529534, 2008.

http://icts.if.its.ac.id/openaccess/2008/files/icts_2
008_088.pdf
[20]

S. Blank, "Why the Lean Start-Up Changes

Everything," Harvard Business Review, May
2013. https://hbr.org/2013/05/why-the-lean-startup-changes-everything

[21]

E. Ries, The Lean Startup, New York: Crown

Business, 2011.

[22]

A. Yahya, Creativity to Commerce, Jakarta:

Gramedia Pustaka Utama, 2014.

[23]

J. Cresswell, Reseach Design : Qualitative and

Quantitative Approach (Third Edition), London:
Sage Publication, 2009.

[24]

Sugiyono, Metode Penelitian Kuantitatif,

Kualitatif, Bandung: Alfabeta, 2008.

[25]

S. Faisal, Penelitian Kualitatif: Dasar-Dasar dan

Aplikasi, Malang: YA3, 1990.

[26]

R. Yin, Case Study Research, Design and

Methods, 3rd Edition ed., Beverly Hills, CA:
Sage Publication, 2003.

[27]

K. Eisenhardt, "Building Theory from case study

research," Academic Management, pp. 532-550,
1989. http://www.jstor.org/stable/258557