Agility at an eCommerce Startup Lessons Learned Robert Galen Director, Product Development bob.galen@channeladvisor.com

1. Agility at an eCommerce Startup Lessons Learned Robert Galen Director, Product Development bob.galen@channeladvisor.com

2. Agenda • A Little About ChannelAdvisor • ChannelAdvisor Agile Overview • Domain Centric Challenges • How We’ve ‘Implemented’ Agility • Tools Path • Plans for “Next Steps” • Key Learnings • Q&A

3. ChannelAdvisor Overview • Founded July 2001 as spinout from Overture (Yahoo! Search Marketing) • Leading on-demand software platform for managing eCommerce channels • Drives increased customer revenues, higher ROI • Headquartered in RTP, NC, with offices in Atlanta, Seattle, London, Berlin, Limerick, and Australia • Over $1.6B in GMV (Gross Merchandise Volume) processed in 2006, $2B+ in 07 • 100+ Enterprise customers, 900+ SMB customers, 5500 customers total • Integrated product suite • Paid Search/Natural Search • Comparison Shopping Engines • Marketplaces • SMB eCommerce stores • Business model: SaaS • Growing at 65+% y/y • Subscription + Transactional

4. Ecommerce – Large and Growing (20+%) Market • US and European Online General Merchandise Market for the next 5 years in $ billions • Forrester Research, October 2006 “US eCommerce Five-year forecast and data overview.” ChannelAdvisor excludes food, travel, grocery, beverage and event tickets.

5. Reasons for Retailer to Leverage Software

6. Agility at an eCommerce Start-up

7. Agile Adoption Timeline • In late 2006 adopted Scrum as agile methodology • Rally Software delivered consulting & tooling (Rally) • Piloted within our Paid Search team (6 months) • In June 2007 rolled out Scrum across our organization • Organizationally (SLT, cross-functionally) • Organizationally, we have ~ 60-70 developers, ~12-15 testers, and ~6-8 product managers • RTP, NC development team - baseline • Atlanta, GA development team – introduced in January 2008 • Limerick, IE development team – introduced in April 2008

8. Agile Adoption Timeline • In late 2007, co-located the core NC teams in our Agile Development Center • Developers, Testers, Product Owners co-located • Low fidelity planning spaces • Collaborative environment • We’re midway thru 2008 as a fairly well integrated Agile team—continuously learning

9. A Few of Our Challenges • Software as a Service (SaaS) is a challenging model • Expected (required) quality levels • Customer proximity & expectations • 7x24 demands • Legacy codebase • Brittleness of historic components (VB6, COM) • Lack of unit tests and general test automation • Inherent complexity—lack of a proper layered architecture All -- inhibiting Agile practices • Database code (stored procedures) not connected to Continuous Integration (CI)

10. A Few of Our Challenges • Limited / specialized domain expertise within the engineering staff • Driving multi-project assignments • Early on +90% of the team was multi-tasking • Little time for cross-training • Lack of test automation at all levels • Traditional automation – QTP regression scripts, tough to maintain, limited coverage, and focused on the UI • 10% automation and 90% manual testing • Little to no unit or feature-driven testing • Large backlog of defects and high customer support levels • Varied per product line • Historical nature of codebase evolution

11. Product Stability & Brittleness

12. Our Agile Implementation • Scrum as the “Wrapper” agile framework • Product Backlog(s) drive all work; Product Owners drive the Backlog(s) • 2 week Sprints • Self-directed teams: estimates, approaches, delivery • Extreme Programming practices • Continuous Integration • Refactoring and Emergent (Simple) Design • Test-Driven Development (Unit Testing) • User Stories • Customer-Driven Testing (Acceptance Testing) • Some informal pairing going on • Lean ‘Thinking’ • Just-in-Time; Just Enough; Few things ‘in process’; Focus on ‘Done’ • Feedback loops w/Stop the Line mentality; Systems thinking

13. Our Agile Implementation • Scrum of Scrums • For team composition planning; dependencies; release planning • Cross Product Owner communication; organizational visibility • Developed 3 levels: • S2 – cross team dependencies • S3 – team staffing & resource needs • S4 – Scrum ‘leadership’ • Spent significant time on organizational learning • SLT Agile introduction • Cross-functional team (service, support, finance, operations, etc.) introductions • TDD & User stories • Developing internal Scrum Masters • Peer-to-peer feedback

14. Agility Example – Scrum Source: Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. 24 hours Daily Scrum Meeting Backlog tasks expanded by Team 2 weeks Sprint Backlog Potentially Shippable Product Increment Product Backlog As prioritized by Product Owner

16. Initially installed Rally as the “central” tool for all planning & tracking We had a Wiki (Confluence - Atlassian) as well But agility is less about tools So we “retired” Rally and began to… Use cards, Post-it notes, whiteboard & corkboard tracking, flip charts – very low fidelity team planning tools Use the Wiki as a more permanent archive Today we’re still quite low fidelity Installing JIRA for bug / issue tracking; installed agile plug-in and may use it as a collaborative tool Continue to track all Sprints via the Wiki (Product/Sprint Backlogs, Burndowns, Capacity, Velocity) Teams seem to ‘like’ the cards and drawing on walls… Our Tools Path…

17. Our Way Forward • Organizationally • We’re blessed with a very solid Product Manager (Product Owner) team. Simply continue to collaborate, partner, and grow – together • Scrum of Scrums still evolving; - ad-hoc meetings & leadership • Sr. leadership is very supportive of agility; we need to show results! • Foster more Lean Thinking across the entire team • Tools & Techniques • Will probably extend our use of Atlassian tools; they seem to “get” agility • Fisheye connector for Jira – Subversion • Crucible for code review collaboration • However, keeping things simple and team collaboration will be the rule • At a team member level—enable efficiency improvements within individual teams • Always consider visibility

18. Our Way Forward • Continuous Integration • CruiseControl.net; NAnt; Subversion • Moving from environment to environment part of our efforts – so failed build vs. failed deployment • Database code and automated environment deployment still a WIP • Focus on Quality • Continue to foster a Team View (not QA team view) to overall quality—it’s everyone’s job • Brought in Test-Drive Development (TDD) / FIT class in late January 2008; still trying to hone our adoption of TDD • Tremendous upside to our testing connection towards CI • We’ve been experimenting with code reviews (inspection and learning) • QA team is driving automation of our existing higher level, business tests

19. Our Way Forward • Architecture • Refactoring as we move forward and to some degree on our legacy • Making the case for component replacements • Learning how to effectively balance Emergent (or Just Enough) architecture as we replace old and build new components • Teams • Smaller teams (4-5) members are best; try to keep them together • We’d like to improve on our “Slack” time • Continue to reduce multi-tasking; cross-training on our legacy; improve new hire mentoring & training • Invest in training for our teams; foster self-directed learning

20. A Few Lessons Learned • Organizational level training is a must • Everyone needs to have a fundamental understanding of the shift • Establish internal expertise / coaches; continuously improve skills • The “power” of transparency or visibility! • Removes wishful thinking; reality-based • Convincing yourself that you can build systems in “small pieces” is hard! • Automation is a MUST for effective agile adoption • In non-Greenfield environments – you must remain patient • It is a PATH • Our approach is incremental agility; learning & adapting as we go…

21. One Important Point • Agile practices are WORKING at ChannelAdvisor • We’re engaging our customers—delivering value from their perspective • We’ve improved our delivery reliability & held to our quality goals • We’re focusing on the ‘right’ things • The teams are thriving in the methods; would NEVER go back to Waterfall • We’re inspecting & adapting; learning and changing as we grow