Agile Manifesto & Principles
Mari kita mulai tulisan ini dengan sebuah pertanyaan? Mengapa kita membutuhkan pendekatan yang berbeda dalam menjalankan suatu project? Bukankah pengertian project dan framework yang selama ini kita ketahui sudah ada di dalam PMBOK?
Jawaban simpelnya adalah setiap project membutuhkan pendekatan yang berbeda. Yup, seperti yang kita tahu, project itu unik. “Is there a silver bullet project management methodology?”
Jika kita menarik kembali ke belakang dimana manusia pada awalnya adalah pengembara yang selalu berpindah-pindah dan akhirnya menetap menjadi makhluk sosial dan bercocok tanam. Peradaban inilah yang kita sebut dengan istilah Agricultural Revolution. Transformasi berikutnya adalah munculnya mesin-mesin yang mengubah tata cara manusia bekerja, dan manusia mulai berpindah dari desa menuju kota. Situasi seperti ini yang kita kenal dengan Industrial Revolution. Pada tahap inilah muncul konsep Project Management yang masih kita gunakan hingga saat ini dimana tool Work Breakdown Structure (WBS) dan Gantt Chart menjadi tool wajib yang harus digunakan oleh Project Manager. Tahap terakhir, dimana kita berada saat ini, yang kita sebut dengan Information Revolution mulai fokus ke hal-hal yang berhubungan dengan informasi dan kolaborasi. Menempatkan proses empiris sebagai proses yang berkelanjutan dalam pembuatan barang dan jasa. Orang-orang yang terlibat dalam proses ini disebut juga sebagai Knowledge Workers atau Subject Matter Expert (SME).
Ketika project Knowledge Work semakin banyak ditemui dan menjadi umum, orang-orang mulai menemukan cara bagaimana mereka berkomunikasi dan berkolaborasi di dalam project-project yang menuntut requirements berubah dengan cepat dan sulit didefinisikan di awal project. Pendekatan Agile mulai dikembangkan untuk merespon permasalahan ini. Awalnya pendekatan ini dijalankan di project-project Software Development, tetapi saat ini mulai digunakan di berbagai jenis industri.
Cara lain membedakan Industrial Work dan Knowledge Work adalah dengan melihat bagaimana cara mendefinisikan sebuah kebutuhan dari suatu project. Industrial Work umumnya adalah proses yang kebutuhannya sudah pasti sehingga bisa kita definisikan langkah-langkah pengerjaannya di awal Project. Sedangkan Knowledge Work lebih mengedepankan proses empiris dimana cara menjalankan suatu project diperoleh dari hasil observasi, atau juga berbagai percobaan. Pendekatan Agile akan terasa manfaatnya untuk project-project yang masuk ke dalam Knowledge Work ini.
— Agile Manifesto & Principles —
Agile Manifesto dan Principles adalah jawaban dari tantangan yang dihadapi oleh metodologi Waterfall pada tahun 90an, dimana kebutuhan bisnis pada saat itu tidak dapat diimbangi dengan deliverable product yang diinginkan Customer/ Client ataupun User.
Pada tanggal 11-13 Februari 2001, tepatnya di “The Lodge” yang berlokasi di “Snowbird Ski Resort” pegunungan Wasatch, Utah, 17 orang bertemu untuk berdiskusi, bermain ski, bersantai, dan mencoba untuk menemukan kesamaan. Melahirkan sebuah “Agile Manifesto” sebagai perwujudan yang mewakili Extreme Programming, Scrum, DSDM, Adaptive Software Development, Feature-Driven Development, Pragmatic Programming dan beberapa alternatif Software Development. Ketujuhbelas orang tersebut adalah:
Kent Beck | Mike Beedle | Arie van Bennekum | Alistair Cockburn | Ward Cunningham | Martin Fowler | James Grenning | Jim Highsmith | Andrew Hunt | Ron Jeffries | Jon Kern | Brian Marick | Robert C. Martin | Steve Mellor | Ken Schwaber | Jeff Sutherland | Dave Thomas
— 4 Agile Manifesto —
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Individuals and interactions over processes and tools
Project dibuat oleh people, bukan tools. Masalah diselesaikan oleh people, bukan process. Seperti halnya project diterima oleh people, scope didiskusikan oleh people, dan definisi dari suatu project telah selesai juga dinegosiasikan oleh people. Ini bukan berarti bahwa process dan tools tidak membantu dalam suksesnya suatu project. Kita hanya memberikan suatu fokus terhadap interaksi individu-individu di dalam project.
Working software over comprehensive documentation
Value ini memberikan fokus bagaimana tujuan dari suatu bisnis adalah membuat produk atau jasa, dibandingkan dokumentasi atau paperwork. Pendekatan Agile melihat dokumentasi sebagai sesuatu yang “just enough, just in time, dan just because“. Just enough berarti cukup untuk menggambarkan kebutuhan suatu project. Just in time berarti dibuat pada saat last responsible moment atau ketika dokumentasi itu memang benar-benar siap dibuat. Jadi kita tidak perlu waktu ekstra untuk membuat dokumentasi tersebut tetap updated sebagai requirements ataupun perubahan design. Sedangkan just because berarti dokumen tersebut dibuat jika diminta atau dibutuhkan.
Customer collaboration over contract negotiation
Value ini mengingatkan kita pentingnya fleksibilitas daripada sesuatu yang pasti atau tidak bisa diubah sama sekali. Kita biasanya membuat sesuatu berdasarkan kebutuhan yang pasti di awal, tapi jika Customer membutuhkan perubahan atau ada perubahan prioritas, akan lebih baik jika kita siap untuk mengakomodasi perubahan tersebut. Menjadi fleksibel dan berusaha untuk membuat tujuan baru daripada harus “memaksakan” diri dengan kebutuhan awal. Kebutuhan bisnis terkadang berubah dengan cepat dan teknologi semakin canggih. Salah satu cara beradaptasi dengan perubahan yang cepat adalah dengan menerima perubahan tersebut. Kolaborasi ini membutuhkan trust relationship dan model kontrak yang mengakomodasi perubahan.
Responding to change over following a plan
Value ini mengingatkan kita bahwa perubahan tidak bisa dihindari dalam Knowledge Work. Daripada energi kita dihabiskan untuk memastikan bahwa project harus sesuai dengan kebutuhan awal, akan lebih baik jika kita siap merespon perubahan tersebut. Bukan berarti kita harus mengabaikan planning yang sudah dibuat. Kita tetap membutuhkan planning, tetapi juga harus tahu bahwa initial plans dibuat berdasarkan pengetahuan kita di awal suatu project dan akan tetap di-update seiring project berjalan.
— 12 Principles —
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Prinsip ini memiliki 3 poin penting. Pertama adalah memuaskan Customer. Kunci dari keberhasilan suatu project adalah Customer puas dengan hasil project dan sesuai dengan kebutuhan Customer itu sendiri. Poin kedua adalah early and continuous delivery. Proses dari Software Development adalah membuat value sedini mungkin (early) dan sesering mungkin (frequently). Biasanya orang akan cenderung menolak jika membuat sesuatu yang belum selesai dan harus ditunjukkan kepada orang lain. Akan tetapi jika kita bisa mendapatkan feedback, problem ataupun issue di awal akan lebih baik jika dibandingkan di akhir-akhir project. Poin terakhir adalah valuable software. Yup, fokus dari Software Development adalah value dari software itu sendiri. Tujuan akhirnya bukan project itu selesai sesuai dengan planning atau dokumentasi. Tujuan akhirnya adalah membuat suatu produk atau jasa yang memiliki nilai bagi Customer.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Dalam project-project yang sifatnya predictive, change bisa diartikan sesuatu yang negatif. Change bisa dianggap sebagai “scope creep” atau project yang tidak sesuai dengan planning. Change harus melalui prosedur sebelum akhirnya change tersebut dapat diterima atau tidak. Proses change management yang kaku menjadi masalah ketika berhadapan dengan lingkungan yang cepat berubah seperti Software Development. Agile menganggap bahwa perubahan tidak bisa dihindari. Faktanya di XP (Extreme Programming) menganut “we embrace change“. Agile menggunakan pendekatan yang “lightweight” dan “high visibility“, artinya proses perubahan prioritas akan selalu ada selama product dibuat. Perubahan prioritas ini akan di-update ke dalam “backlog“. Dengan menerima perubahan, secara tidak langsung kita juga mempersiapkan diri bagaimana menemukan cara yang efisien ketika berhadapan dengan perubahan tersebut.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Terlepas dari niat baik kita dalam membuat sesuatu, kita secara alamiah cenderung untuk tidak memberikan sesuatu yang belum siap atau lengkap kepada orang lain. Iya apa iya? Pendekatan untuk deliver software secara sering adalah untuk mendapatkan feedback di awal, daripada harus berjalan jauh tapi ternyata kita berada di track yang salah. Tujuan dari deliver software dengan timeframe yang singkat adalah mendapatkan feedback dengan cepat apakah software yang dibuat memang sesuai dengan kebutuhan Customer.
Business people and developers must work together daily throughout the project.
Bekerja bersama perwakilan atau orang-orang Business secara harian bisa membuat kita belajar bagaimana cara membuat atau mengumpulkan requirements. Hasilnya, kita bisa memberikan saran terhadap solusi atau pilihan-pilihan dari permintaan Business team. Jika interaksi secara harian sulit untuk dilakukan, kita bisa membuatnya lebih fleksibel. Misalnya dengan membuat working group secara berkala yang bisa kita tentukan sendiri dengan Business team. Kolaborasi dengan Business team sangat penting untuk menjaga semua team members “on the same page” dalam proses development.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Karena Development Team adalah salah satu faktor penting dalam prosess development, Agile mengedepankan proses empowering. Team akan bekerja lebih baik jika mereka diberikan kebebasan untuk mengatur dan merencanakan pekerjaan mereka sendiri. Agile membebaskan team dari micromanagement. Sebaliknya, memberikan perhatian terhadap peer collaboration dan teamwork, yang menghasilkan tingkat produktivitas yang lebih tinggi.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Face-to-face communications memungkinkan kita untuk mentransfer informasi secara cepat dengan cara yang lebih beragam mencakup emosi dan bahasa tubuh. Dengan face-to-face communications, pertanyaan-pertanyaan dapat dijawab dengan segera daripada harus disimpan terlebih dahulu dengan harapan akan ada penjelasan atau jawaban nantinya. Tentu saja, rekomendasi face-to-face communications tidak bisa diaplikasikan di semua project, tetapi Agile Team perlu untuk melakukan ini jika memungkinkan. Dengan face-to-face kita juga mendapatkan keuntungan dari osmotic communication, dimana kita bisa mendengarkan secara tidak langsung (overhearing) informasi yang sedang dibicarakan oleh team di satu ruangan yang sama.
Working software is the primary measure of progress.
Dengan mengadopsi working software (atau bisa juga working system) adalah ukuran utama dalam mengukur suatu progress, maka fokus kita adalah hasil dari working software daripada fokus ke dokumentasi atau desain. Dengan working software kita menghasilkan results-oriented dalam suatu project. Jadi kita akan lebih fokus dalam proses utama sebuah feature development, yaitu membuat sebuah product yang bisa memberikan value ke Customer.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Agile berusaha untuk memaksimalkan value dalam jangka panjang dengan cara mengenalkan sustainable pace yang memungkinkan team untuk mengatur work-life balance mereka. Sustainable pace tidak hanya baik untuk team, tetapi juga untuk organisasi atau perusahaan. Hasilnya, team menjadi lebih happy, lebih produktif, dan hubungan kerja menjadi lebih baik.
Continuous attention to technical excellence and good design enhances agility.
Sementara development team bekerja keras untuk men-deliver banyak value, kita juga harus aware bahwa menjaga desain tetap clean, efficient dan open to change, harus menjadi perhatian kita. Technical excellence and good design memungkinkan Development Team untuk memahami dan memperbaharui desain dengan lebih mudah. Agile Team membutuhkan keseimbangan dalam deliver value dan design. Keseimbangan ini memungkinkan product dapat di deliver dalam jangka panjang tanpa kesulitan untuk me-maintain, change atau extend. Salah satu cara yang bisa dilakukan adalah dengan memberikan waktu yang cukup kepada Development Team untuk melakukan refactoring.
Simplicity–the art of maximizing the amount of work not done–is essential.
Agile fokus dalam simplicity untuk mengurangi feature-feature yang tidak terpakai dan berpotensi tidak bertahan lama. Project yang complex cenderung meningkatkan risiko dan berpotensi meningkatkan kegagalan. Agile mencari apa yang bisa kita kerjakan terlebih dahulu atau elemen paling mendasar apa yang bisa kita deliver ke Customer. Pendekatan ini bukan berarti kita mengesampingkan further extension dari sebuah product, tetapi lebih ke “vanilla version built” terlebih dahulu. Pendekatan ini tidak hanya dapat memitigasi risiko, tetapi juga membantu meningkatkan sponsor confidence.
The best architectures, requirements, and designs emerge from self-organizing teams.
Kebanyakan orang menyukai self-organize. Ini memungkinkan mereka untuk mencari pendekatan yang cocok dengan metode, interaksi, dan juga lingkungan mereka. Architecture, requirements, dan design akan menghasilkan yang terbaik jika diimplementasikan oleh orang-orang yang membuatnya, karena mereka mempunyai kebebasan dalam menghasilkan ide-ide dan technical details dalam suatu project. Hasilnya, team dapat dengan cepat mengenali suatu issue dalam proses implementasi, sekaligus sebagai kesempatan dalam proses improvement.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Mengadakan sesi lesson learned di akhir suatu project bisa dibilang telat. Agile mengedepankan proses lesson learned selama itu bisa diaplikasikan dan dapat dilakukan. Artinya, kita bisa melakukan lesson learned selama project berlangsung, dan yang paling penting adalah kita melakukan sesuatu dari proses pembelajaran tersebut. Retrospective adalah sebuah refleksi terhadap apa yang sudah kita kerjakan dan mengidentifikasi kesempatan untuk lebih baik lagi. Umumnya Retrospective dilakukan di akhir iterasi untuk memastikan sebuah team mendapatkan kesempatan untuk me-review proses yang sudah dilakukan. Salah satu keuntungan kita melalukan Retrospective secara berkala adalah kita tidak lupa terhadap problems atau issues.
Referensi:
- https://agilemanifesto.org
- https://www.atlassian.com/agile/manifesto
- https://www.leadinganswers.com
- PMI ACP Exam Prep by Mike Griffiths
One Response to “Agile Manifesto & Principles”
[…] tulisan sebelumnya mengenai Agile Manifesto and Principles, saya banyak menyinggung mengenai Value. Yup, Value adalah komponen inti di Agile. Konsep ini […]