第一次做“敏捷教练”

一位软件产品公司朋友找我，想在公司内部推动敏捷，让我帮忙做研发团队敏捷教练。这是四、五个月前的事情，不久前，团队终于在Scrum模式下完成了一款产品升级，尽管跌跌撞撞，但还是坚持下来了。我在过程中只参加了两次回顾会。

 

第二款产品比第一款困难得多，无论技术难度还是业务复杂度都不在一个量级上，团队里有一半成员经验丰富，另一半几乎是新手。经过商量，他们决定让经验丰富的成员带新手，将项目分成几个大的模块，每个人带一个新手领一个模块。PO和架构师都认为这样既能保证开发进度，也能保证质量，只是将八个人变成四个人的敏捷团队。是这样吗？

 

敏捷模式在达到交付目标过程中，与传统开发模式在策略上有一个很大的差异，传统模式是直接围绕既定的交付目标工作，而敏捷模式是通过最大化成员效率，实现最优的交付目标。传统模式下，项目经理为完成一次交付，会要求成员加班；敏捷模式下，Scrum Master为不断提高成员效率，禁止成员加班。靠加班，只能保证工作量，效率并不提升。

 

敏捷的交付策略是最大化个体效率，从而导致最好的团队效率，最终带来最好的交付结果，交付结果并不是固定不变、项目开始前就定义好的，PO／客户与团队的密切沟通和协作，是保证最优交付结果的前提条件。另一个方面，敏捷模式关注人，以个人发展为出发点，实现业务／交付目标。人的发展在前，团队的发展、业务目标在后。传统模式下，团队建设和发展会是个难题，因为团队建设为交付服务，成员发展并不是首要任务，成员甚至要为业务／交付目标做出牺牲。

 

回到刚才的问题上，我问其中一位经验丰富的成员，自己一个人做，和带一个人一起做，哪个更快？他想了想，说自己做更快。

 

我们已经知道敏捷团队关注个人效率，但只有独立完成工作才有个人效率。如果没有人带，新手怎么参与项目，怎么成长？目前他们甚至不能理解架构，靠自己怎样完成从设计到实施的过程？

 

眼前的方案，是团队里经验丰富的成员要先写完／设计好底层结构，再由新手完成剩余部分。如果要新手自己设计底层，就需要对架构有深刻的理解，并反复尝试不同的设计方案，直到最终完成，这可能会花10倍、20倍的时间／工作量。我们细想想，给10倍、20倍时间，让新手独立完成一个功能，和在别人帮助下，迅速完成这个功能，哪一个更有利于新手成长？

 

容许新手花费10倍、20倍的时间独立完成工作，是企业对员工真正的投资。急于让新手有所产出，出发点是保证交付目标，而不是人的发展。

 

从PO／客户的角度，他的目标是用最少的预算拿出最优的产品，培养新手不是他最关心的问题。企业应该有独立的预算和部门用于梯队建设和新人培养。

 

同样的，以盈利为目的来开展业务对一个企业看似天经地义，这与开发团队直接以交付为目标是一样，没有分清事情先后顺序。企业获得利润在最后，个人利益和发展应该在前。一个不断为个人发展创造机会，为客户创造价值的企业会变得更有生机和活力，把盈利放在后面，水到渠成。如果一个公司负责人整天忙于获得更多利润，他就会陷入自己编织的利润黑洞里，不能自拔。让公司每一位成员获得更好的发展，拥有更大的价值，在我看是更优的企业盈利战略，也是负责人应该花时间思考的问题。