浅析Scrum落地实施︱敏捷方法转型

引言
 
小编最近在按照Evelyn老师推荐的书单一本本的研读，这篇开始，将梳理《Scrum敏捷软件开发》这本书的“知识点”，希望对小伙伴们有一些帮助。其实小编一开始看到这本书时，觉得是一本很基础的讲授敏捷（Scrum）基础的书籍（小编这次对封面产生了认知偏差），后来经同窗好友[台]Edward推荐，开始研读，然后深感自己“以貌取人”的错误。
 
无论是团队还是组织向Scrum或其他敏捷方法转型时都是比较困难的。而且比许多企业预期的要困难的多。获得敏捷带来的所有回报而必须进行的变革是意义深远的，这些变革不仅要求开发人员也要求企业中其他的成员进行大量的付出。工程实践只是一方面，观念的改变确实完全不同的另一个方面。
有些发起敏捷转型的管理层认为，只给开发人员提供培训和支持就足够了。他们没有考虑到Scrum对销售人员、销售部门甚至财务部门的工作带来的影响。如果这些地方没有改变，组织惰性会把整个公司重新带回原点。 “愿意改变是一种优势，即使意味着某个时间会使公司的某个部分陷入混乱。”
那么我们应该如何做呢？
 
01敏捷转型到底是自下而上还是自上而下？  
前一段时间，我学了Scrum@Scaled Practitioner课程，其中提到了一个观点，叫做 Agile Bubbles（敏捷小泡泡），也就是说，在落地规模化Scrum变革时，可以先组织落地实施一个小团队的Scrum。当一个Team的Scrum做好了以后，它会吸引其他的团队，然后进行规模化的实施，即建立EAT团队 和 EMS团队。在Mike Cohn这本《Scrum 敏捷软件开发》中却不这样认为。Mike Cohn认为成功的组织变革不能完全是自上而下或自下而上。同样，在《拥抱变革：从优秀走向卓越的48个组织转型模式（Fearless Change ：Patterns for Introducing New Ider）》中也同样有写到“我们相信引入变革的最佳方式是自下而上的，同时需要管理层在适当的时候基于支持，包括基层和更高层的。”书中还写到“人们其实没有那么反对变革，他们反对的是被强行改变，如果人们在变革引入中起到一定的作用，会更好地面对处理变革。”自下而上的参与是有必要的，因为团队成员才是工作的主体，他们才知道如何使Scrum在企业内变得更有效。但是一个组织尝试向Scrum转型，如果没有公司高层的支持，他们会遇到基层无法克服的阻力。这常常发生在一个Scrum过程开始影响初始团队的工作的时候。作为应对，中层管理者可能会保护自己的部门而剔除Scrum带来的变化。移除这些类型的障碍和困难，就需要自上而下的支持。
 
02Scrum的好处  
现在越来越多的企业和团队都开始落地敏捷或规模化的敏捷，再讨论敏捷能带来什么好处，显得有些落伍了，但是有些要点还是要提一下。“Scrum 是一个让我们关注于在最短时间内交付高质量商业价值的敏捷框架。（Cohn 2007）” 重点在于交付价值。举个例子，有时我们盲目的在追求发布次数（发布频率），有时我们会说，我们的系统能做到每周（月）发布一个版本，而这个发布次数（频率）和我们企业的Outcome真的有关吗？再比如我们做的是星巴克App的团队，我们真的需要每周（月）Update一次吗？
 
03ADAPT模型  
上图为The House Of Scrum，其中右边的支柱代表了Adapt模型，它是指成功、持续实施Scrum必备的五个活动：1、意识（Awareness）：当前的过程已不能实现可接受的结果。2、渴望（Desire）：把实施Scrum作为一种方法来解决当前的问题。3、能力（Ability）：有能力成功实施Scrum。4、推广（Promotion）：通过分享经验来推广Scrum，从而能让我们记住并能让他人看到我们的成功。5、传递（Transfer）：把实施Scrum带来的影响扩大到整个公司。这五个活动，意识、愿望、能力、推广以及传递，使用英文的首字母缩写为ADAPT。意识、愿望和能力是相互重叠的，而推广和传递在整个转型过程中会重复出现。在开始转型之后，这个循环还会随着改进持续下去。