Robert Fan, Robert Slifka, Sharethrough

1. Evolution of Sharethrough’s
Product Process
From 2008 to 2013

2. The Sharethrough Platform
Powering Advertising For the Modern Web
Sharethrough supports all types of digital content
Distributing your content in the “newsfeeds" of
the Modern Web

3. Our Methodologies Over the Years
Year
Methodology
# of Engineers
# of Product
# of UX
2008
“Cowboy”
3
0
0
2009
Agile Scrum
4-5 *
1
0
2010
DIY XP
3
1
1*
2011
Pivotal XP
3-5
1
0
2012
Pivotal XP
5-8
2
1
2013
Agile XP
10
2
1
* Includes contractors

4. Year 1
“Cowboy’ing it”
I’m cracking on some code at
Sharethrough’s first office located on 650
Mission St. At the time of this picture,
the company was only 5 people.
!
Picture was taken in March 2008.

5. Year 1 - “Cowboy’ing it”
In Theory
1st Phase
of Vision
Build Cycle 1
2nd Phase
of Vision
Build Cycle 2

6. Year 1 - “Cowboy’ing it”
In Reality
1st Vision
2nd Vision
3rd Vision
.
.
.
nth Vision
Build Cycle 1

7. Year 1 - “Cowboy’ing it”
Frequency
Visioning/Roadmap
Daily
Iteration Planning
None
Daily Planning
Sporadic
Feedback
None
Stability/
Predictability
None
Business Engineers
3
3

8. Schedule(
Day$1$
Day$2$
Day$3$
Day$4$
Day$5$
• Daily(Scrum(
• Sprint(Planning(
(1(hr)(
• Daily(Scrum(
• Daily(Scrum(
• Daily(Scrum(
• Daily(Scrum(
Day(6(
Day(7(
Day(8(
Day(9(
Day(10(
• Daily(Scrum(
• Backlog(
Grooming((1(hr)(
• Daily(Scrum(
• Daily(Scrum(
• Daily(Scrum(
• Daily(Scrum(
• Sprint(Demo((15(
min)(
• Sprint(
RetrospecCve((1(
hr)(
Year 2
Agile Scrum
After hours of reading, attending Scrum
school, I summarized all my learnings in
Daily(Roles(
Scrum$Master$
• Burn(Down(Charts(
• Remove(Impediments(
Delivery$Team$
• EsCmates(of(Work(Remaining(
Product$Owner$
• Looking(Ahead(w/(
Business(
• Adding(stories(&(
acceptance(criteria(
a series of slides to the entire company (a
whooping 8 people). This a slide taken
from presentation given on April 24,
2009.

9. Year 2 - Agile Scrum
24 hrs
2 weeks
http://en.wikipedia.org/wiki/Scrum_(software_development)

10. Year 2 - Agile Scrum
In Theory
Database/Backend
Frontend
Testing
Deployment

11. Year 2 - Agile Scrum
In Reality
Database/Backend
Frontend
Testing
Deployment

12. Year 2 - Agile Scrum
Frequency
Visioning/Roadmap
Daily
Iteration Planning
Every 2 Weeks
Daily Planning
Daily
Feedback
Weekly Sprint Demo
& Weekly Retro’s
Stability/
Predictability
Average
Business
3
Product
1
Engineers
5

13. Year 3
DIY XP
After getting tired of everyone throwing
features over the wall to part of the stack,
we started trying out XP.
!
Here are two pictures that represent our
short lived Kanban board (I don’t think
post cards ever ended up on this board)
and one of our first 5 Why’s.

14. Year 3 - DIY XP
In Theory
Testing
Full-Stack
Deployment

15. Year 3 - DIY XP
In Reality
Testing
Full-Stack Development
Deployment
TDD without experience slowed productivity down
and made deployment extremely brittle

16. Year 3 - DIY XP
Frequency
Visioning/Roadmap
Monthly
Iteration Planning
Every 2 Weeks
Daily Planning
Daily
Feedback
Weekly Sprint Demo
& Weekly Retro’s
Stability/
Predictability
Low
Business Engineers
3
3
Product
1

17. Year 4
“Pivotal XP”
In our new offices on Jackson St with
our early pairing stations. This was
toward the end of our engagement with
Pivotal as 3 Pivots came back with us to
ramp the team “down”.

18. Year 4 - Pivotal XP
In Theory
User
Stories
Pivotal
Pivotal
Pivotal
Tracker
Pivotal
Tracker
Tracker
Tracker
Test
Pair Up
Code
Refactor

19. Year 4 - Pivotal XP
In Reality
User
Stories
Pivotal
Pivotal
Pivotal
Tracker
Pivotal
Tracker
Tracker
Tracker
Test
Pair Up
Code
Refactor
With the right discipline this methodology worked for us.

20. Year 4 - Pivotal XP
Frequency
Visioning/Roadmap
Every 3 Months
Iteration Planning
Every Week
Daily Planning
Daily
Feedback
Weekly Retro’s
Stability/
Predictability
High
Engineers
5
Business
10
Product
1

21. Year 5
Balanced Team
Experiment
A former Shaethrough Product Manager
presents Mission Control to key business
stakeholders.

22. Year 5 - Balanced Team Experiment

23. Year 5 - Balanced Team Experiment
Mission Control

24. Year 5 - Balanced Team Experiment
Stakeholder Meeting - Identifying “Problems”

25. Year 5 - Balanced Team Experiment
In Theory
Design Studio
User
Stories
UX
Eng
PM
XP
Process

26. Year 5 - Balanced Team Experiment
In Reality
Design Studio
PM
User
Stories
UX
Eng
XP
Process

27. Year 5 - Balanced Team Experiment
Frequency
Visioning/Roadmap
Every Week
Iteration Planning
Every Week
Daily Planning
Daily
Feedback
Weekly Retro’s
Stability/
Predictability
Average
Engineers
8
Product 2
Design 1
Business
50

28. Year 6 (aka Now)
Agile XP
Pictured here are our two information
radiators. The one on top of our
quarterly roadmap with stories cards
under each milestone. While the one on
bottom represents one teams current
sprint commitment.

29. Year 6 (aka Now) - Agile XP
Inputs
Epics
Cust Dev
Roadmap
Review
Cust Dev
Learnings
Story
Cards
Milestone
Planning
Milestone
Meeting
2 Eng
2 Eng
Execs
Roadmap
Epics
Epics
Epics
VP of Eng
Spike
Learnings
UX
PM
UX
Dir of PM
PM
Customer
Outputs
Story
Cards
Epics
Epics
Business
Request
Spikes
Story
Cards w/
Dod

30. Year 6 (aka Now) - Agile XP
Story
Cards w/
Dod
Roadmap
Epics
Epics
Epics
Inputs
Sprint
Planning
UX
PM
Outputs
Frontend
Systems
Story
Cards w/
Dod
2 Week
Commit
UX
Dev Ops
Backend
Sprint
Radiator
Epics
Epics
Epics
PM
Frontend
Systems
Dev Ops
Backend
Product
Features

31. Year 6 (aka Now) - Agile XP
Frequency
Visioning/Roadmap
Every 2 Weeks
Iteration Planning
Every 2 Weeks
Daily Planning
Daily
Feedback
Retro’s Every 2 Weeks
Demos Every Week
Stability/
Predictability
Average
Engineers
12
Product 2
Design 1
Business
80

32. Six Years and Six Processes
4 Key Learnings and Take-Aways
1
Processes Evolve
with the Business
You can’t expect a process that
works at 3 people, work when the
organization is also 80 people.
!
The process needs to change as the
business needs change.
2
Retros are a Must
Retrospectives are an essential
element to successfully evolve a
team’s process.
3
Culture of Change
Create a culture for process
change from the start. Enact
process change very swiftly but
with very detailed plans.
4
No Process is
Perfect
Every process will have it’s
inefficiencies, it’s all about what
is best for your business and
where you want spend the time
resolving those inefficiencies.

33. Thank you.
@robfan
@robslifka