Praktik Agile: Bagaimana Menghindari Kesalahan yang Dilakukan Tim Pemasaran Kami

Rahasianya sudah keluar. Manajemen proyek yang tangkas adalah pengubah permainan - dan pengembang serta orang-orang TI bukan lagi satu-satunya yang mengetahuinya.

Sebagai seorang pemasar, Anda pasti pernah mendengar tentang Agile. Tim Anda mungkin menggunakan beberapa praktik Agile, seperti sprint proyek dan rapat stand-up. Jika demikian, Anda termasuk minoritas. Manfaat Agile sebagian besar masih belum dimanfaatkan oleh tim pemasaran. Menurut laporan baru oleh Workfront dan MarketingProfs, hanya 30% tim pemasaran menggunakan pendekatan Agile untuk mengelola proses mereka. 70% lainnya mungkin mengalami frustrasi yang sama yang dialami tim saya sebelum kami berkomitmen untuk membuat Agile berhasil.

Tim pemasaran tujuh orang kami di Prospify telah mempraktikkan Agile selama hampir satu tahun. Kami membutuhkan waktu enam bulan untuk sampai pada titik mempraktikkannya dengan baik: menghasilkan pekerjaan yang lebih baik, lebih cepat, dan dengan lebih banyak energi dan keterlibatan.

Saat kami mulai berlatih Agile, kami membuat banyak kesalahan. Begitu banyak kesalahan, pada kenyataannya, sehingga kami mengunci setengah dari tim kami di ruang konferensi suatu hari dan tidak pergi sampai kami mengidentifikasi dan mengatasi beberapa kekurangan yang signifikan dalam pendekatan kami. Untungnya, ada bir dan itu hari Jumat. Tetap saja, itu menyakitkan, dan butuh waktu untuk menggali diri kita sendiri dari beberapa lubang berorientasi proses yang dalam.

Pada artikel ini, saya membagikan kesalahan tersebut sehingga Anda dapat menghindari penguncian yang menyakitkan seperti kami. Agile dapat merevolusi kemampuan tim pemasaran Anda untuk berkolaborasi dan memberikan pekerjaan lebih cepat - jika Anda berkomitmen untuk membuat proses tersebut berhasil untuk Anda.

Sebelum kita mulai, mari kita bahas beberapa hal mendasar:

Apa itu praktik Agile?

Praktik tangkas (sering disebut sebagai "Agile") menekankan pengiriman terus-menerus dari bagian pekerjaan yang lebih kecil melalui proyek dengan tugas yang saling berhubungan lebih besar yang dapat berlangsung selama berminggu-minggu atau berbulan-bulan (yang secara tradisional disebut manajemen gaya air terjun).

Dasar-dasar tangkas meliputi:

• Tim scrum: Tim yang sangat kolaboratif ini, yang diorganisir di bawah seorang master scrum, memecahkan masalah yang kompleks dan memberikan solusi dalam iterasi jangka tetap yang disebut sprint, yang dapat berlangsung dari satu minggu hingga 30 hari. Sebuah tim scrum yang mengerjakan konten, misalnya, dapat memulai sprint dua minggu yang berkomitmen untuk membuat infografis atau lembar data baru.
• Minimum viable product (MVP): Saat merencanakan kiriman, prinsip Agile menekankan untuk mengeluarkan proyek di alam liar secepat mungkin sehingga tim Anda dapat merespons masalah nyata lebih awal. Untuk mencapai model pengiriman berkelanjutan, scrum master mendorong tim untuk menentukan MVP dan mencari cara paling kreatif untuk menyelesaikan produk dalam batasan sprint. Misalnya, jika Anda memulai sprint dua minggu untuk membuat e-book sebagai MVP Anda, dan desainer Anda jatuh sakit, Anda dapat memutuskan untuk mendefinisikan kembali MVP sprint itu sebagai rangkaian posting blog dan merancang e-book berikutnya lari cepat.
• Rapat stand-up harian: Anggota tim berdiri melingkar selama 15 menit atau lebih setiap pagi untuk membahas tugas tim scrum yang telah diselesaikan, area fokus, dan blocker yang mungkin menghalangi mereka menyelesaikan pekerjaan sprint yang ditugaskan. Di akhir sprint, tim Agile menyelesaikan serangkaian proyek yang ditentukan, yang kemudian dinilai dan diperbaiki di sprint berikutnya. Beberapa tim scrum juga menggabungkan pertemuan retrospektif, di mana mereka membahas kekurangan proses yang dapat ditangani di sprint berikutnya.

Mengapa pemasar harus menggunakan Agile?

National Public Radio menggunakan metodologi Agile untuk membuat dan menguji program baru. Pikirkan tentang itu selama "momen jalan masuk" Anda berikutnya. Meskipun akar Agile ada di manajemen TI, bentuk pengiriman proyek ini dapat diterapkan ke banyak fungsi bisnis, termasuk pemasaran.

Mengadopsi model Agile dari iterasi berkelanjutan memungkinkan tim pemasaran Anda dengan cepat menguji pesan atau kampanye baru, bereaksi lebih cepat terhadap pembaruan produk, dan menetapkan harapan dengan pemangku kepentingan yang meminta pekerjaan dari tim Anda.

Momen cemerlang tim saya datang hampir sembilan bulan setelah kami memulai perjalanan Agile kami, saat kami menyegarkan konten di situs web kami untuk membuat beberapa perubahan dalam perpesanan produk kami. Kami menentukan apa yang bisa kami capai dalam satu minggu, dan kami menyelesaikan pekerjaan itu sesuai jadwal. Konten yang tidak sempat kami perbarui dalam sprint itu, kami sembunyikan dari navigasi. Kami terus menambah dan menyegarkan pesan pada halaman-halaman itu selama sprint berikutnya.

Kesalahan apa yang harus dihindari?

Jika Anda mempertimbangkan untuk mengadopsi Agile di tim Anda, bahkan jika Anda hanya ingin menyederhanakan proses dalam tim pemasaran Anda, Anda pasti ingin menghindari empat kesalahan pemasaran Agile yang dibuat oleh tim kami:

1. Kami menyebut diri kami Agile tanpa mengerjakan pekerjaan rumah kami.
2. Kami gagal menunjuk pemilik masalah.
3. Kami fokus pada kiriman daripada masalah.
4. Kami berdesak-desakan alih-alih memprioritaskan (dan berpura-pura kami bisa menyelesaikan semuanya).

Kesalahan 1: Kami menyebut diri kami Tangkas tanpa mengerjakan pekerjaan rumah kami

Ketika saya mulai dengan tim pemasaran saya, saya dengan cepat melakukan stand-up harian untuk memberikan cara yang cepat dan tanpa rasa sakit untuk memeriksa proyek. Saya pikir saya telah melakukan stand-up dan mengatur sprint di peran sebelumnya, jadi saya punya pengalaman dengan Agile, bukan? Salah.

Jangan masuk kerja pada satu hari Senin dan mengumumkan bahwa Anda "pergi ke Agile" seperti yang saya lakukan. Hanya karena Anda melakukan pekerjaan dalam sprint dua minggu dan melakukan stand-up harian tidak berarti Anda adalah tim Agile. Keindahan Agile adalah memberi tim Anda kekuatan untuk berkomitmen pada proyek bersama dan untuk menentukan kualitas yang dapat dikirimkan dalam lingkup waktu yang ditentukan. Jika Anda hanya mencoba menjejalkan sebanyak mungkin pekerjaan dalam dua minggu dan mengorbankan kualitas untuk mencapai garis finis, keindahan itu ditiadakan.

Sebelum melembagakan proses Agile di tim pemasaran Anda, lakukan pekerjaan rumah Anda. Buka satu atau dua buku. Saya sarankan memulai dengan Scrum oleh Jeff Sutherland (dikenal banyak orang sebagai salah satu bapak Agile) dan Hacking Marketing oleh Scott Brinker. Juga, baca beberapa artikel bagus CMI tentang pemasaran Agile.

Setelah Anda menyelesaikan pekerjaan rumah Anda, prioritaskan beberapa perubahan sederhana pada proses Anda yang ada untuk mulai menyusun pendekatan Agile yang akan bekerja untuk tim Anda.

Kesalahan 2: Kami gagal menunjuk pemilik masalah

Jika skenario berikut belum terjadi, Anda dapat melewati bagian ini; Anda telah mencapai suatu bentuk nirwana proses pemasaran yang belum saya temukan.

Sisanya, bayangkan ini: Anda 98% melalui proyek tim besar dengan tenggat waktu yang jelas, dan pemangku kepentingan yang mengejutkan masuk pada jam terakhir dengan lusinan revisi. Kemudian, tim Anda dipaksa untuk memperpanjang proyek dua minggu ekstra untuk mengatasi perubahan tersebut karena tidak ada yang bisa membantah bahwa pemangku kepentingan ini salah.

Masih membaca? Saya pikir begitu.

Kurangnya kepemilikan yang ditentukan tim kami adalah hambatan terbesar bagi kemajuan kami sebagai departemen pemasaran Agile. Kami kewalahan dengan pekerjaan. Kami merasa frustrasi ketika banyak pemangku kepentingan mempertimbangkan kualitas proyek. Dan kami tidak mendapatkan apa pun karena pengeditan dan perbaikan di menit-menit terakhir.

Jika tim pemasaran Anda sama seperti tim kami, Anda kesulitan untuk mengetahui siapa pemilik akhir dari sebuah proyek. Siapa orang yang secara langsung bertanggung jawab atas keberhasilan penyampaian? Siapa yang menetapkan hasil yang dapat diukur untuk tugas yang dapat diselaraskan oleh tim? Siapa yang membutuhkan proyek ini untuk sukses sehingga pada akhirnya dia juga bisa sukses?

Untuk mencegah pengerjaan ulang di menit-menit terakhir, kami sekarang menugaskan orang seperti itu - pemilik masalah - ke setiap proyek.

Setiap kuartal, kami menetapkan sasaran prospek yang memenuhi syarat penjualan untuk setiap saluran pemasaran utama kami: iklan, acara, prospek situs web organik, dan seterusnya. Kemudian, masing-masing saluran tersebut ditetapkan sebagai pemilik di tim kami, dan pemilik tersebut menjadi orang yang tepat untuk setiap kiriman yang termasuk dalam saluran itu.

Masalah kepemilikan sangat berhasil untuk tim kami karena beberapa alasan:

• Itu menempatkan tanggung jawab kesuksesan pada satu orang , yang bertanggung jawab jika tujuan tidak tercapai.
• Ini memaksa pemilik saluran untuk mengemukakan masalah lebih awal sehingga tim dapat mengatasinya secara proaktif.
• Ini memungkinkan seluruh tim untuk terlibat dalam melakukan brainstorming solusi dan menerapkan perbaikan.
• Ini memberdayakan satu orang untuk memandu kualitas proyek tertentu.

Jika tim Anda tidak jelas tentang siapa yang memiliki keputusan akhir dalam proyek konten Anda, duduklah bersama departemen Anda dan ajukan satu pertanyaan yang sangat sederhana namun menantang: “Siapa yang memiliki apa?” Menjawab pertanyaan itu - dan mencatat jawaban Anda untuk dilihat semua orang - akan menciptakan akuntabilitas yang tak terukur.

Kesalahan 3: Kami berfokus pada kiriman daripada masalah

Momen lain yang mengubah permainan untuk tim Agile kami adalah ketika kami berhenti melihat pekerjaan kami sebagai sekumpulan kiriman untuk diselesaikan dan mulai berpikir tentang pekerjaan kami sebagai serangkaian masalah untuk dipecahkan.

Pikirkan tentang kontributor individu di tim Anda: developer, copywriter, desainer, dan peran implementasi serupa lainnya. Seberapa sering mereka diminta untuk "mendesain slide ini" atau "menulis e-book" dengan sedikit konteks mengapa mereka melakukannya?

Cukup menugaskan tugas pada daftar tugas tanpa membantu tim Anda memahami tujuan sebenarnya di balik proyek akan menghasilkan pekerjaan yang tidak bersemangat tanpa investasi pribadi dari tim Anda.

Faktanya, kurangnya pekerjaan yang berorientasi pada tujuan dapat memiliki implikasi yang parah pada lebih dari sekedar taktik pemasaran Anda. Dalam survei anggota LinkedIn, lebih dari 60% responden yang tidak memiliki pekerjaan yang berorientasi pada tujuan berencana meninggalkan perusahaan mereka dalam tiga tahun atau kurang.

Di tim kami, kami memiliki aturan yang kuat untuk tidak memulai proyek apa pun dengan tujuan yang ditentukan. Hadapi saja, pemangku kepentingan tidak selalu tahu apa yang mereka inginkan. Pemecahan masalah membantu mendorong kolaborasi untuk hasil yang lebih baik.

Sebagai gantinya, kami memulai setiap proyek dengan pernyataan masalah, yang mengikuti format yang secara teratur disebut cerita pengguna di dunia pengembangan Agile. Format itu terlihat seperti ini:

Ketika __________ terjadi, saya ingin ________, sehingga kami mendapatkan hasil yang terukur ini: ___________.

Berikut adalah contoh jenis pernyataan masalah (atau cerita pengguna) dari proyek hipotetis:

Setiap pemilik masalah proyek menentukan masalah mana yang akan ditangani tim untuk proyek itu. Misalnya, pemilik mungkin menganggapnya sebagai masalah jika situs web tidak diberi peringkat untuk kata kunci tertentu atau jika pesan perlu diperbarui untuk pameran dagang yang akan datang. Tidak peduli masalahnya, pernyataan masalah tidak pernah menyertakan solusi. Setelah kami memutuskan untuk memprioritaskan masalah tertentu, tim kami menganalisis masalah tersebut bersama-sama, pada akhirnya mencari solusi yang dapat kami jalankan dalam sprint berikutnya.

Memecahkan masalah sebagai sebuah tim memungkinkan setiap orang memiliki kepentingan dalam hasilnya.

Selain itu, pendekatan ini memaksa tim untuk mengungkap poin nyeri di balik masalah tingkat permukaan untuk sampai pada solusi yang memenuhi kebutuhan inti daripada permintaan kesombongan.

Misalnya, tim penjualan kami melaporkan bahwa beberapa prospek tidak muncul di rapat demo yang dijadwalkan dan tidak menanggapi permintaan penjadwalan ulang. Wakil presiden penjualan kami ingin tim pemasaran membuat video animasi penjelasan yang lebih baik untuk prospek utama pertemuan mereka, meskipun hal itu akan memakan waktu berbulan-bulan.

Setelah menanyakan beberapa pertanyaan tentang proses penjualan, kami menyadari bahwa masalah inti tim penjualan dapat diselesaikan dengan pesan email yang ditingkatkan sebelum rapat demo. Kami memulai kampanye tiga email yang dipicu segera setelah pertemuan dijadwalkan. Solusi ini hanya membutuhkan waktu dua hari untuk membangun tim. Sejak membuat kampanye ini, kami telah mengurangi lebih dari setengah jumlah orang yang perlu menjadwalkan ulang rapat.

Sebelum menugaskan tugas kepada anggota tim, tanyakan pada diri Anda mengapa pekerjaan itu penting. Dengan membuat pernyataan masalah dan berkolaborasi dalam sebuah solusi, kami dapat mengidentifikasi perbaikan cepat yang telah memberikan keuntungan bagi tim kami. Jika kami telah membuat video animasi, tim penjualan mungkin telah menangani masalah yang sama selama berbulan-bulan sambil menunggu perbaikan kami.

Kesalahan 4: Kami berdesakan alih-alih memprioritaskan (dan berpura-pura kami bisa menyelesaikan semuanya)

Jika Anda mencoba menyesuaikan sebanyak mungkin dengan setiap sprint pemasaran Agile, seperti yang kami lakukan, Anda salah melakukannya.

Tanpa rasa prioritas bersama, Anda tidak tahu ke mana harus memfokuskan waktu. Dan tanpa fokus, Anda terpaksa mengatakan ya untuk segalanya. Dan ketika Anda mengatakan ya untuk semuanya dan tidak memiliki pemilik masalah untuk proyek Anda, Anda mendapati diri Anda berada di tengah-tengah kuartal yang penuh tekanan dengan banyak kiriman yang setengah jadi.

Banyak tim Agile menggunakan estimasi untuk memprioritaskan pekerjaan dan meningkatkan kecepatan sebagai sebuah tim. Mereka memperkirakan jumlah usaha yang dibutuhkan sebuah proyek atau mendiskusikan berapa jam yang dibutuhkan individu untuk menyelesaikan tugas mereka. Seiring waktu, banyak tim Agile mencapai hasil rata-rata per sprint, yang membantu mereka merencanakan tugas baru.

Di bulan-bulan awal kami sebagai tim Agile, kami mulai melakukan estimasi seperti ini. Sayangnya, kami akhirnya memanipulasi perkiraan kami untuk membuatnya tampak bahwa kami dapat menyelesaikan semuanya. Kami menebak berapa banyak pekerjaan yang dibutuhkan sebuah proyek, dan kemudian kami menawar persyaratan untuk menyediakan ruang bagi tiga permintaan lainnya. Pada akhirnya, kami meniadakan nilai memperkirakan pekerjaan, mengabadikan lingkungan stres yang tiada henti.

Kami mencoba dua atau tiga metode pelacakan kecepatan (termasuk perencanaan poker, cara umum memperkirakan pekerjaan). Kami berfokus pada penggunaan estimasi sebagai cara untuk membuktikan bahwa kami dapat menyelesaikan banyak pekerjaan, bukan sebagai cara untuk menjadi tim yang lebih efisien. ITU adalah kesalahan kami.

Baru-baru ini saya mengobrol dengan direktur teknik perusahaan kami yang mengelola proses Agile untuk tim produk kami. Ketika saya menyebutkan bahwa tim kami tidak pernah menguasai estimasi, dia mengatakan ini:

Jika pemangku kepentingan Anda terus-menerus meminta laporan kecepatan atau perkiraan yang ditingkatkan dari tim Anda, Anda mungkin mengalami masalah proses yang lebih besar yang mengganggu kemampuan tim Anda untuk mengirimkan pekerjaan kepada mereka tepat waktu.

Ketika tim Agile Anda yang berfungsi baik secara teratur mengirimkan iterasi cepat dari sebuah proyek dan menandai kekhawatiran kepada pemangku kepentingan ketika tenggat waktu tidak masuk akal, Anda tentu saja menghindari pertanyaan tentang keluaran atau produktivitas di tim Anda. Manajer proyek atau master scrum memiliki tanggung jawab untuk mengoreksi dan mengkomunikasikan perubahan tersebut ketika pekerjaan tertinggal.

Jangan takut untuk memprioritaskan hanya satu atau dua proyek baru (atau masalah atau cerita) di sprint berikutnya karena Anda memiliki beberapa proyek tersisa di sprint Anda saat ini. Pastikan untuk mengomunikasikan sisa pekerjaan itu secara tepat waktu kepada pemangku kepentingan dan bagikan rencana Anda untuk menyelesaikan proyek secepat mungkin.

Dan jangan takut untuk menunjuk satu pemimpin untuk membuat keputusan akhir tentang apa yang perlu diprioritaskan. Tim kami, misalnya, melarang semua orang memindahkan kartu Trello ke kolom sprint "prioritas" kecuali wakil presiden pemasaran kami. Itu menempatkan tanggung jawab untuk memprioritaskan orang dengan pandangan terbesar dari seluruh bisnis.

Kesimpulan

Tim kami, seperti setiap tim Agile, mengadaptasi prinsip Agile dengan cara yang sesuai untuk kami. Apa pun pendekatan Agile yang mungkin diambil tim Anda, itu hanya akan berhasil jika Anda memberikan peluang untuk umpan balik terbuka tentang proses tersebut dan jika Anda cukup fleksibel untuk mengubah alur kerja Anda secara teratur. Jika saya memiliki log dari setiap tweak yang kami buat pada pendekatan Agile kami sejauh ini, itu akan lebih lama dari posting ini.

Kesalahan apa yang dilakukan tim Anda saat menerapkan proses Agile? Bagaimana Anda mengatasi kesalahan tersebut? Beri tahu kami di komentar.

Ingin meningkatkan struktur Anda untuk efektivitas pemasaran konten? Mendaftarlah untuk buletin mingguan Strategi Konten untuk Pemasar kami, yang menampilkan wawasan eksklusif dari Robert Rose, kepala penasihat konten. Jika Anda seperti banyak pemasar lain yang kami temui, Anda akan menantikan pemikirannya setiap hari Sabtu.

Gambar sampul oleh Joseph Kalinowski / Content Marketing Institute