SCRUM telah menjadi sangat populer sehingga sekarang mereka mencoba menerapkannya hampir di mana-mana. Di perusahaan besar, kadang-kadang ternyata SCRUM diimplementasikan demi pelaporan, atau agar menjadi "progresif" dan "modis". Akibatnya, situasi, yang tampaknya seperti manajer yang bertanggung jawab, menetapkan tanda centang berikutnya, kata mereka, itu perlu untuk menerapkan metodologi - dilaksanakan, dilakukan dengan baik, tetapi alih-alih beberapa perbaikan kualitatif, apa yang disebut "Zombie SCRUM" muncul pada output. Ini adalah ketika kerangka kerja diimplementasikan secara formal, tetapi tidak ada yang bekerja secara normal di atasnya. Karena itulah namanya.
Nama saya Oleg Egorkin, saya seorang pelatih yang gesit di Rostelecom, dan dalam posting ini saya akan memberi tahu Anda mengapa “zombie scrum” muncul secara umum, bagaimana menghindari ini dan bagaimana memastikan bahwa semuanya siap bagi perusahaan untuk meluncurkan tim scrum.
Pendekatan yang Ada untuk Menjalankan Perintah
Kadang-kadang mereka mencoba meluncurkan tim scrum di IT, yaitu dari bawah ke atas. Ini adalah saat para pengembang itu sendiri dan para kepala departemen memahami bahwa inilah saatnya, untuk produk ini kita membutuhkan bekas luka. Nilai tambahnya adalah bahwa inisiatif tersebut berasal dari orang-orang dalam subjek. Minus - dengan pendekatan ini, bisnis tidak terlibat. Dan jika bisnis tidak terlibat, maka struktur organisasi itu sendiri dengan pendekatan ini sedikit berubah, atau (lebih sering) tidak berubah sama sekali. Akibatnya, kemungkinan scrum tersebut menjadi “scrum zombie” sangat tinggi. Tentu saja, tidak akan seperti itu di hari pertama semuanya akan salah seperti yang diinginkan. Tetapi setelah sekitar enam bulan, orang akan menyadari bahwa semua minus yang ada di startup tidak pergi ke mana pun. Karenanya frustrasi yang selalu memengaruhi produk sedih.
Ada cerita terbalik - dari atas ke bawah. Juga bukan hal yang harus diperjuangkan. Sebagai contoh, ingat, beberapa tahun yang lalu, pada awal Agile, 50 tim baru diluncurkan di satu bank hijau atas instruksi otoritas tinggi "pada musim panas," dan pada akhir tahun - 5000. Ini adalah pendekatan yang sangat tepat untuk scrum demi scrum. Apa yang terjadi dalam kasus ini? Orang-orang bergegas menjalankan tugas. Di bawah layar, semua yang tidak kacau mulai mendayung. Scrum dalam cerita ini tidak pernah merupakan peningkatan pengembangan dan metodologi baru, itu hanya tanda centang di KPI manajer. Hasilnya adalah "scrum zombie."
Dan ada pendekatan ketiga - inisiatif ini atas dan bawah secara kodrional. Kami beruntung, dan di Rostelecom barusan. Suatu hal dalam apa. Di tingkat manajemen puncak, selalu ada bantuan untuk semua pendekatan transformasional dalam tim. Pada saat yang sama, tidak ada yang membuat rencana "ambisius".
Untuk perusahaan besar dan sangat besar, ini tidak sepenuhnya familiar. Cara kerjanya seperti ini: sebulan sekali saya memberikan pelatihan dasar satu hari tentang Agile. Baik karyawan TI dan orang-orang dari bisnis datang ke pelatihan, 25 orang dalam grup. Saya mencoba membicarakannya seluas mungkin dan seluas-luasnya. Setelah beberapa waktu (mungkin diperlukan dari satu minggu hingga beberapa bulan), kolega, mencerna pengetahuan yang diperoleh, kembali dengan permintaan yang dimengerti untuk membuat tim scrum.
Tentang daftar periksa
Ada dua jenis permintaan untuk saya - baik untuk meluncurkan tim sebagai bagian dari transformasi produk yang sudah ada, atau ke tim untuk produk baru. Untuk memproses permintaan ini, saya menulis daftar periksa khusus, dengan bantuan yang saya periksa semua persyaratan yang diperlukan untuk menjalankan. Jika aplikasi tidak melewati satu titik dan tidak memenuhi persyaratan awal, maka kami tidak menjalankan tim. Ini adalah kebutuhan yang diakui - jika Anda terus terang mencetak setidaknya satu poin dan menjalankan tim tanpa itu, itu masih tidak akan membawa hasil. Yah, selain fakta bahwa tidak lemah mendemotivasi semua peserta.
Jika seseorang dari IT datang kepada saya dengan aplikasi, saya memintanya untuk berbicara dengan bisnis dan kembali bersama. Karena bisnis di Agile adalah komponen kunci. Dari sini kami memiliki item daftar periksa pertama:
1. Tim tangkas harus ingin membuat bisnis
Di sini, seperti halnya vampir - mereka tidak bisa hanya mengambil dan memasuki rumah, mereka harus diundang. Dengan pelatih Agile, hal yang sama, dalam arti bahwa perubahan harus diminta.
Orang-orang dari bisnis dan dari IT memperhatikan bahwa beberapa produk bekerja dalam kondisi pasar yang sulit, mereka menghubungi saya sendiri dan mengatakan - pendekatannya perlu diubah. Dan di sini, jika Anda sangat beruntung, maka permintaan datang sama sekali di awal, ketika belum ada tim, tetapi ada ide di mana orang dapat mulai berkumpul. Pada saat yang sama, semua orang mengerti bahwa spesifikasi yang jelas untuk produk tidak dapat dibentuk, itu akan berubah tergantung pada model bisnis, dan tidak jelas model mana yang akan bekerja dan mana yang tidak.
Secara umum, sangat penting bahwa bisnis terlibat.
Penting juga bahwa pendorong keterlibatan ini harus menjadi sesuatu yang nyata, dan bukan sekadar hype. Oleh karena itu, saya memeriksa bahwa motif bisnis secara kasar jatuh ke dalam yang berikut:
- kurangi waktu ke pasar jika indikator ini terlalu besar;
- meningkatkan efisiensi kerja tim;
- meningkatkan pengelolaan dalam menghadapi prioritas yang berubah.
Jika salah satu dari tiga poin ini adalah, maka semuanya baik-baik saja, ini adalah tanda pasti bahwa tim memulai dengan harapan yang memadai.
2. Harus ada produk untuk diluncurkan
Pertama, ini logis. Adalah konyol menjalankan tim produk untuk suatu produk ketika Anda tidak memiliki produk. Dan tidak masalah apa yang kita semua mulai lakukan di sekitarnya - di sekitar produk atau layanan.
3. Pemilik produk harus memiliki visi dan peta jalan untuk pengembangan
Selain itu, peta jalan untuk satu tahun di muka adalah minimum, dalam bentuk pemahaman tingkat tertinggi tentang apa yang umumnya perlu dilakukan. Bahkan jika seseorang memiliki 3-5 hipotesis tentang model bisnis apa yang akan dia terapkan, apa yang ingin dia jelajahi. Jika saya melihat ada peta jalan, lanjutkan.
4. Bisnis harus punya uang
Yakni, anggaran untuk tim lintas fungsi. Karena produk harus disewa untuk tim penuh waktu, dan bisnis harus siap membayar untuk itu di cakrawala selama sekitar satu tahun di muka. Saya memastikan bahwa semua ini dilakukan, saya melihat di mana pusat pertanggungjawaban keuangan terlibat dalam hal ini, sehingga tidak berhasil bahwa ada ide, ada keinginan untuk meluncurkan tim, tetapi tidak ada uang.
5. Harus menjadi pemilik produk dalam bisnis
Pemilik Bukan pemilik. Satu pemilik
Seseorang yang 100% didedikasikan untuk produk khusus ini. Ada kasus ketika dua manajer datang dan berkata - kami ingin menciptakan produk motivasi dan pendidikan (hal internal bagi karyawan). Saya memberi tahu mereka - hebat, tetapi apakah Anda memiliki pemilik produk? Mereka menjawab - ya, tentu saja, satu pemilik produk adalah untuk pelatihan, dan yang lainnya - untuk motivasi. Produk ini memotivasi dan mendidik.
Saat itu saya diminta berpikir dan menyetujui siapa yang akan bertanggung jawab atas seluruh produk. Ini ternyata menjadi masalah yang sangat sulit dan tim berhasil diluncurkan hanya enam bulan kemudian.
Satu produk - satu pemilik produk. Ini penting.
6. Semua peserta dalam tim pengembangan juga harus dialokasikan 100% untuk produk.
Jika seseorang dari tim pengembangan bekerja di 50%, 30%, 10% - ini tidak segera. Seseorang harus sepenuhnya dalam produk. Tetapi pada saat yang sama, saya tidak memerlukan kehadiran tim yang berlokasi bersama. Dalam kondisi kami, sangat jarang, Rostelecom sangat besar, kami memiliki banyak anak perusahaan dan afiliasi (anak perusahaan afiliasi), di mana pengembang yang termasuk dalam tim bekerja. Dan mereka dapat tersebar di Moskow, Peter, Krasnodar dan kota-kota lain di tanah air kita yang luas. Terkadang sulit dan menghabiskan waktu untuk dengan cepat membentuk tim di Moskow, tetapi seringkali tidak berhasil sama sekali.
Oleh karena itu, saya maju, tetapi ada persyaratan tandingan - bahwa tim berkumpul untuk 2 hari pertama ketika pelatihan sedang berlangsung, dan kemudian setiap enam bulan untuk memelihara kontak pribadi dan membahas masalah saat ini.
7. Metode pembayaran produk
Ini juga merupakan hal yang penting, juga banyak yang terhubung dengan uang. Ketika pemilik produk memiliki anggaran, ia dihabiskan berdasarkan permintaan. Artinya, TK ditulis pada urutan, penilaian dilakukan untuk implementasinya, dan kemudian dana dalam anggaran dialokasikan untuk kasus ini. Kedengarannya mudah. Namun ada nuansa.
Ketika Anda beralih ke pekerjaan kustom, maka pada akhir pelaksanaan pesanan harus ada prosedur untuk menerima dan mentransfer produk ke operasi. Dan karena TK telah disetujui, sangat sulit untuk mengubahnya. Setiap hasil edit harus dinegosiasikan ulang, disetujui. Ini adalah proses yang sangat kompleks dan lambat, tidak sesuai dengan reaksi cepat terhadap perubahan.
Apa yang telah kita lakukan agar tidak mengubur diri kita dalam hal ini dan tidak menjadi gila.
Anda dapat mengerjakan Waktu & Bahan saat kontrak selesai dan waktu seluruh tim dibayar. Artinya, ada tim yang bekerja untuk pemilik produk. Layanannya dibayar bulanan atau triwulanan. Tetapi di negara kita ini tidak dapat dilakukan dalam bentuk murni, karena ada batasan birokrasi.
Oleh karena itu, kami mulai bekerja sebagai bagian dari pengembangan kebiasaan di tingkat pesanan triwulanan dengan memperbaiki peta jalan (bukan TK), sementara pesanan tidak merinci bagaimana peta jalan akan diterapkan. Pemilik produk memiliki fleksibilitas generasi backlog. Dan ketika kuartal berakhir, kami membongkar dari daftar tugas dari tugas-tugas yang dilakukan dan atas dasar itu kami membentuk tindakan yang ditandatangani dan dibayar. Ternyata Bahan & Waktu yang sama.
Dan di sini tidak perlu mematuhi TK dengan jelas, karena tidak ada TK. Persyaratan yang tidak lagi masuk akal setelah pengujian hipotesis tidak dapat dibuat.
8. Tim tidak boleh memiliki KPI, kecuali yang terkait dengan produk
Hal ini penting karena pengembang dipekerjakan oleh anak perusahaan, di mana KPI digunakan untuk mengatur daur ulang (inilah saat pengembang harus selalu sibuk dengan sesuatu). Bahkan, hampir semua integrator bekerja seperti ini - dalam kondisi kekurangan suatu proyek (atau proyek yang bersaing) dari pengembang yang sama, mereka melukis pada beberapa proyek. Dan kemudian, agar perusahaan hitam, mereka menempatkan pengembang di KPI bahwa ia harus selalu paling tidak 85% sibuk. Artinya, dia sebenarnya memiliki KPI tertentu, yang memotivasi dia untuk masuk ke dalam jumlah maksimum proyek untuk menyesuaikan pembuangannya ke angka yang diperlukan.
Untungnya, tim scrum tidak memiliki kebutuhan seperti itu (secara de facto 100%). Saya memastikan bahwa tim tidak memiliki KPI lain selain bahan makanan.
Total
Ini daftar periksa saya. Menurutnya, saya memeriksa semua tim sebelum memulai, dan karena kami memiliki pendekatan co-directional, saya dapat menuntut perubahan kondisi jika tim tidak melalui setidaknya satu dari poin-poin ini. Oleh karena itu, hasilnya hanya tim-tim yang siap menerapkan nilai-nilai pendekatan gesit.
Jika aplikasi untuk tim melewati semua poin ini, tahap selanjutnya dimulai - melatih dan meluncurkan tim.
Yang akan saya bicarakan di posting berikutnya =)