本文作者在ThoughtWorks工作了12年之久， 回顾了往昔工作之后，他得出了12条经验心得，下面会具体说明。
1. 工具无法取代思考
在我多年的咨询生涯中，每当坐下来与管理者合作解决问题时，经常会遇到这样的情况：管理者认为某个工具能“解决”指定的问题。如果这个问题所涉及的领域很好理解、特例不多，同时每个人都能按照同样的方式来工作，管理者的这种想法是能够成功的。不幸的是，大多情况下事实并非如此。
我目睹了太多次这样的失败：管理者在公司里推行某款工具，而这个工具有特定的运作方式，结果不但没能解决问题，还妨碍了其他解决问题的努力。工具应当是有所帮助的：帮助人们防止已知的错误产生，帮助我们记忆重复性的任务，而不是取代思考本身。
2. 如果公司的管理者团队不懂其价值，那么敏捷“转换”就很难奏效
很多管理者都会犯这样的错误——只要求相关人员“采用敏捷”，但实际上公司里的其他人也是需要向敏捷转变的。在企业中进行这方面的协调会花费大量的时间，并要求对公司不同层级的人员进行同步转变有着丰富的技巧经验。
只在一部分人群中采用敏捷的公司将会面临实际的威胁，正如Martin Fowler所说：“要么改变你的公司，要么换家公司”。
3. 学习需要安全感
学习需要犯错，在技能获取模型中，尤其是新手进阶级的人群需要通过犯错来学习，但如果大家觉得自己会做错事，失去同事的信任，或者还可能祸及进程中的其他人，就不会冒险去犯错。
我是一个热爱教学和学习的人，因此我为人们留出了犯错的空间，让他们可以犯些必要的错误，从而学到经验。
4. 所有人都能成为领导
这个话题我曾经触及过，不过它值得再次重申。常见的心理模型陷阱在于：人们只有在觉得自己想做领导时，才会表现出领导的行止。无论头衔为何，事实证明人们是有潜力成为领导者的，只要他们肯对某项没有明确要求或期望的任务付出行动。
5. 架构师在编写代码时作出最好的决策
在我主持的Tech Lead课程中，我会建议所有技术主管将30%的时间用来编程。将时间花在编程上有助于构建信任、尊重与对当前系统的理解。无视当前的系统来做架构方面的决策，往往只能作出差劲的决策。
6. 需要有改变的勇气
极限编程其中一点就是勇气。在担当领导职责的时候，冒着犯错风险的时候，尝试某样新事物的时候都需要勇气。如果没有风险，通常也没什么回报。
7. 对构建信任而言，言行一致非常重要
有句老话说得好：“依其言而行事，勿观其行而仿之。”事实上无论你说什么，人们首先记住的是你怎么做的，保持言行一致就是确保你的行为与言辞一致，言行不一致会破坏信任。回答“不”或者“现在不行”要比承诺一些做不到的事情好太多。
8. 结对编程的成功与优秀的合作息息相关
尽管并非所有的结对编程环境都很健康，我确信在进展顺利时，团队的合作文化会更佳。许多开发者偏爱基于（长期）分支开发的反面模式，这样一来包括反馈以及与来源潜在冲突在内的一切就会被推迟。
我认为（可导航的）冲突正是团队合作的健康标志，在对长期分支进行代码审查时，如果推迟反馈，则会因交付过迟而造成更多不满。
9. 多样化思考会产出更强大的成果
我在读大学时最喜欢的学科是“哲学导论”，那个学期我们每周都要研究不同的哲学家。在我的职业生涯中，我逐渐懂得欣赏多样化的价值，并通过多个角度来看待问题。系统思维也承认，事实有多种诠释方式，可以引出新的概念或解决方案，也许能带来更好的效果。
10. 欣赏每个人的不同优点
每个人都是独一无二的，所有人都有自己的优缺点。尽管我们倾向于寻求志同道合者，但有着各类不同优势人才的团队更为优秀。在某个领域的优势，在特定情况下也许会成为劣势，而结合各类人才优势的团队则会更加强大。尽管不同的优势会带来冲突，但健康的团队能够欣赏彼此间的差异，而不是互相憎恨。
11. 学习是终其一生的任务
我们周围的世界时刻不停地改变着，因此我们总有机会学些新的技能、技术或者工具。甚至，我们可以学习如何更好地学习，有很多《软件者开发线路图》（Apprenticeship Patterns）以及《前20个小时：如何如何快速学习新技能》（The First 20 Hours）之类的书籍可以让你了解这方面的经验。
12. 积极的影响造就幸福感
著名的《Drive》一书讨论了人们如何通过朝着特定目标努力，来产生幸福感。在我的体验中，这一点经常能够帮助人们找到办法，对他人产生积极影响，这也是为什么Pillar 2（推动IT变革，追求软件卓越）及Pillar 3（积极提倡社会和经济公正）的价值对于我们来说如此重要。
结论
以上12点总结并非我在ThoughtWorks学到的所有经验，但它们确实是我与客户合作时的法宝。