1. Symantec eCommerce (buy.norton.com) experience report - Adesh Agarwal, Ebay; and Ravi Tadwalkar, Cisco Enterprise Agile means Succeeding with bit of process and more of collaboration
2. Agenda● Program Charter, Business Driver & Goals● Brief History of "failing slow" twice● Inheriting Legacy- Train model & RUP baggage● Size of Hybrid, multi-vendor & multi-geo PMO● Velocity "Drags" We Faced● Success Toolkit- Collaborate, Collaborate & Collaborate! ○ Product Management ○ Engineering ○ Build/Release Management ○ Command Center for Application Monitoring● Success Factors & Lessons Learned
3. Program Charter, Business Driver & GoalsCharter for “Las Vegas” program:● to create an internally owned and operated eCommerce buy.norton.com to support Consumer/Small/OEM BUs.Business Driver-● Company eCommerce sites were developed by an external provider, except for renewal business.● This created major business problem of paying a significant margin.Business goals-● To focus on both Acquisition and Retention business workflows for Online Sales Channel, to: ○ increase sales margin, revenue parity & maintain business continuity ○ gain control over B2C & B2B platforms built-from-scratch.
4. Brief History of "failing slow" twice● Before we joined ○ Two attempts to create eCommerce (B2C) & eBusiness (B2B) ○ However, result was successive and slooooow failures.● Symptoms & Root causes ○ Lack of strong partnership / vendor relations ■ choice of (wrong) framework & technology ○ Lack of management commitment & perseverance ■ using RUP-based iterative process in wrong way ● big requirements up front- large # of SUCs, each ~20 page ● big design up front- via big design overview handbook ● no PoC/spikes to solidify requirements capture & architecture ● "boards" for everything- ceremonies of inspections & reviews ■ focus was on up-front planning, not on execution ■ middle-management heavy PMO structure
5. Inheriting Legacy- Train model & RUP baggage● Train Model- Not same as software release trains ○ Based on initial scope, PMO created 6 feature teams & 2 transient teams. We used "train" as system metaphor for each feature team, and sub-teams based on cars (“compartments”) of each train. ■ 6 Feature teams: T1:Catalog; T2: eStore; T3: Integration; T4: Support; T5: BI/DW; T6:Framework ■ 2 transient teams: T0: Build/Release process definition, App Monitoring: for Ops control & monitoring ○ Onsite PgMs acted as Scrum masters and began working with these 6 feature teams on transitioning from corporate process to scrum.● RUP Baggage- Transitioning to hybrid-scrum ○ It was a challenging transition (train-ride) to bring the overall LV PMO to get into executing quarterly launch plans, as opposed to having big- bang mega-release launches with RUP-based corporate process. ■ "Before" Team-floor walls had storefront templates & wireframes of web pages ■ "After" Team-floor walls had UML models, scrum boards & timelines.
6. Size of Hybrid, Multi-vendor & Multi-geo PMOStatutory Warning: Smoking too many PMOs is injurious to any corporations long term health.● Program Size for 3rd attempt ○ 2 prior "slow" failures meant cost-consciousness during 1.0 launch. ○ At its peak, LV had 6 feature teams of 180 people onsite/offshore● (16x7) Multi-vendor governance via PMOs ● Infra provisioning- EDS/HP (US); Framework- EP (Canadian Startup) ● StoreFront dev & deploy- HCL (US & India) ● DW/BI- Symantec & HCL (US, Ireland & India)● Legacy of "traditional" PMO meetings ○ we had to create a workable process to accommodate meetings: ○ multi-vendor IT/Infra & Engineering status meetings (weekly) ○ health check status meeting between IT/Engg & Biz VPs (weekly) ○ Ad-hoc dependency tracking meetings- meta-scrum style, no SoS● Meetings we added ○ Daily/multiple multi-shore calls (using Excel-based scrum sheet) ○ IT/Engg & Biz call (delivery managers & leads, @2pm each day)
7. Velocity "Drags" We Faced● NDA "Lock-down"- Strict NDA policy ○ akin to a project requiring security clearance ○ no docs on desks, no share @forums/communities ○ employees from other BUs/departments dis-allowed● "WIP framework" factor ○ An up-and-coming startup delivered work-in-progress framework ○ Dependent teams- core team management, Architects and DBAs - faced "over-commit and under-deliver" situations● Outcomes ○ NDA lock-down introduced "velocity drag", as it was not possible to make references to external vendors UI, due to legal reasons. ■ Adding talent during crunch-time was slower than "Mythical Man Month" says! ■ NDA added lot of paperwork for handling IT issues, e.g. adding laptops/storage. ○ WIP framework factor introduced another drag- it was difficult to get anything on time, within contractual constraints of multi-shore PMO
8. Success Toolkit-Collaborate, Collaborate & Collaborate!● Product Management● Engineering● Build/Release Management● Command Center for Application Monitoring
9. Collaborate, Collaborate & Collaborate!● Collaborate w/ Excel/wiki/scrum-board ○ In war-rooms! ○ On team-floor!
10. Product Management● Quarterly Feature, Site & Product Launch Plans: ● During all-hands meeting, ePM team got updates on "value" of B2C & B2B ○ delivered thru growing revenue numbers daily monitored using enterprise analytics. ● Engineering measured value of program using analytics based business metrics ○ e.g. $/visitor, ○ daily unique visitors, etc.
11. EngineeringDistributed teamsused Excel-based In addition to tracking tasks"Daily Scrum Sheet" in sprint plan, we improvedlike this one: each task estimate by refining it, e.g. each system use case had estimates across architectural layers. For all layers, we added weightage for typical tasks: web content generation, web service mockup, WSDL integration, xUnit test scripting & code review.
12. Build/Release Management● XP best practices like CI and paired programming did not exist before, since corporate process model dealt with check-point reviews, at best.● We created transient team (Train 0) to define build process from scratch: We then created● doing co-development was not co-located always. release team out of this team, to implement continuous integration, while initiating onshore- offshore co- development- just that programming pair.
13. Command Center for Application Monitoring ○ We mentioned about creating a transient team for operations control & monitoring. The cross-functional applications monitoring team needed a command center for monitoring. ○ Launching Command Center for Application Monitoring before, during & after launches gave us 2 things- ■ 24X5 engineering, and 16x7 support model ■ Customer feedback loop based on analytics "playback" feature. ○ Customer Feedback "loop" ■ Even before Lean Startup was published, we applied some principles therein, such as MVP (minimum viable product) and validated learning. ● MVP was realized by applying XP best practices such as Continuous Integration, to release early and often ● Validated learning was realized using business metrics and enterprise analytics best practices - such as A/B testing - to find out what really works and what doesn’t.
14. Success factors & Lessons Learned ○ Success Factors: 100% success via revenue parity & business continuity- based on web analytics tools like TeaLeaf for relevant business metrics. Anecdotes: ■ After 1.0 mega-launch , eCommerce group SVP reiterated that we were doing agile, but not being agile/lean enough to do monthly release-to-web launch, so as to speed up time-to-market. ■ Monthly release-to-web cycle was feasible due to being agile/lean ○ Lessons learned: ■ Although agile/lean was part of cross-functional teams; applying enterprise agile did not mean we avoided false starts ● "scrum-but" syndrome- dev sprint +1 of qa sprint ● "hybrid scrum" syndrome- infra team using waterfall, DW on RUP, eStore/Analytics on scrum. biz-test tried kanban stunt! ■ Enterprise Agile means succeeding with bit of process and more of Collaboration. Collaborate, collaborate & collaborate! .