如果根據 Enterprise Big Data Framework 的理論 來看 數據團隊 的設計，敏捷的方法 (agile methodologies) 是必需要的。但是，這個觀點似乎有一些爭論！其實，要或不要，應該是看你或是你們的需求，必須要靈活思考，而不是一刀兩斷的說：要或是不要。
數據團隊的設計，根據上述的理論，大概有五個面向，需要你的思考：①團隊的分工角色與相應的流程，這點不難理解，有人有流程，每個人的分工合作，促進目標的達成。②實驗設備等相關硬體，這點也不難理解，數據的分析必須要大量的運算與儲存的能力，電腦基礎設施的運作不可缺少。③你的目標，為什麼會有這一個團隊？你們的業務目標是什麼？如何達成？或是如何驗證？然後走過去。④敏捷的方法，這就是今天的重點。⑤成本的分析，關鍵是彰顯自身的價值。利用成本來彰顯自身的價值，才是最簡單的方法，請永遠記住：成本是你的分母，有了投資，才會有分母，才可以計算投資報酬。相對的，不投資，就不會有分母，沒有投資，何來投資報酬的效益呢？
到底甚麼是敏捷？簡單的說：把計畫驅動轉成價值驅動。我們思考一下：假設是一個專案型態的業務問題解決，傳統的作法，專案經理會把範圍固定下來，然後去評估相關的成本與時間，然後著手設計專案來進行某項業務問題的解決。可是，我們如果做一個簡單的思維調整，在固定的時間與固定的預算內，我們是否可以把解決問題的範圍，盡可能的擴大與調整？也就是說：時間與成本固定，但是獲得的效益提升了。
當然，說的都很簡單，但是，事實上不是很容易的操作。更何況，持反面意見的人認為：為什麼上述的假設會是一個專案型態的業務問題解決呢？問題的解決可能牽涉到深層的技術能力，也可能牽涉到需要設計實驗來進行？也就是說想要敏捷，也不一定可以敏捷地起來！持反對意見的人甚至說到：你是資料科學家，你需要不斷的去探索數據可能的價值。這樣說來，似乎又是掉入無窮無盡的深淵之內，而無法自拔。
這篇文章開始，我已經把我個人的態度擺在那邊了，我說到：「要或不要，應該是看你或是你們的需求，必須要靈活思考，而不是一刀兩斷的說：要或是不要。」所以，關鍵不是二分法的要或是不要，而是你是否已經準備好了？當你需要的時候，你就可以隨時拿起來應用了呢？留給自己的機會與事先的準備，是我一再提醒大家需要關注的方向。請注意：無論是數據分析師，還是資料科學家，你的舞台就是在企業內，你一定是團隊中的一分子，或是你帶領團隊，而你面對的是變化相當快速的商業環境，你用甚麼方法，我沒有意見，但是，你的團隊是否能夠即時的應對環境？創造效益？這跟你的收入與獎金是絕對相關的。而即時應對？很抱歉，不是等問題發生才去準備，而是你的事先準備。
Scrum 是敏捷的工作方法之一。當初，設計這個方法，確實是用來優化軟體開發的方法，後來也頗有成效！但是，很多人就因此出現了偏見。英國的敏捷商業聯盟 (Agile Business Consortium)，作為當初敏捷宣言的發起人之一，也針對敏捷商業分析師 (Agile Business Analyst) 的方法，提出了相關的實踐。我的重點是：與其設計一套新的，不如研究別人的好方法，然後在你的場合使用出來，雖然不是很容易，但是，你有其他更好的方法嗎？新年新計畫，多多留意別人的方法，然後優化自己的工作，雖然沒有機會一步到位，但是，不行動，永遠不會超越自己。忙碌是永遠的藉口，簡單的時間規劃，就不用我們在這裡多說了。