Apakah Scrum tidak kompatibel dengan tender publik?


43

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?



1
Jika hasilnya, harga dan kerangka waktu semua bisa dilakukan dimuka, mengapa repot dengan proses yang gesit?
JeffO

3
Scrum kompatibel dengan segalanya, menurut definisi. Paradigma "Tim memiliki proses" memungkinkan seseorang untuk mengubah proses secara radikal, sehingga Scrum dapat menjadi Air Terjun, jika diperlukan. Menjadi "gesit" berarti BUKAN bahwa Anda harus mengikuti beberapa proses dengan nol penyimpangan. Ini berarti bahwa proses tersebut dapat diadopsi sesuai kebutuhan. Perhatikan bahwa titik ini SANGAT tidak populer dengan manajemen - mereka menginginkan proses yang tetap, dan mereka akan menyebut apa pun "gesit" jika mereka terhubung pada Agile / Scrum / Apa pun.
Klaws

3
FWIW, IME, saya belum pernah melihat yang dijelaskan Sebazzz. Kontrak mengatakan secara spesifik apa yang harus disampaikan. Jika tidak memenuhi persyaratan maka Anda belum selesai. Dan itulah seluruh masalah dengan metode tangkas "berikan apa yang Anda miliki ketika dana habis". Ini adalah kesempatan langka ketika Anda dapat memberikan produk yang hanya melakukan subset dari apa yang dibutuhkan pelanggan dan itu sebenarnya bernilai bagi pelanggan. Biasanya itu sama dengan tidak berfungsi sama sekali. Penyimpangan dapat diminta, tetapi jika penyimpangan itu menghapus fungsionalitas maka yang hampir pasti dikombinasikan dengan dana lebih sedikit
Dunk

2
@ CortAmmon-Apa yang saya lihat pemerintah lakukan adalah "pintar" tetapi tidak benar-benar gesit. Mereka pada dasarnya masih mengikuti air terjun, mereka memberikan kontrak secara bertahap daripada upaya pengembangan siklus hidup penuh seperti yang mereka lakukan di masa lalu. Mereka juga lebih rentan untuk merekrut lebih dari satu kontraktor, terutama dalam tahap rekayasa, karena memungkinkan mereka secara kompetitif memilih solusi terbaik yang mereka inginkan untuk beralih ke produk yang dapat diproduksi. Fase terakhir itu yang paling mahal. Mereka ingin melihat apa yang mereka dapatkan sebelum memutuskan untuk memproduksi. Produk yang berfungsi sebagian tidak akan menang.
Dunk

Jawaban:


38

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.


Jawaban yang sangat bagus. Sangat sulit walaupun bukan tidak mungkin untuk mendapatkan organisasi seperti yang dijelaskan oleh OP untuk bergerak menuju pendekatan Agile.
Pak Positif

1
@MisterPositive Anda mungkin tidak membutuhkan lembaga penelitian untuk menjadi gesit. Namun, mereka mungkin harus dapat berinteraksi dengan entitas eksternal yang gesit ketika mereka mengeluarkan kontrak. Mereka bisa melihat manfaat tangkas, pasti.
Thomas Owens

Bagian yang sangat bagus tentang jawaban ini adalah IMHO yang tidak jatuh ke dalam perangkap berdebat tentang Scrum tidak cocok karena "hasil, harga, dan kerangka waktu" sudah diperbaiki.
Doc Brown

1
@DocBrown Mungkin karena Scrum dapat digunakan di mana harga dan kerangka waktu ditetapkan. Dalam pengalaman saya, ketika Anda menyampaikan dengan cepat dan menunjukkan hal-hal kepada para pemangku kepentingan, mereka menyadari bahwa apa yang awalnya mereka pikir mereka butuhkan dan apa yang sebenarnya mereka butuhkan adalah dua hal yang berbeda. Dan kemudian mereka akan mengubah hasil yang diinginkan dalam harga asli dan kerangka waktu.
Thomas Owens

Setuju. Perangkat lunak tidak seperti memiliki arsitek merancang bangunan. Ini adalah target yang bergerak secara inheren, dengan tanah selalu meluncur menjauh di bawah kaki Anda. Tahun depan, upaya tahun lalu terlihat sia-sia.

22

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:

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.


3
Ini adalah jawaban yang bagus, terutama dua paragraf terakhir. Ini benar-benar cara yang bagus untuk meletakkan hal-hal yang belum bisa saya kumpulkan secara koheren.
Thomas Owens

1
Ya, inilah jawabannya. Kontrak dan bagaimana itu ditulis adalah masalahnya. Saya tidak dapat mengkonfirmasi atau menyangkal bahwa pada titik tertentu dalam hidup saya bekerja untuk organisasi seperti itu atau yang serupa dengan itu, dan ketika mereka beralih ke kontrak yang lebih didorong oleh hasil, pengembangan lincah mulai menyebar seperti api.
Greg Burghardt

Jadi kedengarannya seperti 'arsitek' perlu membantu menulis tender di tempat pertama, sebelum dapat dianggarkan dan diberi kerangka waktu. Ini adalah proses dua fase, dengan frasa kedua adalah: "Anda, bangun ini, hari pembukaan adalah ..."

12

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.


5
Ini tidak benar-benar menjawab pertanyaan. Apa yang akan Anda rekomendasikan untuk organisasi ini?
Philipp

9
Bukankah ini klise terhadap pemerintah yang akan bertanggung jawab atas semua kegagalan, lebih dari jawaban yang konstruktif? Saya tidak tahu di negara Anda, tetapi di negara saya ada banyak proyek pemerintah yang sukses. Saya tidak akan dapat mengubah pikiran Anda, tetapi di sini artikel yang menarik berdasarkan fakta objektif dan pengamatan independen: mckinsey.com/industries/public-sector/our-insights/…
Christophe

6
"Inilah sebabnya mengapa banyak dari proyek-proyek ini gagal. Setelah mereka melampaui anggaran". Trope ini diklaim sepanjang waktu oleh orang-orang yang mendorong proses gesit. Namun, ada banyak perusahaan pengembangan yang sukses yang tidak menggunakan salah satu metode tangkas yang diusulkan. Mereka cenderung melakukannya tanpa masalah. Jika ada, masalah sebenarnya adalah praktik mempekerjakan penawar termurah dan tidak cukup menekankan pada kinerja masa lalu dan keahlian domain. Menyalahkan proses adalah herring merah. Keberhasilan dapat diraih oleh tim yang kompeten menggunakan proses yang masuk akal yang mereka miliki.
Dunk

OK, saya sedikit terbawa suasana. Saya masih akan merekomendasikan untuk memantau kemajuan dan mengambil peran pemangku kepentingan itu, setelah kontrak ditandatangani, dengan asumsi itu adalah kepentingan semua orang untuk melakukan. Dan saya tidak mengklaim Agile adalah kuncinya, saya mengklaim tidak ada konflik dengan prinsip-prinsip Agile dan menunjukkan masalah mendasar yang mendasarinya.
Martin Maat

Re: "dengan asumsi itu adalah kepentingan terbaik semua orang untuk memberikan": di mana saya tinggal kami memiliki proyek jangka panjang yang sangat mahal (untuk perluasan utilitas) gagal, dengan kebangkrutan pembangun (mega-abad tua di seluruh dunia perusahaan) dan agen layanan publik yang telah mendapatkan undang-undang yang berpotensi ilegal disahkan, dan pelanggan diharapkan untuk menyelamatkan semua orang. Dalam pemerintahan, hal-hal semacam ini tidak seharusnya terjadi, adalah kepentingan semua orang agar semua pihak tetap layak, etis, dan memenuhi apa yang mereka janjikan. Tidak yakin apakah proses dapat membantu atau tidak.

12

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.


3
Tepat! Ini adalah jawaban yang sangat bagus dan akurat. Dalam webinar ini projectmanagement.com/videos/290684/... seorang pejabat pemerintah AS menjelaskan cara kerjanya secara detail lengkap. Prinsip pengalihan tujuan tender dari produk akhir ke layanan pengembangan juga dapat diatur dalam banyak peraturan pengadaan lainnya dengan cara yang serupa. Kesulitan utama terutama adalah sikap kadang-kadang konservatif dari beberapa pemangku kepentingan, dan bukan ketidakcocokan yang dikatakan.
Christophe

1
Jadi mereka akan menyewa tim scrum termurah yang bisa mereka temukan, dan ketika proyek membutuhkan lebih banyak jam, mereka menyewa tim termurah kedua untuk mengambil alih pengembangan tengah? Pendekatan ini menganggap bahwa klien menilai kualitas tim perangkat lunak yang mereka pekerjakan. Jika mereka memiliki keahlian seperti itu, saya ingin tahu apa yang mereka butuhkan untuk melakukan outsourcing kontrak?
meriton - saat mogok

@meriton: Kebanyakan tender dilakukan oleh pemerintah, yang biasanya diharuskan menggunakan penawaran kualifikasi termurah . SCRUM tidak mengubahnya. Namun, SCRUM menempatkan pemilik produk dalam peran aktif, yang memang membantu di sini.
MSalters

Namun, jika dikontrak seperti yang Anda sarankan, SCRUM mengubah insentif untuk penyedia layanan. Mereka tidak lagi dapat dimintai pertanggungjawaban karena tidak memenuhi persyaratan, satu-satunya insentif mereka adalah menurunkan harga, sementara memenuhi surat kriteria kualifikasi, tetapi tidak harus semangat mereka. Lebih mudah bagi pembeli untuk menilai apakah perangkat lunak memenuhi persyaratan, daripada apakah tim cenderung menghasilkan perangkat lunak yang sesuai. Tapi ya, pendekatan Anda adalah salah satu cara terbaik untuk menggunakan SCRUM di sektor publik. Saya hanya ingin menyebutkan mengapa pembeli mungkin tidak mau mengadopsinya.
meriton - saat mogok

9

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).


3
+1 Saya tidak dapat menghitung berapa kali pekerjaan itu dilakukan karena seseorang menerima kontrak yang buruk, dan kemudian menggunakan koneksi itu untuk meningkatkan kontrak menjadi sesuatu yang lebih dekat dengan apa yang sebenarnya diinginkan pelanggan.
Cort Ammon

1
Izinkan saya menyoroti ini - jawaban ini mengatakan bukan Scrum tidak kompatibel dengan tender publik, tetapi pengembangan perangkat lunak berbasis kontrak secara umum . Bukannya saya tidak setuju.
Doc Brown

3

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 ...)


Saya akan menulis komentar seperti pernyataan terakhir Anda, tapi saya akan membiarkan Anda mendapatkan kredit :)

3

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.