Divergent Evolution and Evolution by the Birth-and-Death Process in
Sharethrough's process evolution
-
Upload
robert-fan -
Category
Technology
-
view
221 -
download
3
description
Transcript of Sharethrough's process evolution
Evolution of Sharethrough’s Product Process
From 2008 to 2013
The Sharethrough PlatformPowering Advertising For the Modern Web
Sharethrough supports all types of digital content
Distributing your content in the “newsfeeds" of the Modern Web
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
Our Methodologies Over the Years
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.
Year 1 “Cowboy’ing it”
1st Phase of Vision Build Cycle 1
2nd Phase of Vision Build Cycle 2
Year 1 - “Cowboy’ing it”In Theory
1st Vision Build Cycle 1
2nd Vision
3rd Vision. . .
nth Vision
Year 1 - “Cowboy’ing it”In Reality
Frequency
Visioning/Roadmap Daily
Iteration Planning None
Daily Planning Sporadic
Feedback None
Stability/Predictability None
Business 3
Engineers 3
Year 1 - “Cowboy’ing it”
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)(
Scrum$Master$• Burn(Down(Charts(• Remove(Impediments(
Delivery$Team$• EsCmates(of(Work(Remaining(
Product$Owner$• Looking(Ahead(w/(Business(• Adding(stories(&(acceptance(criteria(
Daily(Roles(
After hours of reading, attending Scrum school, I summarized all my learnings in a series of slides to the entire company (a whooping 8 people). This a slide taken from presentation given on April 24, 2009.
Year 2 Agile Scrum
Year 2 - Agile Scrum
http://en.wikipedia.org/wiki/Scrum_(software_development)
24 hrs
2 weeks
Database/Backend
Frontend
Testing
Deployment
Year 2 - Agile ScrumIn Theory
Database/Backend
Frontend
Testing
Deployment
Year 2 - Agile ScrumIn Reality
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
Year 2 - Agile Scrum
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.
Year 3 DIY XP
Testing
Full-Stack
Deployment
Year 3 - DIY XPIn Theory
Testing
Full-Stack Development
Deployment
TDD without experience slowed productivity down and made deployment extremely brittle
In Reality
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 3
Product 1
Engineers 3
Year 3 - DIY 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”.
Year 4 “Pivotal XP”
Pivotal Tracker
Pivotal Tracker
Pivotal Tracker
User Stories
Pivotal Tracker
Test
Code RefactorPair Up
Year 4 - Pivotal XPIn Theory
Year 4 - Pivotal XPIn Reality
Pivotal Tracker
Pivotal Tracker
Pivotal Tracker
User Stories
Pivotal Tracker
Test
Code RefactorPair Up
With the right discipline this methodology worked for us.
Frequency
Visioning/Roadmap Every 3 Months
Iteration Planning Every Week
Daily Planning Daily
Feedback Weekly Retro’s
Stability/Predictability High
Business 10 Product
1
Engineers 5
Year 4 - Pivotal XP
A former Shaethrough Product Manager presents Mission Control to key business stakeholders.
Year 5 Balanced Team Experiment
Year 5 - Balanced Team Experiment
Year 5 - Balanced Team ExperimentMission Control
Year 5 - Balanced Team ExperimentStakeholder Meeting - Identifying “Problems”
User Stories
Eng PM
UX XP Process
Year 5 - Balanced Team ExperimentIn Theory
Design Studio
Year 5 - Balanced Team Experiment
User Stories
Eng
PM
UX
XP Process
Design Studio
In Reality
Frequency
Visioning/Roadmap Every Week
Iteration Planning Every Week
Daily Planning Daily
Feedback Weekly Retro’s
Stability/Predictability Average
Business 50
Engineers 8
Product 2
Design 1
Year 5 - Balanced Team Experiment
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.
Year 6 (aka Now)
Agile XP
Year 6 (aka Now) - Agile XP
Epics
Roadmap Review
EpicsEpicsEpics
Roadmap
Milestone Meeting
Milestone Planning
Epics
Story Cards
Story Cards w/
Dod
Story Cards
Spikes
Spike Learnings
Execs
Dir of PMVP of Eng
Inputs
Outputs
2 Eng
PMUX
Customer
Business Request
2 Eng
PMUX
Epics
Cust Dev Cust DevLearnings
Year 6 (aka Now) - Agile XP
Inputs
Outputs
Frontend
PM
UX
Backend
Dev Ops
Systems
EpicsEpicsEpics
Roadmap
Sprint Planning
EpicsEpicsEpics
Sprint Radiator
Story Cards w/
Dod
Frontend
PM
UX
Backend
Dev Ops
Systems
2 Week Commit
Story Cards w/
Dod
Product Features
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
Business 80
Engineers 12
Product 2
Design 1
Year 6 (aka Now) - Agile XP
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.
Culture of Change
Create a culture for process change from the start. Enact
process change very swiftly but with very detailed plans.
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.
Retrospectives are an essential element to successfully evolve a
team’s process.
Six Years and Six Processes4 Key Learnings and Take-Aways
Retros are a Must1 2 3 4
Thank you.@robfan
@robslifka