[翻譯] Bring Agile to the Whole Organization

原文出自:
https://hbr.org/2014/11/bring-agile-to-the-whole-organization
by Jeff Gothelf

Software has eaten the world. And as it continues to consume new and diverse industries it’s transforming the way business is done. We are all in the “software business” now, regardless of the product or service we provide, forcing us to reexamine how we structure and manage our organizations.
軟體正蠶食鯨吞著這個世界，當他把新興的或不同的產業吞下肚子時，也正在改變做生意的方法，我們所有人現在都在所謂的『軟體產業』裡面了，不管我們做什麼服務或產品，我們都必須重新檢視如何組織並管理我們的公司。


When I ask managers if their organizations practice “agile” they almost always say yes. Probing a bit deeper reveals that most of this agility starts and ends with the product development teams – specifically software engineering. There is rarely a mention of “agile in the HR group” or “continuous improvement in finance.” And yet, it is in these infrastructural disciplines that agility must take root to support software-driven businesses.
當我問主管們說，你們的公司是否有在實行敏捷，他們大部分都說 Yes。深入一點了解的話，會發現其實所謂的敏捷只在 product development teams，特別是軟體部分．很少聽到像是『人資部門的敏捷度』或是『持續改善的財務部門』。但是，這都是為了要做軟體為導向的生意所必須的基礎建設與基本的紀律。


As the nature of software continues to shift towards continuous delivery, we are able to create a new type of conversation with the marketplace – a continuous one. We deploy products, observe, measure, interview, learn, and optimize in hours, not months. Decisions are made quickly. Directions shift overnight. To support this rapid, iterative optimization of our business the internal organizations that staff, fund, manage, and reward our people need to exhibit that same level of agility. “The way we’ve always done it” starts to put the management tier in direct conflict with the potential of the execution teams.
軟體的本質就是會向持續交付(Continuous Delivery)移動，我們就是有辦法與市場創造出新型態的對話，而這種對話是持續不斷的．我們佈建產品，量測他，然後與使用者做面對面的交流，從中學習後作最佳化，這一切不是幾個月的事情，而是只發生在幾個小時之內。決定事情很快速，而整體的產品方向可能隔天就變了。為了要跟上這麼快的節奏，所以要不停的對產品做迭代式的最佳化(iterative optimization)，而公司內部對於人員的組成，薪資，管理與獎懲的部分也需要有相同等級的敏捷性。『過去我們都是這樣做的』會在管理階層與執行階層造成直接的矛盾。


Let’s take a look at HR first. The object around which most HR organizations operate is the job requisition. A traditional job requisition is usually nothing more than a list of tools and capabilities buffered by ambiguous language about “self-starters” and “team players.” These job descriptions are written to fill a gap in a discipline-specific silo (e.g., the software engineering team or the design team). Recruiters, incentivized to fill roles quickly, scour resumes for these skillsets ensuring that anything that makes it through to the next round has “ticked all the boxes.” Three years of Rails? Check. GitHub? Check. Candidates are passed on to hiring managers who are then pressured to make a decision – ensuring the HR teams hit their time-to-fill quotas.
先說HR吧，大部分HR的工作大概是招人，找人來上班；傳統做法大概就是在Job Description內列出工具與能力，再塞一些偉大的詞像是『self-starters』或是『Team Players』。這些都是為了紀律為主的團隊而列的（像是軟體團隊或是設計團隊）。Recruiters 傾向趕快找到人，快速的篩選履歷，在應徵者進到下一輪面試之前，必須先確定他已經符合了某些條件，比如：三年的RoR經驗？有，打個勾；GitHub？有，打個勾。然後用人主管必須在HR的壓力下做出決定，以確保HR的招人Quota有達標。


This style of hiring doesn’t build organizational agility. Quite the contrary, it reinforces the barriers between disciplines and minimizes cooperation. Instead, HR teams need to start hiring for creativity, collaboration and curiosity. They need to seek out the non-conformists — the candidates that don’t easily fit into a box. These are the generalists with an entrepreneurial spirit. They’re the multi-faceted tinkerers who have specialized in a discipline like design but turn out to be pretty good coders. They’re the skeptical members of the team. The ones always pushing back on the status quo and forcing the business to rethink the way it presents itself to its customers. New hiring practices have to be put into places to attract these candidates. Interview structures and exercises have to be completely rethought. It’s nearly impossible to assess a candidate’s collaboration skills in a one-hour Q&A. What do we need to change in order to learn if this new candidate is the innovator that will push our company forward? How do we ensure that our hiring practices continue to improve as the nature of our business evolves?
這樣徵人不會讓公司變的敏捷的，事實上正好相反，這樣的做法增加了部門之間的障礙，也降低了部門間的合作。HR部門應該要開始徵一些有創意的，可以協同合作的與有好奇心的人來，要找一些不願意墨守成規的，不在框框內思考的人．他們是有著創業精神的通才，他們是多面向的工匠卻也專精在某個領域，像是設計，而且剛好又是個不錯的coder。他們在團隊裡面常抱持的懷疑態度，讓他們不斷挑戰現狀，並且讓公司重新思考公司本身在客戶面前所呈現的樣貌。新的徵人方法必須吸引這些優秀的應徵者來，面試的架構與方法也必須完全重新思考。要在一個小時之內的問答之間來判斷面試者的能力幾乎是不可能的，我們要做出什麼改變，才能學到怎麼知道這個面試者會是推動公司前進的創新者？我們如何確定在公司不斷進化的同時，我們的徵人的方法也可以隨著進步？


If we’re hiring ever-curious, entrepreneurial team members, the next logical question is how do we incentivize and retain them? In the past, we’d just assign them to a team; give them a project to build and if they shipped on time and on budget (or at least close enough to it) they got rewarded in some way. That’s not enough anymore. Financial compensation is not the main motivator for these folks. Building something meaningful, something they can call their own holds much more value. Is there a way for us to rethink compensation structures to include equity (or at least upside) for the ideas our collaborative teams create?
如果我們真的找了最有好奇心的，最有創業精神的人，那麼下一個問題就是，如何激勵並留住這些人才？過去的做法是，把他們丟到某個團隊，給他們某個專案做，如果在時間預算內(或是，至少接近)作出來了，那他們就會得到某種獎賞。這已經不夠了。金錢上的獎勵對這群人來說已經不是主要的激勵了。對他們來說更有價值的事情是，做出某個有意義的東西，某個他們可以驕傲的說『是我做的』的東西，所以，是不是我們該思考的是一個新的獎賞制度，來對團隊所創造的想法做獎賞？

Project funding is another monolith that must conform to our new reality. CFO’s want to know what will ship in return for funding an initiative. While there is never a shortage of answers (you are trying to get funded after all), the true answer is rarely given – we don’t know. There is an ambiguity in software development that renders the end state unknowable. Unpredictable levels of complexity, market turmoil, and shifts in customer behavior put any product roadmap longer than four to six weeks at a high risk of quickly becoming an outdated artifact.
專案的金錢來源(Funding)也是另一個必須符合新的現狀的大事情，CFO需要知道金錢投資會變出什麼來，其實啊，這有千千萬萬種答案，你總會想到的(因為我們必須要這些Funding才能做事)。但真正的答案是：『我不知道』。軟體開發的不明確之處就是，無法一開始就知道開發到什麼狀態是可以結束了，無法預期的複雜度加上混亂的市場加上使用者的行為也會改變，使得roadmap超過4到6周的產品，會有很高的機會變成落伍的半成品。


Taking a cue from the startup world, the CFO’s office needs to start treating each team as an in-house startup – a group of people tasked with solving a business problem. That business problem has an objective, measurable goal that ultimately determines the team’s success. At the end of each funding period, the teams must present their cases to the finance office for re-funding. This builds a cadenced resilience into the way the organization makes decisions, allowing it to make short commitments and then further those commitments or not, based on real-time market-based realities as opposed to lofty predictions of a future state that may never come.
來參考一下Startup界吧，CFO必須把各個團隊當成是內部的Startups，也就是為了解決某個商業問題的一群人。商業問題會有一個可量測的目標，這最終決定了這個團隊的成功與否。在每段 Funding 結束後，為了取得下一段的Funding，團隊必須呈現他們的成果給CFO，這在公司或組織內部當要下決定時，會形成一種節奏，讓團隊或組織或公司基於即時的市場的現實狀況，可以先對短期的目標做出承諾，然後再考慮是否要承諾長一點的目標；而不是基於對未來作出華麗的預測下決定，因為那美好而華麗的未來通常不會發生！


Lastly, decision-making hierarchies need to change. Traditionally decisions are run past layers of management ensuring everyone is bought in before direction shifts. These processes are slow. They provide cover in the event that someone makes a mistake. Agility in the organization requires decision-making to be done as close to the customer feedback as possible. The teams working on the products need to be able to quickly decide how to move forward based on the continuous inbound stream of market insight. Making mistakes shouldn’t be a capital crime. Instead, mistakes should be quickly analyzed and any new information should be incorporated into the next set of tactics.
最後，『做決定』的階層也要改變。傳統做法是，決定方向要轉變之前，先確定大家都買帳，所以會經過好幾層管理階層來來回回，這，太慢了。但如果有人做了錯誤的決定，這樣的過程會造成保護，不至於犯錯。可是敏捷是希望當客戶有回應(feedback)時，越快做出決策越好，開發團隊需要持續不斷的知道行銷或市場的狀況，而決定如何把產品向前推進。在這樣的情況下，相對容易出現錯誤的決定，錯誤的決定不是滔天大罪，相反的，我們要盡快的分析這些錯誤，在這之中，如果得到了任何新的資訊，都應該在思考下一個戰略目標時考慮進來。

Incentives should support measuring outcomes, making evidence-based decisions, and learning. The culture of software development allows all of this, but without organizational support, the teams can’t take full advantage of it. At the end of the day, the day-to-day tactical decisions the teams make should not be the concern of managers. Instead, managers should focus on the teams’ progress towards the strategic business objectives. To allay managerial anxiety and ensure broader strategic cohesion, the onus falls on the teams to communicate back to the organization as much as possible. They must proactively report on their tactics, learnings, progress, and next steps. However, without the safety to report the whole process, warts and all, most teams will opt for safety and predictability – effectively undermining their agility.
獎賞與薪酬應該是藉由衡量產出的結果，基於證據做出的決定還有學習的過程而來，軟體開發的文化是允許這樣的，但若沒有公司的支持，團隊便無法享受其利。每天下班前，由團隊所做的每日戰略目標(譯者註，就是進度的意思)不該是主管的事，相反的，主管們應該少看團隊進度，而更聚焦在商業目標上。但為了減輕管理層的焦急與確保各層之間的策略是一致的，公司或組織與開發團隊的溝通要越多越好，而，這是開發團隊的職責，開發團隊必須要積極的報告他們的戰略，學習到的東西，目前進度以及接下來下一步要做什麼。但是，如果團隊假如報告了壞消息卻被責備時，那麼團隊可能會更報喜不報憂，會更傾向做出安全而可預測的決定，這會有效的大幅降低敏捷度。


As our companies turn into highly focused software organizations, we must change the way we manage them. A continuous learning environment fueled by round-the-clock customer insight and feedback demands teams, environments, decision-making structures, and funding models that exhibit the true meaning of the word agility — resilience, responsiveness, and learning.
當各公司慢慢的關注軟體開發，我們必須改變管理軟體團隊的方法。持續學習的環境，快速的洞察客戶，持續索求使用者feedback的團隊，這樣的環境，決策結構，跟專案資金的來源，都能展現『敏捷』的含義，那就是強韌，快速反應與持續的學習。



原文出自:
https://hbr.org/2014/11/bring-agile-to-the-whole-organization

Disclaimer: I do not own any rights of this article. I am just volunteering and translating it so that more Traditional Chinese readers can have better access to the concept in the article. Please let me know if you find it improper or having the risks of violating the copyright.