因为ETC与Scrum开发团队一样使用Scrum,所以他们也通过Sprint取得进展。每个ETCSprint以计划会议开始,以评审和回顾会议结束。这些会议和Scrum开发团队的那些会议完全一样,也经常发生同样的问题。来自KeyCorp(美国一家大型的金融机构)的Thomas Seffernick,参加了他所在公司的ETC(也称敏捷实施团队)的第一次回顾会议。他回忆了团队如何犯下许多新Scrum开发团队都有的一个共同错误——与演示工作中取得的进展相比,他们更愿意谈论计划。
因为领导要站着描述他们扫除障碍的计划,所以第一次敏捷实施(ETC)Sprint评审会议比较痛苦。会中传递的信息是清晰的——计划不错,但结果有待证明。此后的评审会议就有变化,结果成为会议的焦点。(2007,202)
一些ETC举行每日站会,我认为这是一项良好的实践。但是,我并不认为必须像Scrum开发团队一定要举行每曰站会那样,坚持要求做到这点。因为ETC成员要完成的工作不像开发团队要完成的工作那样紧密地互相交错,所以每日站会是一件很有价值但非必须的事情。类似地,ETC成员很少是全职的,大多数人已有其他工作,许多时候,他们待在原来的工作上更有意义。例如,对于一位开发部门主管,让他离开自己的岗位而服务于ETC,与任其留在自己的工作岗位相比,无疑后者更有助于排除企业的更多困难。
ETC Sprint的长度取决于ETC成员。不过以我的经验而言,两周是最好的。这也是Ken Schwaber(2007,10)所推荐的Sprint长度。Elizabeth Woodward是指导IBM大规模实施敏捷的ETC成员之一,她如下描述有关他们Sprint长度的经历。
我们用过两周和四周的Sprinto迄今为止,我们看到最成功的是两周的Sprint。我相信其中的原因在于其“交付物”展示的良好势头和对外可见的进展。我们把各个社区的工作收集到一个简短的摘要中——封能让人们在15分钟内读完的电子邮件。发起人和产品负责人很多成功的Scrum实施都由一个明确的发起人(sponsor)启动和推进,发起人是企业中负责成功转型的资深人士。Salesforce.com非常成功的大规模转型就由公司的一位共同创始人Parker Harris发起。作为负责技术的执行副总裁,Harris
处在一个绝佳的位置,可以支持这样的变革——它会显著改变Salesforce.com开发组织中每个人的工作方式。
转型发起人应来自企业正在计划实施转型的部门级别。Salesforce.com需要公司管理层充当发起人,因为其转型是整个企业范围的。如果是部门的转型,那么部门级别的领导是合适的选择。
发起人也是ETC的产品负责人。这意味着,有时ETC的产品负责人是没什么Scrum经验的人。不过没有关系,如同所有的产品负责人一样,ETC的发起人能够通过寻求其他ETC成员的帮助来履行这个职责。作为ETC最资深的成员,发起人将在转型实施沟通中扮演着重要角色,但他不必是转型愿景中唯一的来源,还有其他人。
开始采用Scrum时,Primavera就了解到强势发起人的重要性。BobSchatz和Ibrahim Abdelshafi,当时是Primavera的技术执行官,他们如下描述发起人支持的重要性:
实施敏捷或实施任何重大的变革,都需要管理层真诚的支持。事情得到解决前道路是崎岖不平的,尽管有任何问题或失败,但管理层的支持都能让变革之路坚持下来。(2005,38)
……