世界 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