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 & Goals
Charter 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 PMO
Statutory Warning: Smoking too many PMOs is injurious to any corporation's 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 vendor's 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. Engineering
Distributed teams
used Excel-based In addition to tracking tasks
"Daily Scrum Sheet" in sprint plan, we improved
like 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!
.