CSM学习第二天，首先感恩自己做出了这个选择，从日常繁忙的工作中专门抽出两天的时间来体验这个工作坊。
我讲的是体验，不是学习，体验最重要的是感受和连接。体验到的东西和学习的东西，在我们内在知识系统中产生的效果是不一样的。前者已经经过了一个转化，变成了自己的东西，而学习可能停留在相对更浅的层次，这也是为什么常规意义上的培训和授课往往听课的效果相对较差，听的时候觉得很有道理，过不了多久可能就忘记的差不多了。也解释了，为什么工作中用了多年的知识一直不能形成一个系统，而仅仅停留在只见树木不见森林的阶段，因为我们太忙，而忘记了让自己停下来，慢一点，用心去感受后体验，去思考和总结。
今天体验后跟我产生连接的关键词是边界:
最近这个词总在各种场景出现在我的面前，以Bob举的一个例子来说:
当开发团队发现，一个SPRINT即将结束的时候，我们还有一个item没有完成，团队遇到这个问题的时候，应该怎么办？
如他所预料的，两个团队都给出了相同的答案:“放到下一个迭代作为最好优先级去执行。”，听起来似乎很有道理，我们日常工作中好像也是这样做的。但我们仿佛忽略了一个问题，PB的梳理的owner应该是PO，所以做这个决定的应该是PO，PO不属于SCRUM团队，团队没有权利来做出这个决定。
这让我想起我们日常生活、工作中好像没有太注意“边界”的概念。比如，SM做着做着把自己做成了保姆，变成了替大家解决各种麻烦的人，搞得自己很累，久而久之自己变成了一个团队的瓶颈。再比如:PO很强势，希望团队做更多的需求，于是乎利用自己的权威强制给团队压了很多团队本迭代根本无法完成的任务……越界替别人做事、做决定，意味着你需要去替别人承担压力和后果，往往累死了自己，却得不到别人的认可，把自己做成了夹心饼干，或把团队做成了命令+控制型的团队，于团队的长远发展是无益的。所以，为什么在SCRUM里是更建议有专职的SM，但在实际工作中，我们很难做到专职，而一旦出现身兼多个角色的时候，对于边界的把握就更加的困难，对于个人在教练的技能的要求上也会更高，把控起来会更加的困难。
再进一步，往生活里看。人与人的相处之道在于，每个人都需要对个人的边界有敬畏和尊重，越界意味着干涉和控制。
最后，聊聊LeSS和SOS，都是用于解决多团队SCRUM运作的一个解决方案，但两者解决问题的方式却不太一样。
SOS更多的是解决多个SCRUM团队之间的沟通、交流、协作的问题。比如:一个项目有5个特性团队，SOS就像搭建了一个平台，当产生依赖的时候去协调解决依赖，并承担一些信息传递，经验共享的作用。当项目制定一个目标时，往往会把目标拆分到各个团队，由团队去制定团队目标，制定改进行动计划以支撑项目目标的达成。
而LeSS，它类似于SCRUM，也定义了一个框架，框架之内是将产品作为一个系统来考虑。比如，和上面相同的一个场景，当项目制定了一个目标时，会从整体开做根因分析，系统的来思考分析这个问题可能改善的地方，并由产品PO梳理出改进的PB，再由团队类似认领需求PBI一样，在SPRINT迭代中去规划实现，以支撑最后项目目标的达成。
两者的根本区别在于，一个是以团队为单位去改进，一个是以系统为单位去改进。而SCRUM团队能做的事情往往比较有限，尤其是运作相对比较稳定后，很容易进入到一个瓶颈期。而LeSS站在系统的角度去做思考如何做，往往能找到根本原因，效果会比较好，但想要把LeSS做好，对项目，对教练的要求会比较高，需要站在一个系统的、全局的高度来做，但我们可以持续去做演进，从SOS开始，逐步走向LeSS。
再次感谢Bob，感谢两天在一起的小伙伴们，让我收获了很棒的体验，产生很多连接。周末了，充实的两天过去了，我想要和家人产生更多的连接，愿大家周末快乐。
