SCRUM

Disadur dari : Rizki Adam Kurniawan


Joshua Partogi, 2015 Jeff Sutherland, 2017
Managemen Modern : Penerbit Bentang Pustaka,
SCRUM #1 Scrum: Meningkatkan
Produktivitas Dua Kali Lipat
dalam Waktu Setengahnya
Saja
Ken Schwaber and Jeff
Jeff Sutherland, 2014 Sutherland, 2017
Scrum- the art of doing The Definitive Guide to
twice the work in half Scrum: The Rules of the
the time Game
 https://agiledigest.com/
https://www.scrumguides.org/ http://www.agilecampus.org/
 • Banyak orang berfikir jika masalah
dalam proses software development
dapat dipecahkan dengan
meningkatkan kualitas teknologi.
• Permasalahan dalam software
development mungkin sebenarnya
Ada 3 alasan, mengapa software bisa adalah permasalah sosiologi bukan
memiliki kualitas rendah, memiliki dirty masalah teknologi.
code dan tidak memiliki automated test. • Permasalahan terbesar dalam
software development adalah
1. Software developer tidak mengetahui teknik dan interaksi manusia yang terlibat
praktik untuk mengembangkan sw berkualitas didalamnya.
tinggi
2. Software developer tidak diizinkan oleh
manajernya atau pelanggannya untuk
mengembangkan software berkualitas tinggi
karena mereka mengganggap hal tersebut
menyita waktu dan terlalu mahal untuk dilakukan
3. Software developer yang tahu mengembangkan
sw kualitas tinggi dan diiinkan oleh manager &
pelanggannya, namun tidak memiliki motivasi
untuk melakukannya.

– Tantangan lebih kompleks
1. Tuntutan pengguna lebih tinggi
2. Jumlah pengguna lebih banyak
3. Tingkat kelihaian hackder sistem jauh lebihcanggih
4. Jumlah tim lebih banyak
5. Tingkat kerumitan teknologi lebih tinggi
6. Jumlah baris kode bertamah setiap harinya
7. Tingkat pengalaman dan keahlian orang yang menggunakan
teknologi tersebut juga bervariasi
8. 1 Developer tidak uup mengetahui satu bahasa
pemrograman, dev diharapkan untuk dapat menguasai
polygot programming. belum lagi user experience yang
semakin tinggi dari beragam karakter pengguna.
Tips Menjadi Polyglot Programmer
1.Kuasai Konsep dasar Pemrograman
1. Variabel dan Tipe data
2. Operator
3. Control Flow
1. Percabangan
2. Perulangan
4. Prosedur dan Fungsi
5. Penjebakan Error (Try/Catch)
6. Class dan Objek (OOP)
7. Menggunakan Library
8. Mengakses Jaringan (API, Web service, Soket, dll)
2.Kuasai dulu satu bahasa pemrograman secara mendalam
3.Berpikir seperti seorang Polyglot Programmer
1. Tidak ada yang instan
2. Berpikir terbuka dan tidak fanatik
4.Banyak-banyak latihan dan praktik
5.Baca tutorial, langsung coba
6.Tulis blog agar tidak lupa yang dipelajari
7.Ajari orang lain
Ref :
https://www.youtube.com/watch?v=mgf2ofYx8OE
https://www.quora.com/What-is-polyglot-programming
https://news.ycombinator.com/item?id=4748029
https://www.petanikode.com/apa-itu-polyglot-programmer/
Software development berbeda dengan proyek konstruksi. Setuju? Kalau kalian cuma bisa memilih
dua dari tiga dari time, scope dan quality, mana yang akan kalian pilih?

1. Time & Scope terpenuhi (DDD) tetapi kualitas buruk.

2. Time & Quality terpenuhi tetapi ruang lingkup dikurangi.
3. Scope & Quality terpenuhi tetapi waktu penyelesaian molor.
 WATERALL • Metodologi managemen proyek prediktif seperti
CREATE SOMETHING
(OBVIOUS PROBLEM) WATERFALL sangat cocok untuk domain masalah obvious
serta jenis pekerjaan yang bersifat prediktif dan repetitif
karena hubungan antara sebab dan akibat nya sudah jelas
• Dalam domain masalah obvious, perencanaan mula-mula
Big design dari awal digambarkan lewat gantt chart dan work breakdown
TAKUT SALAH BUAT sampai akhir kayak
gedung structure. Hal ini sangat optimal jika tidak mengalami
perubahan selama proyek
• Jika perencanaan mulamula terlalu sering berubah, berarti
domain masalah anda sedang berada di domain
Solusi : project
TAKUT TIDAK manager, mandor – complicated atau bahkan complex
OPTIMAL planning as a plan as a
scope.
 2. Daftar keinginan product
owner untuk softwrae,
meliputi:
1. Teknologi yang digunakan, meliputi : • Ketidakjelasan
• Seberapa banyak jenis teknologi yang desirement yang
digunakan diminta karena belum
• Seberapa rumit & kompleks teknologi itu pernah dibuat
dipelajari oleh tim pengembang sebelumnya oleh tim
• Jumlah baris kode yang ada didalam sw dev
hari ini • Perubahan pasar begitu
• Persentase perkembangan baris kode cepat
setiap hari nya • Profil pengguna yang
• Kebersihan baris kode menggunakan software
• Seberapa sering teknologi tsb mengalami • Bagaimana dan dimana
diupdate oleh vendornuya pengguna akan
• Integrasi dengan sistem lain (platform & menggunakan software
teknologi yang berbeda) • Sistem birokrasi hierarki
• Dimana sistem akan dideploy: cloud atau perusahaan
on promise • Regulasi pemerintah
• Berapa banyak server yang digunakan • Kompetisi dan
• Lokasi dan jumlah pengguna yang akan kompetitor
mengakses sistem secara bersamaan. • Kerumitan proses bisnis
dalam perusahaan
3. Orang yang terlibat di
pengembangan software.
Meliputi :
• Tingkat keahlian dan
pengalaman
• Tingkat kedewasaan
• Jumlah anggota
• Jumlah stakeholder
• Tingkat kekuatan politik
dan gaya memimpin
masing-masing stakeholder
• Distribusi lokasi
• Hubungan dan kontrak
antara pelanggan dengan
vendor software dev
• Gaya berfikir dan
kepercayaan
• Sifat psikologis orang yang
terlibat

WATERALL AGILE using scrum
CREATE SOMETHING
(OBVIOUS PROBLEM) (COMPLEX PROBLEM)
Big design dari awal
TAKUT SALAH BUAT sampai akhir kayak
gedung
Solusi : project manager,
TAKUT TIDAK OPTIMAL mandor – planning as a
plan as a scope.
• Scrum menganggap memprediksi
masa depan adalah sebuah
kesiasiaan.
• Oleh karena itu scrum menggunakan
pengalaman masa lalu untuk
Small designs validation
memproyeksikan masa depan.
Iterative & prequent • Scrum didasari oleh metode empiris,
Prototype-mvp 3 hal yang menentukan keberhasilan
Design sprint
proses empiris :
1. Transaparansi (semua variabel yang
Self organize & perlu dikatehui dibuat transparan
transparansi. Pembangun
sw agar semua orang peduli)
2. Insepksi (Tinjau)
3. Adaptasi (iterasi adopsi)
• Tujuan akhir dari Agile Management
adalah “happiness”. Happy
customers dan Happy Employee.
• Scrum didasari oleh metode empiris
• Berbeda dengan metode prediktif
seperti metode waterfall yang
memastikan semua requirement
sudah jelas sebelum proyek dimulai,
dalam metode empiris kita tidak
berusaha mendetailkan semua
desirement karena masa depan tidak
dapat diprediksi
• Mendetailkan semua desirement
dalam lingkungan yang penuh
ketidakpastian menghabiskan banyak
waktu dan uang
1. Di konsep management project tradisional,
kita biasanya mengestimasi keseluruhan
project di awal sehingga seorang PM bisa
mengatakan bahwa, okay this is perfect &
just stick to the plan. But...

2. Ada fundamental problem disini ketika

mengestimasi project dengan cara seperti ini,
yaitu cognitive biases yang berdekatan dengan
irrartional thinking sehingga memunculkan bad
judgement.
3. Masalah ini terdiri dari 2 hal, yakni Planning
Fallacy & Sunk cost & status quo bias
4. Solusinya adalah dengan scrum
 Scrum sendiri dapat hidup didalam sebuah metodologi.
Scrum juga dapat digabungkan dengan teknik dan metode
pengembangan software dev lain. Oleh karena itu
membandingkan scrum dengan metodologi lain adalah
seperti membandingkan apel dengan jeruk.
• Tahukan kamu pekerjaan kamu bisa diselesaikan dengan setengah anggaran biaya
dalam waktu yang cepat? Scrum solusinya
• Scrum menggunakan metode perencanaan, pengerjaan, pengecekan dan tindak
lanjut.
• Kesalahan yang sering dilakukan banyak orang adalah pengecekan dan tindak lanjut
kerjaan dilakukan setelah kerjaan itu selesai.
• Hal ini menyebabkan adanya tekanan untuk jangan sampai salah.
• Dalam scrum, salah itu merupakan pembelajaran untuk memperbaikinya.
• Pengecekan dan tindak lanjut kerjaan dilakukan selama pengerjaan
• Ini mendorong adanya perbaikan sesegera mungkin ketika kesalahan sudah diketahui.
Plan do check act.
• Dengan begitu suatu kerjaan akan lebih cepat diperbaiki dan tidak perlu mengulang
pekerjaan dari awal.
http://www.scrumguides.org/scrum-guide.html
 PO = Product Owner
SM = Scrum Master
DT = Development Team
PM = Project Manager
• Rancangan -> Sotware, dalam project
management traditional, kita kenal PM.
• PM (BOSS) = ada di awal rancangan sampai
sw itu benar-benar selesai.
• Dimanakah letak peran Project Manager
dalam Scrum? Scrum tidak mengenal peran
Project Manager karena dalam Scrum peran
tersebut redundan. Dalam Scrum, peran dan
tanggung-jawab Project Manager dipegang
bersama oleh Scrum Master, Product Owner
dan Development Team.
• Jumlah team scrum terdiri dari 3-9 orang agar
bisa bekerja efektif
 PO = Product Owner
SM = Scrum Master
DT = Development Team
PM = Project Manager
• PO = tanggung jawabnya ada di zona rancangan, tidak
bertanggung jawab di zona pengembangan software
nya. PO memiliki hak veto terhadap rancangan
software seperti apa.
• DT = Bertanggung jawab terhadap pengembangan
software. DT membantu PO menerjemahkan
rancangannnya.
• SCRUM = bingkai kerja PO & DT
• SCRUM MASTER = Menegakkan bingkai kerja scrum
agar berjalan. Scrum master membantu DT
menyelesaikan masalah. SM tidak mesti pandai dari sisi
teknis, tapi dia bisa membuat DT bekerja lebih tangkas.
SM putus-putus = SM tidak bertanggung jawab atas
sebuah keluaran. Dia hanya bertnggung jawab pada
proses. PO & DT lah yang bertanggung jawab terhadap
sebuah keluaran software
Bertanggung jawab penuh atas keberhasilan rancangan sotware dimata user
1. Bertanggung jawab atas transparasi rancangan dia ke DT (untuk
keberhasilan komunikasi)
2. Seluruh pihak di organisasi (CEO, MANAGER, SEMUA CHIEP, DEVTEAM,
SCRUM MASTER) harus menerima keputusan akhir PO
3. Satu-satunya yang boleh mengarahkan waktu kerja DT. Kuncinya DT harus
fokus, karna sulit mengembangkan sw dalam waktu singkat.
1. Bisa mengatakan ‘TIDAK’
• Product owner adalah seorang mini CEO
• Keputusan po sering kali di-override oleh CEO atau CTO perusahaan
• PO adalah seorang yang di-empower oleh para petinggi perusahaan dan
dipercaya untuk dapat mengambil keputusan untuk meningkatkan nilai
produk yang dia kelola
2. Memiliki Visi terhadap produk
3. Keahlian kewirausahaan. Orang yang menjadi PO biasanya berasal dari orang
bisnis
4. Memegang atau punya akses terhadap dana pengembangan produk
5. Berpikiran terbuka
1. Terdiri dari para praktisi yang propesional
2. Karena berkewajiban menghasilkan updatean baru software yang siap dideploy ke user,
minimal setiap sprint (maks 1 bulan).
3. Bukan berarti di DT ini tidak boleh ada team yang baru belajar, tapi seluruh team harus
mampu BERKOMITMEN menyelesaikan seluruh rancangan yang ada di awal sprint.
4. DT harus lengkap memiliki semua keahlian hulu ke hilir sebagai satu tim. Mulai dari
rancangan bisnis sampai sotware yang siap guna ke user. (harus ada analys, programer,
designer, tester, dll). Mereka semua ini adalah developer(scrum meminta itu). Cross
function. Di 1 tim ada semua keahlian.
5. Punya hak penuh mengatur cara mereka DT bekerja. How to Build rancangan dari PO.
6. Berjumlah 3 sampai 9 orang
7. Push slow worker & and give congratulation the greatest worker
8. They are rockstar
1. Software developer bukanlah
Resource
• Resource memiliki arti tempat atau benda
yang bisa dimanfaatkan sewaktu-waktu
bila dibutuhkan.
• Software dev diperlakukan sebagai
‘resource’ yang membebani perusahaan
sehingga harus dimanfaatkan semaksimal
mungkin.
• Software dev justru perlu dikembangkan
potensinya agar dapat meningkatkan bisnis
value bagi perusahaan
• Software developer lebih tepat disebut
KNOWLEDGE WORKER karena
menggunakan otaknya & knowledgenya
sebagai asset dalam bekerja bukan otot.
2. Tiga Motivasi intrinsik rockstar developer
• Visi yang jelas
Visi yang jelas menciptakan self direction. Fokus pada visi.
Jangan lakukan multitasking dalam pekerjaan. Orang yang
terlalu sering multi tasking akan tidak bisa fokus, cepat lupa,
& susah berkonsentrasi, tidak ada rasa memiliki dalam
pekerjaan & produk, dan orang tidak bisa menjadlin
hubungan yang baik dengan banyak orang.
• Self Management
Karena pada dasarnya manusia adalah makhluk yang liar,
bebal, tidak bisa diatur & memiliki otoritas yang tinggi
terhadap dirinya sendiri. Oleh karena itu scrum master
perlu mencoaching tim ini agar dapat self managing.
• Aktualisasi diri (self actualization)
3. Hal yang salah kaprah terdapat software
developer
• Semua software developer itu sama
dan harus diukur
• Waktu software developer harus di
optimalkan hingga 100%
• Multitasking
• Respect my downtime
• Interupsi
• Able to work well underpressure
• Its overtime (lembur)
• Cari software developer yang
semurah mungkin
4. Prasyarat scrum development team
• Berfungsi antarlintas (cross functional) – rugby
team, jangan seperti management traditional
yang berjalan dengen melempar pekerjaan satu
sama lain.
• No superhero in tim, semuanya harus bekerja
bersama
• Mampu berkomunikasi dengan baik
• Proaktif dan tidak takut bertanya & meminta
bantuan
• Openmind & mau menerima pendapat orang
lain
• Mampu memberi saran dgn kalimat yang tidak
menghakimi
• Meaningfull conversation
• Shared goal
 DATABASE BUSINESS USER
SOLUTION TEST
ADMINISTRATOR ANALYST EXPERIENCE
ARCHITECT ENGINEER mengembangkan
mengembangkan mengembangkan mengembangkan (UX) DESIGNER
skema basis data & executable documents
arsitektur software automated mengembangkan
testscript stored procedure user experience

TECHNICAL WRITER SOFTWARE WEB & UI BUILD & SECURITY

mengembangkan user ENGINEER DESIGNER DEPLOYMENT ENGINEER
manual dan screencast mengembangkan mengembangkan
mengembangkan ENGINEER (DEV
software dengan kode halaman website sistem yang aman
yang bersih (Frontend dev)
OPS) mengembangkan
automated build dan
automated deployment
Apa itu scrum master berdasarkan Scrum Guide

Scrum master =

• Memastikan scrum itu dipahami dan dihidupi oleh tim scrum sesuai scrum guide
• Dia adalah servant leader, pemimpin yang melayani (Servant Leader).
• Mereka diluar team scrum, harus memahami interaksi mana yang bermanfaat dan mana
yang tidak. scrum master harus berani memastikan tim diluar scrum tidak mengganggu
tim scrum.
• Scrum master harus bisa membuat seseorang keep improving.
• Scrum master harus selalu bertanya dalam diri “Bagaimana saya dapat melayani orang-
orang didalam perusahaan lebih baik lagi dari kemarin agar seluruh potensi mereka keluar
dari dalam diri mereka”
1. Scrum master adalah nama lain technical leader
2. Scrum master adalah customer proxy
3. Scrum master adalah nama lain dari manajer proyek
4. Scrum master adalah sekretaris pribadi untuk tim dev
5. Scrum master adalah Subject Matter Expert (SME)
Hal-hal yang harus diketahui scrum master, Based in scrum guide :
1.Scrum Guide Knowledge
DT mengambil jumlah kerjaan sendiri, tanpa ada intervensi dari siapapun ketika awal sprint. Ada pengontrol
Kualitas, Definition of done. Dev team bisa mengontrol sendiri standar minimum kualitasnya.
2. Teaching Skill, merupakan kemampuan menyusun materi ajar scrum
3. Process Managing Skill, merupakan Self Organize, Proses nya yang jadi inti nya. Scrum master tidak bertanggung
jawab pada keluaran program, tapi bertanggung jawab pada minimum proses itu berjalan. Scrum master harus dapat
mengencourage other to Team & Improve the process, harus dapat menumbuhkan rasa memiliki ke product ke
semua team scrum.
4. Retrospective Facilitator Skill, membantu mengarahkan orang-orang untuk perbaikan diri & perbaikan komitmen.
Bagian ini terdiri dari Continous Improvement Mindset (Jadikan spirit & semangatnya harus ada dalam diri scrum
master sebelum memberi motivasi ke pada orang lain), Emphiricms, pengetahuan hanya didapat oleh indera data
metric fokus, dan Discipline on retrospective, Scrum master harus pertama kali bertiindak ketika sesuatu yang buruk
terjadi dalam tim nya.
Hal-hal yang harus diketahui scrum master, Based in scrum guide :

5. Organization Influencing Skill, wajib untuk memastikan proses minimum berjalan. Scrum master tidak melakukan
locked deadline, Tidak ada deadline sesuai scope dan lainlain. Bagian ini terdiri dari:
a. Bird View, harus mampu melihat organisasi. Idea, idea solutif.
b. Contagious, berani untuk interupt
c. Persistance, ngotot ga ngeyel.

6. People Skill
a. Human Happiness
b. Conflict Mediation
c. Team Motivating
 Membantu memahami Mempasilitasi praktik Bersama scrum master lain:
perancangan produk ala scrum terlaksana untuk DT Memimpin dan
empirisme (bisa diukur & yang baru mengenal membimbing organisasi
fleksible diubah) SCRUM dalam penerapan scrum
berdasarkan data nyata Membantu DT untuk
dari pengguna. Bukan Membantu setiap pegawai
mengatur diri sendiri. SM

Untuk DT, Scrum master

Untuk PO, Scrum master
harus

harus

master harus
Untuk ORGANISASI, Scrum
perintah CEO. dan stakeholder untuk
harus jadi inspirator DT memahami scrum
Membantu terus mencari Bekerja iterative dalam membantu membuat
teknik terbaik untuk waktu yg singkat. Ini butuh perubahan di level
mengelola backlog (antrian skill tinggi organisasi yang mendukung
pekerjaan yang fleksible) Mendorong DT untuk selalu tim scrum
memperbaiki cara kerja
dan kualitas sw buatan
mereka
Menghilangkan gangguan-
gangguan lain yang
menghambat mereka
namun diluar kendali DT
• Scrum master adalah seorang ‘Master’ dalam scrum
• Scrum master adalah seorang partner. Scrum master akan berjalan disamping tim nya,
bukan hanya dalam keadaan senang, tapi juga dalam keadaan susah. Scrum master tidak
menghakimi timnya ketika mereka gagal atau khilaf
• Scrum master bukanlah orang yang ‘sok tahu’ hanya karena ia lebih berpengalaman
dibanding timnya.
• Scrum master menggunakan ‘artful questions’untuk memandu mencari jawaban itu
sendiri dan mencari teknik-teknik lain untuk memecahkan sebuah masalah.
• Scrum master tidak mengelola dan memberi instruksi kepada tim pengembang. Ia bahkan
tidak menugaskan orang-orang untuk mengerjakan sebuah pekerjaan.

• Scrum guide Tidak melarang

rangkap peran.
• Yang dilarang scrum guide hanya
rangkap peran PO dengan SM
1.Product backlog
2.Sprint backlog
3.Potentially shippable product increment
1. Adalah antiran pekerjaan (Feature a, b, c) yang dilakukan DT, bisa membuat
fitur, mebetulkan bugs, atau merapihkan kode. Ini sipatnya antrian.
2. Setiap pekerjaan itu dinamakan PBI, PRODUCT BACKLOG ITEM. (bagian dari
product backlog)
3. Informasi minimal, ditiap PRODUCT BACKLOG ITEM yang ideal :
1. Deskripsi
2. Urutan Stack
3. Nilai estimasi kesulitan
4. Estimasi Nilai bisnis
4. Product backlog
1. Nilai Estimasi kesulitan dikuasai DT
2. Sisasnya dikuasai PO (Desk, urutan, nilai bisnis)
5. Meski begitu, DT bisa membantu PO menuliskan deskpsi tersbut. PO hanya
via mulut,
6. KUNCI AGILE : PRODUCT BACKLOG = FLEKSIBLE (berubah ditengah
Berdasarkan data pengguna)
7. Multitaskting is not Good
• Product backlog item harus muat dalam 1 sprint, apabila
tidak muat, hendaknya dipecah agar muat dalam satu sprint
• Agar mudah dimengerti, buat product backlog item dalam
bentuk user story. Tim pengembang yang bertanggung jawab
untuk melayani product owner menuliskan PBI
• Scrum tidak mengenal change request karena segala bentuk
perubahan terhadap produk harus dimasukkan ke dalam
product backlog dan diurutkan kembali pengerjaanya.
Product backlog item (PBI) termasuk dan tidak hanya
terbatas dari:
1. Fitur baru
2. Technical design and specification
3. Defect
4. Non functional requirement
5. User interface mockup/wireframe
6. Enhancement
7. Beautification
8. Use case scenario
9. Acceptance criteria
10. Standard compliance
11. Customer support request
Story point : memberikan gambaran estimasi
seberapa lama suatu pekerjaan dibutuhkan
untuk diselesaikan.
Value point : seberapa penting sebuah task
untuk dilakukan
Pada agile estimasi, kit amembutuhkan
“DELIVER VALUE EARLY”
yang berisi 2 hal diatas
Gunakan konsep relative dari setiap tasknya
Pernyataan singkat mengenai pekerjaan yang
akan difokuskan dalam sebuah sprint
• Sprint adalah Fase-fase pengembangan yang singkat,
dimana didalamnya harus ada pengerjaan secara penuh.
(Analyze, design, integrate, test, build). Sprint backlog
adalah pekerjan disetiap 1 sprint.
• Sprint backlog Terdiri dari PRODUCT BACKLOG ITEM (PBI)
yang diambil dari PB & cara mengerjakannya (biasanya
terwujud dalam ‘tasktask’)
• Sprint backlog dikuasai sepenuhnya oleh DT
• Kecuali detail PBI yang PO luput dari sprint planning (artinya
SB fleksibel)
• Estimasi kesulitan PBI membantu DT melihat prporma
mereka dari sprint ke sprint
• TASK Biasanya ukurannya dalam JAM bukan HARI
1. Individu memilih sendiri pekerjaan yang
ingin mereka lakukan
2. Pekerjaan tidak pernah ditugaskan pada CONTOH SPRINT BACKLOG :
individu
3. Perkiraan sisa pekerjaan diperbaharui setiap
hari
4. Setiap anggota tim dapat menambahkan,
menghapus atau merubah sprint backlog
5. Pekerjaan baru dalam sprint akan muncul ke
permukaan
6. Apabila sebuah pekerjaan tidak jelas, buat
sebuah item sprint backlog yang baru
dengan durasi waktu yang lebih lama dan
dipecah di kemudian hari
7. Perbaharui daftar sisa pekerjaan ketika ada
pekerjaan yang telah diselesaikan
 Bntukya sotware / user manual. Apapun yang bisa digunakan oleh user.
Kubus = sw, increment adalah potongan kecil dari kubus. Jadi increment user dapat
menggunakannya lgsg.

Incement membuat sw semakin lama semakin matang, kenaopa agile? Increment dibuat
berdasarkan respon terbaru dari penguna. Jadi kita benar-benar membuat sw yang sesuai dengan
maunya pengguna. ITULAH INDAHNYA AGILE
Kita mulai dari sprint planning, simplenya,
kita membuat sprin backlog & sprint goal

Peserta:
1. Semua tim scrum
2. Tenaga ahli (optional)
Masukkan (INPUT) Sprint planning,
sebelum alur dimulai :
1. Product backlog
2. Inkrement terbaru. Inkrement
sprint sebelumnya bisa dicoba
3. Rekam performa pengembangan.
Dokumen performa sprint sblmnya.
Alur
1. PO menjabarkan tujuan yang dia mau diawal
2. DT menjabarkan apa yang ingin mereka kerjakan
3. Lalu PO & DT berembuk bersama, menentukan
sprint goal, lalu mendetailkan PBI-PBI Terkait.
4. Fokus ke DT, DT mengambil jumlah pekerjaan (PBI)
untuk SPRINT BACKLOG yang visible dikerjakan 1
sprint(sanggup) (2minggu / 1 bulan). TIDAK ADA 1
ORANG PUN YANG BISA MENDIKTE DT untuk
mengambil jumlah kerjaan yang tidak mampu DT
kerjakan. DISINI DILAPANGAN SERING TERJADI
MEMBUAT DT bekerja lebih menderita. BAHAYA YA,
JANGAN.
5. Pendetailan PBI-PBI di SPRINT BACKLOG menjadi
plan (task) setidaknya garis besar. Minimal untuk
beberapa hari kedepan, yang jelas, detail HOW TO
nya bisa terus diubah dibeberapa hari kedepan.
Keluaran
1.Sprint Goal
2. Spring Backlog (PBI & PLAN)

• DARI SISI WAKTU, Scrum guide membuat sprint planning

punya batas waktu maksimum, SELESAI GA SELESAI, lewat
dari waktunya maks 8 jam untuk sprint selama 1 bulan.

• Karena kita berbicara tentang sprint backlog & berbicara

mengenai pendetailan produk backlog item sesuai arahan
PO, kita perlu membicaran DEFINITION OF DONE (DOD)

• Planning dilakukan berdasarkan fitur bukan aktifitas

Durasi masing-masing activity dalam scrum:
SPRINT PLANNING REVIEW RETROSPECTIVE DAILY SCRUM
30 Hari 8 Jam 4Jam 3 jam 15 menit
3 minggu ~ 6 jam ~ 3 jam ~ 2 jam 15 menit 15 menit
2 minggu ~ 4 jam ~ 2 jam ~ 1,5 jam 15 menit
1 minggu ~ 2 jam ~ 1 jam ~ 45 menit 15 menit
Pertimbangkan faktor-faktor berikut :
1. Seberapa mampu tim pengembang untuk menghantarkan production ready software. Beberapa tim
pengembang mungkin belum mahir untuk hal tersebut dalam waktu 2 minggu, sehingga 3 minggu atau sprint 1
bulan lebih cocok
2. Seberapa sering product owner ingin melihat perkembangan. Bagi beberapa product owner mungkin waktu 1
bulan terlalu lama
3. Seberapa sempat PO untuk hadir di sprint planning, sprint review, dan sprint retrospective. Bagi beberapa
product owner yang sibuk, mungkin bertemu dengan DT setiap 2 minggu sekali dirasakan terlalu banyak
4. Seberapa banyak item yang terdaftar di “DEFINITION OF DONE”. Bagi beberapa DT yang bekerja dibank, mereka
harus membuat banyak dokumentasi sehingga dalam 2 minggu mungkin belum dapat menghantarkan software
ready

Karena scrum menggunakan pendekatan BOTTOM-UP, yang dapat menjawab berapa durasi sprint yang ideal
hanyalah Product owner dan tim pengembang. Kedua pihak ini yang akan membuat kesepakatan mengenai durasi
sprint setelah mempertimbangkan semua faktor.
“ ”
• Dod = ceklis prasyarat yang harus dilalui setiap PBI, tapi tidak
tertulis di deksripsi PBI, Syarat standar kena ke semua PBI &
DT.
• Versi minimum DOD adalah standar perusahan sendiri
• Maks DOD? Tidak ada, DOD adalah milik DT karena SB adalah
milik DT, Harus terus memperbaiki diri. DT boleh
menambahkan standar kualitas sw dia. BANYAK BANGET
EKSEKUSI DILAPANGAN yang membuat penggunaan SCRUM
menjadi sw yang tidak berkualitas. Karena dituntut dalam
waktu singkat, jadinya ada teknical dev issue. Solusinya jaga
oleh DEV OF DONE. Definisi dari selesai ditentukan bersama secara
konsensus
Contoh:
Telah di-deploy di local server oleh CI
Semua function telah melewati unit test
Semua fitur telah di-test oleh tester
Software sudah dalam bentuk releasable
1. Code refactored, clean code all the time with low 5. Documentation has been created with best effort:
cyclomatic complexity and high maintain ability index • User requirement specification
2. All automated test script has been created with best • User guide and user manual
effort: • Architexture & texhincal specification
• Unit test script • Test scenario
• Integration test script • Functional test result
• Functional test script • Executale document that validate the code
• Performance test script 6. All code are checked in and built by continouos build
• Security test script 7. Continuous build have build package to be runable inside
• Coded UI test script Docker
3. Mission ciritcal business method are: 8. Sexy and clean UI/UX
• Pair programmed 9. Page loading time should not be more than 2 second
• Code reviewed by the whole team
10. Manual functional testing and explanatory testing has
• Covered by automated test and code coverage shoul been done with best effort
not be lower than 85%
11. Product owner can deploy the system with a single click
4. No Compiler warning of a button with in release
12. We are proud to mention this software in our resume
• Sepanjang pengembangan:
• Sprint GOAL Tidak boleh berubah (Masalah besar untuk tujuan
bersama tidak boleh berubah)
• Plan pengerjaan boleh berubah, ga usah nunggu dari PO. DT boleh
mengubah cara how to mencapai tujuan.
• Terkait detail deskripsi PBI di SB bisa merubah (PB refinement)
• PB refinement bisa terjadi (seperti sprint planning PO & DT
berembuk untuk tujuannya untuk mempercantik, memperdetail &
memperjelas product backlog) secara adhoc(tidak bisa diduga)
ditengah2 (max. perubahan 10%)
• PBI di SB boleh berubah biasanya karena kendala teknis yg besar
atau instruksi darurat PO. Bisa ada PBI yang keluar
1. Perubahan vs Kualitas
• Tujuannya bukanlah menghabiskan
banyak waktu untuk menciptakan
software dengan arsitektur
sempurna, namun menciptakan
sebuah software dengan arsitektur
yang dapat menerima perubahan
kapanpun juga
• DT perlu meningkatkan skillnya
dengan menerapkan design
principle dan design pattern yang
meastikan fw tetap berkualitas dan
feksibel terhadap perubahan
2. Test engineering vs click testing
• Seorang tester tidak boleh hanya dapat
melakukan ‘Click testing’ karena
siapapun dapat melakukan hal tersebut.
• Test engineering adalah aktifitas
mengembangkan automated test script
dan membangun infrastruktur untuk
automated test.
• TE bukan hanya mahir dalam test dari
tampilan sistem (black box testing),
namun harus mahir juga dalam internal
sistem test (whitebox testing)

3. Executable documents not static 4. Dirty Code
documents
• Tugas seorang bisnis analyst
adalah menerjemahkan
kebutuhan dari pihak bisnis
dalam bentuk dokumentasi
yang nantinya akan
diterjemahkan oleh
software engineer. BA harus
kolaborasi dengan test
engineer dan belajar
mengembangkan executable
document yang dapat
memvalidasi bisnis logic
b) Method dan class yang
susah untuk di unittest
c) Algoritma dan kode
yang masih di copy
• Kode yang pertama kali paste dari sumber
ditulis oleh software diinternet
engineer itu bagaikan d) Class yang terlalu
draft buku. Karena panjang dan melakukan
masih draft. Maka kode banyak hal
tersebut sifatnya masih e) Method yang berada di
kotor. dalam class yang salah
• Sangat mungkin draft f) Algoritma yang masih
kode ini memiliki kompleks dan belum
atribut berikut: efisien bila di ukur
a) Method terlalu dengan BIG-Onotation
besar dan g) Penamaan variabel,
melakukan banyak class dan method yang
hal (God method) belum self explaining
5. Nanti juga ada yang membersihkan
Dirty Code bersifat menular dalam tim dev yang tidak memiliki mental
profesionalisma. Perbedaan seorang software engineer yang profesional dengan
software engineer yang tidak dapat dilihat ketika mereka melihat sebuah kode
berjumlah 1000 baris sebelum menambahkan kode.
a) Software engineer yang tidak profesional akan menambahkan kode diatas kode
yang sudah berjumlah 1000 baris tersebut yang bisa menyebabkan kode melebihi
1000 baris
b) Software engineer yang profesional akan melakukan pairing dengan test engineer
untuk menuliskan unit test dan me-refactor kode yang berjumlah 1000 baris
tersebut sebelum menambahkan kode baru.
6. Production Ready Software 7. Yang penting jalan dulu deh
• Dibutuhkan seorang software developer berkaliber • Mental “yang penting
untuk dapat melakukan rilis product ready secara jalan dulu deh” tidak
konsisten di setiap sprint memiliki kebudayaan
• Kebanyakan software dev mengatakan kalau fanatisme terhadap
production ready software adalah SUDAH DI TEST kualitas
& MEMENUHI ACCEPTANCE CRITERIA. Definisi ini • Managemen & pimpinan
tidak dapat diterima karena untuk harus memiliki perusahaan harus
standar tinggi terhadap software yang dibuat menciptakan sebuah
dengan yang diberi nama DEFINITION OF DONE. lingkungan kerja dimana
• Sebelum product development dimulai, Product kualitas menjadi budaya
owner dan DT berkolaborasi mendefinsikan perusahaan
“DEFINITION OF DONE” seperti contoh yang ada
pada slide DEFINITION OF DONE.
Peserta :
Hanya DT

Penyelenggara (EO) :
Dev Team

Alur :
1. Masing-masing DT bergantian, tanpa diinterupsi harus lanjut, bercerita
1. Aktifitas kemarin (melakukan apa saja)
2. Kendala kemarin (internal, eksternal)
3. Rencana aktifitas hari ini apa saja. Ke 3 hal ini untuk membantu tim capai
sprint goal.
Penting untuk menyebarkan informasi pengembangan
2. Setelah daily scrum meeting ditutup, baru boleh rapat adhoc (terpisah)
3. Waktu maksimum 10-15 menit
• Setelah dikerjakan increment
• Tujuannya untuk meninjau increment
• Peserta : PO & DT. Stakeholder terkait dan User
sample.
• Penyelenggara : PO mengundang
• Tujuan : meninjau increment dari DT ke PO &
memperbaharui PB.
• Waktu maks 4 jam untuk 1 sprint
• Alur :
1. PO yang punya acara, membuka dengan
menelaskan/menyatakan PBI mana yang sudah
selesai dan mana yang belum selesai
2. DT menjelaskan apa saja yang berjalan baik
sepanjang sprint, masalahnya seperti apa dan
pemecahan masalahnya seperti apa.
3. DT mendemonstrasikan inkrement (demo
produk)
4. PO mengulas keadaan pasar. (Analytic kita
begini, kompetitor kita begitu)
5. PB Refinement baru sembari tinjau hal hal
terkait perilisan produk, timeline, budget
potensi kapabilitas dan kondisi pasar
Activities :
Menginspect & mengadapt , meninjau dan mengadatasi proses
kerja DT
Peserta :
DT & SM
ALUR :
1. Ditinjau bagaimana sprint yang telah selesai berlangsung,
orangnya, hubungan antara orang, proses, dan perangkat kerja
2. Meninjau eksperimen perbaikan satu sprint ke belakang.
Adalah sebuah proses baru yang kita coba eksperiemtn 1
sprint. Ditentukan ekprerimen apa yang akan dikerjakan
ekpreimen selanjutnya. Bisa jadi eksperimen ini dilanjutkan ke
sprint selanjutnya.
3. Boleh memperbaharui DOD. Cth menambah jenis test di DOD
4. SM membuka wawasan DT terkait proses kerja (teknis,
nonteknis) boleh lewat referensi. Setidaknya bisa memberikan
pakar-pakar teknologi atau referensi buku.

Keluaran : Rencana implementasi perbaikan (improvement

experiment)
Waktu maks : 3 jam di 1 sprint
Catatan : Retrospecive adhoc diperbolehkan ditengah2 sprint.
• Dalam scrum, management risiko adalah dengan menghantarkan sesuatu yang
bernilai untuk pelanggan dalam jangka waktu sesingkat mungkin
• Apabila DT tidak bisa menghantarkan sesuatu yang bernilai bagi pelanggan dalam
jangka waktu 30 hari atau kurang, maka hal tersebut sudah merupakan resiko
tersendiri bagi pelanggan karena pelanggan secara eksponensial akan semakin
kehilangan kontak dengan pasar yang terus berubah.
• Model sprint menyediakan banyak opsi kepada pelanggan untuk dapat kompetitif di
pasar karena jangka waktunya yang singkat.
• Pelanggan akan lebih sering melihat perkembangan software developement dalam
bentuk product ready software.
1. Scrum project meningkatkan kinerja secara
eksponensial dilihat dari aktifitas daily scrum
meeting dan end of each sprint yang
membutuhkan feedback untuk
menindaklanjutin pekerjaan agar lebih baik.
Dari sini bisa terlihat scrum melakukan twice
of work in half the time
2. Adanya konsep 80/20 principle. 80% value
dapat dihasilkan dari 20% waktu project
keseluruhan. Hal ini menjadi pemicu yang
lebih cepat dengan kualitas yang baik untuk
dilakukan di sprint selanjutnya
3. Sprint dalam scrum are constraint
with work hour, dalam scrum, kamu
akan melakukan catch up terhadap
kualitas pekerjaan setiap hari, jadi
akan terlihat hasil kualitas yang
semakin maksimal dibanding harus
melakukan work hour dengan project
traditional work yang dapat membuat
kualitas pekerjaan menurun
1. Meningkatkan kualitas software
2. Mempercepat proses pengembangan dan penghantaran software
3. Menurunkan tingkat turnover dan meningkatkan tingkat kepuasan pegawai
4. Meningkatkan transparansi dalam perusahaan
5. Menghancurkan tembok pembatas penyebab birokrasi dan politik
6. Membentuk team culture of learning and continuous improvement (antistatus-
quo)
7. Meningkatkan sense of ownership setiap pegawai
1. Cari satu alasan terkuat kenapa perusahaan anda harus berubah sekarang
2. Cari sponsor untuk dapat mendukung perubahan didalam perusahaan
3. Jelaskan kepada pimpinan kunci perusahaan lainnya untuk mengenal perubahaan
ini
4. Membuat sebuah aliansi untuk bersama-sama dapat membuat perubahan dalam
perusahaan
5. Buat dan urutkan product backlog untuk menuju perubahan ini
6. Edukasi dan empower pihak lain yang akan terlibat dalam perubahan
7. Review perubahan ini dan dampaknya terhadap perusahaan sebulan sekali
8. Scale out, make it persistent
 Populate backlog dari semua fitur yang akan
kamu lakukan di project. Daftarkan semua backlog tersebut
kedalam format userstory. Semua task harus memiliki narasi
1. Siapa yang membutuhkan
2. Apa hal spesifik dibutuhkan
3. Dan kenapa dia membutuhkan itu

Setelah dibuat userstory, lalu prioritaskan product

backlog ini kedalam urutan pengerjaan berdasarkan
COSTUMER VALUE & IMMEDIATE IMPACT sesuai visi
product owner. Product owner & DT bisa mengisi
bagian ini.

Detail kan product backlog ini menjadi task-task yang

lebih rinci seperti proses analisis dokumentasi, desain,
code, test engingeering, integrasi, dll tanpa ada urutan
sekuensial pada masa developmentnya.
• Gunakan fibonacci sequence : 1,2,3,5,8,13,etc
• Jangan mengestimasi di kondisi yang pasti seperti jumlah jam
pengerjaan.
• Untuk mengimplementasikan relative estimae, mulai dari task
yang paling susah dan paing panjang pengerjaannnya. Lalu isi
task lain, dari relative ke yang paling susah
• Story point tidak mengukur kompleksitas, tapi mengukur
seberapa besar effort yang harus dilakukan
• Works sprint biasanya terdiri dari 1-2 minggu,
maksimal 1 bulan
• Dan goal nya adalah melakukan demo day di akhir
sprint
• Tentukan seberapa banyak point yang bisa kamu
selesaikan sampai ending sprint
• Misal setelah story point kita kalkulasi, plan awal
akan menghasilkan total 108 point, lalu setelah
pengerjaan sprint ini kita hanya mencapai 96 point.
Maka gunakan 96 point ini sebagai baseline di
sprint selanjutnya ditambahkan 10 % volume dari
task yang selalu sukses
• Buat scrum story board (misal di trello)
• Simple story board, hanya terdiri dari 3 kolom,
yaitu DO, DOING, DONE
• Populate task kedalam bentuk sticky notes dan
tempelkan
• Setiap hari kamu update task card ketika kamu
bekerja. Kemudian dokumentasikan kedalam
burndownchart.
• Burndownchart adalah chart sederhana yang
menunjukkan initial value storypoint yang bergerak
setiap harinya sampai end of sprint.
• Target harapannya dengan bundownchart ini
adalah di end of sprint memiliki nilai storypoint 0
(semua task yang diestimasi di awal selesai)
 Feature list :
•Story Points: Set Story Points for
Trello Cards
•Effort completed: Set time spent on
tasks and remaining to check if your
team is still on track.
•Tags/Categories/Labels: Group
Cards into tags, User Stories or
projects, these are colored
automagically to save you time.
•Progress Bars: Visualize your Sprint
progress instantly with unobstrusive
background progress bars on both
cards and lists.
•Header Separators: Use header
separators to group cards inside lists.
•Variable font size: Cards with more
Story Points have a slightly increased
Instructions font size so you can distinguish bigger
Add Story Points to a card by typing the number in parenthesis: from smaller tasks at a glance.
(3) Design new homepage header
Track time spent on each card:
(1/3) Design new homepage header
Add a Tag to a card by writing it in square brackets:
[dev] Implement Ads in footer
Create a Header Separator by creating a new card with three asterisks at the start and end:
*** Sprint 3 ***
https://youtu.be/BuZyd9ewflQ

https://trello.com/b/zJsfh8jP/bantu-anak-asuh-apps
• Lakukan daily standup meeting sekitar 5 menit.
• DT membahas secara bergantian,
• Apa yang sudah dikerjakan kemarin
• Apa yang akan dilakukan hari ini
• Masalah apa yang terjadi selama pengerjaan
agar dapat dilakukan improvement
Jika ada problem yang butuh didiskusikan
bersama, maka dilakukan terpisah setelah daily
standup meeting
• Diakhir sprint lakukanlah demo Minimum valuable
productnya
• Bukan product secara keseluruhan, tapi fitur yang
paling penting yang dibutuhkan user
• Selama demo, kalian grab feedback terkait product
nya dari user/customer
• Customer disini harus berkomentar, apakah
mereka APPROVED dengan fiturnya atau they need
IMPROVED fiturnya.
• Kumpul bersama tim scrum
• Bahas hal-hal berikut,
• Apa saja hal yang baik selama sprint
ini?
• Apa saja hal yang kurang baik selama
sprint ini?
• Dan improvement apa yang harus
dilakukan agar kinerja bisa lebih
meningkat, efektif & efisien