Bagaimana cara memperkenalkan Agile ke tim yang menggunakan metode non-Agile kaku?


16

Pertimbangkan sebuah perusahaan yang dengan bangga disertifikasi untuk beberapa metodologi non-Agile, menggunakannya sebagai titik penjualan kepada pelanggannya untuk menunjukkan akuntabilitas.

Bagaimana cara Anda memperkenalkan Kanban atau Scrum secara progresif tanpa merusak seluruh sistem mereka dan tetap membuat mereka yakin bahwa itu masih bisa dipertanggungjawabkan / diaudit ?


Saya tahu ini mungkin terkait dengan " Bagaimana Anda memperkenalkan metodologi lincah seperti Scrum ", tapi di sini saya bertanya-tanya tentang cara untuk menghindari / mengatasi kenyataan bahwa perusahaan menerapkan cara tertentu mengelola SDLC dengan alasan palsu bahwa itu adalah satu-satunya cara untuk memiliki jejak audit.


Apa sertifikasinya? Apakah ini ISO-9000?
Robert Harvey

1
Anda sedikit memahami detail; jika sertifikasi memerlukan artefak tingkat minimum tertentu untuk tetap tersertifikasi, dan perusahaan telah memetakan artefak tersebut dengan ketat pada proses pengembangan Anda dengan cara yang meminimalkan dampak, maka tidak ada solusi.
Robert Harvey

@Robert Harvey: ISO-9001 akan menjadi contoh yang baik. Apa pun yang membutuhkan persyaratan yang dapat diaudit dan menguji spesifikasi serta keterlacakan untuk pemilik dokumen dan tugas.
haylem

@ Robert Harvey: Ya, tetapi pemetaan hanya perlu diaudit. Sejauh yang saya tahu, sebagian besar pelacak masalah / cacat / tugas / bug dapat menjadi bagian dari jejak audit karena mereka mencatat kepemilikan tugas dari waktu ke waktu. Dan bahkan dapat dihubungkan, dalam hal pengembangan perangkat lunak, ke SCM untuk melacak nomor revisi juga. Plus Anda dapat menggunakan pelacak Anda untuk mengidentifikasi persyaratan, f-spesifikasi dan ID uji juga dan mendapatkan matriks keterlacakan Anda dari sana.
haylem

@Robert Harvey: terutama mengingat pelacakan untuk ISO-9001 tidak terlalu sulit untuk didapatkan dan dipelihara, tetapi entah bagaimana sering terlihat sebagai sesuatu yang perlu redundan dan sangat buruk.
haylem

Jawaban:


12

Saya pikir ini adalah mitos bahwa tim proyek Agile tidak mendokumentasikan aplikasi mereka dan ini adalah poin pertama dari perlawanan yang Anda dapatkan di perusahaan yang disertifikasi untuk memiliki dokumentasi terbaik sesuai standar mereka.

Saya bekerja di perusahaan bersertifikat ISO-9001, tetapi kami juga melakukan scrum pada sejumlah besar proyek kami. Dalam kasus kami, perubahan datang dari kepala Pengiriman Proyek (yaitu orang-orang yang cukup senior) dan itulah mengapa itu diadopsi - sebagai lawan dari Manajer Proyek atau Pengembang mencoba untuk mendorong perubahan ini.

Salah satu praktik bermanfaat yang kami ikuti adalah Mendokumentasikan Cukup tetapi Terus-Menerus . Ini jelas berarti kita tidak mengikuti semua templat yang ditentukan untuk proyek, tetapi ada pemahaman dan kesepakatan sadar mengenai bagian / dokumen mana yang dibutuhkan vs.

Anda kemudian perlu mensosialisasikan sudut pandang ini dan mendapatkan persetujuan dari kelompok Kualitas atau divisi Standar atau apa pun namanya.

Prinsip Agile adalah dokumentasi 'cukup'. Bisakah Anda mencoba dan mendorongnya dari Pelanggan untuk mengungkapkan kepada tim berapa yang cukup? Manajer proyek dapat berbicara dengan pelanggan dan memahami apa harapan mereka dan kebutuhan organisasi dan kemudian keduanya mendokumentasikan keputusan dan memenuhi harapan itu. Jika itu cukup baik untuk mereka (yaitu pelanggan yang membayar), maka itu bisa menjadi apa yang Anda ikuti.

Jika mereka berpikir Agile tidak meningkatkan proyek-proyek besar, yakinkan mereka bisa - dengan dekomposisi dan upaya paralel.

Dalam organisasi besar, kontrol dan pengawasan untuk program besar diselesaikan dengan menjalankan Kantor Pemantauan Proyek (PMO) yang melakukan perencanaan konvensional untuk penetapan biaya / akuntansi / manajemen sumber daya dll - karenanya mereka menuntut banyak dokumentasi, tetapi mereka dapat memantau kemajuan menggunakan praktik Agile (grafik burn-down SCRUM untuk satu). Mereka perlu tahu bagaimana teknik seperti integrasi berkelanjutan membantu mereka lebih awal daripada kemudian, dan karenanya lebih baik bagi produktivitas semua orang untuk mengeluarkan dokumen biaya tambahan.

Agile adalah seperangkat keterampilan yang dapat dipelajari oleh tim yang sebagian besar ortogonal dengan keterampilan teknis tradisional kami. Tetapi jika Anda menambahkan ini ke keterampilan mereka yang ada, tentu saja Anda bisa menjadi tim yang lebih efektif. Standup harian (mis. Rapat Scrum) tidak mungkin dilakukan dalam semalam - tetapi Anda akan mengadakan pertemuan tim reguler (katakanlah dua mingguan) saat ini? Saya akan mengatakan mulai dengan mengubah mereka menjadi mengikuti agenda pertanyaan Scrum (tidak terlalu licik;) dan menyampaikan kepada tim yang lebih luas mengapa pendekatan ini dapat bekerja dan tidak berarti dokumentasi lemah / standar yang buruk atau apa pun mitos lainnya.


Meskipun jawaban lain bagus, saya pikir jawaban Anda adalah yang paling sulit untuk menjawab pertanyaan spesifik, tidak hanya memberikan petunjuk umum tentang penggunaan gesit dan mencoba mencari tahu mengapa kami ingin menggunakannya. Jawaban yang bagus. Terima kasih.
haylem

@ayaylem: senang bisa membantu. dalam kasus kami, kami menunjuk anggota tim yang jagoan Agile Champion untuk memfasilitasi transisi. Dia membuat kita semua sadar akan banyak hal ini. Mungkin Anda bisa menjadi sukarelawan untuk peran seperti itu.
JoseK

8

Saya akan memisahkan Scrum dari Kanban terlebih dahulu.

Dengan Kanban - dan inilah sumber yang cukup bagus tentang bagaimana melakukannya dengan benar - prinsipnya adalah Anda menghormati proses keluar saat Anda mulai. Kanban bukan apa yang Anda ganti dengan proses yang ada, tetapi apa yang Anda terapkan padanya. Petakan, visualisasikan, dan atur kondisi tertentu untuk peningkatan bertahap.

Scrum pada dasarnya berbeda dalam arti bahwa itu adalah sesuatu yang akan menggantikan proses yang ada.

Sebuah tim yang terbiasa dengan siklus SDLC air terjun 12 bulan (atau lebih lama) akan mengalami masa transisi yang sangat sulit ke Scrum. Perpendek siklus secara bertahap menjadi kereta rilis 6 atau 3 bulan dengan cakupan yang lebih kecil bisa menjadi langkah perantara yang bermanfaat.


Saya suka ide untuk menghormati proses yang ada. Saya tidak yakin tentang pemendekan bertahap, mungkin memberikan rasa sakit tanpa banyak manfaat. Saya akan melakukan buy-in manajemen senior dan kemudian beberapa minggu membuat orang terbiasa dengan proses tangkas scrum harian dan iterasi dua minggu.
Michael Durrant

6

Seperti hal baru apa pun yang akan Anda coba kenalkan pada suatu organisasi, Anda akan menghadapi tentangan yang kuat. Apakah Anda siap untuk dikritik dan menjadi yang bertanggung jawab jika gagal? Anda harus menjadi orang yang kuat. Itulah harga yang harus dibayar ketika mengekspos diri Anda.

  • Tanyakan pada diri sendiri mengapa Anda ingin menggunakan Scrum . Apakah Anda perlu memecahkan masalah nyata?
  • Pastikan bahwa ANDA berkomitmen untuk itu, karena tidak ada yang akan melakukannya untuk Anda. Anda akan menjadi pemilik benda itu. Setidaknya hingga membawa efek positif dalam organisasi
  • Latih dirimu . Buku dan internet tidak cukup. Pergi ke kursus pertama, atau Anda akan meningkatkan secara dramatis peluang Anda untuk mengimplementasikan Scrum secara tidak benar. Yang mungkin akan membawa tim Anda ke hasil yang lebih buruk dari sebelumnya
  • Jual dulu ke tim . Anda harus mendapatkan dukungan penuh mereka, jelas
  • Jangan usulkan perubahan, usulkan tes . Dan anggap seperti itu. Scrum mungkin tidak cocok untuk organisasi Anda (atau untuk tim Anda)
  • Temukan sponsor di manajemen puncak

+1: "Tanyakan pada diri sendiri mengapa Anda ingin menggunakan Scrum. Apakah Anda perlu memecahkan masalah nyata?": Poin yang sangat bagus. Sebelum memperkenalkan cara kerja yang baru, orang harus bertanya apa yang coba dipecahkannya. Sayangnya, memperkenalkan SCRUM (atau metode lain) untuk menyelesaikan masalah yang tidak ada hanya akan menciptakan overhead dan produktivitas yang lebih rendah daripada meningkatkannya (saya berbicara dari pengalaman langsung).
Giorgio

3

Inilah yang persis terjadi di perusahaan kami. Kami mengikuti metode yang ketat dan tidak gesit. Ketika Manajer Teknis Pimpinan baru bergabung, yang memiliki pengalaman dengan SCRUM , dia pikir akan lebih baik untuk mencobanya.

Cara kami melakukannya, adalah membawa sekelompok kecil pengembang (dan analis) untuk membuat tim pilot SCRUM. Kami mengikuti metodologi SCRUM yang ketat selama sekitar 4 bulan, setelah itu perusahaan merefleksikan apa yang telah kami lakukan, bagaimana kami melakukannya, dianalisis terhadap data (Anda tahu, semua hal yang perlu dilakukan BA).

Apa yang mereka temukan adalah bahwa pilot itu sukses besar. Jadi mereka membuat tim lain yang mengikuti Kanban, dan mereka juga telah sukses besar. Saya pikir ada pembicaraan bahwa sisa pengembang juga membentuk tim SCRUM / Kanban.

Saya pikir pilot itu penting. Ini memberi sisi ketat waktu bisnis untuk mengevaluasi dan memastikan bahwa itu berfungsi lebih dulu.


1

Saya seorang pelatih yang tangkas dan salah satu kunci untuk mengubah inisiatif adalah dukungan di semua tingkatan! Ini termasuk eksekutif, tim pengembangan, manajer, ... dll. Sebelum mengumumkan upaya perubahan besar atau kecil, saya akan menyarankan agar Anda bergabung terlebih dahulu dengan Anda. Melakukan ini melalui percakapan orang ketiga adalah cara termudah bagi individu untuk mulai mencari ide-ide baru. Apa itu orang ketiga? Blog, video youtube, presentasi, ... dll. Dengan cara ini, orang-orang itu dapat mulai dengan ide-ide mereka sendiri dan dengan pengaruh Anda akan bergabung dengan inisiatif perubahan.

Berikut adalah dua video licik yang saya gunakan untuk memicu minat di semua tingkatan dalam rantai makanan.

Kanban: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI


+1 untuk buy-in, terutama mengingat komentar dalam pertanyaan yang menunjukkan kurangnya buy-in.
Michael Durrant

@ KanbAnimation: Saya pikir Anda harus bertanya pada diri sendiri apakah SCRUM baik untuk perusahaan tempat Anda mencoba memperkenalkannya. (Dari pengalaman langsung saya) SCRUM tidak baik untuk semua jenis proyek dan memperkenalkannya tidak selalu membuat perusahaan lebih efektif. Eksekutif yang meyakinkan (yang mungkin kurang memiliki pengetahuan teknis untuk memahami konsekuensinya) untuk memperkenalkan SCRUM dapat dalam jangka panjang merusak perusahaan jika SCRUM tidak cocok untuk jenis proyek yang mereka lakukan.
Giorgio
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.