团队，作为一般公司或者组织权责划分的最小管理单元，其管理直接面对一线员工，对团队管理者有着不同于中高层管理者的要求。有人这样形容开发团队管理者：写的了代码，玩的了Word，秀的了PPT，还要做得了心灵导师！
在很多公司里，特别是在开发团队里，团队管理者往往是“技术优而管”，本人也不例外（大言不惭一下）。出身于技术的管理者，往往没有经过专门的管理教育，但是经过一段不太容易的摸爬滚打和自我学习，往往也会形成一套自己的管理风格。
初入管理往往会陷入两个误区：集中控制管理和微观管理。
工作四年开始带领团队，由于是要接手一个厂商开发的基于C/C++的系统，并对其进行技术转移，天天忙着和大家一起处理各种问题，我有幸没有陷入到微观管理的陷阱里，当然也和组织上安排了一位资深的管理者像导师一样一路辅导是分不开的。那是我深深怀念的一段美好时光，可以和大家一起调代码，一起享受经过几天的分析跟踪终于解决了一个“系统不定时假死”的灵异Bug后的欢呼。
刚开始带领团队，我也经过一番对管理知识的自我学习，培训、看书、听视频讲座，不断学习了包括任务管理、时间管理、绩效管理等方方面面能触及到的管理知识。但是，对于自己所在团队的掌控感的不自觉的向往，还是让我不能自拔的陷入集中控制管理的陷阱之中。
进入其中，管理者会有如下表现：
1、希望自己清楚团队工作的每一个细节，并且身体力行的去深入研究和掌握这些细节；
2、希望自己清楚团队成员每一个人的工作内容；
基于以上两点，管理者自己会觉得：
1、自己可以指导团队成员每一项工作和改进，并对自己的意见信心满满；
2、自己可以为所有人进行任务安排，并让所有人都高效的运转。
我一直做的很好，最起码自我感觉是这样，直到终于有一段时间，我感觉力不从心，感觉自己会成为大家的瓶颈。
恰在此时，看到杰克·韦尔奇先生的一句名言：“在GE，我做的最棒的一件事情是创造了一台准确报时的钟。”在企业中，即使是仅仅管理一个小型团队的初级管理者，管理者的目标也应该是打造一座可以自动运转并精确报时的时钟，而不是自己去报时。
此后，我做了很多针对公司和部门流程在团队工作层面的细化，我称之为“工作细则”，将所有日常团队可以通过自身机制自动处理的工作都落实成团队中众所周知的规则。自己更多的开始关注自身和团队中每一个人的学习和成长，团队的异常事务的处理，团队目标的设定和更高目标的找寻。
一切都看起来很好，……
此时，我“遭遇”了敏捷。
敏捷，是2001年从一个滑雪场发起的一场来自一线软件开发者的革命。2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。
敏捷软件开发方法，在国内的兴起大致在2005年，大多得益于类似于诺基亚等的外企在中国设有的分公司。在中国的当下，敏捷与互联网几乎是同生共荣的，躲在大型组织的角落里的我，从2013年才开始意识到这场软件开发模式的革命夹杂在移动互联网时代到来的号角声中扑面而来。
2013年有幸作为负责人加入了一个新的小组，小组目标是研究互联网新技术，实践敏捷新工艺。由此，我开始接触敏捷，各种上网搜索、各种资料收集、各种买书，新知识的学习总是令人兴奋。利用一个星期的业余时间看完了《Maven实践》，用两天的时间看完《硝烟中的Scrum和XP》。直到现在，对于敏捷入门，我仍然强烈推荐阅读《硝烟中的Scrum和XP》，这是我到目前为止，见过的最好的适用于开发人员的敏捷入门书，最主要的是直观。
随后，参加敏捷基础导入的培训，以及与外部敏捷咨询师的交流，让我终于对于敏捷开始有一点浅浅的理解。
我作为团队管理者的角色参与敏捷推广，一边学习敏捷的思想和方法，一边也在思考团队管理者在组织进行敏捷转型时应该如何自处。
管理者的“神光”并不总是好事。
我遇到的第一个问题是，我作为Scrum Master组织站会的时候，所有的成员说话的时候都看着我，像是在向我汇报昨天的工作进展和今天的工作计划。我知道这样是不对的，敏捷应该引导团队不断向自组织迈进，首要的就是要培养团队成员间的协作意识，进而形成自组织，而站立会议是促成这种成员间协作的主要形式之一。可是我又不知道该如何处理，因为，仅仅告知团队成员说话的时候不要看你或者当你不存在是虚伪的，这种所谓的建议在实际操作层面毫无意义。敏捷教练给我的建议是，你不妨缺席几天的站立会议。
此时，我意识到在组织里相对于其他成员，管理者是有“神光”的，特别是相对于你直接考核和管理的成员。这种所谓“神光”有的时候是有用的，它可以让懒散、推诿和各种组织里的不良邪气见光而散。同时，它也是有害的，它让团队成员不自觉的产生依赖和等待指示的心态。
“敏捷转型下管理者应该如何自处？”
这是我自2013年以来一直在思考的一个问题，通过不断的实践、思考和阅读，在《管理3.0：培养和提升敏捷领导力》一书中找到了一个一些答案的蛛丝马迹。
团队管理的终极目标是打造一个“自组织”的团队，比打造“时钟”的隐喻更进一步，是要打造一个“生命体”，他不仅可以自动报时，还可以响应变化，自我成长。
需要团队管理者首先要做到信任和放手。
“信任和放手”是技术出身的管理者很难做到的，我们总是不自觉的想站出来告诉大家怎么做更高效，更准确，更容易。记得在敏捷咨询教练在场的一次计划会上，我看到几个同事的具体操作方法明显是错误的，我刚要起身去纠正，敏捷教练拉了我一把。他没说话，我诧异了一下，然后我好像明白了他的意思就又坐下了，一会儿同事们发现了自己的问题所在，自己修正了。
作为团队管理者，不能仅仅关注团队这一次把事情做对了，关键是，团队通过自己的成长持续的把事情做对，以致做得更好。拔起来的苗和自己长起来的苗是不一样的。
当然，信任不是冷漠，放手与放弃也只是一字之差，“度”的把握一直是中华民族最伟大的智慧。
自组织团队需要适度的灰度管理作为土壤，以管理者的自律来浇灌。
任正非先生2010年有一篇文章叫做《管理的灰度》，说的是管理者妥协的艺术，也就是企业管理中“内方外圆”的智慧。我这里说的“灰度”是另外一个维度，是一种有意的“视而不见”和“不打扰”。
作为团队管理者，对团队中的所有事物的细节都有一种天然的“好奇心”，这种“好奇心”可能来自于对自己管理工作安全感的需要，也可能出于自身掌控欲望的驱使，或者干脆就是纯粹的好奇。
要想打造敏捷的自组织团队，需要管理者对自己的这种好奇心有足够的自律和戒心。
在敏捷咨询过程中，有一次团队进行敏捷回顾，是敏捷咨询师在主持，我端着自己的水杯，夹着本子很自然的就推门而入了。咨询师拦住我问团队，“他被邀请了吗？”团队成员有的傻笑，有的不说话，有几个起哄的说“没有——”。咨询师就知道怎么回事了。然后，我被请到门外等待，咨询师开始征求团队的意见，大意是我的进入会不会影响团队的回顾效果。
这件事对我触动很大，仿佛有一种被当头棒喝后的顿悟。工作中，能够瞬间触动自己，进而通过自省，让自己成长和领悟的事件往往是有代价的，一般都是自己犯了比较大的错误。像这种被堵在门口就能小成本感悟的机缘，的确难得，因而我至今记忆犹新。
团队管理者要打造敏捷的自组织团队，必须给予团队足够的属于团队自己的空间。因为既然是“生命体”，就是有隐私的，就不像“时钟”一样，随时都可以打开看看里面的齿轮转的怎么样。需要一些不同的沟通方式和管理方法。
敏捷转型对于软件开发组织是一场关于开发工艺、开发方法以及管理思维的转变，我还在不断学习和思考的路上，一点感悟，以启来者。（本资讯于2016-07-05首次发布）
