- As the startup grew from 2 to 15 people, they implemented Scrum processes like daily standups and sprint retrospectives to improve communication and collaboration across teams. - Key roles like product manager and architect were added to plan features further out while engineers focused on the next 1-2 sprints. - Processes were established for ideas to move from roadmap to development to production, including backlog grooming, epic and sprint planning, and end of sprint demos. Frequent meetings helped align teams working on interdependent features. - Continuous improvement of processes and tools helped support the growing product complexity and multiple teams across timezones needed for large enterprise customers.

1. alikhajeh
Feb 2018, Silk Road Startup
Scrum and Agile:
Experience growing from 2 to 15 people
Ali Khajeh-Hosseini

2. I’m here to talk about...
a few things I learned trying
agile software development and scrum
when growing a 2-person startup
to 15 people.

3. Scrum
Image taken from http://edelalon.com/blog/2017/09/scrum/

5. - Before our first startup:
- Ali PhD in cloud computing
- Hassan consultant in Accenture
- Alistair software eng in startups
- 1st startup 6 years ago: PlanForCloud
- Acquired by RightScale in California
- Alistair was our first team mate
- 2nd startup (AbarCloud): Oct 2016
- Aram was our first team mate
Our background

6. Our approach
Start with minimal processes/tools.
Use end of sprint retro to change things.
Keep iterating and improving process/tools.

7. Starting up
We both did a bit of everything,
one focused on building it,
one focused on getting users.

8. Keep it simple

9. Roles: growing to 4 people
A software engineer and designer joined the team.
I spent more time on pairing/reviewing, and hiring.
Hassan spent more time with users and thinking
ahead.

10. Process/tools: growing to 4 people
Started having:
- sprint planning meeting
- daily scrum meeting
- sprint retro meeting

11. Roles: 6 people
Our role changed from
describing what we should do next to
explaining the problem and
setting the context
and letting the team come-up with solutions

12. Process/tools: 6 people
Started using a wiki (product requirements, customer interviews,
meeting minutes, technical designs… everything)
Created a Continuous Integration env for unit tests and
integration tests. Helped us ship faster with more confidence.

13. New challenges
We pivoted from selling to startups to large enterprises, whos buying cycles took 6-18
months. Some of their challenges weren’t solved by our current product but their
cheques and timelines were large enough that we could promise them features we
didn’t have.
Product was growing in complexity, due to load and number of systems involved. Big
changes needed thinking/investigation/planning time.
Had multiple teams, across timezones. Communication was challenging.

14. Growing to 15 people
Product Manager to look at the next 3-6 months in detail.
Architect & designer to look at the next 2 months in detail.
Needed a process for features from product to production.
Design 2 sprints in detail.
Commit to 1 sprint and communicate it to other teams.

15. Process: 15 people
Multiple teams with overlaps, but different focuses
Product-to-production workflow
Weekly backlog grooming meetings
Weekly front/back-end meetings
Product roadmap meetings
TechTalks
End of sprint demos
Lots of new tools

16. Life of a feature
Roadmap vision features: features we’re looking at building, but haven’t been designed in a wiki.
Product iTimes: features being worked on by during “iTime” projects.
In Design: features that have been designed in the wiki, but haven’t been implemented.
In Development: features currently in dev/test, and will be released soon.
Live for employees: features visible to employees only.
Live for private-beta users: features visible to private-beta or selected users.
Live for all users: shipped!

17. Backlog grooming: PM, Scrum Master & Architect discuss features on roadmap. PM
writes a wiki for the ones that are next priorities.
Kick-off meeting: everyone to get a heads up of what’s coming from PM.
Epic planning: Features spanning 2 sprints or more. Highlights order of stories coming
into sprints. Gives investigation time.
Sprint planning: PM & designer need to be available for any questions. Usually 1 day
per 2 week sprint.
End of sprint demos: open to everyone in team, work in progress is OK.
Product to production workflow

18. Product + Design + Engineering = Love
Neither of them has the full solution.
They need to work together as partners to come up with solutions.
Do not “chuck things over the wall”. Causes friction
and slows things down.
Image taken from http://dev2ops.org/2010/02/what-is-devops/

19. Summary
Start with minimal processes/tools.
Use end of sprint retro to change things.
Keep iterating and improving process/tools.

20. Visit AbarCloud.com if you’d like a free trial to see
how easy it is to deploy and automate your systems.
Email: ali@abarcloud.com
Twitter: @alikhajeh