客户案例:敏捷转型的二三事儿

在接触敏捷的这一段时间内,也听了不少曲折离奇的故事。很少有团队在转型敏捷的时候,没有系统学习或外力支持就能做的风生水起。毕竟这里面的“水”很深。


比较巧合的是,我所供职的公司目前便在做敏捷转型。不过,我们的转型过程并不是顺风顺水的。因此,在转型过程中,我们注意到的那些“ 事儿”,你也一定关心。

领导是在充分认识到敏捷的益处之后,决定转型敏捷的。因为敏捷所提倡的“拥抱变化”更适应公司的开发过程:尽管公司是 To B 企业,但用户参与度依旧很高,这就导致产品经理在与用户代表对接的过程中,会不断地产生产品需求更改的情况。既然是这样,那么沿用瀑布开发的模式就显得有些笨重了。

 

困难一:全员敏捷

 

决定要转型敏捷之后,如何让公司全员了解敏捷呢?第一个困难出现了。

针对这一问题,公司开始引入敏捷方法论的知识,推动全员进行敏捷方法论的学习,包括制定学习计划来督促大家的学习进度:观看敏捷相关视频、阅读敏捷书籍等。在有了一定的理论知识之后,敏捷开发的推进就稍显轻松。

顾虑到除研发部门外,其他业务部门转型敏捷的优先级并不算高,公司决定先将研发部门划为试点部门,小范围试行敏捷。所以就出现了每天早上,其他部门的同事都要去看一看研发部门有没有在开站立会议的现象。尤其是将 Scrum 流程融入到日常办公中时,这给同事们带来了一种之前从未体验过的新鲜感。这种新鲜感让其他业务部门不仅有了对敏捷一探究竟的好奇心,还开始憧憬自己部门转型敏捷之后的“愉快生活”。

minjiekaifa-agile-2

显然,研发部门的敏捷转型成功了,这带给了公司上下莫大的信心。紧接着,其余的业务部门也开始了敏捷转型。实施了一段时间之后,大家发现,转型敏捷是一个非常正确的决策。在大家都沉浸在“转型成功”的欢天喜地的氛围中时,领导又拧紧了眉毛。

 

困难二:流于形式


领导发现,虽然各方面的形式做到位了,但公司实际并没有明显的业务价值的提高,问题出在哪里?

考虑了一下,领导选择请一位敏捷教练,让他到公司实际考察,帮助捋清到底哪里产生了问题。敏捷教练的到来让公司有了意外的收获。教练在各个业务部门之间转了几天,了解了我们的现有敏捷模式,随后指出了几点问题:

  1. 站立会议流于形式,其他人并没有认真听主讲人的工作内容及问题;
  2. 看板的应用不规范,无法得到及时更新,不能传递相应价值;
  3. 工时估算随意,无法体现任务价值等。

minjiekaifa-agile-3

除此之外,敏捷教练还纠正了很多我们在工作中的小问题。在教练的帮助下,虽然大大小小的会议依旧不少,但在不断迭代的过程中,大家都很明显地发现自己的工作计划变得更加完善详实了,其间如果出现与计划不相符的结果,也能很快地找到问题所在。

可以说,我们转型没有失败的很大原因,在于我们将小范围的试点扩大到了整个公司的范围内。除自己公司之外,我也有看到过其他转型敏捷的公司,只是在某一部门中推行敏捷,尽管小范围内的敏捷转型成功了,但它也有相应的局限性,会阻碍敏捷带来的深远影响和战略价值。

除去转型的准备工作,公司也拿出了很多的时间来巩固转型的成果:比如 开展各种敏捷培训, 定期开展工作回顾与总结等,这些无一不在丰富我们对敏捷的认知。

直到现在,我们虽还未转型成功,但也算小有心得。公司员工的愿景一致,是否借助外部力量,还是通过管理工具进行调整,这些都还是次要。最重要的是,公司是否有转型敏捷的毅力与魄力,毕竟这是一场真正的持久战。

往期文章:

从科学管理到丰田生产模式,精益是如何产生的?

第15届敏捷状态报告:敏捷引领全球数字化转型

设计思维 VS 敏捷:两者有什么区别?

posted @ 2021-08-20 10:28  敏捷开发  阅读(135)  评论(0编辑  收藏  举报