Bagaimana Jika Karyawan Malas?

Seiring semakin banyaknya perusahaan yang menerapkan Agile, pertanyaan ini kerap muncul di sesi pelatihan Agile Campus. Ini menjadi pertanyaan umum mengingat dalam rangka kerja yang tangkas ini, semua anggota tim yang terlibat diharapkan adalah yang profesional. Tentu harapannya adalah :

• paham bekerja dengan efektif dan sigap
• tidak menunggu tugas dulu baru bekerja
• bisa bekerja tanpa perlu pengawasan penuh

Bayangkan ketika backlog sudah menumpuk, salah satu tim anda terlihat membuang waktu, reaksi awal kita cenderung ingin segera menyalahkan mereka sebagai karyawan yang malas bukan? Sebelum kita menuduh mereka, alangkah baiknya kita melihat beberapa aspek 

• Mari cek dulu Product Owner. Apakah dia sudah menjelaskan MENGAPA? Kita sering lalai dalam hal ini. Manusia bekerja lebih giat ketika mengetahui apa alasannya sebuah tugas dilaksanakan. Ini berlaku untuk semua koq. Tidak melulu di perusahaan yang menerapkan AGILE. Nah, karena merasa bahwa karyawan hanya sebagai alat produksi, kita sering mengharapkan mereka menghasilkan sebuah karya tanpa merasa perlu menjelaskan mengapa sebuah tugas dibuat.
• Saat sprint planning, silahkan berargumen dengan baik untuk menyarankan DT memasukkan lebih banyak PBI. Kalau memang PO dapat memberikan data yg terukur seharusnya kepemilikan tim DT nya lebih tinggi dan bersedia ambil lebih banyak tugas
• Mari melihat Development Team. Dalam Agile, kita sepakat bahwa pekerjaan dilaksanakan oleh DT yang mana kita memberikan kepercayaan kepada tim tersebut untuk mengatur beban dan pembagian kerja di dalam tim mereka sendiri. 
• Akan tetapi anggaplah kita agak-agak ikut campur sedikit. Kita mau tahu apakah semua hasil pekerjaan yg dia berikan memenuhi Definition of Done (DoD) atau tidak. Kecepatan kerja tiap orang memang beda-beda. Kalau semua pekerjaan dia masih memenuhi DoD, maka harusnya tidak masalah.
• Di sini masuknya peran Scrum Master. Anggaplah ternyata memang benar kontribusi karyawan tersebut yang paling sedikit. Bagaimana kita bisa menunjukkannya sehingga ada perubahan nyata? Ya pastikan segala sesuatunya terukur dan terbukti. Bukankah Agile mendasari segala sesuatu dari data empiris? Scrum Master silakan total deliverables dalam 1 sprint dan dipampang ke umum berikut 'skor' total pengerjaan orang-orang, jika memang dia kerja dikit harusnya 'skor' dia paling sedikit. Jadi bisa kelihatan. 

SM is a full time work. It's like taking care of 3 to 9 children to reach their maximum potential, there's no junior or senior position in that 😁

Berikutnya untuk Tim HRD/ Manajemen:

Tindak lanjut dari skor yg keliatan di atas bisa beragam:

- bisa jadi yang bersangkutan akan malu sendiri

- bisa jadi tim baru sadar ada yang kurang perform

- bisa jadi terjemahannya di penggajian, more points = more salary

- bisa jadi sebenarnya tim sudah tahu dan tidak mempermasalahkan karena pekerjaan yang bersangkutan di dalam tim nya bukan hanya sebagai pekerja deliverables tapi yg juga membuat tim semangat?

Dari pengalaman saya pribadi, internal tim itu jauh lebih tahu kalau ada problem dengan satu atau dua orang di tim. Saya tidak pernah punya inisiatif mecat orang. Tapi tim-tim saya selalu menginformasikan apakah ada anggota tim yg mereka rasa kurang cocok untuk bekerja sama. So they sort out their own problem. Jadi tidak terbalik, yaitu tim menunggu2 saya "nyadar" dan mengeluarkan orang tersebut. DT yang punya inisiatif dan saya sebagai manajemen yang memfasilitasi apapun inisiatif mereka.

Sebagai manajemen juga harus mengerti, ketika kita yang mengeluarkan orang, resikonya adalah bisa jadi sudah terlambat DAN bisa menurunkan moral orang (bagaimanapun pemecatan dari manajemen itu membuat karyawan "panik"), tapi kalau tim yang mengeluarkan orang dan kita memenuhi permintaan mereka, moral mereka justru naik karena mereka sudah diberikan kepercayaan untuk mengatur semua masalah internal mereka.

Yang membuat DT tidak bisa menyelesaikan masalahnya biasanya adalah perusahaan tidak memberikan kuasa yang cukup bagi atau tidak mempercayai dan menjalankan saran keputusan dari DT untuk menyelesaikan masalahnya. 

Misalnya keputusan untuk mengeluarkan seseorang dari tim bukan di tangan mereka, tapi di tangan manager sumber daya yang mereka juga hanya melihat orang ini dua kali, saat wawancara masuk dan saat wawancara keluar 😁 Ini yang disebut sebuah perusahaan yang minta developernya agile tapi perusahaannya sendiri sebenarnya tidak bersedia agile.Kalau satu tim semuanya defensif dan tidak perform, kemungkinan yang salah justru rekrutmennya 😁 Kenapa rekrut tim yang tidak bersedia agile untuk mengikuti cara agile?

Kesimpulannya, hati-hati menerjemahkan pekerjaan seorang DT dari sisi 'produktif'. Itu dekat ke abuse of power. Lebih baik menerjemahkannya ke sisi 'happiness'. Happy people are productive people.