敏捷實踐：如何避免我們的營銷團隊犯的錯誤

秘密出了。 敏捷項目管理可以改變遊戲規則-開發人員和IT人員不再是唯一了解它的人。

作為營銷人員，您肯定已經聽說過敏捷。 您的團隊可能正在使用某些敏捷實踐，例如項目衝刺和站立會議。 如果是這樣，那麼您就是少數。 營銷團隊尚未充分利用敏捷的好處。 根據Workfront和MarketingProfs的新報告，只有30％的營銷團隊使用敏捷方法來管理其流程。 在我們致力於使敏捷工作之前，其他70％的人可能會遇到我的團隊同樣的挫敗感。

我們在Emplify的七人行銷團隊已經實踐敏捷近一年了。 我們花了六個月的時間才能很好地實踐它：更好，更快地進行工作，並投入更多精力和精力。

當我們開始練習敏捷時，我們犯了很多錯誤。 事實上，如此多的錯誤使我們有一天將一半的團隊鎖定在會議室，直到我們發現並解決了我們的方法中的一些重大缺陷後才離開。 幸運的是，那天有啤酒。 但是，這仍然很痛苦，並且需要花一些時間才能將自己從一些深層的，面向過程的漏洞中解脫出來。

在本文中，我分享了這些錯誤，以便您可以避免像我們這樣的痛苦鎖定。 如果您致力於使流程為您服務，那麼敏捷可以徹底改變您的營銷團隊的協作能力並更快地交付工作。

在開始之前，我們先介紹一些基本知識：

什麼是敏捷實踐？

敏捷實踐（通常稱為“敏捷”）強調在具有較大互連任務的項目上持續交付較小的工作部分，這些任務可能跨越數週或數月（傳統上稱為瀑布式管理）。

敏捷基礎知識包括：

• Scrum團隊：這個高度協作的團隊由Scrum負責人組織，解決了複雜的問題，並以稱為sprint的定長迭代提供解決方案，該迭代可以持續一周到30天。 例如，負責內容的Scrum團隊可能會開始進行為期兩週的衝刺，承諾創建新的信息圖表或數據表。
• 最小可行產品（MVP）：在規劃可交付成果時，敏捷原則強調盡快將項目發佈出去，以便您的團隊可以對實際問題做出早期響應。 為了實現持續交付的模型，Scrum主管鼓勵團隊定義MVP並找出在sprint範圍內完成產品的最具創造性的方法。 例如，如果您開始一個為期兩週的衝刺以創建電子書作為您的MVP，而您的設計師生病了，則可以決定將該衝刺的MVP重新定義為一系列博客文章，然後在下一個設計電子書短跑。
• 每日站立會議：團隊成員每天早上圍坐15分鐘左右，以討論Scrum團隊已完成的任務，重點領域和阻礙者，這可能會阻礙他們完成分配的衝刺工作。 在sprint結束時，敏捷團隊將交付一組已定義的項目，然後在下一個sprint中對其進行評估和改進。 一些Scrum團隊還參加了回顧會議，在會議上討論可以在下一個Sprint中解決的過程缺陷。

營銷人員為什麼要使用敏捷？

國家公共廣播電台使用敏捷方法來創建和測試新節目。 在下一個“車道時刻”考慮一下。 儘管敏捷的根源是IT管理，但是這種形式的項目交付可以應用於企業的許多功能，包括市場營銷。

採用連續迭代的敏捷模型，您的營銷團隊可以快速測試新消息或廣告活動，對產品更新做出更快反應，並與要求您團隊工作的利益相關者建立期望。

在我們開始敏捷之旅近九個月之後，我們團隊的光輝時刻就出現了。那時，我們刷新了網站上的內容以對我們的產品消息進行一些調整。 我們定義了一周內可以完成的工作，並按計劃完成了這項工作。 我們在導航中隱藏了我們沒有時間在該sprint中更新的內容。 在後續的sprint中，我們一直在不斷添加和刷新這些頁面上的消息。

應該避免什麼錯誤？

如果您正在考慮在團隊中採用敏捷，即使您只是希望簡化營銷團隊中的流程，您也要避免我們團隊犯下的這四個敏捷營銷錯誤：

1. 我們自稱敏捷而不做功課。
2. 我們未能指定問題負責人。
3. 我們專注於可交付成果，而不是問題。
4. 我們做事而不是優先考慮（並且假裝我們可以完成所有工作）。

錯誤1：我們不做作業就自稱為敏捷

當我開始與營銷團隊合作時，我迅速建立起每日站立的機會，以提供一種快速，輕鬆的方式檢查項目的方法。 我以為我曾擔任過以前的角色，曾做過站姿和有組織的衝刺比賽，所以我有敏捷的經驗，對嗎？ 錯誤。

不要在一個星期一上班，像我一樣宣布您要“敏捷”。 僅僅因為您正在進行為期兩週的衝刺，並且每天都站起來，並不意味著您就是一個敏捷團隊。 敏捷的優點在於，它使您的團隊有權共同致力於項目，並在指定的時間內定義可交付的質量。 如果您只是想在兩個星期內完成盡可能多的工作，並且為了達到終點而犧牲質量，那美就被否定了。

在營銷團隊中建立敏捷流程之前，請做好功課。 破解一兩本書。 我建議從Jeff Sutherland（被稱為敏捷之父之一）的Scrum和Scott Brinker的Hacking Marketing開始。 此外，請閱讀CMI關於敏捷營銷的出色文章。

完成作業後，優先考慮對現有流程的一些簡單更改，以開始製定一種適用於您的團隊的敏捷方法。

錯誤2：我們未能指定問題所有者

如果沒有發生以下情況，則可以跳過本節； 您實現了我尚未發現的某種形式的營銷過程必殺技。

其餘的人則想像一下：在一個大型團隊項目中，您有98％的工作期限很明確，最後一個小時，利益相關者驚訝地加入了數十次修訂。 然後，您的團隊被迫將項目延長兩個星期以解決這些更改，因為沒有人可以說這個利益相關者是錯的。

還在讀書嗎？ 我是這麼想的。

我們團隊缺乏明確的所有權是我們發展敏捷營銷部門的最大障礙。 我們不知所措。 當多個利益相關者參與項目質量評估時，我們感到沮喪。 由於最新的編輯和修復，我們沒有得到任何幫助。

如果您的營銷團隊像我們一樣，那麼您就很難知道項目的最終所有者是誰。 由誰直接負責交付成果的成功？ 誰為團隊可以完成的任務設定可衡量的結果？ 誰需要這個項目才能成功，以便他或她最終也能成功？

為了防止最後一刻返工，我們現在為每個項目分配這樣的人員（問題負責人）。

每個季度，我們都會為我們的每個主要營銷渠道設定銷售合格的潛在客戶目標：廣告，活動，有機網站潛在客戶等。 然後，為這些渠道中的每個渠道分配一個團隊所有者，而該所有者將成為該渠道下任何可交付成果的首選人。

由於以下幾個原因，問題的所有權對於我們的團隊特別成功：

• 它把成功的責任放在一個人身上，如果沒有達到目標，這個人就要負責。
• 這迫使渠道所有者儘早發現問題，以便團隊主動解決。
• 它允許整個團隊參與集體討論解決方案並實施修補程序。
• 它使一個人可以指導任何給定項目的質量。

如果您的團隊不清楚誰在內容項目中擁有最終決定權，請與您的部門坐下來，問一個棘手的簡單但具有挑戰性的問題：“誰擁有什麼？” 回答該問題並記錄您的答案以供所有人查看，將產生不可估量的責任感。

錯誤三：我們專注於可交付成果，而不是問題

對於敏捷團隊來說，另一個改變遊戲規則的時刻是，當我們停止將我們的工作視為一組可交付的成果時，便開始考慮將我們的工作視為要解決的一系列問題。

考慮一下團隊中的各個貢獻者：開發人員，撰稿人，設計師和其他類似的實現角色。 他們多久被要求“設計這張幻燈片”或“撰寫此電子書”，而他們卻很少這麼做，為什麼？

只是在待辦事項列表上分配任務而沒有幫助您的團隊了解項目背後的真正目的，會導致工作乏善可陳，而無需您的團隊進行個人投資。

實際上，缺乏針對目標的工作不僅會對您的營銷策略產生嚴重影響。 在對LinkedIn成員的一項調查中，超過60％的非定向工作受訪者計劃在三年或更短的時間內離開公司。

在我們的團隊中，我們有一個嚴格的規則，禁止在考慮到規定的交付成果的情況下開始任何項目。 面對現實吧，利益相關者並不總是知道他們想要什麼。 解決問題有助於促進協作以獲得更好的結果。

取而代之的是，我們在每個項目中都以問題陳述開始，該陳述遵循在敏捷開發世界中通常稱為用戶故事的格式。 該格式如下所示：

當發生__________時，我想________，以便我們得到此可衡量的結果：___________。

這是一個假設項目中此類問題陳述（或用戶案例）的示例：

每個項目的問題所有者確定團隊將為該項目解決哪些問題。 例如，如果網站未針對某個關鍵字進行排名，或者需要為即將到來的貿易展覽更新消息，所有者可能會認為這是一個問題。 不管有什麼問題，問題說明都永遠不會包含解決方案。 在決定優先處理特定問題之後，我們的團隊將一起分析問題，最終確定可以在下一個衝刺中執行的解決方案。

團隊解決問題可以使每個人都對結果負責。

此外，這種方法迫使團隊發現表面問題背後的痛點，從而找到解決核心需求而不是虛榮要求的解決方案。

例如，我們的銷售團隊報告說，一些潛在客戶沒有參加他們預定的演示會議，也沒有響應重新安排的請求。 我們的銷售副總裁希望營銷團隊創建動畫講解視頻，以更好地吸引見面的人，儘管這樣做可能要花幾個月的時間。

在詢問了有關銷售流程的一些問題之後，我們意識到可以通過在演示會議之前改進電子郵件消息來解決銷售團隊的核心問題。 我們安排了一次會議，立即啟動了一個三電子郵件滴灌運動。 該解決方案只花了兩天的時間就使團隊得以構建。 自製作此廣告系列以來，我們將需要重新安排會議時間的人數減少了一半以上。

在將任務分配給團隊成員之前，請先問問自己為什麼這項工作很重要。 通過創建問題陳述並就解決方案進行協作，我們能夠確定快速解決方案，該解決方案已為我們的團隊帶來了回報。 如果我們創建了動畫視頻，則銷售團隊可能在等待修復的過程中已經處理了幾個月的問題。

錯誤4：我們塞滿了重頭戲，而不是優先考慮（並裝作可以完成所有工作）

如果您像我們一樣嘗試盡可能地適應每個敏捷營銷衝刺，那麼您做錯了。

沒有共同的優先感，您就不知道將時間集中在哪裡。 如果沒有重點，您只能對所有事情說“是”。 當您對所有事情都說“是”並且沒有項目負責人時，您會發現自己陷入了緊張的四分之一的困境中，並交付了許多未完成的項目。

許多敏捷團隊以團隊為單位使用估算來確定工作的優先級並提高速度。 他們估算了一個項目所需的工作量，或者討論了個人完成任務可能需要花費多少小時。 隨著時間的推移，許多敏捷團隊會感覺到每個sprint的平均產出，這有助於他們計劃新任務。

在敏捷團隊的最初幾個月中，我們著手進行這種估算。 不幸的是，我們最終操縱了我們的估計，以至於看起來我們可以完成所有事情。 我們猜測了一個項目將要花費多少工作，然後我們降低了需求，以便為其他三個請求騰出空間。 最後，我們否定了估算工作的價值，使壓力持續存在。

我們嘗試了兩種或三種跟踪速度的方法（包括計劃撲克，這是估算工作量的常用方法）。 我們專注於使用估算來證明我們可以完成很多工作，而不是成為一支更有效率的團隊。 那是我們的錯誤。

最近，我與我們公司的工程總監聊天，後者為我們的產品團隊管理敏捷流程。 當我提到我們的團隊從未掌握過估算時，他說：

如果您的利益相關者不斷要求團隊提供速度報告或改進的估計，您可能會遇到更大的過程問題，這些問題會損害團隊按時向他們交付工作的能力。

當運作良好的敏捷團隊定期交付項目的快速迭代，並在不合理的期限內向利益相關者提出問題時，您自然會迴避有關團隊產出或生產力的問題。 當工作落後時，項目經理或Scrum主管有責任進行糾正並傳達這些更改。

不要害怕在下一個Sprint中僅優先處理一個或兩個新項目（或問題或故事），因為當前Sprint中有一些剩餘項目。 只要確保及時將剩餘的工作傳達給利益相關者，並共享您的計劃，以盡快完成該項目。

並且不要害怕指定一位領導者就需要優先考慮的事項做出最終決定。 例如，我們的團隊禁止所有人將Trello卡移至“優先”衝刺欄中，但我們的營銷副總裁除外。 那就是把責任放在優先考慮整個業務的人身上。

結論

就像每個敏捷團隊一樣，我們的團隊正在以對我們有用的方式適應敏捷原則。 無論您的團隊採用哪種敏捷方法，只有在您提供機會就流程進行公開反饋並且足夠靈活地定期更改工作流程時，該方法才有效。 如果到目前為止，我對我們對敏捷方法所做的每一次調整都擁有記錄，那將比這篇文章更長。

您的團隊在實施敏捷流程時犯了哪些錯誤？ 您如何解決這些錯誤？ 在評論中讓我們知道。

是否想改善內容營銷效率的結構？ 訂閱我們的“營銷商內容策略”每週新聞，其中包含首席內容顧問Robert Rose的獨家見解。 如果您像我們遇到的許多其他營銷人員一樣，您將在每個星期六期待他的想法。

封面圖片：Joseph Kalinowski /內容營銷學院