Di scrum, keywordnya adalah “self managed team” dimana setiap tim di dalam scrum dapat mendevelop aplikasi sesuai kecepatan tim tersebut, naah bayangkan fun-nya kerja di tim seperti ini: nggak lembur nggak dikejar2 deadline wew, holy grailnya developer tho? hal ini dimungkinkan dengan adanya sistem pull kerjaan bukanya push. Sekarang coba deh lihat kerjaan masing2, semuanya dipush kan? mau featurenya mau estimasi kapan selesainya semuanya dipaksa dengan adanya gant-chart. Kadang2 PM yang konyol suka bilang “pokoknya besok harus jadi”, wew.

Project owner di scrum diberi kekuasaan untuk menentukan feature apa yang akan dikerjakan dalam satu sprint, diurutkan berdasarkan feature yang paling banyak memberikan “bussiness value” terhadap aplikasi di mata kepada konsumen. Kemudian programmer akan menentukan task apa saja yang akan dilakukan dan estimasinya. Project owner ga boleh turut campur menentukan estimasi ini, apa artinya? artinya adalah programmer bekerja sesuai kecepatanya dan bisa mengasumsikan bahwa jam kerja adalah jam 9-18. cool tho?

Project owner kemudian harus memilih mana saja feature yang akan diimplementasikan agar bisa memenuhi kontrak ke customer. Setiap sprint berakhir ada yang namanya retrospektif, semua orang berkumpul dan memberikan saran. Coba deh dipikir2, kapan sesekalinya programmer bisa ketemu sama semua pihak dalam project? jarang kan, nah di scrum ini diwajibkan di awal dan akhir sprint.

Hal yang terpenting kemudian adalah transparansi antar semua pihak yang terlibat, programmer bisa aja bilang sama manager perusahaan kalau internetnya lemot ga bisa cari informasi dengan cepat, atau PCnya dah outdated karena layar cembung dan bikin sakit mata, atau hal2 yang lebih spesifik ke project misalnya informasi tentang rumus tertentu belum tersedia. Transparansi ini bisa didaftar dan disampaikan ke stakeholder setiap hari, karena ada daily scrum meeting. Jadi masalah2 nggak muncul meledak di satu waktu. Daily scrum meeting juga berfungsi untuk memberikan kesan demokratis ke dalam tim, kenapa? karena anggota tim melaporkan apa yang dilakukan kemaren dan hari ini ke anggota tim lain, bukan ke “boss”.

Wah masih banyak deh inspirasi dari belajar Scrum, kanban, agile dan lean management.

http://waroengvb.net

Sesuatu yang aku kurang setuju adalah dengan list kekurangannya. di point kedua dan ketiga kamu mengatakan bahwa agile meningkatkan resiko kesalahan teknis dan proses yang kurang terorganisir. Aku ingin menanggapi sedikit kedua point tersebut.

Agile justru mengurangi resiko kesalahan teknis dengan adanya komunikasi antar developer dan juga dengan stakeholder. Setiap developer juga berkerja dengan user stories yang akibatnya, banyak developer yang menyentuh code satu sama lain. Ini memiliki efek positif, karena secara natural kode akan di-review satu sama lain dan secara konstan ter-refaktor.

Agile justru menurut aku lebih teroganisir dan disiplin dari metodologi pada umumnya. Di setiap saat, stakeholder/scrummaster(xp coach) bisa melihat burn down chart/velocity untuk melihat produktivitas team, melihat progress user story yang sudah ditutup dan sedang dilaksanakan. The lack of gannt chart, maupun UML tidak harus berarti projeknya 'kurang' terorganisir. Toolingnya aja yang beda.

itu lah yang bikin agile lebih jarang di adopt, apalagi buat konsultan. karena bisnis cenderung pengen tau berapa duit dan apa yang dibikin di depan melalui analisa, desain dan proposal. sedangkan di agile, visi ke depannya tidak jauh (untuk supaya ga mubazir itu).

aku juga cukup tertarik nih buat mencari software house di indonesia yang pake agile. kalo ada rekmendasi, pengen nih diajak ngobrol.

btw, iya neh kok tumben podcastnya pendek banget,
aku tertarik ama method ini, software house di indonesia ada yg pake metode ini gak ya?
pengalaman ama beberapa software house cenderung programmer is superman, analis iya, ngoding iya, dokumentator iya, customer support iya.
kalo pun programmer > 1, gak ada namanya pair progamming, si A garap modul 1, si B garap modul 2.

Saya juga baru ngepost artikel tentang agile di http://bit.ly/8T1DTE, mungkin mas ronald bisa cek en kasih feedback kalo ada kesalahan pemahaman saya.

Tapi sayang podcast kali nie kok sebentar amat hehe, pengen saya sedot nie ilmu agile-nya bro ronald hehe.

Saya juga baru ngepost artikel tentang agile di http://bit.ly/8T1DTE, mungkin mas ronald bisa cek en kasih feedback kalo ada kesalahan pemahaman saya.

Tapi sayang podcast kali nie kok sebentar amat hehe, pengen saya sedot nie ilmu agile-nya bro ronald hehe.

my_blog