Saya diminta oleh sebuah organisasi publik untuk memberikan lokakarya informal tentang 101 pengembangan tangkas yang menjelaskan istilah dan konsep Scrum, Kanban, dan sejenisnya. Saya telah bekerja di lingkungan yang gesit selama sekitar lima tahun sekarang, tetapi saya tidak menganggap saya sebagai penginjil Scrum.

Setelah lokakarya mereka menyukai gagasan itu. Namun, mereka menjelaskan bahwa pendekatan itu mungkin tidak berlaku untuk mereka karena mereka perlu menugaskan perusahaan perangkat lunak eksternal untuk mengembangkan perangkat lunak untuk mereka (mereka hanya memiliki beberapa pengembang sendiri). Kegiatan ini perlu dilakukan dalam proses tender publik yang menggambarkan hasil, harga, dan kerangka waktu. Ini adalah persyaratan hukum untuk mengajukan anggaran bagi organisasi ini (lembaga penelitian publik).

Kendala-kendala ini tampak agak bertentangan dengan prinsip-prinsip dasar pengembangan lincah, bukan?

Apakah Scrum hanya tidak kompatibel dalam lingkungan seperti itu?

Apa yang akan Anda rekomendasikan untuk organisasi ini?

Scrum mungkin tidak sesuai untuk organisasi ini.

Dari Panduan Scrum, "Scrum adalah kerangka kerja untuk mengembangkan, memberikan, dan mempertahankan produk yang kompleks." Ini juga dirancang untuk tim yang terdiri dari 3-9 anggota Tim Pengembangan yang mengerjakan produk, Pemilik Produk, dan Master Scrum (yang mungkin atau mungkin tidak termasuk dalam Tim Pengembangan) dengan total jumlah 4-11 orang.

Sehubungan dengan pengembangan internal, Anda menyebutkan bahwa mereka hanya memiliki beberapa pengembang. Jika tidak ada tim yang cukup besar untuk membentuk Tim Scrum, maka tidak masuk akal untuk menggunakan semua Scrum. Namun, beberapa praktik Scrum mungkin bermanfaat bagi organisasi.

Untuk pengembangan yang dikontrak, dimungkinkan bagi salah satu pihak eksternal untuk menggunakan Scrum. Dalam hal ini, berguna bagi lembaga penelitian untuk mengetahui tentang praktik Scrum dan memahami peran dan cara kerjanya. Mereka mungkin masih perlu memahami secara spesifik bagaimana organisasi pengembangan eksternal menggunakan praktik-praktik Scrum serta praktik-praktik lain, tetapi itu dapat membantu mereka memahami cara kerjanya. Misalnya, memahami kebutuhan untuk berpartisipasi dalam Ulasan Sprint atau bekerja dengan organisasi (mungkin Pemilik Produk mereka) dalam memesan Product Backlog.

18F, sebuah agen layanan digital dalam pemerintah AS, telah melakukan banyak pekerjaan tentang bagaimana pemerintah dapat menulis kontrak untuk memungkinkan penggunaan metodologi tangkas dengan cara yang konsisten dengan hukum, menentukan hasil umum daripada persyaratan terperinci untuk bagaimana pekerjaan harus dilakukan. Beberapa sumber daya mereka meliputi:

• Meningkatkan hasil pemerintah melalui format kontrak yang gesit
• Perjanjian Pembelian Selimut Agile
• Modular Contracting (memecah proyek-proyek besar menjadi yang lebih kecil dengan pengembangan tangkas)
• Apakah proyek Anda menggunakan "agilefall"?

Keuntungan dari metode kerja lincah adalah bahwa mereka fokus pada menemukan solusi untuk masalah setelah kontrak diberikan, yaitu, selama pelaksanaan pasca-penghargaan, daripada menentukan solusi rinci di depan seperti dengan Bagian 15. Kontrak lincah mencoba untuk tentukan masalah yang memerlukan solusi terperinci, sering kali sebagai Product Backlog Items yang menjelaskan area pengiriman kontrak tingkat tinggi.

Memahami masalah ini, Kantor Manajemen dan Anggaran dan Kantor Kebijakan Pengadaan Federal mengarahkan agensi untuk berhenti menggunakan SOW dan beralih menggunakan Pernyataan Kerja Kinerja (PWS) untuk memperoleh layanan. Seorang PWS "harus menyatakan persyaratan secara umum tentang apa (hasil) yang harus dilakukan, daripada bagaimana (metode) itu dilakukan" Petugas kontraktor yang baik memberi tahu agen bahwa dengan membeli layanan ahli, itu menyiratkan bahwa Anda bukan yang paling berpengetahuan. dalam "bagaimana" pekerjaan dilakukan. Sebagai pemilik misi, Anda adalah ahli dalam "apa," harus dicapai, tetapi menggabungkan keduanya menempatkan misi Anda dalam risiko dan membuat kontrak lebih sulit untuk memberikan nilai.

Pada dasarnya, pendekatan ini lebih seperti mempekerjakan penyedia layanan untuk bekerja dengan Anda merancang solusi, daripada mendaftar halaman spesifikasi terperinci sebelumnya. Lembaga itu tidak akan menyewa seorang arsitek untuk merancang sebuah bangunan baru dengan menyebutkan "desainnya harus empat lantai, dengan tinggi atap 37º. Lantai ketiga harus memiliki dapur seluas 237 kaki persegi yang berisi empat lampu neon, yang dikendalikan oleh sebuah gerakan. - Saklar cahaya sensitif, di langit-langit drop. " Sebaliknya, mereka akan memiliki kontrak untuk arsitek untuk menyediakan layanan desain dengan berkonsultasi dengan klien, dan bergantung pada vendor mereka, seorang ahli di lapangan, untuk menghasilkan hasil yang dihasilkan.

Sementara perinciannya akan bergantung pada institusi dan kebijakan serta undang-undang pengadaan yang berlaku, rinciannya menunjukkan bahwa, di tengah semua kegagalan proyek TI pemerintah yang besar, ada kelompok yang bekerja untuk memindahkan tender publik untuk pengembangan perangkat lunak ke metodologi yang lebih modern, diberikan kemauan politik yang cukup dan mitra pembangunan yang dapat dipercaya. Dibutuhkan perubahan besar dalam bagaimana proyek tersebut dipahami dan dikelola (termasuk banyak waktu yang berkelanjutan memberikan umpan balik pengguna di seluruh proses), yang organisasi mungkin atau mungkin tidak tertarik untuk mengejar.

Memang terdengar khas. Setelah tender telah ditulis, penawaran sudah masuk dan salah satu pesaing telah diberikan kontrak ... sejauh yang menyangkut perwakilan organisasi publik, proyek selesai.

Inilah sebabnya mengapa banyak dari proyek ini gagal. Setelah mereka pergi jauh melebihi anggaran.

Poin yang mereka lewatkan (atau setidaknya tidak merasa menjadi perhatian mereka) adalah bahwa mereka adalah pemangku kepentingan yang harus menghadiri pertemuan dan demo.

Jadi tidak ada konflik dengan Agile atau Scrum sama sekali. Orang-orang tidak mengambil peran mereka. Ini adalah cara kerja pemerintah yang menyebabkan ini.

Ini tidak seperti "kami ingin memiliki sistem ini dan kami bersedia melakukan upaya di dalamnya dan melihat seberapa jauh kami dapat mengambilnya".

Tidak. Itu seperti "demokrasi kita telah memutuskan kita AKAN memiliki sistem ini, pada saat itu". Yang tidak menyisakan ruang antara kesuksesan 100% di satu sisi dan kegagalan 100% di sisi lain. Ditakdirkan sejak awal.

Ini juga merupakan undangan ke pasar untuk meminta harga yang konyol. Tidak mengerjakan proyek karena terlalu mahal bukanlah suatu pilihan, keputusan untuk melakukannya sudah dibuat sebelum tender ditulis.

Cukup adil, bahkan jika para pemangku kepentingan akan mengambil peran mereka, mereka akan sama sekali tidak berdaya. Tak satu pun dari mereka akan memiliki tongkat yang kredibel untuk dibawa ke demo tersebut karena alasan yang sama.

Tidak, SCRUM tidak kompatibel dengan tender publik. Anda harus menyatakan secara eksplisit apa yang Anda beli dalam tender publik.

"Pembeli ingin membeli 10 sprint pengembangan selama 2 minggu, dari tim SCRUM berpengalaman yang terdiri dari 5 pengembang dan master SCRUM bersertifikat (pembeli akan mengisi peran Stakeholder). Sprint akan berjalan dari Maret 2018 hingga Juli 2018" cukup masuk akal mulai dari tender. Anda harus membuat daftar keterampilan tim yang diperlukan, tentu saja, dan memberikan gambaran tentang proyek yang akan mereka kerjakan, tetapi dapat diterima untuk memiliki tender untuk merekrut tim.

Tentu saja, Anda menyerah pada "ruang lingkup tetap" di sini. Lagipula itu tipikal untuk SCRUM. Dengan sedikit lebih banyak kata-kata dalam tender (tapi kami mendapatkan di wilayah hukum di sini) Anda dapat memungkinkan untuk perpanjangan cakupan kecil, yaitu sejumlah kecil sprint tambahan. Tetapi jika Anda memutuskan untuk menginginkan 10 sprint tambahan setelah 10 sprint awal, Anda mungkin perlu tender ulang.

Itu sulit.

Anda jelas tidak bisa menawar pekerjaan dengan anggaran terbuka. Jadi, Anda harus melihat apa yang perlu dilakukan dan berapa banyak upaya yang diperlukan untuk melakukan ini.

Sekarang alasan banyak proyek perangkat lunak gagal adalah karena fakta bahwa memperbaiki, waktu, usaha dan ruang lingkup di muka sangat rawan kesalahan. Misalnya, spesifikasi seperti yang diberikan dalam tender hampir selalu memiliki beberapa ambiguitas.

Jadi ada masalah mendasar tidak hanya dengan gesit, tetapi dengan konsep tender terbuka untuk pengembangan perangkat lunak. Peluang seseorang untuk pergi dan menciptakan apa yang Anda inginkan, pada waktu yang Anda tentukan, rendah.

Jika Anda mengizinkan beberapa fleksibilitas, Anda dapat meningkatkan ini.

Sepertinya proses pelelangan umum tidak fleksibel. Namun, begitu kontrak dimenangkan, Anda mungkin menemukan ada ruang geli. Anda dapat, misalnya, memungkinkan kerja gesit tetapi Anda harus menerima (dan mendapatkan izin hukum) bahwa ini dapat mempengaruhi ruang lingkup.

Sekarang saya percaya bahwa ini akan menghasilkan produk yang lebih baik karena Anda akan dapat melihat apa yang terjadi lebih awal dan melakukan perubahan sebelum dimasukkan ke dalam produk. Putaran umpan balik yang ketat dan pengembangan berulang dapat membuat produk yang lebih sesuai dengan persyaratan aktual (yang mungkin atau mungkin tidak diajukan untuk tender).

Tergantung, tapi mungkin ya.

Saya bersedia bertaruh uang bahwa setiap orang yang pernah bekerja dengan pemerintah mana pun pada proyek terkait TI akan tahu bahwa dalam praktiknya, 'batasan keras' yang dijelaskan dalam tender tidak pernah dipenuhi. Hal-hal cenderung melebihi anggaran, tertunda dan / atau ruang lingkup diubah. Biasanya banyak dari itu. Jika pemerintah mau mengakui bahwa ini adalah kebenaran dan menjadi bersedia untuk memperlakukan mereka seperti pedoman mereka, maka scrum dapat bekerja dengan sangat baik.

Dari pengalaman pribadi (baik saya sendiri maupun dalam jaringan profesional saya), saya tahu bahwa persyaratan sering berubah di sebagian besar proyek pemerintah. Komite yang bertanggung jawab juga cenderung memiliki banyak umpan balik ketika mereka akhirnya terlibat di akhir proyek. Ini adalah masalah yang cocok untuk Scrum.

Namun, ini akan membutuhkan perubahan mendasar dalam pola pikir dari pihak pemerintah dan lembaga mereka. Di sebagian besar negara, sangat kecil kemungkinan perubahan ini akan terjadi. Sampai saat itu, tender publik akan terus tidak kompatibel dengan bekerja dengan Scrum. (Untuk itu, menurut pendapat pribadi saya tender publik akan terus tidak sesuai dengan setiap praktek-praktek pengembangan perangkat lunak yang berkelanjutan, tapi itu masalah lain untuk lain waktu ...)

Apa yang akan Anda rekomendasikan untuk organisasi ini?

Pada titik ini tidak ada apa-apa.

Apa yang kurang di sini adalah kisah tentang masalah apa yang menyebabkan proses mereka saat ini. Scrum bukanlah sesuatu untuk direkomendasikan secara membabi buta. Ada benarnya. Ini bukan satu ukuran untuk semua.

Tanyakan kepada mereka masalah apa yang menyebabkan proses mereka saat ini. Mendengarkan. Hanya rekomendasikan metode yang mengatasi masalah mereka yang sebenarnya. Mereka akan menjadi bias terhadap proses mereka saat ini. Tinders mungkin tampak seperti mereka menentukan proses pengembangan tetapi mereka tidak melakukannya. Mereka menentukan proses pengiriman. Tapi itu perbedaan yang kemungkinan tim belum pernah buat sebelumnya.

Agile bekerja paling baik ketika persyaratan berubah lebih dari 3% selama umur proyek. Kalau tidak, air terjun masih sangat efektif. Ini masih digunakan di banyak tempat saat ini. Dan tentu saja banyak pengembang yang sukses tidak pernah memformalkan proses mereka. Informal bekerja dengan baik ketika masalah-masalah sulitnya bersifat teknis, bukan tentang orang-orang.

Jadi bicarakan dengan mereka tentang proses mereka saat ini dan masalah yang dimilikinya. Beri tahu mereka tentang apa yang membantu metode ini. Tetapi jika tidak rusak jangan memperbaikinya.