世界 IT 公司 20 强企业的敏捷转型实例

本文来自作者 沈灏（Steve） 在 GitChat 上分享 「世界 IT 公司 20 强企业的敏捷转型实例」，「阅读原文」查看交流实录。

「文末高能」

编辑 | 哈比

敏捷转型案例—某数据通信巨头

我将分下面的几部分来分享这个案例：

1. 案例的背景；

2. 大略的转型成果；

3. 大致的演进历程；

4. 四个主要阶段的得失；

5. 管理和工程实践的总结；

6. 转型可继续改进处；

7. 个人小结。

案例的背景

• IT communication products, 50% + Global Mkt share, Revenue = 2B US$/Yr

• Market competition is high

• Nearly 5 Years of this transformation

• People

  • Cross continental PDCA

  • About 170 people to be transformed into 14 scrum teams in China

  • Functional org-chart: Arch, Dev, SysTest, Alpha/Beta, HW, Sustaining, etc

• Quality is the 1st priority on delivery

• Traditional Q-Gate review waterfall process

大略的转型成果

• Productivity (1/4 increase at least, 25%+ features delivery capability)

• Quality 1/3 less bugs in Final Regression, bug # on field less than earlier release. Note, this company has an industry wide fame for its STRONG quality)

• Regression phase 50% cut (7 wks to less than 3 wks, more time for feature dev)

• Shorter Release Cadence (from 12 to 3 months)

  • Portfolio: Biz value (IRR-ROI) based team # allocation

  • Feature: Priority by Kano, and then Karl Wieger,  when needed

  • Agile Release Train

• • Release Level Ceremonies
    

    
    

• • Rolling wave release backlog adjustment before the final release

  • X-teams demo, there are team & sys level US/feature demo and feedback. If it’s not too late as in regression phase, rolling wave planning is still possible

  • Priority Method:

  • New Org-Chart
    

大致的演进历程

• 阶段〇 ：we tried mini-waterfall (phased delivery), cutting the whole release timeline into 3 parts, each 3-4 months

  • Documents driven work flow: MRD->PRD->SFS->SDS/TestPlan

  • Each function still worked in a silo mode

• 阶段一 ：Agile basics, Scrum framework & basic practices

• 阶段二 ：Solidify basics with focus on US DoR and Delivery DoD

• 阶段三 ：Single backlog & X-team PDCA processes

• 阶段四 ：Ops review & Maturity on X-releases

敏捷实践的 4 个主要阶段

阶段一

• Agile basics. Scrum framework; Kanban for HW/Arch/sustaining, ~1 year on a top priority new product.

• Good parts:

  • Release run in Agile with easier managed Req change

  • Improved Dev & Business alignment by frequency

  • Quicker increments from teams at sprint end

  • Risks are exposed and managed earlier

  • Improved project visibility to Top mgmt

  • Benefits to top-mgmt and prod/mkt:

  • Scrum teams & Roles are in place, though they are virtual and large (10+)

  • Product & Sprint Backlog are in place but are almost horizontal and requirements need to be finished more than a 3-week-sprint

  • System Test automation started and later separately as a single project

  • Teams use proto-Kanban or Scrum task board see better cooperation

• Lessons Learned:

  • Delivery cadence is unstable, though we see increments at some sprint end

  • Team has no bandwidth to digest Scrum framework & practices

  • Virtual team can work with 5 events clumsily while disturbance to them is too much

  • Managers plan and assign tasks to team members, esp. when US were horizontal and schedule was at risk (some of them are SM/PO).

  • X-teams PDCA is mostly driven by Mgrs/PgM, more in a component based way

  • Agile practices and existing tools need better integration

  • 5 events, Roles, Artifacts, and Tools:

  • Kanban is task-based, just visualized, some WIP to prevent over-burden, seldom address bottleneck

  • 6 teams to start agile piloting is too challenging for a top priority new product, because of the extra Agile “process” complexity at team and X-teams level, but we found out places to improve and internal agile activists.

  • We learnt aftermath that the 1st step is better to have a trial on the new way of working to learn the impact & gap and identify who are the change agents, not on a top priority program. Even if teams & mid-mgmt want to learn the new way, a top priority project won’t allow a deep drop of the delivery performance, nor a “long” period of time of undesired delivery performance. Top-mgmt has limited patience, so we need to manage this with special effort.
    

阶段二

• Solidify Basic Practices, focus on DoR/DoD, and intro XP engineering practices (ATDD & CI & automation enhancement), ~1 year

• Good parts:

  • CI with CB/ UT/ Coverage/ StaticAnalysis/ BuildSanity/ Daily Regression

  • 100% new feature automated when applicable

  • Main branch development with Git/Gerrit

  • DoD at US level, e.g. UT/critical bug#/X-US test/just enough Doc/ etc

  • Smaller sprint end delivery increments

  • Better in-sprint quality with ATDD

  • Grooming mtg is 1 wk before Sprint Planning, and US are vertical slices mostly

  • UX to be 1 sprint DoR-ed in advance

  • DoR checklist is in place, e.g. Assumption /ScopeNotIn /Dependencies /Scenario

  • 2-E2E-feature team for a release run in scrum, grasp the basics

  • Better cadence & predictability

  • Better Productivity

  • CoP along with team self-learning help building up agile capability

  • Lead by example PO/SM-PgM & dedicated teams on the release

• Lessons Learned:

  • Smaller req in US becomes demanding for PO/Team

  • Delivery cadence is still unstable, as we still have carry-overs

  • ATDD needs more investment on automation and CI

  • Managers’ role in Agile is to be further explored, instead of just command & control or fully hands-off to the other extreme

  • Project scrum team members are dismissed back into functional team after release

阶段三

• Single Backlog & X-teams. 6+ teams (1 team in US) in a common rel ~1 year, other rels with 2-4 teams,

• Good parts:

  • 1 Rel integration team to lead X-teams integration & hardening (like SAFe’s sys team); Scrum teams do regression on other teams’ features

  • Release PgM monitors/controls for Rel PDCA at each sprint, e.g. Rel Backlog DoR for sprint+1, X-teams sprint integration issue tracking, rel bug trend, etc

  • Release level DoD, e.g. X-teams Gerrit for +2 code review, feature completion/test coverage/bug situation/ security&IP/ doc/ etc

  • System regression successfully spreaded into feature teams and done in 3 wks

  • Managers help remove transformation obstacles & help team by Go See

  • Kanban are workflow based, WIP applied, bottlenecks are managed, but combined tasks with US/bugs

  • Rally is expensive but really powerful for X-teams with basic functions and customization

  • Single release backlog for one common Rel with US mapping

  • Multiple teams grooming & pickup process (X-teams Rel planning on feature & big US => PO of PO for sprint+1 US list => X-teams sprint grooming lunch session => team pick and sprint grooming => sprint planning).  This Rel level DoR process and progress visualized and controled with e-Kanban, with WIP control, e.g. on UX

  • More effective req prioritization, e.g. IRR/Kano/Karl Wieger

  • Better US DoR, by using reference US pts, GWT as AC in a 2-week-sprint cadence, Spike (Research) US was in practice to explore a Req’s DoR

  • X-teams SoS during sprint when needed

  • Code refactoring is common, depending on US’s need

  • Local team level CI emerged from some teams, covering regression

  • 6 permanent teams run in Scrum

  • Release level monitor and control

  • Sys-Testers are good PO candidates for teams

• Lessons Learned:

  • PO is under high pressure for sprint +1/+2 backlog candidates, but dedicated their scrum team, SME, Arch, can surely help at early stage

  • Floating PO (not dedicated) for 1-2 teams are much less constructive

  • Only those who interested in new US grooming to join the X-teams sprint grooming lunch session, no mandatory

  • Performance review & career path in Agile way are challenging

  • CoP needs more support from the top with transformation goals

  • Leverage managers’ expertise on X-rels ops review and its follow-up actions. They help readout the current status to top-mgmt, and accountable for the rel and X-rels level Agile execution.

阶段四

• Ops Review (Governance) & Maturity, X-releases portfolio

• Good parts:

  • PdM/PO quarterly mtg with eng experts, to make Investment adjustment for quarter +1

  • Quarterly estimation/plan by product lines based on investment category, granularity is at Feature (big->small)

  • Product lines are site bounded, and weekly X-sites sync-up for portfolio progress (PdM/PO).

  • No Dev or Test title difference (pair programming between Dev/Test, & Junior/Sr.Dev)

  • SM and PO career path is created by HR

  • Focus on 2 US at a time for better Lead Time

  • E2E direct automation without Automation framework

  • Spontaneous X-teams align for in-sprint delivery and US grooming for +1/+2

  • Releases run in Scrum has ops review to predict, prevent, and improve on each release level flow bottlenecks and issues (Rel obstacles /risks /DoR /Velocity /Quality /RCA for bugs, etc)

  • Mgrs drive on Ops Review, plus removing obstacles from stage III

  • Agile systematic improvement by Agile Maturity Assessment, almost no managers’ interference at team level

  • Ops Review & Maturity

  • Self-managed team could be very proactive & productive, e.g.

  • Career path update by HR

  • Alpha team support alpha deployment per sprint with different scale

  • Portfolio

• Lessons Learned:

  • Team can be more engaged into Agile Transformation, e.g. leveraging them more by adopting more ideas from them (transformation backlog)

  • Team based performance assessment on Self-mgmt capability (DoR/DoD/etc), and then individuals

  • Release financial aspects need to go more with Agile Rel cadence (e.g. no rel commitment mtg and slide deck anymore for Rel’s funding sake, CapEx/OpEx are allocated quarterly)

  • Perspective alignment among Top, mid, and team level could be more frequent and transparent, Agile is not just adopting practices but transformation of the way we think and work.

管理实践的改进

• From team, to X-teams (Rel), and then X-releases (Portfolio)

  • Fixed Rel cadence with corresponding ceremonies for most product lines (~3 months) with visibility and predictability, namely, Quarterly est/plan (portfolio), Release planning (product-line), weekly PdM/PO sync-up (X-rels), PO of PO for Sprint+1 US candidates (rel), Site level grooming, team level grooming.

  • Almost permanent FEATURE teams for all product lines, could be adjusted to other release when needed. Career bath for new roles. Self-org is really doable, at least to the level of mastering individual team process/progress

  • Rally and other tools integration and customization are done progressively

• Agile US Level Management

  • Using US mapping alike practices to have a big picture for X-teams based release level planning. US mapping used for multiple releases and also multiple sprints for a release

  • US conveyed in 3W/ADS/AC (Given/When/Then), so US can split via AC

  • Bug situation and Test cases associated with US, supported by customized tools

• Agile CoP for roles and technologies to let agile activists get more engaged

• Top-down empowerment via governance & maturity

  • Mgrs to remove escalated obstacles, no C&C style on teams

  • Ops review on Rel health in an Agile way (Rel obstacles /risks /DoR /Velocity /Quality /RCA for bugs, etc)

  • Maturity assessment

工程实践的改进

• ATDD is in use but not always test scripts in advance

• Main branch Dev for multiple product lines and CI for regular build, daily regression, weekly regression

• Local CI for private build, new US/feature, and regression sanity check

• Peer and Expert code review (Gerrit +1/+2)

• Pair programming really improves quality and productivity (Dev&Test, SM&Test)

• Code refactoring on demand can improve arch when needed, helps maintainability and testability

• Auto build deployment improves quick feedback and saves time

• Automation cases rate for regression over 60%, for new features over 90%

转型可继续改进处

• Transformation could be more iterative and incremental with targeting benefits

• Strategic people and execution staff could be more interactive in feedback process, with better transparency and alignment

• It will be much helpful if involving more agile activists into the whole agile transformation (more bottom-up)

• Sense of urgency and coaching could be improved for less pain/chaos/waste on people’s cognitive and emotional learning curve

• Institutionalize the good practices and reward excellent agile goers systematically

• Managers’ coaching style could be more structured, e.g. ACI, CEC

• In short, Agile transformation could be more agile/lean itself.

关于激发自组织的小结

• Autonomy：主要在于团队敢于对 how 做出承诺，对 what 大胆提问和建议，并对 Sprint 执行进行 PDCA 的执行和调整。在具体实践中，尽量引导团队的自发性。有时是问题式发问，有时是大概的演示，也有 “激将”，以及带着方案的 “民主” 式讨论。对错相对次要，重要的是，团队的同志们真正参与了 (engaged)。

  即使有争论，那也是建设性的！具体场合有 retro，standup，平时线下接触中的。对待同志们提出的问题，我一定认真对待，找出合理答案才好。team 投票做出的选择，我们必须尊重。

  在我经历的 teams 实践中，如果做出了不太理想的选择，团队还都会自我调整的。而且，有过一定的教训后，一般 team 做出的选择实践证明没啥不好的。他们也知晓步子不能太大，小步前进，夯实每一步。

• Mastery：主要是 team 对掌握技术的广度和深度相联系。这方面我经历的实践是，team 一道确定互相分享和学习的内容。

  以及，工作中能尝试的相关新技术。包括不同角色的互换（dev<->test, > dev<->sm, test<->sm)。sm 也可以参与一些 test 和 po 工作，以及 bug fixing，code review。

• Purpose：主要有几个方面，和团队一起的实践。

  1）对 release 和 sprint BL 的 why 的理解和反馈；

  2）对 sprint 运行 (PDCA) 的管理和改进，如果，控制同时进行的 US(WIP), 不必等到 sprint 结束时再接受 US；

  3）对自我发展的目标进行设置和调整。

个人小结

• Agile transformation is a hard and long journey. When it comes to multiple teams and other supporting functions, it is even harder. It evolves personal, team, X-teams’s behaviorial and cognitive change to make it really effective. In essence, it belongs to Change Management (变革管理). For me, I find the ideas/practices from author below are very helpful, Kurt Lewin, John Kotter, ADKAR, John Fisher, etc.

• The most important driving force in this Agile like grass-root transformation , is the Big Boss’ continuous support. If that support ceases, so does the transformation.  

• Before and along the intro of agile practices, key people’s awareness on why Agile and what Agile means to them need to grow especially. Otherwise, new Agile practices will rollback to where their actual understanding left. Institutionalize the best practices and proper promotion are crucial to root the new practices.

• You can also find helpful info and support from local Agile community, many guys can help, even if they are PMP/CMMi guys.

• A lot of people helped and supported along this journey, and I want to thanks those volunteered from internal community, esp. Xuan, Eleanor, David, Kun, Fiona, and many others…

近期热文

《Jenkins 与 GitLab 的自动化构建之旅》

《通往高级 Java 开发的必经之路》

《谈谈源码泄露 · WEB 安全》

《用 LINQ 编写 C# 都有哪些一招必杀的技巧？》

《机器学习面试干货精讲》

《深入浅出 JS 异步处理技术方案》

《敏捷教练 V 形六步法实战：从布朗运动到深度协作》

「阅读原文」看交流实录，你想知道的都在这里