Value Driven Delivery

By vlado, September 10, 2021

Di tulisan sebelumnya mengenai Agile Manifesto and Principles, saya banyak menyinggung mengenai Value. Yup, Value adalah komponen inti di Agile. Konsep ini selaras dengan salah satu Agile Mindset yang menyatakan bahwa “Working software over comprehensive documentation“, dan Agile Principle yang menyatakan “Working software is the principal measure of progress“.

Apa yang dihasilkan dari Project? Tentu saja Project menghasilkan Business Value. Business Value disini bisa berupa product, services, regulatory, compliance, atau apapun yang memiliki nilai tambah bagi organisasi atau perusahaan. Nah, Business Value tadi datangnya dari Sponsor. Kita sebagai Project Manager tentunya memiliki pertimbangan-pertimbangan tertentu dalam menjalankan suatu project, seperti business risk, pemilihan feature apa saja yang akan di release, jadwal implementasi dan biaya yang dikeluarkan. Apa yang tidak disadari oleh Sponsor tersebut menjadi awareness bagi Project Manager. Value Driven Delivery bisa menjadi semacam panduan bagi seorang Project Manager dan juga Stakeholders dari proses Planning, Execution dan Monitor/ Control.

Dalam konsep Value Driven Delivery di Agile, Risk dianggap sebagai Anti-Value. Ibarat dua sisi mata uang, satu sisi adalah Value, sisi yang satunya lagi adalah Risk. Artinya untuk memaksimalkan sebuah Value, maka kita perlu menekan Risk. Ya, pasti teman-teman lagi membayangkan mindset Risk Management di PMP dimana risiko bisa berarti positif dan negatif. Kalau saya melihatnya positif risk di Risk Management, bisa kita ubah mindsetnya menjadi opportunity untuk memaksimalkan Value.

Agile mengedepankan early value delivery. Ini bertujuan untuk men-deliver Value tertinggi dari suatu project sesegera mungkin. Alasannya adalah time to market. Semakin lama kita menjalankan suatu project, ada kemungkinan semakin besar risiko kegagalan yang terjadi, berkurangnya manfaat dari feature yang di release, atau bisa juga kehilangan peluang dari market/ user. Jadi untuk bisa memaksimalkan kesuksesan, usahakan untuk men-deliver “the highest value” sebanyak mungkin dan sesegera mungkin.

 

Assessing Value

Dari kacamata Business, penilaian sebuah project biasanya dilihat dari financial ramifications atau financial metric, seperti return on investment (ROI), present value (PV), net present value (NPV), dan internal rate of return (IRR).

Untuk melakukan progress monitoring, kita bisa menggunakan Earn Value Management (EVM). Hanya saja penggunaan EVM perlu dilakukan dengan penuh kehati-hatian karena EVM membandingkan actual project performance dengan planned project performance. Baseline menjadi faktor kesuksesan dalam penggunaan tool ini. Di Agile kita tahu bahwa initial plan bisa saja berubah, dan penggunaan EVM akhirnya menjadi tidak akurat. Lantas kenapa masih menggunakan EVM? Karena EVM adalah leading indicator yang bisa memprediksi completion dates dan juga final cost. Selain itu, EVM juga tool yang visual. Umumnya orang dapat dengan mudah memahami sesuatu dengan hal-hal yang visual. Penjelasan secara visual dapat membantu team secara kolaboratif.

Untuk memaksimalkan Value, team perlu untuk mempertimbangkan risiko dan ketergantungan teknis, dan menginfokan dampak yang terjadi ke Stakeholder atau Customer. Salah satu cara untuk mengurangi risiko adalah dengan iterative development. Feature atau Story yang memiliki risiko tertinggi dapat diatasi di awal iterasi. Tool penting yang dapat digunakan oleh team untuk me-manage risiko adalah dengan menggunakan risk adjusted baclog dan risk burndown chart. Kedua tool tersebut membantu team dalam menentukan prioritas risk response ke dalam development backlog.

Salah satu hal yang penting dalam proses Value Assessment adalah Compliance atau Regulatory. Umumnya requirements yang menyangkut Regulator dan Compliance tidak bisa dinegosiasikan, dan menuntut dokumen spesifik yang harus disiapkan oleh project team. Ada dua pendekatan yang bisa kita lakukan terkait  dengan Compliance, yaitu memasukkan compliance documentation ke dalam proses development, atau membuat compliance documentation setelah product atau feature selesai dibuat. Dari dua pendekatan tersebut, kita juga bisa menggabungkan keduanya, yaitu dengan memiliih beberapa komponen penting yang berkaitan dengan compliance, team lalu men-develop dan mengetes komponen tersebut sampai benar-benar sesuai dengan requirements. Kemudian ketika seluruh pekerjaan sudah selesai, team bisa membuat final documentation.

 

Prioritizing Value

Prioritisasi adalah proses fundamental di Agile. Untuk memahami hal ini, kita bisa melihat kembali salah satu pernyataan Agile Principle, “welcome changing requirements, even late in development”. Ini bukan sekadar teori, melihat kenyataan di project yang kita kerjakan sehari-hari dimana semua project dianggap prioritas oleh Stakeholders (sambil menganggukan kepala). Agile team menggunakan Prioritization sebagai konfirmasi kalau mereka men-deliver sebuah Value. Jika Customer diajak untuk melakukan prioritisasi secara terus menerus, mereka akan terbiasa untuk menempatkan feature yang sesuai dengan kebutuhan mereka.

Banyak cara melakukan prioritisasi. Dalam pendekatan Scrum, terdapat “product backlog“, FDD memiliki “feature list“, dan DSDM memiliki “prioritized requirements list“. Idenya adalah sama. Team bekerja berdasarkan list dan memastikan mereka mendeliver value berdasarkan highest-value.

Di Agile tidak terdapat skema prioritisasi secara spesifik. Masing-masing team memilih cara berdasarkan apa yang mereka butuhkan di dalam project dan pekerjaan terbaik yang bisa team berikan kepada organisasi atau perusahaan. Secara sederhana, mungkin prioritas bisa kita susun berdasarkan Prioritas 1, Prioritas 2, dan seterusnya. Atau bisa juga Low, Medium, dan High. Tetapi cara sederhana tersebut menimbulkan masalah karena tidak ada standard atau guide, apa yang membuat prioritas tersebut masuk dalam kategori Low, Medium dan High.

1. MoSCoW. Skema prioritisasi MoSCoW dipopulerkan oleh DSDM, yang merupakan singkatan dari susunan kata: Must have, Should have, Could have, dan Would like to have but not this time. Must have Requirements adalah fundamental dari suatu feature. Feature tidak memiliki value tanpa requirements Must have ini. Should have adalah feature yang sangat penting. Could have adalah additional feature yang bisa memiliki nilai tambah. Sedangkan Would have adalah “nice to have“.
2. Kano Analysis. Skema prioritisasi Kano terbagi kedalam 4 kategori, yaitu: Delighters/ Exciters, Satisfiers, Dissatisfiers, dan Indiffirent. Project Stakeholders menggunakan Kano Analysis untuk melihat dan memahami bagaimana hubungan antara kebutuhan dan kepuasan Customer. Delighters/ Exciter adalah kebutuhan Customer yang jika tidak kita berikan sebenarnya tidak menimbulkan ketidakpuasan, tetapi jika kita berikan Customer akan sangat puas. Satisfiers bisa dikategorikan sebagai “the more the better” dimana Customer akan semakin puas jika feature yang diberikan juga semakin baik. Dissatisfiers adalah kebutuhan dasar atau wajib dipenuhi. Sedangkan Indiffirent adalah kategori dimana Customer tidak peduli terhadap feature yang ada.

 

Delivering Incrementally

Incremental Delivery merupakan cara yang digunakan dalam pendekatan Agile untuk memaksimalkan value. Dengan incremental delivery, team secara berkala me-release suatu hasil development ke Customer. Artinya apa yang di release benar-benar bisa digunakan dan ada manfaatnya bagi Customer.

Di Agile kita mengenal istilah MVP (Minimal Viable Product) dan MMF (Minimal Marketable Feature) untuk melihat bagaimana suatu feature bisa diimplementasikan dengan kondisi market saat ini (time to market).

 

Agile Contracting

Agile team perlu memastikan ketika bekerja dengan vendor dan stakeholders dari eksternal, mereka sudah siap bekerja di lingkungan Agile. Kontrak adalah salah satu hal yang sangat penting karena menyangkut mengenai requirements dalam suatu project. Jika dirasa ragu, tanyakan ke vendor apakah sudah pernah bekerja di lingkungan Agile. Hal ini penting untuk mempertimbangkan cost-benefit trade-off yang mungkin saja terjadi di dalam project. Akan menjadi suatu masalah jika Agile Team bekerja dengan requirements yang mungkin saja berubah, tetapi vendor bekerja dengan traditional contracts/ fixed price.

Pendekatan Agile untuk menjembatani perbedaaan ini adalah dengan kolaborasi. Agile Manifesto ketiga, “Customer Collaboration over Contract Negotiation” menjadi mindset bahwa cara terbaik untuk men-deliver suatu value adalah dengan kolaborasi antara kedua belah pihak. Dalam arti lain, Agile lebih mengedepankan “trust“, daripada sebuah traditional contract.

Berikut adalah beberapa tipe contract yang bisa digunakan di dalam project-project Agile.

1. Money for Nothing and Change for Free. Kontrak yang dikenalkan oleh Jeff Sutherland ini adalah kita bisa menggunakan kontrak Fixed Price dimana di dalamnya terdapat kontrak Time & Material untuk tambahan pekerjaan dengan memasukkan klausul Change for Free. Customer dapat menggunaakan klausul Change for Free jika Customer bekerja sama dengan Team di setiap Iterasi.  Product Owner akan melakukan prioritisasi di setiap akhir iterasi. Customer bisa memasukkan new feature dan mengeliminasi low feature di dalam product backlog. Sedangkan untuk kontrak Money for Nothing, Customer bisa memberhentikan suatu project jika mereka merasa bahwa features yang diimplementasikan sudah cukup memberikan value bagi mereka. Customer bisa mendapatkan value terbaik mereka, project bisa selesai dengan cepat, dan vendor bisa mendapatkan full payment.
2. Graduated Fixed Price Contract. Tipe kontrak ini dikenalkan oleh Thorup and Jensen. Di kontrak ini, Customer dan Vendor berbagi risk dan reward dengan variasi schedule. Thorup and Jensen menyarankan menggunakan perbedaan hourly rates berdasarkan: on early, on time, dan late delivery. Jika Vendor bisa menyelesaikan project dengan on time, maka mereka akan dibayar dengan standard rate. Jika lebih cepat mereka dibayar dengan rate yang lebih tinggi, dan jika telat maka dibayar dengan rate yang lebih rendah. Customer akan merasa senang jika value bisa di deliver lebih cepat, dan Vendor juga akan senang karena dibayar lebih tinggi dari standard rate. Tapi, kedua duanya tidak akan senang jika project ternyata telat. Customer bisa kehilangan time to market, dan Vendor dibayar lebih rendah.
3. Fixed Price Work Packages. Tipe kontrak ini digunakan untuk memitigasi risiko dari underestimating atau overestimating setiap work packages. Dengan kontrak ini, Customer bisa melakukan re-prioritize sisa work packages di project berjalan berdasarkan biaya yang sudah dikeluarkan.
4. Customized Contract. Customer dan Vendor bisa menggunakan beberapa kombinasi dari ketiga kontrak di atas yang bertujuan untuk kolaborasi dan relationship dari kedua belah pihak.

 

Verifying and Validating Value

Pendekatan Agile umumnya digunakan di project-project yang intangible (design, software). Karena intangible, maka sangat penting untuk memvalidasi apa yang sedang kita kerjakan, apakah masih on track atau mempunyai business value.

Dari gambar diatas menjelaskan “what on person describes is often very different from how to interprets it“. Perbedaan ini sering disebut dengan istilah “gulf of evaluation“, yang disebabkan communication failure dalam menjelaskan sesuatu yang intangible. Karena sering terjadi perbedaan tersebut, maka penting untuk dapat dicari perbedaan tersebut sedari awal. Salah satu teknik yang digunakan dalam pendekatan Agile adalah dengan menggunakan testing secara regular, checkpoints, dan review untuk mengidentifikasi masalah sebelum menjadi besar. Proses testing & verification di software development bisa menggunakan Exploratory Testing and Usability Testing, Continuous Integration, dan Test-Driven Development/ Acceptance Test-Driven Development.

 

Referensi:

• https://agilemanifesto.org
• https://www.leadinganswers.com
• PMI ACP Exam Prep by Mike Griffiths

This site uses Akismet to reduce spam. Learn how your comment data is processed.