1. Tech Lead转型做Scrum Master
Jimmy是一位资深的高级开发工程师，为人靠谱，技术过硬。因为公司敏捷转型需要，上级很自然地将scrum master这个在转型中起到关键作用地角色交给了Jimmy。Jimmy也十分尽责，每天召开大家一起开站会，为了保证会议的高效性，他在站会的时候认真地将大家反馈上来的疑点难点记录下来，在会后找到相应的人员了解情况，解决问题。
久而久之，团队对于Jimmy的专业能力赞不绝口，团队成员也乐于向Jimmy请教问题，开发遇到问题不能决定时的第一想法就是Jimmy会解决的。Jimmy虽然很开心能够受到大家的信赖，但同时心里也有一些潜在的疑惑和担忧，他感到自己的负担越来越重，有时甚至成为了团队的瓶颈，而开发同学的独立思考能力却好像下降了，有些事情明明并没有那么困难，却依旧需要他的指导才能完成。
实际上，敏捷提倡的时发展一个自组织团队，团队能够自发地进行学习，自我提升，scrum master在这个里面不同于tech lead，是需要激发团队成员学习地积极性，自发地去寻找解决问题的办法，培养解决问题的能力，而不是直接上手“替”成员解决问题。
2. PM转型做Scrum Master
Joey是一位出色的产品经理，他做事细致，考虑问题全面，他设计的产品通常都能很好地满足客户的需求，相应的，他也非常了解产品的业务架构。和Jimmy一样，在新成立的敏捷团队中，他成为了一名新任的Scrum Master。
Joey非常喜欢看板的设计，这让整个团队的开发进度一目了然。让他头痛的是，总会有一些开发同学忘记更新自己的ticket导致看板不能准确地反映出团队的现状。Joey素来雷厉风行，他在站会上了解到大家的工作进度后，在站会上直接将ticket挪动到了正确的位置。保证了看板至少在daily的节奏上是准确的。
他对自己的做法并没有更多的考虑，但是他渐渐发现，他在站会上需要更正的ticket越来越多了。
实际上，看板作为一个工具，是来辅助团队内部沟通以及团队和外部的沟通的，而不仅仅是一个对外汇报的工具，团队需要认识到看板工具对于自身沟通的帮助，对完成团队承诺的帮助，进而自发地去使用看板来发布信息。
