Self-Organization. Antara Mimpi & Kenyataan
“Dulu sewaktu masih pakai struktur lama, biasa Technical Lead yang mengatur Pak. Jadi tugas setiap orang jelas dan ada yang ditakuti”.
“Karena setiap orang merasa sejajar, jadinya orang susah dikasih tahu. Akhirnya kita kerja sendiri-sendiri aja”.
“Setiap orang pilih-pilih kerjaan yang dia mau. Akibatnya kerjaan itu jadi saya terus yang mengerjakan.”
Kalimat-kalimat itu dirangkum dari keluhan beberapa crew yang disampaikan pada seorang chief tempo hari. Tidak bisa dipungkiri, pola kerja yang dilakukan selama bertahun-tahun tentu membentuk pola pikir seseorang. Seorang software developer yang terbiasa dengan model organisasi hirarkis berbentuk piramid, dimana setiap tim dipimpin oleh Technical Leader (TL) dan melapor pada Project Manager (PM), tidak serta-merta bisa menyesuaikan diri dengan self-organization model.
Self-organization adalah bentuk organisasi dimana setiap anggota berinteraksi secara spontan tanpa ada pihak lain yang mengendalikan, baik pihak internal maupun eksternal. Bentuk desentralisasi ini bertujuan agar organisasi tidak mudah goyah karena tergantung pada salah satu atau beberapa anggotanya saja. Self-organization bukanlah konsep baru, apalagi baru “ditemukan” seiring berkembangnya agile framework semacam scrum.
Perilaku self-organized dapat ditemukan dalam tim sepak bola. Dalam permainan sepak bola, setiap pemain paham betul tujuan tim, yaitu membobol sebanyak-banyaknya gawang lawan dan mencegah gawang sendiri kebobolan. Sebelum bermain, tim menyusun strategi. Tapi, ketika permainan berlangsung, apakah kapten atau pelatih menentukan secara detail langkah setiap pemain?
Peran Dalam Organisasi
Self-organization model tentu berbeda dengan organisasi piramid. Namun demikian, keduanya memiliki kesamaan. Kedua model ini berfungsi menyatukan beberapa orang untuk mencapai tujuan bersama, dengan cara dan sumber daya yang disepakati.
Dalam organisasi piramid, biasanya ada pembagian peran secara vertikal. Ada level chief yang berperan sebagai penentu arah (tujuan), level manajer yang berperan sebagai penyusun proses kerja, level supervisor yang berperan sebagai pengawas proses, dan level eksekutor yang berperan sebagai pelaksana pekerjaan. Pembagian peran ini bukannya tanpa alasan, penyebab yang paling umum adalah kompetensi dan karakter. Karena fokus kita tentang organisasi, maka saya coba mengesampingkan faktor kompetensi teknis.
Setiap level membutuhkan jenis dan tingkat karakter yang berbeda. Semakin tinggi level seseorang, maka semakin banyak dan tinggi standar karakternya. Seorang eksekutor diharapkan memiliki karakter disiplin, bisa bekerja sama dalam tim, dan mau belajar. Ketika dia ingin menjadi supervisor, maka 3 karakter diatas tidaklah cukup. Sebagai supervisor dia harus mampu mengawasi dan memperlancar pekerjaan para eksekutor. Dia baru bisa menjadi manajer jika mampu menyusun proses kerja (cara) untuk mencapai suatu tujuan, mengumpulkan dan mengelola sumber daya, bertanggung jawan atas pencapaian target, dan memaksimalkan potensi tim. Sedangkan chief level mempersyaratkan ybs untuk mampu membaca dan menentukan arah.
Organisasi piramid maupun self-organization sama-sama membutuhkan tujuan, cara, eksekusi, pengawasan, dan perbaikan. Dalam organisasi piramid, manajer adalah simpul organisasi. Setelah seorang chief menentukan arah, maka manajerlah yang akan “mencerna”-nya menjadi rencana kerja, menentukan kebutuhan sumber daya, mengarahkan tim, dan meningkatkan efiesiensi serta potensi anggota tim. Tanpa melakukan hal-hal diatas, maka sesungguhnya ia hanya manager by title saja. Tidak benar-benar menjalankan fungsinya secara baik dan benar.
Dalam kegiatan pengembangan software, Technical Leader berperan sebagai manajer. Ia bertugas memahami tujuan pekerjaan, menyusun arsitektur sistem, melakukan pembagian tugas, mengarahkan , dan mengawasi pencapaian anggota tim. Singkatnya, menjamin project delivery.
Self-Organization
Peran sentral manajer membawa konsekuensi mendasar terhadap sustainability dan kompetensi organisasi. Hilangnya seorang manajer akan berdampak besar terhadap organisasi. Ketimbang mensentralisasi peran manajer di satu individu, kenapa kita tidak membaginya ke seluruh anggota tim (crew)?
Membagi peran manajer ke seluruh crew tentu meningkatkan sustaibility. Tapi juga membawa konsekuensi, bahwa crew harus memiliki kualitas karakter & kompetensi sebagai manajer, bukan sekedar kualitas karakter & kompetensi sebagai eksekutor semata.
Banyak orang salah paham dengan mengartikan manajer sebagai orang yang memiliki anak buah. Pada kenyataannya, manajer bisa saja tidak memiliki anak buah. Peran manajer melekat pada diri seseorang karena ia berfungsi sebagai pengelola (baca: menyusun cara, menetapkan sumber daya, mengukur keberhasilan, melakukan improvisasi) sejumlah tugas. Sama-sekali tidak terkait dengan memiliki atau tidak memiliki anak buah.
Mempersyaratkan karakter manajer pada software developer itu wajar, karena developer adalah knowledge worker, bukan blue-collar worker. Oleh karena itu, software developer harus belajar berperilaku sebagai knowledge worker yang mengutamakan & mengembangkan pengetahuan serta karakter, ketimbang berperilaku seperti blue-collar worker yang mengutamakan tenaga dan jam kerja.
Tujuan
Self-organization dimulai dari kejelasan tujuan. Setiap crew harus paham tujuan tim (organisasi). Sebagai pemilik visi produk/project, maka Product Owner harus menyusun Product Backlog Item berdasarkan urutan manfaat bisnis. Development Team (DevTeam)bisa memberi masukan dari perspektif teknis, misalnya backlog item mana saja yang sebaiknya dikerjakan bersamaan agar pekerjaan dapat diselesaikan lebih cepat. Tanpa tujuan yang jelas maka progress pekerjaan tidak mungkin diketahui, apalagi diukur.
Di setiap sprint, tim menentukan backlog item mana yang dapat diselesaikan dalam 2 minggu mendatang (sprint backlog/goal). Merencanakan pekerjaan berdurasi 6 bulan bisa jadi sulit, tetapi merencakan pekerjaan berdurasi 2 minggu seharusnya masih masuk akal. Agar tim memperoleh cukup gambaran dalam menentukan sprint backlog sekaligus menghemat waktu sprint planning, maka satu sprint sebelum suatu sprint dimulai, tim perlu melakukan grooming atau backlog refinement. Misalnya, di akhir sprint 1, DevTeam perlu melakukan grooming yang rencananya akan dikerjakan pada sprint ke-2.
DevTeam lebih memahami cara kerja dan kapabilitas mereka sendiri, oleh karena itu mereka berhak memperkirakan (membuat estimasi) backlog item mana yang dapat diselesaikan pada sprint mendatang. Meski demikian, DevTeam harus mampu menjelaskan dengan baik alasan perkiraan tersebut kepada Product Owner (PO).
Secara alamiah, PO menginginkan sebanyak dan secepat mungkin backlog diselesaikan. Jika PO yang melakukan estimasi, maka bias kepentingan ini dapat mengakibatkan estimasi menjadi sangat optimistis bahkan tidak realistis. Kebalikannya, DevTeam secara alamiah menginginkan waktu yang cukup bahkan lebih. Jika DevTeam tidak wajib mempertanggungjawabkan estimasi, maka bias kepentingan ini akan mengakibatkan durasi pekerjaan menjadi berlebihan dan tidak kompetitif bagi bisnis.
PO dan DevTeam harus bekerja sebagai satu tim. Jika menerapkan KPI, maka keduanya harus berbagi prestasi secara identik. Dengan demikian, keduanya memiliki satu tujuan yang sama, yaitu memaksimalkan nilai dan jumlah keluaran, dengan mempertahankan situasi yang kondusif.
Cara
Tanpa koordinasi yang baik, maka sinergi tidak akan bisa tercapai. Masalahnya, kita sering mengidentikan koordinasi dengan kontrol. Seolah koordinasi berarti ada satu otoritas yang berhak mengatur bagaimana seluruhan tim bekerja.
Karena seluruh anggota DevTeam adalah “manajer”, maka mereka harus berperilaku sebagai manajer. Saat sprint planning, seluruh anggota DevTeam harus mau dan mampu memahami sprint goal. Dengan demikian, setiap crew berkontribusi dalam strategi eksekusi sprint. Beberapa orang mungkin lebih paham tentang suatu hal dibandingkan lainnya. Mereka bisa menjadi narasumber yang berharga. Rekan sesama crew yang semula tidak paham, bisa jadi mendapat pelajaran berharga saat proses perencanaan ini berlangsung. Diskusi aktif, dimana setiap ide dapat di-challenge akan memunculkan resiko-resiko yang semula tak tampak, bahkan memunculkan cara-cara baru yang semula tak terpikirkan.
Sebagai pemilik visi, peran PO menjadi sangat vital. PO harus mampu menjelaskan backlog item pada DevTeam. Perlu diingat, ada dua hal yang bisa membuat pekerjaan sulit diselesaikan. Pertama, tidak tahu apa yang mau dikerjakan. Kedua, tidak tahu bagaimana mengerjakannya. Kalau PO tidak paham apa yang ia inginkan, maka spesifikasi akan terus berubah tak terkendali. Kalau DevTeam tidak memiliki kompetensi membuat produk, maka waktu pelaksanaan pekerjaan mustahil dapat diprediksi. Keduanya akan mengakibatkan ketidakpastian akut, yang berujung moving target (target penyelesaian yang terus-menerus mundur). Sekali lagi, crew tidak perlu merencakan pekerjaan berukuran besar dan lama, cukup 2 minggu ke depan.
Dalam konteks manufakturing, desain produk dilakukan di awal, sehingga proses kontruksi hanyalah memproduksi benda yang sama secara berulang-ulang. Dalam konteks pengembangan software, seluruh proses kontruksi sebenarnya adalah proses desain. Developer tidak hanya mengulang-ulang pekerjaan, tetapi selalu berhadapan dengan pekerjaan yang berbeda dari satu modul ke modul lainnya. Hal ini menciptakan ketidakpastian. Adanya ketidakpastian bukan disikapi dengan menghindari estimasi, melainkan dengan mengelola ekspektasi stakeholder.
Eksekusi
Eksekusi adalah bagian terlama dibandingkan lainnya. Bagian ini yang paling menentukan apakah pekerjaan dapat diselesaikan atau tidak. Metode Self-organization berbeda dengan piramid karena tidak ada otoritas yang menentukan tugas harian setiap crew.
Selama sprint berlangsung, setiap crew harus memahami sisa pekerjaan dari perspektif tim, bukan dari perspektif dirinya semata. Setiap crew harus memiliki inisiatif untuk memilih sendiri task mana yang ia akan kerjakan dengan mempertimbangkan dampak bagi keseluruhan tim. Pada prakteknya, ini adalah bagian yang sulit. Developer yang terbiasa bekerja atas perintah TL seringkali tidak memiliki inisiatif dan hanya peduli dengan urusannya sendiri. Mantan TL pun seringkali terpancing untuk mengatur “siapa-mengerjakan apa”. Masalah ini wajar terjadi di tahap awal, tapi jangan dibiarkan berlarut-larut. Self-organized itu artinya tim mengelola sendiri, bukan setiap orang bekerja sendiri-sendiri, apalagi cuma mikirin maunya sendiri.
Tim mempraktekan scrum untuk meningkatkan “kelincahan”. Seluruh crew diharapkan berinteraksi secara aktif ketika memahami kebutuhan, melakukan desain, atau menguji aplikasi. Interaksi dilakukan secara langsung dan spontan tanpa perlu jembatan (orang yang mengatur). Buang jauh-jauh birokrasi yang menghambat, bekerjalah secara efektif: Lakukan yang perlu; jangan lakukan yang tidak/kurang perlu.
Dalam organisasi piramid, anggota tim cenderung membatasi diri pada bidangnya masing-masing. Self-organization biasanya dikombinasikan dengan prinsip cross-functional team. Hal ini memungkinkan crew mempelajari bidang lain dari rekannya. Crew dapat menguasai berbagai bidang secara general, dengan tetap mendalami bidang spesialisasinya sendiri, sehingga memiliki T-Shape skill.
Pengawasan dan Perbaikan
Umumnya organisasi memiliki mekanisme pengukuran kinerja dan process improvement. Indikator progress / kinerja sangat vital, tanpanya kita tidak tahu kapan bisa sampai tujuan. Ibarat berkendara dari Jakarta ke Bandung melewati tol Cipularang, sangat sulit untuk menentukan kapan sampai tujuan kalau tidak tahu sekarang kita ada di km berapa.
Mekanisme pengukuran haruslah akurat. Dalam metodologi waterfall, progress biasanya diukur berdasarkan porsi pekerjaan yang sudah diselesaikan. Jika setengah pekerjaan dan dokumen requirement sudah selesai, maka bisa dianggap 50% fase requirement berhasil dilaksanakan. Pada prakteknya, requirements yang salah, sulit terdeteksi. Umumnya project tidak terlambat di fase requirement atau design. Kebanyakan project terlambat di fase construction dan testing. Kenapa? Karena ketidakmampuan menghasilkan aplikasi di fase construction akan tampak jelas, dan error yang muncul di fase testing akan mudah diidentifikasi. Artinya, progress 50% fase requirements di atas sebenarnya tidak akurat.
Ukuran progress dalam scrum adalah penyelesaian backlog (yang sesuai standar Definition of Done) atau tepatnya, sisa backlog yang belum terselesaikan. Sisa backlog ini menunjukkan berapa banyak item harus dikerjakan untuk menyelesaikan tujuan yang telah ditetapkan. Demo working code saat sprint review jauh lebih akurat untuk digunakan sebagai ukuran progress.
PM dan TL adalah penanggung jawab utama dalam organisasi piramid. Oeh karena itu, bobot suaranya tentu berbeda dengan anggota tim lain. Tingkatan ini menghambat komunikasi dua-arah antara PM, TL, dan Tim. Tim biasanya tidak berani mengungkapkan kekesalan pada PM atau TL yang notabene adalah atasan mereka. Hal ini menjadi pelik bila sumber masalah sebenarnya adalah PM atau TL itu sendiri.
Sprint retrospective adalah saat yang tepat bagi tim untuk mencurahkan keluh-kesah, menetapkan solusi, dan mencari ide segar. Dengan tidak adanya tingkatan, diharapkan semua crew berani mengungkapkan ide dan masalah. Tidak mudah bagi seorang senior untuk menerima kritik dari juniornya. Namun jika sang senior mampu, maka organisasi akan mampu melesat lebih cepat. Follow-up dan kontinuitas hasil sprint retrospective ini perlu dijaga. Percuma memiliki ide apabila tidak konsisten dilaksanakan.
Kepemimpinan Dalam Self-Organization
Ketika beberapa orang berkelompok, secara alamiah akan ada satu orang yang secara de-facto menjadi pemimpin. Tidak terkecuali saat kelompok itu melabeli dirinya self-organized team. Kosa kata pemimpin masih terlalu umum, karena dalam dunia manajemen ada perbedaan antara boss dan leader seperti yang tampak dalam ilustrasi dibawah ini.
Sentralisasi kepemimpinan dalam organisasi piramid menyebabkan sang pemimpin memikul tanggung jawab terbesar. Prestasi atau kegagalan cenderung jadi miliknya. Untuk menghindari masalah, sang pemimpin bisa saja menutupinya dari pihak luar (misalnya customer). Misalnya, seorang PM menyatakan progress pekerjaan sudah 80% disaat sebenarnya hanya 40%. Pada saat bersamaan, ia meminta tim untuk mengejar ketertinggalan.
Sebagai leader dari suatu self-organized team, agenda utamanya adalah menciptakan transparansi. Transparansi berarti tujuan yang konkrit, cara (strategi) yang jelas, progress yang akurat, kompetensi tim yang gamblang, terungkapnya semua masalah, dan keluarnya semua ide dari lubang kubur 👻. Scrum Master umumnya diberi predikat sebagai servant leader yang berperan sebagai Process Coach, Protector, dan Problem Solver. Satu hal yang perlu dipahami, Coaching bukanah Training. Coaching hanya bisa dilakukan kepada crew yang telah memiliki kompetensi. Jika belum, crew tersebut harus diberi training.
Kembali ke Awal
Ok, mari kita kembali ke keluhan-keluhan di awal dan bayangkan apa kira-kira jawabannya :)
“Dulu sewaktu masih pakai struktur lama, biasa Technical Lead yang mengatur Pak. Jadi tugas setiap orang jelas dan ada yang ditakuti”.
S: “Product backlog sudah jelas?”
T: “Jelas Pak”
S: “Ow, ok. bagus kalau sudah jelas. Enak mana, kita bicarakan sprint backlog sama-sama biar yakin targetnya masuk akal atau mau di kasih aja targetnya dari PO? oya, kalau dari PO, ya terserah PO nya mau nuntut apa”
T: “Ya mending saya ikutan Pak”
S: “Kalau sprint backlognya jelas, setiap hari bisa nggak menentukan sendiri mau mengerjakan apa?”
T: “Mestinya sih bisa”
“Karena setiap orang merasa sejajar, jadinya orang susah dikasih tahu. Akhirnya kita kerja sendiri-sendiri aja”.
S: “Ok,Jadi semua crew sudah merasa paling pintar di bidangnya dan tidak perlu pendapat orang lain?”
T: “Ya enggak lah Pak”
S: “Owh, enggak gitu? Lain kali dikasih pendapat mau pertimbangkan?“
T: “mmmm.. Ya”
S: “Oya, Kita kan mengadopsi model cross-functional team, sudah pernah dengar tentang T-Shape skill? Coba googling”
“Setiap orang pilih-pilih kerjaan yang dia mau. Akibatnya kerjaan itu jadi saya terus yang mengerjakan.”
S: “Kalau kerjaanmu beres tapi kerjaan temanmu gak beres, nilai prestasimu akan lebih baik?”
T: “Enggak, kan shared KPI Pak”
S: “Kalau dia sakit, yang lain gak bisa menggantikan, terus mau gimana? pasrah aja kalau gagal gitu?”
T: “Ya enggak gitu juga sih Pak”
