Jawaban ini ditulis dari sudut pandang seseorang yang memiliki sistem manajemen kinerja seperti itu ditempatkan di sekitar tim Agile; seperti Anda, semua orang di tim menyadari kesulitan / kegunaan dari tujuan SMART selama setahun yang diterapkan pada kelompok Agile, di mana, ketika berfungsi penuh, penerapan Agile dapat dianggap secara inheren / sudah SMART.
Tidak benar-benar! Panggil berikut rasionalisasi jika Anda perlu (jika logika setengah matang ...), tetapi menjelaskannya kepada pengulas di luar organisasi langsung telah menetapkan panggung untuk "tujuan" yang sebenarnya kita masukkan ke dalam sistem manajemen kinerja.
- S untuk spesifik : selama setiap perencanaan sprint, tim menyetujui serangkaian tugas khusus untuk dicapai, dan berkomitmen untuk melakukannya. Tugas (dan kisah pengguna), menjawab pertanyaan tentang apa yang ingin saya capai, tujuan / manfaat dari mencapai tujuan, siapa yang terlibat, di mana itu terjadi, dan kendala.
- M untuk terukur : daftar tugas ini, ditambah pergerakan tiket di seluruh sprint, dari pengembangan ke peninjauan kode ke QA untuk dirilis (atau apa pun aliran Anda), menjawab pertanyaan tentang seberapa banyak pekerjaan dan kapan akan diselesaikan .
- A untuk dapat dicapai : kelompok Agile yang berfungsi biasanya tidak berkomitmen pada sesuatu dalam tahap perencanaan kecuali jika itu jelas dapat dicapai - semua bagian ada untuk mengetahui bagaimana mencapainya
- R untuk relevan : pertanyaan seperti apakah itu berharga, apakah ini waktu yang tepat, apakah itu cocok dengan upaya kami yang lain - cerita dan tugas tidak ditarik ke dalam sprint, dan berkomitmen untuk, kecuali jawabannya adalah ya untuk semua pertanyaan ini ( biasanya ... YMMV)
- T untuk batas waktu : sprint harus terikat waktu, baik itu 2 minggu, 3 minggu, lebih, atau kurang.
Jika Anda memahami / meyakinkan diri sendiri bahwa pekerjaan triwulanan Anda (dan dengan demikian pekerjaan sepanjang tahun Anda) itu sendiri adalah satu tujuan SMART yang besar, dan bahwa Anda tahu Anda mencapai tujuan Anda karena tim berkinerja baik, kecepatannya positif, pelepasan terjadi. , lalu Anda sampai ke titik pertanyaan Anda, yang pada akhirnya adalah bagaimana menerjemahkan proses SMART ke dalam serangkaian tujuan SMART untuk kepentingan orang lain.
Saya sudah bisa melakukan ini dengan sukses di masa lalu dengan menulis sesuatu yang bagi saya terlihat samar-samar dan, yah, tidak terlalu SMART, tetapi sebenarnya bisa diterima oleh orang lain.
Beberapa contoh yang telah saya lakukan di tempat lain:
"Saya ingin merilis versi baru dari WidgetMaker setiap tiga bulan di tahun berikutnya, dengan mengikuti proses pengembangan perangkat lunak internal kami, untuk menyelaraskan dengan jadwal pengembangan produk secara keseluruhan (bla bla)."
"Saya ingin meningkatkan kecepatan pengembangan tim sebesar n% dari rilis A ke rilis B, dengan fokus pada perubahan bertahap pada proses perawatan backlog, untuk meningkatkan efektivitas kami dan mengurangi keterlambatan pengiriman produk."
Anda tahu dan saya tahu bahwa ini bukan prinsip panduan dari grup pengembangan Anda yang sebenarnya, tetapi mereka tidak sepenuhnya terkait, dan dalam pengalaman saya adalah jenis hal yang tampak sangat SMART dan berguna bagi orang-orang di luar organisasi langsung Anda (tanpa kebohongan langsung atau lumpuh total).