2016年6月15日 星期三

[翻譯] 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?

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.

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.

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.


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.