Peran Ke-2 Trainer : Promote Behavior Change
N Kuswandi

Wave of change, ocean of opportunity - badai perubahan, lautan kesempatan, begitulah quote yang sangat relevan untuk era VUCA (volatil, uncertainly, complex, ambigu). Perubahan tersebut juga terasa di dunia Learning and Development. Deloit, sebagai multinational consultant bahkan menggambarkan secara masif, lima perubahan besar learning and development dalam 17 tahun terakhir (era elearning, era talent management, era continuous learning, era digital learning dan sebentar lagi akan muncul artificial learning). Artinya tiap 3.5 tahun sekali era learning telah berubah. Kalau diibaratkan "belum selesai belajar dan implementasi satu evolusi learning and development sudah berpindah ke evolusi berikutnya".

Ada yang memandang perubahan ini sebagai gelombang ancaman, namun ada juga yang memandang bahwa perubahan tersebut adalah lautan peluang. Dan orang-orang yang berselancar dalam lautam peluang dengan "embrace" tantangan kemudian disebut sebagai paradoc navigator.

Dalam konteks learning and development para paradoc navigator tersebut punya fleksibilitas untuk terus belajar, tak terkecuali membawa paradoc paradigma mendelivery learning and development. Kemarin saya telah share bahwa satu peran seorang facilitator adalah create safe learning environment. Maka dikesempatan kali ini saya ingin share tentang paradigma peran kedua seorang facilitator *Promote Behavior Change*. Peran ini menjadi kritikal, karena saat facilitatot mampu memainkan peran ini maka tujuan learning pada level ketiga (behavior change) dan level ke empat (business result) akan tercapai.

Ingat bahwa ilmu itu ibarat pohon yang kuat, dan buahnya adalah menjalankan ilmu tadi. Mengajarkan trainee kita tentang ilmu membuat mereka menjadi pohon yang kuat. Dan pohon yang kuat akan lebih bermanfaat saat berbuah. Bayangkan saja bagaimana merasa ruginya oranf yang membiayai pendidikan trainee namun perilaku trainee tidak berubah. Disinilah peran facilitator yang promote behavior change menjadi penting.

Sekarang bagaimana melakukan peran tersebut? Peran ini sebenarnya sangat erat kaitannya dengan ilmu influencing. Dan Anda bisa mengaplikasikan aneka pendekatan influencing yang telah dibuktikan dengan riset yang mumpuni. Dua tokoh psikologi yang memiliki pengakuan terhadap hal tersebut adalah Garry Yukl dan Cialdini.
Saya pernah membahas salah satu taktik Garry Yukl pada buku saya yang berjudul *Coaching Handbook* (satu satunya buku yang membahas coaching competenciea dari International Coach Fedetation), maka izinkan kali ini saya berbagi tentang salah satu jurus promote behavior change yang diperkenalkan oleh Cialdini. Dari riset yang dia lakukan, Cialdini menemukan enam cara menginfluence orang yaitu otoritas, rasa suka (perhatikan bahwa cara ini bisa dilakukan dengan mengimplementasikan create safe learning environment), timbal balik, kelangkaan, konsistensi dan bukti sosial.

*Bagaimana mengaplikasikan keenam cara influencing tersebut dalam kontek learning and development bisa dibaca di buku People Development Handbook*

Ingat kita punya peran membengaruhi, namun kesiapan perubahan perilaku bukanlah keputusan facilitator, namun seorang trainee. Bahkan Nabi Muhammad SAW sendiri sebagai tokoh yang paling berpengaruh di dunia tidak bisa mempengaruhi pamannya banyak membantunya, Abu Tholib. Hingga Allah SWT menurunkan ayat khusus terkait hal tersebut,
"Innaka la tahdi man ahbabta, walakinnallaha yahdi mai yasha'."
"Sesungguhnya kau takkan dapat memberi hidayah pada orang yang kau sayangi, tetapi Allahlah yang memberi hidayah kepada sesiapa sahaja yang Dia kehendaki (QS Al Qoshos 56-57)
Inilah yang juga menyebabkan peran seorang facilitator disebut sebagai Promote behavior Change. Karena peran kita sebagai seorang facilitator adalah promosi bukan change

Berkah selalu

Agile adalah satu prinsip dalam model project management yang sekarang ini banyak digunakan. Hal ini terkait dengan berkembangnya banyak produk teknologi, software produk, aplikasi, yang dikembangkan oleh startup yg menjamur. Jika dulu kita mengenal project management banyak digunakan untuk project konstruksi, building, dan bangunan fisik lainnya. Sekarang dengan trend perusahaan yang mengutamakan scalability dan low asset, maka perusahaan membangun “virtual asset” yaitu software as a service. Pendekatan project management yang digunakanpun ikut berubah, jika dulu mengikuti proses waterfall, sekarang mengikuti agile.

Pola waterfall mensyaratkan kita sudah memiliki “bangunan yang sudah jadi secara mental”. Yang kemudian dituangkan dalam produk requirement. Misalkan membangun rumah, kita sudah tahu persis bentuk rumahnya, bentuk tampilan muka dan belakang, pintunya dimana, jendela dimana, kamar ada berapa, tembok menggunakan material apa, pintu, jendela, ubin pakai material apa, tembok rumah dan dinding dalam rumah menggunakan cat apa, dsb. Kita sudah tahu persis perwujudan fisik rumah yang sudah jadi secara mental. Kemudian hal ini dituangkan dalam perwujudan product requirement dan spesifikasi.

Ada moto dalam project management waterall yaitu “no gold plating”. Tidak ada spesifikasi dan scope yang berubah saat project berjalan. Semuanya dikunci dan dituangkan dalam kontrak yang disepakati sebelum project dijalankan. Kemudian proses dijalankan mulai dari fase initiating, planning, executing, control, sampai closing. Tidak ada gold plating, tidak ada perubahan scope. Satu perubahan pada spesifikasi akan menimbulkan masalah ke project plan keseluruhan. Goal yang harus dicapai adalah On Quality, On Time, On Cost, dan On Scope.

Setiap fase dijalankan secara serial, mulai dari fase initiating ke planning dan seterusnya. Tidak ada turning back, karena akan mengganggu project secara keseluruhan. Di dalamnya kita juga mengenal knowledge areas yaitu management time, cost, scope, resources, quality, procurement, communication, risk, dsb. Saat pola waterfall ini diadopsi oleh project manager dalam membuat produk software maka masalah muncul. Software beda dengan produk fisik. Produk software memiliki requirement yang berkembang dengan sangat cepat seiring waktu. Software memiliki bug yang baru ditemui pada proses testing. Customer dari produk software ada banyak dan memiliki preference dan keinginan untuk customisasi. Bentuk akhir berupa user interface perlu diupdate mengikuti desain yang terbaru. Feature yang dibutuhkan terkadang baru diketahui tidak pada awal project. Dan sebagainya.

Sedemikan banyak masalah dan perbedaan antara produk software dan produk bangunan fisik, maka saat project management waterfall diadopsi oleh project manager maka muncul masalah-masalah berikut: Software banyak yang tidak selesai, banyak yang error saat delivery, banyak produk jadi yang membutuhkan rework, banyak software yang gagal dideliver, banyak software yang sudah dideliver ternyata akhirnya tidak dipakai, dan masih banyak masalah lainnya. Akhirnya para project manager berkumpul dan memikirkan perlu adanya pendekatan yang baru. Sampai akhirnya lahirlah Agile. Berbeda dengan waterfall, agile menggunakan prinsip iterasi. Produk tidak dibangun sekaligus besar, tetapi dibangun kecil-kecil tapi sering. Tujuannya adalah meminimalkan resiko diakhir project. Pola pengembangan software yaitu desain-build-test-release dipecah dalam banyak iterasi yang disebut sebagai sprint box.

Product final dengan feature lengkapnya juga dipecah-pecah menjadi produk kecil dengan fitur minim tapi bisa berjalan, yang disebut dengan  minimum viable product. Hal ini tidak memungkinkan untuk produk fisik konstruksi, tapi mungkin untuk produk software. Bayangkan jika waterfall kita membuat bangunan rumah, pertama kita buat fondasi dulu, kemudian dinding, kemudian atap, kemudian pintu dan jendela, kemudian finishing berupa pengecatan. Jika di agile, maka ilustrasinya adalah pertama kita bikin rumah burung dara, terus bikin rumah anjing, bikin rumah kuda, bikin rumah sederhana, sampai akhirnya bikin rumah mewah. Bentuknya tetap rumah dan berfungsi, tetapi fiturnya sedikit. Bangunan fisik hal ini tidak mungkin, tapi kalau membuat software hal ini mungkin.

Keuntungan yang didapat adalah: Produk akan lebih cepat terdeliver ke customer, jika ada kesalahan maka akan cepat dikoreksi, resiko juga akan lebih kecil karena kesalahan terdeteksi lebih awal, feature-feature baru dapat ditambahkan pada iterasi berikutnya, lebih uptodate dan mengikuti trend, secara bisnis akan menguntungkan karena ada produk yang sudah bisa dideliver, perubahan feature baru pada produk dan perbaikan bug akan masuk dalam update produk, ada kepastian kapan software akan dideliver, team development memiliki tanggungjawab yang jelas dalam mendeliver produk sesuai target waktu dan komitmen.

Kita mengenal ada 4 agile manifesto yaitu: deliverables produk lebih penting dibanding dokumentasi proyek, interaksi individu lebih pentiing dibanding proses tools, kolaborasi dengan customer lebih penting dibanding negosiasi kontrak, merespon perubahan dibanding hanya mengikuti plan. Ini yang membedakan agile dengan waterfall. Sedangkan metodologi yang digunakan mengikuti agile adalah scrum. Jika agile menjelaskan prinsipnya maka scrum menjelaskan organisasi dan prosesnya. Organisasi scrum terdiri dari 3 yaitu scrum master, product owner, dan team developer.

 Scrum master berperan sebagai coach, memastikan team mengikuti rule of the game, membantu meresolve masalah terkait proses scrum. Product owner adalah orang yang bertanggung jawab terhadap produk, mendeliver value ke pelanggan, mampu menyediakan resources, dan mengatasi hambatan selama proses development. Team member bertugas mendesain, build, memastikan kualitas produk, dan mendeliver produk tepat waktu. Ketiga peran ini mengikuti proses scrum secara iterasi mulai dari visioning, release planning, spesifikasi, sprint planning, daily standup, sprint review, dan retro.

Proses Visioning adalah membuat user stories untuk menjelaskan apa yang akan dibuat, untuk siapa dibuat, dan kenapa harus dibuat. User stories datang dari semua stakeholder mulai dari produk owner, customer, dan team developer. User stories ini dikumpulkan dalam suatu list yang disebut produk backlog. Salah satu artifact dalam scrum methodology. Produk backlog ini memprioritaskan user stories berdasarkan value terhadap customer. Prioritas dibagi menjadi 3 yaitu high, medium, low.  Setelah produk backlog selesai maka masuk ke tahapan release planning. Proses ini berupa meeting yang bertujuan merancang release dalam kotak2 sprint. Caranya adalah dengan mengumpulkan beberapa user stories ke dalam satu sprint box. Dengan catatan bahwa jika user stories tersebut dibuat maka akan menjadi satu deliverables. Meskipun itu baru bersifat minimal. Akhirnya semua akan dikelompokkan dalam beberapa sprint box dan memberi estimasi akan ada berapa kali sprint dan kapan akan dilakukan release. Setiap release akan memiliki rentang waktu tidak lebih dari 1 bulan. Baru kemudian akan disusul oleh release berikutnya.

Proses berikutnya adalah spesifikasi yaitu setiap user stories yang ada harus memiliki acceptance criteria, termasuk screenshotnya akan seperti apa. Tahapan spesifikasi adalah merinci requirement dari user stories. Karena spesifikasi ini akan dikunci saat masuk ke tahapan sprint. Proses berikutnya adalah sprint planning, yaitu membuat rencana pelaksanaan sprint. User stories yang ada akan diberikan estimasi waktu yang dibutuhkan untuk penyelesaian. Dan setiap penyelesaian maksimal adalah 8 jam. Jika lebih dari 8 jam maka akan dipecah menjadi beberapa task dengan waktu kurang dari 8 jam. Disini task sudah mencakup desain, coding, test, dan fine tune. Kemudian diberikan urutan task mana yang akan dikerjakan dulu.

Setelah sprint planning maka masuk ke tahapan pekerjaan sprint yang sesungguhnya. Setiap hari akan dimulai daily standup meeting di depan sprint planning board. Dimana ada task yang sudah direncanakan dan waktu yang dibutuhkan. Di dalam prinsip agile, ada komitmen dan tanggungjawab individu. Disini produk owner tidak melakukan assignment tetapi justru anggota team yang melakukan pull. Mereka mengambil tanggung jawab dalam menentukan task yang akan dikerjakan dan komitmen penyelesaian. Setiap daily standup meeting setiap anggota team development akan menyampaikan tiga hal yaitu: Apa yang kemarin sudah dikerjakan, Apa yang akan dikerjakan, Apa masalah yang ditemui jika ada. Hal ini untuk showcase apa yang sudah dikerjakan, dan memunculkan perasaan accomplishment, ownership terhadap work result, dan tidak ada informasi yang hilang selama proses. Daily standup meeting maksimal waktunya 15 menit. Jika ada masalah tidak dibahas dimeeting tapi harus diselesaikan secara offliine.

Setelah melakukan beberapa kali iterasi dalam sprint, maka akan sampai pada titik sprint tersebut selesai dan masuk ke proses sprint review. Sprint review adalah meeting untuk menunjukkan apa yang sudah dikerjakan dan mendapat feedback. Team akan mendemonstrasikan hasil sprint yang sudah ditest dan accept. Kemudian akan mendapat feedback atas pekerjaan mereka. Tahapan berikutnya adalah retro. Retro adalah meeting untuk mengevaluasi performance team. Bagaimana team bekerja, apa yang bagus dan apa yang perlu diimprove. Retro akan mengevaluasi laporan selama sprint seperti burn up chart dan burn down chart, berapa tugas yang selesai tepat waktu, berapa tugas masih tersisa, bagaimana performance individu, berapa jumlah defect, berapa kali test gagal, dan sebagainya. Hasil evaluasi ini akan dituangkan dalam action plan untuk perbaikan kinerja team. Proses sprint ini akan diulang terus-menerus, sehingga deliverables produk makin lama akan makin sempurna dengan update terbaru.

Sehingga bisa kita simpulkan Agile dan metode Scrum ini adalah focus pada deliverables yang cepat, meminimalkan resiko dengan frequent test inspection, align dengan kebutuhan customer yang terus berkembang, dan menekankan pada tanggungjawab serta komitmen dari anggota team. Pertanyaan yang sering muncul adalah apakah Agile Scrum ini dapat diimplementasikan untuk project non software? Jika kita melihat prinsip-prinsip dan proses yang dijelaskan, maka sangat mungkin untuk menerapkan Agile scrum untuk project non-software. Sudahkah anda mencoba menggunakan Agile?

Learn more about Agile & Lean at www.belajarlean.blogspot. co.id

Written by Riyantono Anwar

Apa peran seorang trainer? Ini adalah pertanyaan sejuta dolar. Karena dengan menemukan dan memahami jawaban pertanyaan ini akan membuat peran Anda sebagai seorang trainer menjadi lebih efektif. Jawaban pertanyaan ini bisa ditemukan dari hasil akhir yang diharapkan dari sebuah proses learning and development. Dan tujuan itu telah dipolakan dengan begitu cantik oleh seorang pakar learning and development bernama Kirkpatrik. Beliau memperkenalkan empat tujuan yang kemudian disebut sebagai empat level evaluasi Kirkpatrik. Level pertama adalah reaction, trainee bereaksi positif terhadap training yang diberikan. Level kedua adalah knowledge, setelah training trainee mendapatkan pengetahuan atau skill baru. Level ketiga adalah behavior change, ada perilaku baru sebagai dampak pengetahuan dan ketrampilan yang dipelajari. Dan level terakhir adalah result, perbubahan perilaku tersebut membawa dampak positif terhadap performance.

Dari empat evaluasi tersebut, jelaslah bahwa seorang trainer memiliki tiga peran utama. Peran pertama adalah create safe learning environment. Peran kedua adalah responds learner needs. Dan peran terakhir adalah promote behavior change.

Peran pertama, create safe learning environment sangat erat kaitannya dengan tujuan training level pertama, reaction. Perlu digarisbawahi bahwa safe learning environment tidak hanya berhubungan dengan keamanan fisik, namun juga keamaan psikologis. Tentunya Anda sering dengar dengan istilah "Emosi positif belajar efektif". Keamaan psikologis berhubungan dengan menciptakan suasana belajar yang mampu menumbuhkan emosi positif.

Saya ingin lebih dalam membahas tentang keamaan psikologis. Istilah "Keamaan Psikologis" digunakan oleh Amy Edmondson pada tahun 1996 di The Journal of Applied Behavior Science. Kemudian diadopsi oleh team People Analytics Google dalam project Aristotle. Para ahli perilaku karyawan Google tersebut ingin memetakan pola perilaku yang membuat 180 team memiliki indikator performance dan hubungan antar anggota team.

Pada awalnya mereka kebingungan mencari polanya. Sampai mereka menyadari bahwa mereka menggunakan indikator yang salah. Indikator awal yang mereka gunakan adalah siapa orang-orang yang akan jadi bagian team yang baik, dari latar belakang apa, kepribadiannya seperti apa. Namun pola yang mereka temukan tidak saling berhubungan. "Siapa" yang berada dalam team tidak menjadi hal yang penting untuk menciptakan team yang baik. Hingga akhirnya, team people analytics mengukur dari indikator uang berbeda, yaitu "bagaimana". Mereka menemukan bahwa norma norma kelompok berperan kritis dalam pembentukan pengalaman emosional dan performance team.

Penemuan ini memunculkan pertanyaan baru, "norma seperti apa?" Dan pertanyaan itu yang dijawab Edmondson pada tahun 1999. Norma tersebut adalah "Keamanan Psikologis" - sebuah perasaan yakin tidak akan dipermalukan, ditolak, ataupun dihukum oleh anggota team yang lain karena angkat bicara.

Mari kita bawa dalam kontek training. Positif reaction sebagai salah satu tujuan training tidak akan tercapai kalau ada peserta yang merupakan anggota team pembelajaran merasa dipermalukan, ditolak, ataupun dihukum. Benar bahwa tempat yang bagus, makanan yang enak, slide yang bagus akan memunculkan positive reacrion. Namun semua itu akan hilanh seketika saat keamanan psikologis tidak tercipta. Sehingga dari awal training berlangsung, sudah menjadi peran wajib seorang trainer untuk Create Safe Learning Environment.


N Kuswandi