Kolaborasi atau approval ?

 belajar dari kolaborasi dengan user selama ini, ketika user diminta approval (secara psikologi user tersebut akan merefleksikan bahwa dia yang akan bertanggungjawab terhadap kegagalan fitur tersebut).

sehingga untuk menjawabnya user sangat hati-hati bahkan minta approval lagi ke managernya atau ke divisi lain untuk share risiko gagal nya (kalau-kalau misalkan ada kesalahan dia ada temannya yang disalahkan). hal ini yang membuat user lama untuk approve.

kalau kita tarik kebelakang, kenapa sih kita mesti ada approval dari user ?

yaps, untuk memastikan apa yang akan kita buat sesuai dengan kebutuhan user yang akan menggunakan epic yang di develop tersebut. 

kalau tujuannya adalah untuk memastikan detail dari epic yang akan di buat sesuai dengan kebutuhan user, apakah perlu menggunakan kata approve ? 

dimana berdasarkan pengalaman kita sebelum-sebelumnya untuk mendapatkan jawabannya terkadang sampai berminggu-minggu padahal jawabnnya hanya iya atau tidak.

kalau kita lihat arti dari approval adalah menyetujui, sedangkan tujuan dari aktivitas kita adalah memastikan mendapatkan detail kebutuhan user. 

seharusnya yang wajar diminta persetujuan adalah jika usernya tidak terlibat dalam proses development atau tidak berkolaborasi dengan tim development. yang kita lakukan saat ini, kita berkolaborasi dengan stakeholder, user terlibat dengan proses develpment, namun juga user di minta approval. 

approval membuat seolah scrum tim dengan stakehlder adalah dua pihak yang berbeda, sehingga perlu ada approval. untuk bisa agile scrum tim dan stakeholder bekerja secara bersama-sama (berkolaborasi) untuk menghasilkan epic yang dapat meningkatkan value product. 

jadi pembelajaran yang kita ambil adalah "praktikal approval menghambat agility".

"The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency." - scrum guide.

Scrum Values

 

🧢 Mengenal 8 Topi Seorang Scrum Master: Lebih dari Sekadar Fasilitator

 Banyak yang mengira peran Scrum Master hanya sebagai fasilitator meeting atau penjaga jadwal. Padahal, menjadi Scrum Master jauh lebih luas dan strategis dari itu. Scrum.org dalam whitepaper-nya memperkenalkan konsep "8 Stances of a Scrum Master" — delapan peran penting yang menggambarkan kompleksitas dan kekayaan tanggung jawab seorang Scrum Master.

Yuk kita bahas satu per satu!

1. Pemimpin yang Melayani (Servant Leader)

Scrum Master adalah pemimpin yang melayani, bukan memerintah. Ia membantu tim mencapai tujuan dengan menghilangkan hambatan, mendengarkan kebutuhan tim, dan menciptakan lingkungan yang mendukung kolaborasi serta pertumbuhan. Berikut postingan saya yang membahas khusus tentang Servant Leader Link...

2. Coach (Pelatih)

Scrum Master membimbing individu dan tim untuk meningkatkan efektivitas, memahami Scrum secara mendalam, serta mendorong self-management. Coaching bukan hanya tentang memberi jawaban, tapi membantu tim menemukan jawabannya sendiri. Berikut postingan saya yang membahas khusus tentang coaching Link...

3. Fasilitator

Dalam berbagai sesi seperti Sprint Planning, Review, dan Retrospective, Scrum Master berperan sebagai fasilitator yang netral. Ia memastikan diskusi berjalan terarah, inklusif, dan menghasilkan keputusan yang bermakna. Berikut postingan saya yang membahas khusus tentang Facilitator Link...

4. Teacher (Pengajar)

Scrum Master adalah sumber pembelajaran untuk tim. Ia mengajarkan nilai-nilai Scrum, praktik Agile, serta membantu semua orang (termasuk stakeholder) memahami peran mereka dalam kerangka kerja ini. Berikut postingan saya yang membahas khusus tentang Teacher Link...

5. Mentor

Berbeda dengan coach, sebagai mentor Scrum Master berbagi pengalaman pribadi, wawasan, dan nasihat kepada anggota tim yang lebih baru atau sedang berkembang dalam peran Agile mereka. Berikut postingan saya yang membahas khusus tentang Mentor Link...

6. Manajer

Ini bukan tentang “mengatur” tim, tapi lebih ke manajemen sistem kerja. Scrum Master memastikan lingkungan kerja sehat, tools mendukung kolaborasi, serta proses berjalan dengan lancar dan berkelanjutan. Berikut postingan saya yang membahas khusus tentang Manager Link...

7. Change Agent (Agen Perubahan)

Scrum Master mendorong perubahan budaya dan pola pikir. Ia memfasilitasi transformasi Agile di level organisasi dan menantang status quo untuk mendorong perbaikan terus-menerus. Berikut postingan saya yang membahas khusus tentang Change Agent Link...

8. Impediment Remover (Penghilang Hambatan)

Ketika tim menemui halangan, Scrum Master tidak tinggal diam. Ia bergerak cepat untuk membantu menyelesaikan isu—baik yang berasal dari dalam tim, maupun dari luar tim. Berikut postingan saya yang membahas khusus tentang Impediment Removal Link...

Kesimpulan : Bukan Sekadar Role, tapi Sebuah Seni

Delapan topi ini menggambarkan bahwa Scrum Master adalah profesi yang dinamis, kompleks, dan sangat berharga. Seorang Scrum Master yang efektif mampu mengenakan berbagai “topi” ini secara fleksibel, sesuai dengan konteks dan kebutuhan timnya.

Kalau kamu adalah Scrum Master, topi mana yang paling sering kamu pakai? Atau topi mana yang ingin kamu kembangkan lebih lanjut?

Agile Story Point

 Menurut definisi dari Atlasian "Story Point adalah ukuran estimasi untuk mengerjakan sebuah product backlog atau sebuah kerjaan. Estimasi terhadap rumitnya, resikonya, lamanya, banyaknya sebuah pekerjaan". Inti dari story point adalah estimasi ukuran pekerjaan.

contoh ukuran teknik untuk menentukan estimasi ukuran story point :

1. Planning Poker 

teknik estimasi ukuran story point dengan planning poker adalah point nya mengikuti angka Fibonacci yaitu 1,3,5,8,13,21, dst.

2. Ukuran T-Shirt

teknik ini meng-estimasi ukuran pekerjaan dimana nilai point nya mengikuti ukuran baju yaitu XS, S, M, L, XL, XXL

3. Bucket System

teknik pengukuran pekerjaan dengan bucet system adalah mengukur pekerjaan dengan nilai point 0,1,2,3,4,5,8,13,20,30,50,100,200.

4. Dot Voting

titik sebagai tanda estimasi dari setiap tim

5. Affinity Estimation

estimasi dengan mengumpulkan story yang sejenis.

sebenarnya masih banyak teknik untuk melakukan estimasi ukuran pekerjaan, biasanya yang paling sering di pakai adalah Planning Poker yaitu point nya mengikuti nilai Fibonacci.

estimasi ini mempunyai banyak manfaat yaitu mempermudah tim untuk mengukur kemampuan tim dan tugas yang akan di selesaikan dan mempermudah tim dan product owner untuk menentukan seberapa banyak value yang bisa dideliver di setiap sprint.

pendekatan dengan story point ini adalah alternatif pendekatan estimasi man-hour yang biasa digunakan pada project konvensional.

BAGAIMANA KALAU ESTIMASI KITA TERNYATA MELESET?

misal pada awal kita mengestimasikan nilai storynya adalah 3 story point, ternyata ketika eksekusi pekerjaan nya cukup sulit yang setara dengan 5 story point. 

Apa yang mestinya kita lakukan? 

apakah kita perlu mengubah story point nya menjadi 5 atau biarkan saja story point nya tetap 3?

Satu hal yang perlu diingat adalah Story Point dan Velocity bukanlah sesuatu yang dianggap bagian dari Scrum. Sehingga untuk kasus diatas, dikembalikan lagi ke tim, bagaimana sebaiknya mengatur dan menyikapi kasus diatas.

Biasanya ada 2 pendekatan untuk masalah ini :

Pendekatan pertama mengacu kepada estimasi pada dasarnya hanyalah perkiraan, sehingga kalaupun meleset, maka dianggap tidak apa-apa. Tidak perlu untuk mengubah story point yang sudah kita estimasi dari awal. Evaluasi mengenai estimasi yang meleset ini bisa dibahas di sprint Retrospective. Agar nanti bisa diperbaiki di sprint berikutnya. Bisa jadi karena kita tidak memperhitungkan faktor risk dalam penentuan story point, atau story nya tidak detil sehingga kita tidak tepat dalam estimasi story point.

Pendekatan kedua mengacu kepada esensi bahwa sprint haruslah merepresentasikan kapasitas tim dalam melakukan sesuatu. Yang digambarkan dari jumlah story point. Dalam hal ini mengubah story point merupakan salah satu cara untuk mencapai tujuan tersebut. Dan hal ini sah-sah saja karena cukup beralasan.

Kesimpulannya :

Dua pendekatan diatas boleh-boleh saja, tetapi biasanya yang dilakukan adalah pendekatan pertama, dimana story point adalah dianggap sebagai estimasi saja, yang bisa salah dan bisa benar. Tidak perlu mengubah story point yang sekarang. Jadikan kesalahan itu sebagai bahan perbaikan di sprint berikutnya.

Rumus Excel - Fungsi IFERROR. contoh, dan cara penggunaannya

seperti yangtelah dijelaskan pada daftar fungsi excel atau daftar rumus excel itu sangat banyak, kali ini kita akan membahas tentang rumus excel jenis logika. pada daftar rumus excel telah di-sounding jenis rumus excel logika ada 5, salah satunya adalah rumus IFERROR.

Rumus IFERROR digunakan untuk antisifasi jika ada error dengan memberikan keterangan jenis error atau penyebab errornya, dengan begitu dapat membantu kita menelusuri penyebab error dan memperbaikin nya.

Format rumus / cara penulisan rumus

=IFERROR(KALKULASI; NILAI_ERROR)

Kalkulasi

Kalkulasi adalah proses kalkulasi yang diuji, apakah error atau tidak.

Nilai Error  

Nilai error adalah nilai yang diproses (execute) jika Kalkulasi menghasilkan error.

Cara Penggunaan

=IFERROR(A+2; "Nilai yang harus dimasukkan harus angka")

 

berikut hasil setelah rumus dijalankan :

Contoh penggunaan rumus lain nya 

berikut adalah contoh menjalankan proses kalkulasi jika proses kalkulasi pertama error, jalankan proses kalkulasi berikutnya.

proses kalkulasi 1 : A3+B3

proses kalkulasi 2 : A2-B2

dari proses diatas, proses kalkulasi 1 adalah proses yang menghasilkan error. sehingga yang  proses kalkulasi 2 dijalankan. dari rumus diatas hasil yang muncul adalah -2, dimana nilai tersebut hasil dari proses kalkulasi 2 (1-3).

 

Situasi yang tepat menggunakan SCRUM ?

Saat ini anda sedang mempelajari apa itu Scrum, saya yakin 90% passion anda adalah dibidang IT. Karena saat ini di Indonesia sebagian besar peminat yang mempelajari Scrum adalah dibidang IT, namun tidak sedikut pula yang belum aware terhadap hal ini. Namun ketahuilah bahwa Scrum bisa di implementasikan pada bidang IT saja.

Lalu case seperti apa yang tepat menggunakan SCRUM ?
Masalah seperti apa saja yang dapat diselesaikan dengnan SCRUM ?

Pertanyaan tersebut dapat dijawab dengan motede Cynefin Framework. Cynefin Framework merupakan alat untuk membantu memahami situasi yang dihadapi sehingga dapat membuat keputusan yang tepat. CYNEFIN diambil dari kata Welsh yang artinya “tempat” atau “habitat” dan menggambarkan berbagai faktor eksternal yang memengaruhi cara kita berpikir dan mengambil keputusan.

Cynefin Framework mengklasifikasikan masalah kedalam lima situasi berdasarkan hubungan sebab-akibat, yaitu :

1. Simple, diketahui
2. Complecated, dapat diketahui
3. Complex, tidak diketahui
4. Chaotic, tidak jelas
5. Disordered, tidak dapat ditentukan

untuk mempermudah memahami penulis menggunakan narasi, hal ini berbeda dengan versi cynefin yang menggunakan istilah-istilah. jadi jika ada kesalahan penerjemahan penulis mohon masukannya.

 Disordered disebut sebagai situasi yang tidak dapat dikategorisasikan dalam empat situasi lainnya. Yang harus Anda lakukan jika menemukan situasi seperti disordered adalah mengumpulkan lebih banyak informasi sehingga Anda dapat mengategorisasikan situasi tersebut dan mampu mengambil tindakan pemecahan masalah yang efektif.

Menjawab pertanyaan di atas, situasi yang tepat menggunakan Scrum adalah ketika berada di situasi Complex. salah satu contoh yang dikategorikan komplex adalah pengembangan software. 

Sejarah SCRUM

Pada tahun 1993, tulisan dari profesor Takeuchi Tanaka tentang Manajemen Proyek dipulikasikan dalam Harvard Business Review. Tulisan tersebut memuat kekaguman Profesor Takeuchi Tanaka terhadap tim olahraga Rugby yang bekerjasama menyingkirkan semua hambatan yang ada didepannya, lalu profesor Takeuchi Tanaka membawa konsep tersebut kedalam Metode Kerja Manajemen Proyek yang diberi nama SCRUM.    

Tulisan tersebut dibaca oleh Jeff Sutherland yang saat itu dia bekerja di Easel Corporation. Pada tahun 1994, Jeff mengajak Ken Schwaber untuk bergabung di perusahaan nya di Easel Corporation untuk mendokumentasikan dan memformulasikan Scrum.

Pada tahun 1996, hasil formulasi Ken dan Jeff dipresentasikan di konferensi OOPSLA. Sejak saat ini Scrum menjadi pilihan utama Sebagai Pengembangan Produk.

Scrum telah diadopsi oleh banyak Para Manager yang menginginkan Fleksibilitas yang tinggi dan menghasilkan produk yang sebaik  mungkin  dan Developer yang ingin memastikan mereka bisa melakukan pekerjaan mereka sebaik mungkin.

Beberapa perusahaan Multinasional yang menggunakan Scrum antara lain :

1. Nokia
2. Motorola
3. 3M
4. Google
5. Capital One
6. Bank of America
7. Citibank
8. BBC
9. Yahoo!
10. IBM
11. Accenture
12. Autodesk
13. Amazon.com
14. Boeing
15. Microsoft
16. Adobe
17. Intel, dan masih banyak lagi perusahaan raksasa lain yang menggunakan Scrum.

Di Indonesia Scrum Telah banyak di implementasikan olah banyak perusahaan dan telah terbukti sukses membuat produk sebaik mungkin, mayoritas proyek teknoogi informasi.  

Tertarik tentang SCRUM lain nya ? Klik Disini....