Apa saja sebenarnya yang dilakukan Tim Software Development sehingga mereka mengaku-ngaku sebagai Tim yang Agile ?

Kita tidak berbicara konsep disini, tapi implementasi yang biasanya kelihatan secara umum dilakukan oleh Tim Software Development.

Ok, coba kita lihat :

1. Membagi waktu pekerjaan dalam slot 2, 3, atau 4 minggu.

Ini disebut Sprint.

Yaitu waktu yang dibutuhkan untuk memilih, membuat, dan menyelesaikan sebuah/beberapa fitur kecil di aplikasi, kemudian mem-presentasikannya ke pada pihak yang membutuhkannya.

Jangan dikacaukan dengan Miskonsepsi tentang IT , yang tentang 2 minggu bikin aplikasi selesai.

Kenapa cuma fitur kecil ?

Karena di Agile, semuanya harus bertahap dan berproses.

Bukan gelondongan besar yang langsung jadi.

2, 3, atau 4 minggu dianggap waktu yang cukup untuk menyelesaikan perubahan-perubahan kecil, kemudian dipresentasikan agar mendapatkan saran dan masukan yang dijadikan landasan bagi Sprint berikutnya.


2. Membuat perencanaan pekerjaan

Ini disebut Sprint Planning.

Yaitu rapat yang digunakan untuk memilih, menganalisa, dan menentukan bobot dari pekerjaan untuk Sprint yang akan dijalani.

Kenapa pekerjaannya perlu dipilih ?

Karena tim terdiri dari anggota yang terbatas, mempunyai kapasitas tertentu yang hanya bisa mengerjakan dalam lingkup tertentu pula.

Kalau tidak dipilih, maka tidak akan cocok antara kapasitas tim dengan bobot pekerjaan yang ada.

Kenapa perlu dianalisa dahulu ?

Karena untuk menentukan bobot dari pekerjaan, kemudian disesuaikan dengan kapasitas dari tim.


3. Melakukan evaluasi harian

Ini disebut Daily Scrum Meeting atau Daily Standup Meeting.

Rapat singkat sekitar 10 - 15 menit, berisikan evaluasi harian dari semua anggota tim.

Tujuannya mengecek kemajuan pekerjaan, hambatan yang dihadapi, ide baru, rencana pekerjaan dan juga saran dan masukan dari semua anggota tim.

Evaluasi ini bukanlah seperti reporting kepada boss, leader, atau management.

Akan tetapi evaluasi internal dari tim agar bisa mencapai tujuan 2, 3, atau 4 minggu Sprint diatas.

Langsung kepada masalah, rencana dan aksi yang akan dilakukan.


4. Menguji efektifitas value di akhir Sprint

Ini disebut Sprint Review.

Tujuan dari Sprint selama 2, 3, sampai 4 minggu itu adalah untuk memberikan value kepada tim bisnis secepat mungkin.

Value disini berupa keunggulan aplikasi yang ditambahkan sesuai kebutuhan bisnis.

Setelah pengerjaan 2, 3, sampai 4 minggu ini, maka saatnya Tim Software Development menguji apakah tambahan fitur, perbaikan bug, perbaikan proses, dll sesuai dengan yang diinginkan oleh tim bisnis.

Menguji dan melihat hasil perubahan aplikasi dalam waktu yang relatif singkat bagi tim bisnis tentunya lebih fokus dan lebih bermakna, dibandingkan menguji dan melihat hasil perubahan aplikasi yang sekali banyak.

Kalau sudah banyak, biasanya akan tidak fokus dan sudah lupa dengan kebutuhan awalnya dahulu.


5. Melakukan evaluasi tim pada akhir Sprint

Ini disebut Sprint Retro.

Evaluasi terus menerus adalah keharusan bagi tim dan bisnis yang berkembang.

Tidak hanya dari sisi pekerjaan, akan tetapi tentu saja terkait dengan psikologi tim, kekompakan, proses dan hal yang mempengaruhi agilitas dari tim selama sprint berlangsung.

Sesi curhat, komplain, care, dan sharing bagi tim IT Software Development mengenai tugas, beban, kesulitan, hal yang menarik, dan hal lain yang menyangkut tim.

Di Sprint Retro ini jugalah, tim bisa mendapatkan pelajaran mengenai cara berkomunikasi yang lebih baik, metode yang cocok bagi tim, dll.


Kesimpulan

Agility dalam sebuah tim IT Software Development adalah sebuah keniscayaan.

Tidak hanya agar bisa kelihatan keren, tetapi yang lebih penting agar bisa lebih fleksibel dan tune-in menghadapi perubahan.

Untuk mendukung hal tersebut, ada beberapa metoda dan tindakan yang dilakukan.

Tetapi apapun nama metoda dan tindakannya tidak masalah, yang perlu ada konsepnya dan konsistensi dalam melakukannya.