Your SlideShare is downloading. ×
0
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Buy.norton.com experience report
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Buy.norton.com experience report

122

Published on

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
122
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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! .

×