PENDAHULUAN
Design thinking, lean startup dan agile development adalah kumpulan metodologi dan teknik yang bisa digunakan kapan saja. Ketiganya memiliki value masing-masing dan saling melengkapi dalam tujuan menciptakan inovasi. sign thinking, lean startup dan agile development
Tiga Mindset yang digunakan dalam penciptaan inovasi tersebut. dapat divisualisasikan seperti Gambar 1.
Sesuai Gambar 1, Jonny Schneider menjelaskan bahwa:
- Design Thinking adalah tentang bagaimana kita melakukan eksplorasi dan menyelesaikan masalah.
- Lean Startup adalah framework yang digunakan untuk menguji apa yang kita percaya dan mempelajari langkah kita untuk hasil yang benar.
- Agile Development adalah tentang bagaimana kita beradaptasi dengan kondisi yang berubah dalam software.
Design Thinking
Design Thinking adalah sebuah mindset, yang dapat digunakan untuk mengeksplorasi masalah kompleks atau menemukan peluang-peluang dalam dunia yang penuh dengan ketidakpastian. Dalam pencarian makna tersebut, biasanya berfokus pada kebutuhan dan experience manusia. Design Thinking menggunakan logika dan intuisi dalam mengeksplorasi dan mempertanyakan apa dan kemudian membayangkan apa yang dapat menjadi solusi masa depan yang inovatif dan berdaya cipta.
Design Thinking: membawa ide dan tool dari dunia arsitektur dan desain produk dengan fokus yang kuat pada human-centered design (desain yang berpusat pada manusia). Hal ini membawa perspektif customer ke jantung proses inovasi.
Lean Startup
Mindset Lean adalah sebuah filosofi manajemen yang merangkul pemikiran ilmiah untuk mengeksplorasi seberapa benar yang kita percaya dan asumsikan selama memperbaiki sistem. Praktisi Lean menggunakan praktik yang disengaja untuk menguji hipotesis mereka melalui tindakan, mengamati apa yang sebenarnya terjadi, dan membuat penyesuaian berdasarkan pada perbedaan yang diamati. Dengan cara itulah organisasi menentukan jalannya, learning by doing, dan memutuskan apa yang harus dilakukan selanjutnya dalam perjalanan untuk mencapai hasil.
Lean Startup: menyediakan mesin iterasi, membangun hipotesis untuk inovasi melalui beberapa siklus.
Pada Lean Startup, kita mengenal Minimum Viable Product.
Pada gambar di bawah ini ditunjukkan perbandingan konsep MVP yang salah dan benar.
Minimum Viable Product diilustrasikan seperti gambar di bawah ini.
Minimum Viable Product (MVP) bukan obyek yang dibangun dengan memenuhi bagian fungsional. MVP dibangun dengan memenuhi syarat sudah berjalan secar functional, reliable, usable dan good design untuk satu fitur utama yang dipilih untuk dikembangkan awal dan divalidasi.
Agile Development
Inti dari Agile Development adalah membangun solusi software yang hebat yang beradaptasi dengan baik untuk mengubah kebutuhan. Agile dimulai dengan masalah (meski bukan sebuah keharusan) dan memberikan solusi yang elegan. Mindset Agile mengakui bahwa solusi yang tepat hari ini mungkin bukan solusi yang tepat untuk besok. Rapid, iteratif, mudah diadaptasi, dan fokus pada kualitas melalui peningkatan berkelanjutan.
Agile: kunci dalam siklus Lean Startup dan membangun solusi didukung teknologi. Dalam siklus berikutnya, dan sebagai skala inovasi, ia bekerja dengan pendekatan lain, seperti DevOps, untuk mengambil solusi ke dalam sistem inti.
Design Thinking, Lean Startup dan Agile dapat dikombinasikan dalam satu alur proses pengembangan solusi, seperti pada Gambar 2.
Design Thinking bertitik berat pada menemukan masalah yang benar, lalu memberikan pilihan-pilihan solusi. Selanjutnya berbagai solusi dipelajari dan divalidasi dengan konsep Build-Learn-Measure dengan membuat Minimum Viable Product (MVP) pada konsep Learn Startup. Setelah divalidasi di customer awal, maka pendekatan Agile Development digunakan untuk membangun produk dengan cara yang benar.
Pada Gambar 3 ditunjukkan bagaimana tiga mindset ini saling tumpang tindih.
Yang terpenting dari semuanya, mindset dan praktek kerja ini adalah tentang bekerja bersama dan mencapai hasil bersama. Belajar adalah kerja tim, dan kolaborasi adalah kunci jika kita akan menemukan jalan kita ke tempat yang kita inginkan. Tidak ada satu cara yang benar, juga tidak ada satu mindset tunggal. Namun secara keseluruhan, elemen dari setiap mindset membantu kita menemukan jalan ke depan.
Inisiatif inovasi dapat berkisar dari menjelajahi ruang masalah yang abstrak, hingga bereksperimen dengan sejumlah solusi, sebelum terus meningkatkan solusi yang sangat konkret dalam ruang pasar tertentu.
AGILE DEVELOPMENT
Agile Software Development adalah kemampuan untuk menciptakan dan merespon perubahan dalam mencapai keberhasilan dalam lingkungan yang bergolak dan tidak pasti. Agile Software Development adalah istilah umbrella untuk serangkaian metode dan praktik berdasarkan nilai-nilai dan prinsip-prinsip yang dinyatakan dalam Agile Manifesto, seperti pada Gambar 4. Solusi berkembang melalui kolaborasi antara tim yang mengatur diri sendiri, lintas fungsi menggunakan praktik yang sesuai untuk konteks mereka.
Manifesto untuk Agile Software Development adalah:
Kami menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukan dan membantu sesama untuk menggunakannya. Melalui usaha ini kami telah dapat menghargai:
Individu dan interaksi lebih dari proses dan sarana perangkat lunak. Perangkat lunak yang bekerja lebih dari dokumentasi yang menyeluruh. Kolaborasi dengan klien lebih dari negosiasi kontrak. Tanggap terhadap perubahan lebih dari mengikuti rencana.
Demikian, walaupun kami menghargai hal di sisi kanan, kami lebih menghargai hal di sisi kiri.
Terdapat 12 Agile Principles dalam Agile Software Development, seperti Gambar 5.
12 Prinsip pada Agile Software Development adalah:
- Prioritas utama kami adalah memuaskan klien dengan menghasilkan perangkat lunak yang bernilai secara dini dan rutin.
- Menyambut perubahan kebutuhan, walaupun terlambat dalam pengembangan perangkat lunak. Proses Agile memanfaatkan perubahan untuk keuntungan kompetitif klien.
- Menghasilkan perangkat lunak yang bekerja secara rutin, dari jangka waktu beberapa minggu sampai beberapa bulan, dengan preferensi kepada jangka waktu yang lebih pendek.
- Rekan bisnis dan pengembang perangkat lunak harus bekerja-sama tiap hari sepanjang proyek.
- Kembangkan proyek di sekitar individual yang termotivasi. Berikan mereka lingkungan dan dukungan yang mereka butuhkan, dan percayai mereka untuk menyelesaikan pekerjaan dengan baik.
- Metode yang paling efisien dan efektif untuk menyampaikan informasi dari dan dalam tim pengembangan perangkat lunak adalah dengan komunikasi secara langsung.
- Perangkat lunak yang bekerja adalah ukuran utama kemajuan.
- Proses Agile menggalakkan pengembangan berkelanjutan. Sponsor-sponsor, pengembang-pengembang, dan pengguna-pengguna akan dapat mempertahankan kecepatan tetap secara berkelanjutan.
- Perhatian yang berkesinambungan terhadap keunggulan teknis dan rancangan yang baik meningkatkan Agility.
- Kesederhanaan–seni memaksimalkan jumlah pekerjaan yang belum dilakukan–adalah hal yang amat penting.
- Arsitektur, kebutuhan, dan rancangan perangkat lunak terbaik muncul dari tim yang yang dapat mengorganisir diri sendiri.
- Secara berkala, tim pengembang berefleksi tentang bagaimana untuk menjadi lebih efektif, kemudian menyesuaikan dan menyelaraskan kebiasaan bekerja mereka.
SCRUM
Teori Scrum
Scrum (kb): Sebuah kerangka kerja (framework) dimana orang-orang dapat mengatasi masalah kompleks adaptif, dimana pada saat bersamaan mereka juga menghantarkan produk dengan nilai setinggi mungkin secara produktif dan kreatif. Scrum bukanlah sebuah proses, teknik, ataupun metodologi.
Scrum bersifat:
- Ringan (lightweight)
- Sederhana untuk dipahami (Simple to uderstand)
- Sulit untuk dikuasai (difficult to master)
Scrum dibangun di atas teori proses kontrol empiris atau bisa disebut empirisme. Empirisme menyatakan bahwa pengetahuan datang dari pengalaman dan pengambilan keputusan didasari oleh apa yang telah diketahui hingga saat ini.
Scrum menggunakan pendekatan yang bertahap (iterative) dan berkelanjutan (incremental) untuk mengoptimalkan kemampuan prediksi dan mengendalikan risiko.
Tiga pilar yang memperkokoh setiap implementasi dari proses kontrol empiris adalah:
- transparansi,
- inspeksi dan
- adaptasi.
The House of Scrum Framework
Tiga Pilar Scrum
Tiga pilar Scrum adalah:
- Transparancy
- Inspection
- Adaptation
Transparancy
Aspek signifikan dari sebuah proses harus dapat dilihat oleh orang-orang yang bertanggung jawab terhadap dampaknya. Transparansi membutuhkan aspek-aspek tersebut ditentukan oleh standar baku sehingga para pengamat memiliki pemahaman yang sama terhadap apa yang sedang ditinjau. Sebagai contoh:
- Semua peserta harus memiliki pemahaman yang sama terkait istilah yang mengacu pada proses; dan,
- Mereka yang melakukan pekerjaan dan memeriksa Increment harus memiliki definisi “Selesai” (definition of “Done”) yang sama.
Inspection
Pengguna Scrum harus sering menginspeksi artefak Scrum dan perkembangan menuju Sprint Goal agar mereka dapat mendeteksi adanya variansi hasil yang tidak diharapkan. Proses inspeksi juga disarankan tidak dilakukan terlalu sering sampai menghambat pekerjaan. Inspeksi akan sangat bermanfaat jika dilakukan oleh pemeriksa yang kompeten di saat dimana pekerjaan tersebut sedang berada.
Adaptation
Jika pemeriksa menemukan bahwa ada satu hal atau lebih dari proses yang menyimpang di luar ambang batas yang bisa diterima yang dapat menyebabkan produk tidak bisa diterima, maka proses atau materi yang sedang diproses harus diubah. Pengubahan harus dilakukan secepatnya untuk meminimalkan penyimpangan yang semakin jauh.
Scrum memiliki empat event formal untuk melakukan inspeksi dan adaptasi, yakni:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Scrum’s Value
Scrum’s Value divisualisasikan seperti pada Gambar 7.
Saat tata nilai dari commitment, courage, focus, openness and respect diwujudkan dan hidup di dalam Scrum Team, maka pilar-pilar Scrum seperti: transparency, inspection, dan adaptation akan menjadi hidup dan membangun rasa percaya satu sama lain. Anggota Scrum Team belajar dan menjiwai tata nilai tersebut bersama dengan penggunaan Scrum roles, events, and artifacts pada saat mereka bekerja.
The Scrum Team
Scrum Team terdiri dari:
- Product Owner
- Development Team
- Scrum Master
Scrum Team bersifat swakelola dan lintas-fungsi. Tim yang swakelola memilih cara terbaik dalam mengerjakan pekerjaan mereka, bukan diperintah oleh orang lain di luar tim ini. Tim yang lintas-fungsi memiliki semua keahlian yang dibutuhkan untuk menyelesaikan pekerjaan mereka tanpa bergantung pada orang lain di luar tim ini.
Bentuk tim dalam Scrum dirancang untuk mengoptimalkan fleksibilitas, kreativitas dan produktivitas. Bentuk Scrum Team telah terbukti menjadikan tim semakin efektif dalam mengerjakan semua tipe pekerjaan yang telah disebutkan sebelumnya dan untuk jenis pekerjaan kompleks apa pun.
Product Owner
Product Owner adalah orang yang bertanggung jawab untuk memaksimalkan nilai bisnis dari produk yang dihasilkan oleh Development Team. Cara melakukannya sangat bervariasi antar organisasi, Scrum Team dan individu. Product Owner adalah satu-satunya orang yang bertanggung jawab dalam pengelolaan Product Backlog. Pengelolaan Product Backlog termasuk:
- Menyampaikan isi dari Product Backlog item secara jelas;
- Mengurutkan Product Backlog item untuk mencapai tujuan dan misi dengan cara terbaik;
- Mengoptimalkan nilai bisnis dari pekerjaan yang dilakukan oleh Development Team;
- Memastikan agar Product Backlog dapat dilihat, transparan, dan jelas untuk semua pihak, dan menampilkan apa yang akan dikerjakan selanjutnya oleh Scrum Team; dan,
- Memastikan Development Team memahami Product Backlog item hingga batas tertentu.
Product Owner dapat melakukan semua pekerjaan di atas atau meminta Development Team untuk mengerjakannya. Namun, hanya Product Owner yang bertanggung gugat terhadap Product Backlog. Product Owner hanya satu orang saja dan bukan berupa komite. Product Owner dapat mewakili
keinginan dari komite di dalam Product Backlog, tetapi pihak-pihak yang ingin mengubah prioritas dari Product Backlog item harus menyampaikannya lewat Product Owner.
Agar Product Owner dapat berhasil, seluruh organisasi harus menghargai keputusannya. Keputusannya dapat dilihat dari isi dan urutan Product Backlog. Tidak ada siapapun yang dapat memaksa Development Team untuk bekerja selain dari yang tercantum di dalam Product Backlog.
Development Team
Development Team terdiri dari para ahli profesi yang bekerja untuk menghantarkan Increment “Selesai” yang berpotensi untuk dirilis di setiap akhir Sprint. Increment “Selesai” wajib tersedia pada saat Sprint Review. Hanya anggota dari Development Team yang membuat Increment ini.
Development Team dibentuk dan diberikan wewenang oleh organisasi untuk menyusun dan mengelola pekerjaan mereka sendiri. Hasil sinergi dari tim ini akan mengoptimalkan efisiensi dan efektivitas Development Team secara keseluruhan. Development Team memiliki karakteristik sebagai berikut:
- Mereka swakelola. Tidak ada satu orang pun (bahkan Scrum Master) yang memberitahu Development Team bagaimana memanifestasikan Product Backlog menjadi gabungan fungsionalitas yang berpotensi untuk dirilis;
- Development Team bersifat lintas-fungsi, mereka memiliki semua keahlian yang diperlukan untuk membuat Increment;
- Scrum tidak mengenal jabatan untuk anggota Development Team, terlepas dari jenis pekerjaan yang mereka lakukan;
- Terlepas dari jenis pekerjaan yang perlu dilakukan, misal testing, arsitektur, operasional, ataupun analisa bisnis, Scrum tidak mengenal pengelompokan di dalam Development Team berdasarkan jenis-jenis pekerjaan ini; dan,
- Setiap anggota Development Team bisa saja memiliki keahlian khusus dan fokus di bidang tertentu, tetapi tanggung gugat adalah milik seluruh anggota Development Team.
Jumlah anggota Development Team yang optimal adalah tidak terlalu banyak agar tim ini tetap lincah, tetapi cukup banyak untuk dapat menyelesaikan pekerjaan secara signifikan di dalam satu Sprint.
- Kurang dari tiga orang akan mengurangi interaksi dan menyebabkan produktivitas yang rendah dan dapat menghadapkan tim pada kekurangan keahlian yang dibutuhkan di dalam Sprint, sehingga Development Team tidak dapat menghantarkan Increment yang berpotensi untuk dirilis.
- Lebih dari sembilan orang menyebabkan terlalu banyaknya koordinasi dan terlalu banyak kompleksitas sehingga proses empiris bisa menjadi tidak bermanfaat. Product Owner dan Scrum Master tidak termasuk dalam jumlah ini kecuali mereka juga turut mengerjakan pekerjaan dari Sprint Backlog.
Scrum Master
Scrum Master bertanggung jawab untuk mengenalkan dan menyokong penggunaan Scrum sebagaimana dijelaskan di dalam Panduan Scrum ini. Scrum Master melakukan ini dengan membantu orang-orang agar dapat memahami teori, praktik-praktik, aturan-aturan dan tata nilai
Scrum.
Scrum Master adalah pemimpin yang melayani Scrum Team. Scrum Master membantu orang-orang di luar Scrum Team untuk dapat memahami interaksi mana yang bermanfaat dan tidak bermanfaat.
Scrum Master membantu orang-orang untuk mengubah interaksi ini guna memaksimalkan nilai bisnis yang dihasilkan oleh Scrum Team.
Layanan Scrum Master kepada Product Owner
Scrum Master melayani Product Owner lewat beberapa cara, termasuk:
- Memastikan tujuan, ruang lingkup dan ranah produk dipahami sebaik mungkin oleh semua orang di dalam Scrum Team;
- Menemukan teknik yang paling efektif untuk mengelola Product Backlog;
- Membantu Scrum Team untuk memahami perlunya Product Backlog item yang jelas dan padat;
- Memahami perencanaan produk di dalam lingkungan empiris;
- Memastikan Product Owner paham bagaimana mengelola Product Backlog yang memaksimalkan nilai bisnis;
- Memahami dan mempraktikkan agility; dan,
- Memfasilitasi acara-acara Scrum bila diminta atau dibutuhkan.
Layanan Scrum Master kepada Development Team
Scrum Master melayani Development Team lewat beberapa cara, termasuk:
- Membimbing Development Team agar dapat swakelola dan lintas-fungsi;
- Membantu Development Team untuk menghasilkan produk bernilai bisnis tinggi;
- Menghilangkan hambatan yang memperlambat perkembangan pekerjaan Development Team;
- Memfasilitasi acara-acara Scrum bila diminta atau dibutuhkan; dan,
- Membimbing Development Team di organisasi dimana Scrum belum sepenuhnya dipraktikkan dan dipahami.
Layanan Scrum Master kepada Organisasi
Scrum Master melayani organisasi lewat beberapa cara, termasuk:
- Memimpin dan membimbing organisasi dalam penggunaan Scrum;
- Merencanakan implementasi Scrum di dalam organisasi;
- Membantu pegawai dan pemilik kepentingan untuk memahami dan menggunakan Scrum dan pengembangan produk secara empiris;
- Membuat perubahan yang dapat meningkatkan produktivitas Scrum Team; dan,
- Bekerja dengan Scrum Master lainnya untuk meningkatkan efektivitas dari penggunaan Scrum di dalam organisasi.
Scrum Events
Event wajib dalam Scrum diselenggarakan guna terciptanya kerutinan dan mengurangi pertemuan lain yang bukan merupakan bagian dari Scrum.
Setiap event memiliki batasan waktu, artinya setiap acara memiliki durasi waktu maksimal.
Ketika Sprint dimulai, durasinya tetap yang artinya tidak bisa diperpendek maupun diperpanjang. Event selain Sprint dapat berakhir kapanpun juga ketika tujuan dari event tersebut telah tercapai, hal ini dilakukan guna memastikan waktu yang digunakan tidak berlebihan dan tidak ada waktu yang terbuang di sepanjang proses.
Selain Sprint itu sendiri, yang merupakan wadah untuk event-event lainnya, setiap event di dalam Scrum adalah sebuah kesempatan formal untuk menginspeksi dan mengadaptasi sesuatu. Event-event ini secara khusus dirancang untuk mewujudkan transparansi dan inspeksi yang bersifat kritis. Tidak diselenggarakannya acara-acara ini akan mengurangi transparansi dan menghilangkan kesempatan untuk melakukan inspeksi dan adaptasi.
Sprint
Jantung dari Scrum adalah Sprint, yaitu sebuah batasan waktu dengan durasi satu bulan atau kurang, dimana terdapat proses pembuatan Increment yang “Selesai”, dapat digunakan dan berpotensi untuk dirilis.
Sprint memiliki durasi yang konsisten sepanjang daur hidup pengembangan produk. Sprint yang baru langsung dimulai setelah Sprint sebelumnya selesai.
Sprint berisi dan terdiri dari:
- Sprint Planning
- Daily Scrum,
- Product Development
- Sprint Review
- Sprint Retrospective
Pada saat Sprint berjalan:
- Tidak boleh ada perubahan yang dapat mengancam Sprint Goal;
- Tingkat kualitas tidak boleh menurun; dan,
- Ruang lingkup dapat diklarifikasi dan dinegosiasi ulang antara Product Owner dan Development Team setiap kali adanya hal baru yang mereka pelajari;
- Setiap Sprint bisa dianggap sebagai sebuah proyek dengan durasi tidak lebih dari satu bulan yang dijalankan untuk mencapai sebuah tujuan.
- Setiap Sprint memiliki tujuan mengenai apa yang harus dibangun, sebuah rancangan dan perencanaan fleksibel yang memandu pembangunan tersebut, daftar pekerjaan, dan hasil dari Increment.
Scrum Artifacts
Scrum Artifacts merepresentasikan pekerjaan atau nilai bisnis guna terciptanya transparansi dan kesempatan untuk menginspeksi dan mengadaptasi. Artefak-artefak yang dijabarkan Scrum dirancang sedemikian rupa untuk memaksimalkan transparansi informasi utama agar setiap orang memiliki pemahaman yang sama mengenai artefak tersebut.
Scrum Artifacts:
- Product backlog
- Sprint backlog
- Increment
Beberapa visualisasi Scrum dapat dilihat pada gambar-gambar di bawah ini.
REFERENSI
- Understanding Design Thinking, Lean, and Agile. Jonny Schneider.
- Scrum Guide. https://www.scrumguides.org/
- Agile Manifesto. http://agilemanifesto.org/iso/id/manifesto.html
- Agile Principles. http://agilemanifesto.org/principles.html
- Gartner. Enterprise Architecture and Technology Innovation Leadership Vision for 2017.
- Schneider, J. Understanding how Design Thinking, Lean and Agile Work Together
- Botjes, E. Three Steps to Successful Innovation
- Claes, G. When, which … Design Thinking, Lean, Design Sprint, Agile?
- Agile 101
- Interaction Design Foundation. Minimum Viable Product (MVP) and Design – Balancing Risk to Gain Reward.
- Feature Image: Photo by Olga Guryanova on Unsplash
Views: 4169
